Recursively build multi-phase TDDs end-to-end. Coordinates architect, builder, and code-review skills to work through each phase of a TDD — reviewing, improving, building, reviewing code, fixing issues, updating the TDD, then advancing to the next phase.
Recursively build multi-phase TDDs end-to-end. Coordinates architect, builder, and code-review skills to work through each phase of a TDD — reviewing, improving, building, reviewing code, fixing issues, updating the TDD, then advancing to the next phase.
Orchestrates the full lifecycle of a multi-phase TDD. For each phase, it reviews the TDD, proposes improvements, builds the phase, iterates on code review feedback until clean, updates the TDD to reflect progress, then moves to the next phase.
Core Loop
For each phase in the TDD, execute the following cycle:
┌─────────────────────────────────────────────────┐
│ Step 1: Review TDD phase │
│ Step 2: Suggest improvements to the TDD phase │
│ Step 3: User confirms which improvements │
│ Step 4: Build phase (/builder) │
│ Step 5: Code review (/code-review) │
│ Step 6: Apply all code review suggestions │
│ Step 7a: Make sure all tests are passing │
│ Step 7b: Re-review until clean │─┐
│ Step 8: Update TDD with progress │ │
│ Step 9: /compact │ │
│ Step 10: Advance to next phase → Step 1 │ │
└─────────────────────────────────────────────────┘ │
▲ │
└── (repeat steps 5-6 until no findings) ──┘
Detailed Steps
Step 1: Review TDD Phase
Read the TDD document and identify the next incomplete phase.
Read the full TDD to understand context and dependencies
Identify which phase is next (look for phases not marked COMPLETE)
Read the phase requirements: tasks, components, tests, deliverables
Check that prerequisites from earlier phases are satisfied
Step 2: Suggest Improvements
Invoke the architect skill to review the upcoming phase for completeness and feasibility:
/architect Review phase [N] of the TDD at [path]. Check for completeness, accuracy, missing details, and feasibility. Suggest specific improvements.
Accept all suggestions and proceed to step 3
Step 3: User Confirms Improvements
Use AskUserQuestion to present the improvement suggestions. Let the user choose which to accept, modify, or reject. Options:
Accept all suggestions
Select specific suggestions by number
Skip improvements and build as-is
Add their own modifications
If the user accepts improvements, apply them to the TDD before building.
Step 4: Build the Phase
Invoke the builder skill to implement the phase:
/builder build [phase name] from TDD at [path]
The builder skill handles the actual implementation — writing code, creating tests, and following the TDD specification.
Step 5: Code Review
After the builder completes, invoke code-review:
/code-review review the phase [N] implementation
Collect all findings (critical issues, improvements, suggestions).
Accept all findings for the user.
Step 6: Apply Code Review Feedback
Address all findings from the code review:
Critical issues — must fix, these are blockers
Improvements — apply all recommended changes
Suggestions — apply all unless they conflict with the TDD
Step 7: Re-Review Until Clean
Validate all tests are passing. Fix any broken tests.
After applying fixes, run code-review again:
/code-review review the changes made to address previous review feedback
Repeat steps 5-6 until the code review returns no critical issues and no meaningful improvements. Minor nitpicks or purely optional suggestions are acceptable to stop on.
Maximum iterations: Cap at 3 review cycles per phase. If issues persist after 3 rounds, present remaining findings to the user and ask how to proceed.
Step 8: Update TDD
Invoke the architect skill to update the TDD:
/architect update TDD at [path] based on progress — mark phase [N] as complete, update code examples to match implementation, note any decisions or deviations made during building
This ensures the TDD always reflects reality.
Step 9: Advance to Next Phase
run /compact
Step 10: Advance to Next Phase
Check if there are remaining phases:
If yes → return to Step 1 for the next phase
If no → report completion summary
Before starting the next phase, present a brief summary to the user:
Wait for user confirmation before starting the next phase.
Invocation
# Start from the beginning
/builder-r [path-to-tdd]
# Resume from a specific phase
/builder-r [path-to-tdd] --start-phase [N]
# Example
/builder-r docs/tdd/angularjs-to-vue-migration.md
Arguments:
First argument: path to the TDD markdown file (required)
--start-phase N: skip to phase N (optional, useful for resuming)
Entry Behavior
On invocation:
Read the TDD document at the provided path
Identify all phases and their completion status
Find the first incomplete phase (or the phase specified by --start-phase)
If the process is interrupted or context runs low:
The TDD document itself tracks progress (phases marked COMPLETE)
Re-invoke /builder-r [path] --start-phase [N] to resume
The TDD is the persistent state — no other state tracking needed
Completion
When all phases are complete, provide a final summary:
## TDD Implementation Complete### Phases Completed- Phase 0: Foundation — [X] tests
- Phase 1: Auth & Account — [X] tests
- ...
### Total Tests: [N]### Review Iterations: [N] total across all phases### TDD Status: Fully implemented and up to date
