Menu
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
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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
[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
| name | using-spec-driven-tdd |
| description | 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 |
You have the spec-driven-tdd workflow: plan and track in OpenSpec, implement with Superpowers discipline (TDD, simplify, review), finish and archive.
When you are about to implement an OpenSpec change — or the user asks to build,
apply, or work through a change — invoke the spec-driven-tdd skill BEFORE
writing code, and follow its steps rather than improvising.
If a 1% chance it applies, invoke it. Knowing the lifecycle is not the same as following it.
/opsx:propose, /opsx:apply, /opsx:archive,
/opsx:sync).test-driven-development, requesting-code-review,
receiving-code-review, systematic-debugging, using-git-worktrees,
verification-before-completion, finishing-a-development-branch) plus this
pack's simplify skill.Dependencies and graceful degradation: see docs/dependencies.md.
Invoke spec-driven-tdd now if you are starting implementation.