القائمة
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.