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