Phase 3: Build¶
Implementation guidance with continuous knowledge capture. Enforces TDD and reminds you to journal decisions.
Command: /3-build
When to use¶
After /2-plan has produced an implementation plan. This is where you write code.
What happens¶
- Context loading -- Reads the plan from Phase 2, critical patterns, and SpecKit specs if present.
- TDD enforcement -- Every feature follows the mandatory cycle:
| Step | Action | Verification |
|---|---|---|
| RED | Write a failing test for the new behavior | Dispatch test-runner in targeted mode — test must fail for the right reason (not syntax/import errors) |
| GREEN | Write the minimal code to make the test pass | Dispatch test-runner in targeted mode — test must pass with no regressions |
| REFACTOR | Clean up while keeping tests green | Re-run targeted test to confirm |
| COMMIT | Commit passing test and implementation together | /commit |
!!! warning "Tests before code" Write the test first. If the test passes without new code, the test-runner flags it: "Test passes without production code — this test may not be testing new behavior."
- Quality skills active during build:
| Skill | Purpose |
|---|---|
test-driven-development |
Enforces the RED → GREEN → REFACTOR cycle |
defense-in-depth |
Input validation and security boundaries |
systematic-debugging |
Structured approach to unexpected behavior |
secret-scanner |
Prevents committed secrets and credentials |
| 4. Journal reminders -- After significant decisions, prompts you to run | |
/journal to capture the reasoning. |
|
| 5. Long session detection -- If the conversation runs long (30+ messages), | |
| suggests saving a mid-build checkpoint and clearing context. |
Supporting commands during build¶
| Command | Purpose |
|---|---|
/journal |
Capture decisions, learnings, problems |
/commit |
Commit with security checks |
/investigate-bug |
Debug unexpected behavior |
Output¶
- Implemented features with tests
- Journal entries documenting key decisions
- A checkpoint file when transitioning to review
Update user documentation¶
If docs/user-manual/ exists, update the feature documentation page before
running the full test suite. The review phase checks documentation completeness.
See Documentation Guide for details.
Before moving to review¶
Run the test-runner in full suite mode to generate .test-gate.md. Phase 4 requires
this file to proceed. See Testing Procedures for framework
setup and the full test-runner reference.
Next step¶
Phase 4: Review -- recommended after /clear to give the reviewer
a fresh, unbiased context window.