Menü
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
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| 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.
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