Menu
Use when implementing any feature or bugfix, before writing implementation code
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
| name | test-driven-development |
| description | Use when implementing any feature or bugfix, before writing implementation code |
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Write code before the test? Delete it. Start over.
No exceptions:
Violating the letter of the rules is violating the spirit of the rules.
Always: New features, bug fixes, refactoring, behavior changes.
Exceptions (ask your human partner): Throwaway prototypes, generated code, config files.
Write one minimal test showing what should happen.
Requirements:
MANDATORY. Never skip.
# Run the specific test
<test command> path/to/test
Confirm:
Test passes? You're testing existing behavior. Fix the test.
Write simplest code to pass the test.
Don't add features, refactor other code, or "improve" beyond the test.
MANDATORY.
Confirm:
Test fails? Fix code, not test.
After green only:
Keep tests green. Don't add behavior.
Next failing test for next behavior.
| Quality | Good | Bad |
|---|---|---|
| Minimal | One thing. "and" in name? Split it. | Tests multiple behaviors |
| Clear | Name describes behavior | test('test1') |
| Real | Tests actual code | Tests mock behavior |
| Excuse | Reality |
|---|---|
| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
| "I'll test after" | Tests passing immediately prove nothing. |
| "Need to explore first" | Fine. Throw away exploration. Start with TDD. |
| "Test hard = skip it" | Hard to test = hard to use. Fix the design. |
| "TDD will slow me down" | TDD is faster than debugging. |
| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is debt. |
Never fix bugs without a test.
Before marking work complete:
Can't check all boxes? You skipped TDD. Start over.
Use before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores intent, requirements, and design before implementation.
Use when completing tasks, implementing major features, or before merging. Covers both performing self-review and responding to external review feedback.
Use when starting feature work needing isolation or when completing a development branch — covers worktree creation, setup, and branch finishing.
Use at the start of every conversation to establish skill-driven workflows. Ensures relevant skills are loaded before any action or response.
Use when you have a spec or requirements for a multi-step task. Covers both writing implementation plans and executing them task-by-task with review checkpoints.
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes