Resume Session
Load a handoff document, verify it is still accurate, and resume where the
previous session left off.
Available handoffs
!ls -1t handoffs/*.md 2>/dev/null | head -10
If no handoffs are listed above, tell the user there are no handoff documents
to resume from and suggest creating one with /handoff at the end of a
session.
Which handoff to load
If arguments are provided ($ARGUMENTS), read the matching file from those
listed above. Accept either the full filename or a partial match. If no match
is found, list the available handoffs and ask the user to specify.
If no arguments are provided, read the most recent handoff (first file listed
above).
Resume process
After reading the handoff document:
Verify against reality — Treat the handoff's "Current State" as a
claim, not a fact. The codebase may have changed since it was written
(another session, a merge, manual edits). Check for drift:
- If the project is a git repository (
git status succeeds), run
git log --oneline --since="<handoff date>" and git status to see
commits and uncommitted changes made after the handoff.
- If it is not a git repository, compare file modification times against
the handoff file instead:
find . -newer <selected-handoff-path> -type f -not -path "./handoffs/*" -not -path "./.claude/*" -not -path "./.codex/*" -not -path "./node_modules/*" -not -path "./.git/*"
- If drift is found, flag it explicitly in the summary and prefer the
actual state of the files over the handoff's description wherever they
disagree.
Review key files — Read each file listed in "Files to Review on Resume"
to rebuild context from the code.
Check the chain — If the handoff has a "Previous Session" reference
with live carryover, note it.
Present a brief summary:
- Where we left off (current state from the handoff)
- Any drift detected between the handoff and the actual codebase
- The immediate next step
- Any blockers, open questions, or warnings
Confirm and proceed — Confirm understanding in 2-3 sentences, state
the first next step, then proceed with it unless the user redirects. If
significant drift was detected, or the handoff is more than a few days
old, pause and ask the user to confirm the next step is still the right
one before starting work.
Exceptions — do not proceed automatically:
- If the first next step is marked (user), it is an action only the
user can perform. Prompt the user to do it (or to skip to the next
Claude-executable step) instead of attempting it.
- If the handoff lists Possible Directions instead of Next Steps, the
previous session ended with direction deliberately undecided. Present
the candidate directions as choices and wait for the user to pick one.
Keep the summary concise. The goal is to get productive immediately, not to
restate the entire handoff document.
1---2name: resume-23description: Resume work from the most recent handoff document. Reads the handoff, verifies it against the current state of the codebase, summarises where things stand, and continues from the next step.4---56# Resume Session78Load a handoff document, verify it is still accurate, and resume where the9previous session left off.1011## Available handoffs1213!`ls -1t handoffs/*.md 2>/dev/null | head -10`1415If no handoffs are listed above, tell the user there are no handoff documents16to resume from and suggest creating one with `/handoff` at the end of a17session.1819## Which handoff to load2021If arguments are provided ($ARGUMENTS), read the matching file from those22listed above. Accept either the full filename or a partial match. If no match23is found, list the available handoffs and ask the user to specify.2425If no arguments are provided, read the most recent handoff (first file listed26above).2728## Resume process2930After reading the handoff document:31321. **Verify against reality** — Treat the handoff's "Current State" as a33 claim, not a fact. The codebase may have changed since it was written34 (another session, a merge, manual edits). Check for drift:35 - If the project is a git repository (`git status` succeeds), run36 `git log --oneline --since="<handoff date>"` and `git status` to see37 commits and uncommitted changes made after the handoff.38 - If it is not a git repository, compare file modification times against39 the handoff file instead:40 `find . -newer <selected-handoff-path> -type f -not -path "./handoffs/*" -not -path "./.claude/*" -not -path "./.codex/*" -not -path "./node_modules/*" -not -path "./.git/*"`41 - If drift is found, flag it explicitly in the summary and prefer the42 actual state of the files over the handoff's description wherever they43 disagree.442. **Review key files** — Read each file listed in "Files to Review on Resume"45 to rebuild context from the code.463. **Check the chain** — If the handoff has a "Previous Session" reference47 with live carryover, note it.484. **Present a brief summary:**49 - Where we left off (current state from the handoff)50 - Any drift detected between the handoff and the actual codebase51 - The immediate next step52 - Any blockers, open questions, or warnings535. **Confirm and proceed** — Confirm understanding in 2-3 sentences, state54 the first next step, then proceed with it unless the user redirects. If55 significant drift was detected, or the handoff is more than a few days56 old, pause and ask the user to confirm the next step is still the right57 one before starting work.5859 **Exceptions — do not proceed automatically:**60 - If the first next step is marked **(user)**, it is an action only the61 user can perform. Prompt the user to do it (or to skip to the next62 Claude-executable step) instead of attempting it.63 - If the handoff lists **Possible Directions** instead of Next Steps, the64 previous session ended with direction deliberately undecided. Present65 the candidate directions as choices and wait for the user to pick one.6667Keep the summary concise. The goal is to get productive immediately, not to68restate the entire handoff document.