القائمة
Reports where the current SDD change stands, what artifacts exist, and which commands can be run next. Use when returning after an interruption and unsure where things left off.
التثبيت باستخدام 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-status |
| description | Reports where the current SDD change stands, what artifacts exist, and which commands can be run next. Use when returning after an interruption and unsure where things left off. |
Read the spec/changes/ directory (excluding archive/) and output the current change status.
spec/changes/*/ to list all un-archived changesresearch.md (current research) + discarded drafts under research/ (if any), design.md, proposal.md, tasks.mdresearch.md to count [TBD-N] entries under ## Open [TBD] and the number of ## Decided entries; count discarded drafts under research/ (if any)proposal.md to check whether the HARD GATE approval marker is present (<!-- APPROVED: YYYY-MM-DD HH:mm -->)verify.md (the verification ledger, if present): frontmatter round / conclusion + count of Status=open findingsNo active change:
No active SDD change.
Start a new task: $spec-research "<direction>"
Active change present:
Active change: <kebab-name>
Artifacts:
research.md ✓ (current research)
Drafts: <K> (under research/, if any)
Open [TBD]: <N>
Decided: <M>
design.md <✓/✗> (note whether one is needed if absent)
proposal.md ✓ (HARD GATE: <pending approval / approved / rejected>)
tasks.md <✓/✗>
verify.md <✓/✗> (round <N>, <pass/fail>, <M> open findings)
Current stage: <determined by the state machine below>
Recommended next step: <mapped from the state machine below — do not generate from memory>
Multiple un-archived changes → list all, and add a note: this workflow is designed for a single active change; there is no switch command. When multiple exist, $spec-archive the completed one(s) first, or name the specific change you mean in subsequent commands.
Generate output strictly from the table below — do not fill in from training-data memory, or you will output stale flow steps (e.g., "reply go to proceed").
Recommended next step must be self-contained (SKILL "Self-Contained Prompts"): do not just throw a command name — include "why this step" (the specific reason the current state leads here). The recommendation texts in the table already include a brief rationale; copy them as-is, do not trim them down to a bare command.
| Detection condition | Current stage | Recommended next step (output this text verbatim) |
|---|---|---|
spec/changes/ is empty | No active change | $spec-research "<direction>" to start a new survey |
research.md exists + ## Open [TBD] is non-empty | Research has open TBDs | $spec-ask to work through the pending decisions |
research.md exists + Open [TBD] empty + no proposal.md | Interrogation done, awaiting propose | For complex tasks, $spec-design first (architecture / >3 interfaces / data-flow diagram); otherwise $spec-propose |
proposal.md exists + no <!-- APPROVED: ... --> marker | Awaiting HARD GATE approval | ✅ Satisfied → $spec-apply (apply auto-appends APPROVED then implements)🔧 Partial changes → $spec-revise [why | what | how | risk]💭 Want to discuss → $spec-chat🔄 Direction changed → $spec-research "<new direction>" |
proposal.md has APPROVED + tasks.md (if present) has unchecked tasks, or code changes have not been through verify | In progress | $spec-apply to continue / run $spec-verify incrementally after each node |
Main implementation done but no verify.md ledger yet (or code changed since its last round) | Awaiting verification | $spec-verify to run the three-dimension check |
verify.md latest round conclusion: fail (incl. escalated still-open findings) | Verification failed | Review the ledger's open findings: $spec-apply to continue fixing / $spec-revise to fix the proposal (if the proposal itself is wrong) |
verify.md latest round conclusion: pass | Verification passed (independent review) | Do not proactively recommend archive — call $spec-archive when you want to archive |
| The user explicitly said "archive" in conversation (not file-detectable — never inferred from artifacts alone) | Ready to archive | $spec-archive |
Heterogeneous peer review (
--codex) is not available in this port — Codex cannot be its own heterogeneous reviewer.
Key anti-patterns:
$spec-apply now auto-appends APPROVED; there is no "reply go" intermediate step)