# Handoff

> Draft a cold-start prompt for a manually operated Claude Code session. Use when the user asks for a handoff, continuation prompt, or something to copy and paste into Claude Code, not when the active agent should ask Claude to review or implement the work.

- Skill: `epicenterhq/handoff` (Agent Skill)
- Install (CLI): `npx skillmds@latest add epicenterhq/handoff`
- Raw SKILL.md: https://api.skillmd.com/api/skills/epicenterhq/handoff/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: epicenterhq (https://skillmd.com/u/epicenterhq)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/epicenterhq/handoff

---


# Claude Code Handoff

Write one prompt the user can paste into a fresh Claude Code session. This
skill is a transport fallback: it never launches Claude and never supervises
execution. Return only the prompt. If the user is designing or reviewing the
handoff itself, a short note before it is fine.

The recipient cannot see this conversation. Everything it needs in order to
think from the same reality has to be in the prompt, and everything else is
noise.

Claude leads the mission and chooses its verification. Codex is an optional
`/codex:rescue` capability for a bounded need, not a default supervisor or
decision-maker.

## Ground it first

Look before writing. For coding work that usually means:

```bash
git status --short --branch
git diff --name-status
git diff -- <relevant paths>
```

Then read the files, tests, specs, ADRs, or logs the prompt will point at, and
note which commands have already been run and whether they passed. For
non-coding work, gather the equivalent source material. Skip the grounding pass
only for something obviously small.

## Write it

Carry the mission and the artifact wanted, the live state, the exact paths
worth opening first, what you currently believe and why, and what is still open
for the recipient to decide or re-check.

Two things are easy to leave out and expensive to lose: the evolution that
explains the current direction (what the user reacted to, what was tried and
dropped), and what the user will recognize as right beyond a passing test run.

Name real hazards: dirty user work, destructive git, deploys, migrations,
security, licensing boundaries, dead paths to avoid, explicit non-goals. Leave
out hazards that are merely conceivable.

Let length follow the mission. A small handoff is 12 to 20 dense lines; an
ambitious one runs as long as it needs to. Cut transcript bulk, not the
reasoning that got you here.

Say that Codex is available through the literal `/codex:rescue` command, since
"Codex" alone does not name the command. For substantial work, suggest a couple
of concrete seams (a diff to excavate, a wave to implement, a verification to
run), and say plainly that they are examples.

## The posture that makes it work

Prefer current read over settled decision. Prefer watch-out over prohibition.
Prefer candidate seam over commandment.

The recipient is picking the work up, not executing a script. It should be free
to reread the code, disagree with your conclusions, throw out the plan, and
choose its own delegation shape. Say what you think is true and why, and do not
promote that to settled unless an ADR, a code path, or an explicit user
decision made it settled.

Close with the likely verification commands or evidence targets, and with what
counts as done: a review memo, a PR-ready diff, a clean implementation branch,
a verified command set, or a blocker list with the smallest remaining
decisions.

For a one-line `/goal`, use [agent-goal](../agent-goal/SKILL.md). A progress
summary for the user is an ordinary response grounded in branch and session
state, not a handoff artifact.