Test-Driven Development (TDD) Workflow
You are not allowed to implement code until the full TDD cycle is followed.
Three-Phase Gate System
Phase 1: RED (Write Failing Test)
BLOCKED: Cannot proceed until test failure is proven
- •Write a test that captures the expected behavior
- •Run the test - it MUST fail
- •Document the failure output as proof
Phase 1 Checklist:
- • Test file created/modified
- • Test run completed
- • Failure output captured
- • Failure is for the RIGHT reason (not syntax error)
Example Phase 1 output:
code
PHASE 1 - RED ✗
Test: should return user by email
Result: FAILED
Failure: expected undefined to equal { id: 1, email: 'test@example.com' }
Proceeding to Phase 2...
Phase 2: GREEN (Make It Pass)
BLOCKED: Cannot proceed until test passes
- •Write the MINIMUM code to make the test pass
- •No refactoring, no extra features, no "while I'm here" changes
- •Run the test - it MUST pass
- •Document the pass output as proof
Phase 2 Checklist:
- • Implementation is minimal
- • Test run completed
- • Pass output captured
- • No new tests added (that's a new cycle)
Example Phase 2 output:
code
PHASE 2 - GREEN ✓ Test: should return user by email Result: PASSED Implementation: Added getUserByEmail() to user.service.ts Proceeding to Phase 3...
Phase 3: REFACTOR (Clean Up)
Only proceed after Phase 2 is complete
- •Review code for improvements (naming, structure, duplication)
- •Make changes while keeping tests green
- •Run tests after each refactoring change
- •Document what was refactored OR why skipped
Phase 3 Checklist:
- • Reviewed for refactoring opportunities
- • Changes made (or documented "No refactoring needed")
- • Tests still pass after changes
Example Phase 3 output:
code
PHASE 3 - REFACTOR Changes: Extracted email validation to shared utility Tests: Still passing (3/3) Cycle complete.
Blocking Conditions
| Phase | Condition to Proceed |
|---|---|
| RED → GREEN | Test failure output must be shown |
| GREEN → REFACTOR | Test pass output must be shown |
| REFACTOR → Done | Tests must still pass |
If Phase 1 (failing test) is missing:
- •Respond with: "BLOCKED: PHASE 1 - RED REQUIRED"
- •Do not write implementation code
- •Do not offer alternatives
Multiple Features
When implementing multiple features:
- •Complete full cycle (RED→GREEN→REFACTOR) for feature 1
- •Then start cycle for feature 2
- •Never batch: "I'll write all tests first, then implement"
Rationalizations (All Rejected)
| Excuse | Why It's Wrong | Required Action |
|---|---|---|
| "It's a simple change" | Simple changes still need tests | Write the test |
| "I'll add tests after" | Tests after = not TDD | BLOCKED |
| "Tests are slow" | Speed doesn't override process | Write the test |
| "I know this works" | Confidence ≠ proof | Write the test |
| "Just this once" | That's what you said last time | Write the test |
Skill Chaining
After REFACTOR Phase
| Chain To | When | Action |
|---|---|---|
| suggest-tests | Tests written | Verify coverage gaps |
| doc-maintenance | Feature complete | Update PLAN.md |
| repo-hygiene | Session end | Clean test-skill-* artifacts |
Chains From
| Source | Condition |
|---|---|
| no-workarounds | Bug fix in tool |
| workflow-orchestrator | New feature |
| research-to-plan | Implementation phase |
Combined With no-workarounds
When both tdd AND no-workarounds are activated:
- •You are BLOCKED from implementing ANY fix until Phase 1 (RED) is complete
- •You are BLOCKED from working around the tool failure
- •The ONLY valid path: RED → GREEN → REFACTOR → Verify tool works
This ensures tool fixes are both test-driven AND actually fix the tool (not worked around).
Combined With dogfood-skills
When bug fix completes a feature:
- •Complete TDD cycle: RED → GREEN → REFACTOR
- •Run
skills scanto check for recommendations - •Install any HIGH confidence skills
Testing Pipeline
TDD is the entry point to the testing pipeline:
code
tdd (RED → GREEN → REFACTOR) ↓ suggest-tests (identify gaps) ↓ unit-test-workflow (generate tests) ↓ property-based-testing (invariants) ↓ repo-hygiene (cleanup) ← TERMINAL