القائمة
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 المهني
| 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)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.