Use when creating a feature, creating a spec, implementing a spec, starting a new work item, or any task involving the spec-driven development pipeline. Provides pipeline ordering and superpowers override rules.
Pipeline map for Spec-Driven Development. This skill is a reference — it documents ordering and override rules but does not orchestrate.
Feature Pipeline
Section titled “Feature Pipeline”| Step | Skill | Output | Next |
|---|---|---|---|
| 1 | sdd:spec-discovery |
discovery.md in the work item, after user approval |
sdd:spec-generator |
| 2 | sdd:spec-generator Phase 1 |
requirements.md |
Phase 2 |
| 3 | sdd:spec-generator Phase 2 |
design.md |
sdd:spec-design-review |
| 4 | sdd:spec-design-review (gate) |
design-review-summary.md |
Phase 3 on pass |
| 5 | sdd:spec-generator Phase 3 |
tasks.md |
sdd:spec-task-review |
| 6 | sdd:spec-task-review (gate) |
task-review-summary.md |
sdd:spec-qa-review plan mode on pass |
| 7 | sdd:spec-qa-review plan mode |
test-plan.md |
subagent-driven-development |
| 8 | subagent-driven-development (superpowers) |
Implementation | sdd:spec-implementation-audit |
| 9 | sdd:spec-implementation-audit (gate) |
implementation-audit.md |
sdd:spec-qa-review review mode on pass |
| 10 | sdd:spec-qa-review review mode |
Updated test-plan.md |
sdd:spec-maintenance on pass |
| 11 | sdd:spec-maintenance |
Updated previous specs, spec-maintenance-report.md |
finishing-a-development-branch |
| 12 | finishing-a-development-branch (superpowers) |
PR | Done |
Bugfix Pipeline
Section titled “Bugfix Pipeline”| Step | Skill | Output | Next |
|---|---|---|---|
| 1 | sdd:spec-generator bugfix |
bugfix.md, design.md, tasks.md |
subagent-driven-development |
| 2 | subagent-driven-development (superpowers) |
Implementation | finishing-a-development-branch |
| 3 | finishing-a-development-branch (superpowers) |
PR | Done |
No quality gate skills for bugfixes. User still reviews each phase document interactively.
Superpowers Override Rules
Section titled “Superpowers Override Rules”These rules take precedence over default superpowers skill chaining:
- For SDD features use
sdd:spec-discovery, notbrainstorming. After either: invokesdd:spec-generator(NOTwriting-plans) - After
subagent-driven-development: invokesdd:spec-implementation-audit(NOTfinishing-a-development-branch) - After
sdd:spec-qa-reviewreview mode passes: invokesdd:spec-maintenance - After
sdd:spec-maintenance: invokefinishing-a-development-branch
Exception: Bugfix pipeline follows default chaining — subagent-driven-development → finishing-a-development-branch directly.
Gate Failure Behaviour
Section titled “Gate Failure Behaviour”All gates follow the same pattern:
- Gate identifies specific gaps or failures
- Dispatch fix subagents for the specific issues
- Re-run the failed gate
- If the fix loop fails twice on the same gate, stop and ask the user
Discovery → Spec-Generator Handoff
Section titled “Discovery → Spec-Generator Handoff”sdd:spec-discoverycreatesproject/work-items/{NN}-{name}/, writesdiscovery.mdthere and, on user approval, passes the directory path tosdd:spec-generator.sdd:spec-generatoruses that directory and readsdiscovery.mdas context forrequirements.md.- After
sdd:spec-task-reviewpasses,discovery.mdis deleted.
Work-Item Identifier Rules
Section titled “Work-Item Identifier Rules”Every change that ships behaviour (feature, bugfix, refactor, infra evolution) must live under a numbered SDD spec directory. The spec number is the primary identifier; the issue-tracker ticket ({TICKET-ID}) is a secondary cross-reference only.
Required: numbered spec directory
Section titled “Required: numbered spec directory”- Directory:
project/work-items/{NN}-{name}/whereNNis the next sequential integer. - Commit scopes:
feat(spec-41),fix(spec-38), etc. — the spec number, not the ticket id. - PR title/description: reference the spec as
spec {NN}. Include the issue-tracker ticket as({TICKET-ID})parenthetically if one exists. - Ticket body: include
spec: {NN}so the crosswalk stays up to date.
Acceptable: ticket-scoped {TICKET-ID} directory (no spec number)
Section titled “Acceptable: ticket-scoped {TICKET-ID} directory (no spec number)”A {TICKET-ID} directory, named after a tracker ticket rather than carrying a spec number, is acceptable only when the work is:
- A throwaway spike that informs a future decision but ships no behaviour change (e.g. evaluation runs, research briefs, discovery spikes).
- A board report or governance document (e.g. full app audit, crosswalk maintenance).
- A single-commit trivial bugfix on tooling or test data that does not warrant a spec lifecycle.
If the spike result ships into production code, promote it to a numbered spec before merging.
When in doubt
Section titled “When in doubt”If you are unsure whether the work warrants a spec: if it changes any user-visible behaviour or any production infrastructure, it gets a spec. Spikes stay in a {TICKET-ID} directory only while they remain exploratory.
Artifacts
Section titled “Artifacts”Feature Work Item
Section titled “Feature Work Item”| File | Created by | Lifecycle |
|---|---|---|
discovery.md |
sdd:spec-discovery |
Deleted after spec-task-review |
requirements.md |
sdd:spec-generator |
Permanent |
design.md |
sdd:spec-generator |
Permanent |
design-review-summary.md |
sdd:spec-design-review |
Permanent |
tasks.md |
sdd:spec-generator |
Permanent |
task-review-summary.md |
sdd:spec-task-review |
Permanent |
test-plan.md |
sdd:spec-qa-review |
Permanent (updated in review mode) |
implementation-audit.md |
sdd:spec-implementation-audit |
Permanent |
spec-maintenance-report.md |
sdd:spec-maintenance |
Permanent |
Bugfix Work Item
Section titled “Bugfix Work Item”| File | Created by | Lifecycle |
|---|---|---|
bugfix.md |
sdd:spec-generator |
Permanent |
design.md |
sdd:spec-generator |
Permanent |
tasks.md |
sdd:spec-generator |
Permanent |
The story behind this skill
Section titled “The story behind this skill”Read the post on Substack, published 20 October 2026. The post describes the skill as it was then, and this page shows it as it is now.
See it in the worked example
Section titled “See it in the worked example”The worked example walks through every artefact.