Session Handoff
Writes the state of the current work thread into a file the next session can start
from — because answer quality degrades well before the context window is full, and
a deliberate, writer-controlled handoff beats automatic summarization.
A handoff is the state of the task + instructions for the next executor — never
a chronology of this session.
Files
- Name:
HANDOFF_<slug>.md in the project root. Slug = issue number + short
topic (HANDOFF_237_deploy.md) or topic alone (HANDOFF_pricing_banner.md) —
readable at a glance, since several handoffs may coexist for parallel work threads.
- One live handoff per work thread, updated in place. No date-stamped copies.
- Git hygiene: immediately add the filename to
.git/info/exclude (never
.gitignore, never stage, never commit). Before any staging of adjacent files,
git check-ignore -v the handoff. Not a git repo → skip this step.
- Delete the file when its task is fully closed (confirm with the user first).
Invocation
/handoff — no args: if exactly one handoff matches the session's current work
thread, update it; none → create; several plausible → ask which one.
/handoff <slug|issue|topic> — explicit target.
- Mid-session "add X to the handoff" — add X to the relevant section now, verbatim
in meaning. Items the user explicitly names ("make sure X is in") MUST land in
the file.
- "Is the handoff current?" — reread the file, diff it against the real session
state, fix every stale point, then confirm.
Structure
# Handoff: <issue #N / topic> — <last updated>
Branch: <branch> @ <short-hash> | Source session: <session id, best effort>
## NEXT
<the new session's concrete first step; then a numbered plan, WHAT-level>
## State / Result
<result first, with numbers where they exist; then git: commits with hashes,
pushed/NOT pushed, what to commit / what NOT, how to restore anything deleted>
## Done
<one terse block per closed stage: hash, essence, who reviewed,
what was consciously deferred (follow-up, not pre-merge)>
## Ruled out — do not reopen
<dead ends and dropped hypotheses WITH THE REASON they are dead ends>
## Don't forget
<env gotchas, sharp details, runnable commands with checkpoints
to verify the environment is alive>
## Artifacts
<issue/PR/ADR URLs, key files with their role; durable knowledge — as a link
to a reference doc or memory, never as a copy>
## Open questions
<decision points AS QUESTIONS — or an explicit "None">
Empty sections are dropped. Language of the file = language of the conversation.
Session id: try $CLAUDE_SESSION_ID; else newest .jsonl in
~/.claude/projects/<project-slug>/; parallel sessions make that ambiguous — omit
rather than guess. It lets the next session pull details via claude --resume <id>
without loading the whole transcript.
Content rules
- WHAT, not HOW. No step-by-step investigation plans ("1. Read X, 2. Grep Y"),
no solution proposals as conclusions, no risk/effort forecasts. Strip markers:
"should probably…", "I recommend…", "likely root cause…", "the next session
must…". This session's dead ends and wrong mental models must not be
transplanted. Allowed: repro steps, symptoms/facts, what was tried and excluded
(with numbers), decision points as questions.
- Result first. "What we achieved + numbers", never "what we did". If the user
shared measurements/screenshots this session, their essence goes in.
- Negative knowledge is first-class. What was ruled out and WHY — it stops the
next session from re-digging.
- Reference, don't duplicate. Durable domain knowledge belongs in a reference
doc / project memory; the handoff links to it.
- Record divergences between the file's assumptions and reality when you notice
them (e.g. manual edits outside the branch) — the next session must know.
Live-document behavior
- Creation — only when the user asks. Updates of an EXISTING file: on request, and
proactively right after a stage completes (collapse the stage's detailed plan into
a short "Done" block with hashes; announce in one line).
- After writing, reread the file once and strip anything violating the content
rules before reporting done.
1---2name: handoff3description: Create or update a session handoff file so a fresh session continues seamlessly where this one stopped. Triggers: "/handoff", "make a handoff", "update the handoff", "add to the handoff", "is the handoff current?", "зроби хендоф", "онови хендоф", "запиши в хендоф" (add triggers in your own language). Create ONLY on explicit request (never unprompted); once the file exists, keep it current through the session. Universal across projects. Counterpart: /pickup reads the file in the new session.4---56# Session Handoff78Writes the state of the current work thread into a file the next session can start9from — because answer quality degrades well before the context window is full, and10a deliberate, writer-controlled handoff beats automatic summarization.1112A handoff is **the state of the task + instructions for the next executor** — never13a chronology of this session.1415## Files1617- **Name:** `HANDOFF_<slug>.md` in the project root. Slug = issue number + short18 topic (`HANDOFF_237_deploy.md`) or topic alone (`HANDOFF_pricing_banner.md`) —19 readable at a glance, since several handoffs may coexist for parallel work threads.20- **One live handoff per work thread, updated in place.** No date-stamped copies.21- **Git hygiene:** immediately add the filename to `.git/info/exclude` (never22 `.gitignore`, never stage, never commit). Before any staging of adjacent files,23 `git check-ignore -v` the handoff. Not a git repo → skip this step.24- Delete the file when its task is fully closed (confirm with the user first).2526## Invocation2728- `/handoff` — no args: if exactly one handoff matches the session's current work29 thread, update it; none → create; several plausible → ask which one.30- `/handoff <slug|issue|topic>` — explicit target.31- Mid-session "add X to the handoff" — add X to the relevant section now, verbatim32 in meaning. Items the user explicitly names ("make sure X is in") MUST land in33 the file.34- "Is the handoff current?" — reread the file, diff it against the real session35 state, fix every stale point, then confirm.3637## Structure3839```markdown40# Handoff: <issue #N / topic> — <last updated>41Branch: <branch> @ <short-hash> | Source session: <session id, best effort>4243## NEXT44<the new session's concrete first step; then a numbered plan, WHAT-level>4546## State / Result47<result first, with numbers where they exist; then git: commits with hashes,48pushed/NOT pushed, what to commit / what NOT, how to restore anything deleted>4950## Done51<one terse block per closed stage: hash, essence, who reviewed,52what was consciously deferred (follow-up, not pre-merge)>5354## Ruled out — do not reopen55<dead ends and dropped hypotheses WITH THE REASON they are dead ends>5657## Don't forget58<env gotchas, sharp details, runnable commands with checkpoints59to verify the environment is alive>6061## Artifacts62<issue/PR/ADR URLs, key files with their role; durable knowledge — as a link63to a reference doc or memory, never as a copy>6465## Open questions66<decision points AS QUESTIONS — or an explicit "None">67```6869Empty sections are dropped. Language of the file = language of the conversation.70Session id: try `$CLAUDE_SESSION_ID`; else newest `.jsonl` in71`~/.claude/projects/<project-slug>/`; parallel sessions make that ambiguous — omit72rather than guess. It lets the next session pull details via `claude --resume <id>`73without loading the whole transcript.7475## Content rules7677- **WHAT, not HOW.** No step-by-step investigation plans ("1. Read X, 2. Grep Y"),78 no solution proposals as conclusions, no risk/effort forecasts. Strip markers:79 "should probably…", "I recommend…", "likely root cause…", "the next session80 must…". This session's dead ends and wrong mental models must not be81 transplanted. Allowed: repro steps, symptoms/facts, what was tried and excluded82 (with numbers), decision points as questions.83- **Result first.** "What we achieved + numbers", never "what we did". If the user84 shared measurements/screenshots this session, their essence goes in.85- **Negative knowledge is first-class.** What was ruled out and WHY — it stops the86 next session from re-digging.87- **Reference, don't duplicate.** Durable domain knowledge belongs in a reference88 doc / project memory; the handoff links to it.89- **Record divergences** between the file's assumptions and reality when you notice90 them (e.g. manual edits outside the branch) — the next session must know.9192## Live-document behavior9394- Creation — only when the user asks. Updates of an EXISTING file: on request, and95 proactively right after a stage completes (collapse the stage's detailed plan into96 a short "Done" block with hashes; announce in one line).97- After writing, reread the file once and strip anything violating the content98 rules before reporting done.