handover

/handover — deliberate session handover

You are about to do a clean session handover. Don't /clear yet; the user will do that after the handover file is written.

Invocation — /handover vs /handover ok

If the command was invoked with the argument ok (case-insensitive — ok, OK, Ok all count), run the flow with the proposed default buckets and no confirmation prompt — but NOT silently. Specifically, in this order:

1. Draft the eight coordinates (Step 1) internally. You do not need to print the long-form draft.
2. Print the Step-2 triage summary table — the compact N. [bucket] item list, defaults already filled in, in the exact format the interactive flow uses (see Step 2). Show it BEFORE acting on or writing anything. This is the recap the user reacts to: because it lands before any M/D/X action or file write, the user can scan it and hit Esc to interrupt and correct course if a bucket is wrong.
3. Do NOT pause for triage adjustments and do NOT ask for confirmation. After printing the table, continue straight on in the same turn — act on the M, D, and X items (Step 3), write the handover file (Step 4), and report (Step 5).

The only pauses still permitted are the deliberate-action confirmations in Step 3 for outward-facing or hard-to-reverse X items (commits, pushes, deletes, sends) — those are never auto-run off defaults.

Otherwise (plain /handover), run the full interactive flow below: present the draft, take the user's triage adjustments, then act.

Step 1 — draft the eight coordinates

Without reading any new files, draft the handover by filling in the sections below from your conversational context. Be concrete and specific — "Discussed the rewrite" is weak; "Agreed lesson 5 opens at the gateway-ASIN question; AMC source still unsourced" is right.

1. Goal — What are we trying to accomplish? One or two sentences naming the objective and why it matters.
2. What was tried — What approaches were explored this session, especially any that failed or were abandoned and why.
3. Decisions & constraints discovered — Choices that were made ("X over Y because Z") and constraints that surfaced ("the API doesn't support batch mode") that aren't captured in code or git history.
4. Recent changes — What was actually modified this session. Concrete: file paths, what changed in each, commit hashes if any.
5. Files in flight — Files still being actively edited or that have uncommitted changes.
6. Next steps — What to do next, in priority order. Note blockers inline ("step 3 is blocked on user confirming the schema").
7. User preferences — Working-style signals that surfaced this session: communication preferences, conventions the user corrected you on, patterns they validated. Only things the next session's Claude would otherwise have to re-learn.
8. Other context — Anything that doesn't fit the sections above but would be useful to the next session: half-formed hypotheses, anomalies noticed but not pursued, tangential observations.