superspec

Use when docs/specs/changes/{name}/tasks.md is user-approved and contains stages with unchecked stage-completion boxes, when about to write implementation code for a planned change, or when resuming work on a change with partially-complete stages — implements tasks one stage at a time, dispatching subagents in parallel or sequential batches as the plan specifies, running one Stage Verification at each stage boundary and recording one Evidence block per stage.

Use when docs/specs/changes/{name}/ contains delta specs but no tasks.md yet, or when a previously-reviewed change has been revised in writing-specs — validates each delta operation's preconditions against current stable specs, checks scenario coverage and RFC 2119 language, then hands inline findings to plan-review which drafts the approval-gated plan.

Use when the user mentions superspec, when starting a spec-driven change, when unsure which workflow stage applies, or when the repo contains docs/specs/ or docs/specs/changes/ and work is about to begin — establishes source-of-truth rules and routes to the correct stage skill (brainstorming, writing-specs, review-changes, plan-review, execution, code-review) before any other action.

Use when brainstorming has settled requirements in chat and delta specs do not yet exist for the change, or when review-changes returned CRITICAL findings that require revising an existing delta — produces delta specs under docs/specs/changes/{name}/specs/{domain}/spec.md using heading-as-identifier requirements, RFC 2119 language, and Given/When/Then scenarios, with a Change Overview header capturing Why/Impact/Non-goals.

Use when docs/specs/changes/{name}/tasks.md has every stage marked `- [x]` with evidence, or when user says "review the change", "ship it", "merge the delta", "archive the change", or a prior code-review returned CRITICAL findings that execution has addressed — verifies every ADDED/MODIFIED requirement has code and tests, re-runs every stage's verification command against recorded evidence, then applies the delta wholesale in RENAMED→REMOVED→MODIFIED→ADDED order and archives the change.

Use when docs/specs/changes/{name}/ has delta specs validated by review-changes but no tasks.md yet, or when user says "plan this change", "write the plan", "what are the tasks" — produces tasks.md grouped into stages with canonical subagent dispatch phrasings, mapping every ADDED/MODIFIED requirement to tasks, with verification and evidence recorded at the stage boundary (not per task). This is the workflow's sole user-approval gate.

Use when the user says "add X", "build X", "fix X", "change X", "I want to", or otherwise requests any feature, bug fix, or behavior modification, and requirements have not yet been settled in conversation — explores intent and scope with the user before any spec is written.