Menu
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
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
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
| name | spec-driven-tdd |
| description | 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 |
Plan and track in OpenSpec. Implement with Superpowers discipline. One change at a time, one task at a time.
Core principle: OpenSpec owns what and progress; the execution skills own how. A task is done only after its review is clean — not at green tests.
Requires OpenSpec CLI + Superpowers installed. If a referenced skill or command
is unavailable, say so and fall back per docs/dependencies.md — never silently
skip a step. /code-review is a Claude-Code-only optional enhancement.
Optional — feasibility spike (risk-gated). If the work carries unproven
technical risk (an untested approach, an external API, an open "is this
possible?"), invoke the spike skill before proposing. Skip it when
feasibility is already clear. Act on its verdict: VALIDATED → proceed to
propose; PARTIAL → narrow scope to the viable subset, then propose;
INVALIDATED → stop, do not create the change (tell the user why). Spike code
is throwaway and never enters the change's worktree.
If no change exists for the work, run /opsx:propose (it uses brainstorming
to shape scope, then writes proposal/design/tasks). OpenSpec is the single
source of truth for scope and the task list. Do not invent tasks outside it.
Before touching code, invoke using-git-worktrees to create an isolated
worktree for the change so the main workspace stays clean. (Pairs with
finishing-a-development-branch at the end.)
Get the task list and context via /opsx:apply (read every contextFiles
path). Then, for EACH pending task, run this micro-cycle:
test-driven-development: write a failing test first. No
production code without a failing test.systematic-debugging before guessing.simplify skill for a diff-wide quality
pass; it applies edits.requesting-code-review on the task's diff; use
receiving-code-review to act on it. On Claude Code you may additionally run
/code-review. Fix Critical + Important before continuing.- [ ] → - [x] in the OpenSpec
tasks file.Optional mode — large changes: instead of the inline loop, invoke
subagent-driven-development to dispatch each task to a fresh subagent with
per-task review. Use dispatching-parallel-agents when tasks are independent.
Pause and ask if a task is ambiguous or implementation reveals a design issue (then suggest updating the OpenSpec artifacts).
When all tasks are [x]:
verification-before-completion — confirm the change actually works.finishing-a-development-branch — integrate the worktree's branch./opsx:archive then /opsx:sync — close tracking and update main specs.[x][x]