메뉴
Resume work from the most recent handoff. Finds the active handoff under .scratch/ by frontmatter, verifies the git baseline still matches, then executes its 开机动作序列. Use at the start of a new session to continue a multi-session task without hunting for the handoff file.
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 | resume |
| description | Resume work from the most recent handoff. Finds the active handoff under .scratch/ by frontmatter, verifies the git baseline still matches, then executes its 开机动作序列. Use at the start of a new session to continue a multi-session task without hunting for the handoff file. |
| argument-hint | Feature slug (optional; omit to use the latest active handoff) |
The inverse of /handoff — locate the active handoff, verify its baseline, continue from its 开机动作序列.
Handoffs live under .scratch/ (feature-scoped .scratch/<feat>/handoff.md or cross-feature
.scratch/handoff.md); frontmatter per ARTIFACT-FORMAT.md.
/resume — locate the most recent status: active handoff and continue from it./resume <feat> — continue from .scratch/<feat>/handoff.md.CLAUDE.md §6 loads the orientation layer at session start, before /resume runs. So /resume only
layers a handoff on top — don't re-load or re-explore what orientation already gave you.
/resume <feat> → read .scratch/<feat>/handoff.md./resume (no arg) → scan .scratch/**/handoff.md for status: active and pick the newest by
date (tie-break on file mtime). If none is active, tell the user there's nothing to resume and
stop — do not resume a consumed handoff without explicit confirmation. (Step 0 has already run,
so even with no handoff the session is oriented — say so rather than leaving the user
empty-handed.)Compare the handoff's git_base against current git rev-parse --short HEAD.
git log --oneline <git_base>..HEAD so they can see what changed, then ask whether to proceed.
The handoff's "关键口径清单" may be stale relative to those commits.Also check working-tree cleanliness; if dirty, surface git status briefly before acting.
Read the handoff's six sections. Section 5 (开机动作序列) is the script: read the listed files, run the listed commands, confirm the stated first decision. Section 4 (关键口径清单) is the load-bearing context — treat those decisions and invariants as binding. Don't re-explore what the handoff already decided; that's the whole point of the document.
If the handoff names a feature, also glance at .scratch/<feat>/INDEX.md row and any
status: ready-for-* issues so you know the live working set.
Once the work reaches a natural stopping point (issue done, or the user starts something else),
set the handoff's frontmatter status: to consumed. If the session itself runs long and needs a
fresh handoff, write a new one via /handoff (overwriting the same rolling file).
Do not mark consumed mid-task — only when the bridge has served its purpose.