handofflisted

## The One Principle **Write only what the next session cannot recover by reading the repo.** The next session is a capable agent with full access to the code, the docs, the git history, and the GitHub API. It will explore on its own. Anything it can find by reading a file is noise in the handoff — it costs tokens, and worse, a stale restatement of a file competes with the file itself. What it *cannot* recover by reading: - **Decisions and their reasons** — the code shows what was chosen, never why, nor what was rejected. - **Dead ends** — an approach that was tried and abandoned leaves no trace in the repo, so the next session will happily retry it. - **Constraints stated by the user** — preferences, scope boundaries, "don't touch X". - **The next action** — what to do first, which the repo cannot tell it. That is the entire content of a handoff. Everything else is a session recap, and a session recap is not a handoff. Test every line before writing it: *"Could the next session learn this by opening a file?"* If yes, delete it and reference the path instead. ## Parse Arguments | Argument | Type | Description | |----------|------|-------------| | `topic` | Optional string | Focus filter — scope the handoff to this topic only (e.g., `/handoff auth 리팩토링`) | | `-y` | Optional flag | Skip the draft step and output the handoff directly | If `$ARGUMENTS` contains `-y`, treat it as the skip flag; the remaining text is the topic filter. If `$ARGUMENTS` is empty, scope the ha