spec-driven-tdd

The spec-driven-tdd delivery workflow (orchestrator) - runs the full lifecycle for an OpenSpec change: OpenSpec planning/tracking + Superpowers TDD, simplify, and code review. Invoked by using-spec-driven-tdd; run it once implementation starts

Use before planning a risky change - a throwaway feasibility experiment that answers "is this even possible?" cheaply and ends in a VALIDATED / PARTIAL / INVALIDATED verdict

Entry point for the spec-driven-tdd workflow - invoke at the START of an OpenSpec change to load the delivery discipline and hand off to the spec-driven-tdd orchestrator before writing code

[Superpowers 5.1.0, MIT] "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."

[Superpowers 5.1.0, MIT] Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

[Superpowers 5.1.0, MIT] Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

[Superpowers 5.1.0, MIT] Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

[Superpowers 5.1.0, MIT] Use when completing tasks, implementing major features, or before merging to verify work meets requirements

[Superpowers 5.1.0, MIT] Use when executing implementation plans with independent tasks in the current session

[Superpowers 5.1.0, MIT] Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

[Superpowers 5.1.0, MIT] Use when implementing any feature or bugfix, before writing implementation code

[Superpowers 5.1.0, MIT] Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback

[Superpowers 5.1.0, MIT] Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

Use after tests pass and before code review - a portable quality pass that simplifies recently changed code while preserving behavior