القائمة
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
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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.