菜单
Edit a single proposal.md section (why / what / how / risk). A full rewrite goes through $spec-propose. After editing, the HARD GATE must run again.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Interrogates preference-driven decision points. Works through each [TBD] in research.md one by one as numbered plain-text questions; answered items are moved to
Spec-driven development workflow overview. Load this skill when the user says "spec this first / draft a proposal / design first / write a proposal", or when a task is >150 lines / spans 3+ files / introduces a new dependency / involves an architecture choice — to learn the sdd plugin's 11 commands, artifact map, and Shared Principles (HARD GATE / interrogation / Stuck Protection / Anti-Cheating).
Implement the code, advancing by proposal/tasks. A pre-command hook checks that proposal.md carries the required prerequisites. Incremental verification: call $spec-verify close to each node as it lands, don't save it all for the end.
Dispatches a researcher agent to survey industry practices and key constraints, writing findings into research.md (single file; Open[TBD]/Decided maintained as before). Changing direction = snapshot the current research.md into the research/ discarded-draft pile first, then overwrite with the new direction; old drafts can be resurrected at any time.
Verifies the current change by dispatching the independent spec-verifier agent (fresh context — the implementing conversation never audits itself) across three dimensions + charter audit. Every run updates the verification ledger spec/changes/<name>/verify.md (stable finding IDs + round diffing + unfixed-escalation). Can be re-run independently.
Archives the current change to spec/archive/YYYY-MM-DD-<name>/. Only invoked when the user explicitly says "archive". Writes an archive-stage retrospect, checks for uncommitted code, and is guarded by the check-archive hook.
| name | spec-revise |
| description | Edit a single proposal.md section (why / what / how / risk). A full rewrite goes through $spec-propose. After editing, the HARD GATE must run again. |
Target section: $ARGUMENTS
| Parameter | Section edited |
|---|---|
why | ## Why |
what | ## What |
how | ## How |
risk | ## Risk |
| none | ask the user which section to edit by presenting numbered options: "Which section to edit? 1) why 2) what 3) how 4) risk" |
spec/changes/<name>/proposal.md, locate the target section<!-- APPROVED: ... --> approval marker (any revision invalidates the old approval)Any revision must pass through the HARD GATE again:
<HARD-GATE>
=== Proposal revised (<section>) ===
Path: spec/changes/<name>/proposal.md
Changes — same explanation layer as propose's gate, scoped to the edit:
<the revised decision in one plain sentence>
Scenario: <what concretely goes wrong without it> / Avoided by: <plain words> / Cost: <the price>
(never paste the proposal line verbatim; define domain terms at first use)
(the old APPROVED marker has been removed)
Next:
✅ Looks good → run $spec-apply to start implementing
apply will automatically append the new <!-- APPROVED: ... --> marker
🔧 Edit another section → $spec-revise [why | what | how | risk]
💭 Want to discuss more → $spec-chat
🔄 Direction changed, redo research → $spec-research "<new direction>"
</HARD-GATE>
NEVER carry over the old approval state.
$spec-revise how$spec-revise risk to add it$spec-chat you decide to change Why → $spec-revise why| Scenario | Use |
|---|---|
| Goal changed, needs fresh research | $spec-research <new direction> |
| Just want to talk, touch no file | $spec-chat |
| Full rewrite of the proposal | $spec-propose (revise edits a single section only; propose has hooks guarding TBD / single-change, revise has no hook) |
| Local edit of one proposal section | $spec-revise [section] |
$spec-apply hook think it's approved)