메뉴
Compact the current conversation into a handoff document for another agent to pick up. Use before /clear, when context is nearly full, or to checkpoint a long multi-session task.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/.
Test-driven development with red-green-refactor loop. Four invocation forms — `/tdd <issue-path>` runs one issue (mode chosen by frontmatter `status:`); bare `/tdd` drains every ready-for-agent issue serially in dependency order; `/tdd <feat>` drains just that feature; a natural-language ask without an issue falls back to interview-driven flow. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
Two-axis review of the diff since a fixed point (commit, branch, tag, merge-base) — Standards (house coding standards + a Fowler code-smell baseline) and Spec (does the diff faithfully implement the originating issue / PRD?). Runs the two axes as parallel sub-agents so neither pollutes the other, then reports them side by side. Use when the user wants to review a branch / PR / work-in-progress, asks to "review since X", or when an orchestrator (e.g. /ship) needs a pre-merge gate.
Resolve an in-progress git merge or rebase conflict by understanding each side's original intent, then preserving both where possible. Use when a merge/rebase is mid-conflict, when the user asks to resolve conflicts, or after a /ship merge-back was aborted and they want to finish the merge by hand.
Orchestrate a feature's ready-for-agent issues to completion. Reads the dependency DAG from frontmatter, topologically sorts, dispatches independent issues to subagents running /tdd (same-module work serialized, cross-module parallelized), enforces a build+test verification gate before each commit, and collects ready-for-human issues into a hands-on checklist.
Break a plan, spec, or PRD into independently-grabbable issues using vertical slices. For a change that touches existing code, first runs an impact-detection pass (blast radius + regression risk) before slicing. When a PRD is re-run after revision, produces a reconciliation report against existing issues (kept / redo / edit / delete / new).
| name | handoff |
| description | Compact the current conversation into a handoff document for another agent to pick up. Use before /clear, when context is nearly full, or to checkpoint a long multi-session task. |
| argument-hint | What will the next session be used for? |
Write a minimal recoverable snapshot so the next session can continue from the current node by reading this one file. This is not a conversation summary — extract current state, key decisions, and next actions. Discard exploration; preserve decisions.
Per the layout in the ship / to-issues skills' ARTIFACT-FORMAT.md:
.scratch/<feat>/handoff.md (rolling — overwrite in place each time; git keeps history). Lives next to that feature's PRD and issues so it never gets lost..scratch/handoff.md (a single rolling file at the .scratch/ root).Do not use the OS temp directory — it gets cleared between sessions. If not inside a git repo, fall back to the working directory root.
Every handoff carries YAML frontmatter:
---
type: handoff
feature: balance # the feature slug, or null for cross-feature work
git_base: 3451766 # `git rev-parse --short HEAD` at write time
status: active # active when written; /resume flips it to consumed
date: 2026-06-18
---
Content already captured elsewhere (PRDs, plans, ADRs, issues, commits, diffs) — reference by path or URL, do not copy the body.
Remove any sensitive information: API keys, passwords, tokens, PII.
# Handoff: <topic> (<date>)
## 1. 当前状态
Where we are + key artifact paths and their status. One sentence that tells someone "how far we got".
## 2. 基线
git HEAD (commit hash), working directory cleanliness, key file list relevant to this work.
If this work changed the **shape** of a module (moved a seam, introduced/removed an invariant, altered
how things wire up), the `CODEBASE.md` section for that area is now stale — refresh it via `/zoom-out`
before handing off, or note here that it needs refreshing, so the next session's session-start load
(which compares each section's `git_base` to HEAD) hands over a map aligned with the code, not one a
commit behind. Skip this if the work touched no structure — don't run `/zoom-out` for its own sake.
## 3. 下一步分叉
Candidate options for the user / next session to decide (A / B / C) with tradeoffs. If the path is already decided, state the next concrete step.
## 4. 关键口径清单 ⭐
Decisions and invariants that must survive across sessions. Each entry includes a "why".
This is the core value of the document — exploration can be discarded, decisions cannot.
- Decision: … | Why: …
- Invariant: … | Why: …
## 5. 开机动作序列
First ordered actions after /clear (which files to read, which command to run, what to confirm first).
## 6. 明确不写的
What was actively discarded (dead-end explorations, failed approaches) — let the user do a final scan to confirm nothing critical was dropped.
## Suggested skills
Skills appropriate for the next session (e.g. `/tdd`, `/diagnose`, `/grill-with-docs`), one sentence each on why.
Section 4 is the core. If the user passed arguments, treat them as the focus of the next session and tailor the document accordingly.