| name | tdd |
| description | Test-Driven Development mode — strict red-green-refactor discipline |
| tags | ["testing","tdd","development"] |
When to Use
- User says "tdd" or wants test-driven development
- New feature that should be built test-first
- User wants strict red-green-refactor discipline
The Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.
Workflow
-
RED: Write a failing test for the feature. The test MUST fail when run. Do NOT write production code yet. Delegate to @omg:test-engineer if available.
-
Verify RED: Run the test via bash. If it passes → the test is wrong, rewrite it.
-
GREEN: Write ONLY enough production code to make the test pass. No extras. No "while I'm here." Delegate to @omg:executor if available.
-
Verify GREEN: Run the test via bash. Must pass now.
-
REFACTOR: Clean up the implementation without changing behavior. Tests must stay green. Delegate to @omg:code-simplifier if available.
-
Verify REFACTOR: Run all tests via bash. Must still pass.
-
Repeat from step 1 for the next feature increment.
Enforcement
| If You See | Action |
|---|
| Code written before test | STOP. Delete code. Write test first. |
| Test passes on first run | Test is wrong. Fix it to fail first. |
| Multiple features in one cycle | STOP. One test, one feature. |
| Skipping refactor | Go back. Clean up before next feature. |
Checklist
Trigger Keywords
tdd, test-driven, red green refactor
Example
copilot -i "tdd: add email validation function"
Quality Contract
- Failing test FIRST, then minimal code, then refactor