| name | test-driven-development |
| description | TDD workflow discipline — red→green→refactor cycle for any new feature, bugfix, or behavior change. Use when implementing any feature or fixing any bug before writing production code. Proactively apply when user says "add feature", "implement", "fix bug", or "build X". |
On-demand loading: Read this skill only when the task clearly matches the description above. Do not load for unrelated work.
Test-Driven Development (TDD)
Write the test first. Watch it fail. Write minimal code to pass. Repeat.
Core law: No production code without a failing test first. No exceptions without explicit user permission.
When to use
- New features or endpoints
- Bug fixes (write a failing test reproducing the bug first)
- Refactoring behavior
- Any implementation the user asks for
Exceptions (ask user first): throwaway prototypes, generated/config files, pure UI styling.
Workflow (summary)
- RED — Write one failing test for one behavior
- Verify RED — Run it; confirm it fails for the right reason
- GREEN — Minimal code to pass
- Verify GREEN — Full suite still green
- REFACTOR — Clean up with tests passing; repeat for next behavior
Full cycle detail, bug-fix pattern, red flags, checklist, and rationalizations: references/red-green-refactor.md
Integration with this Setup
- Pairs with
testing-strategy skill (test design patterns and what to test)
- Pairs with
debugging skill (when a failing test reveals a non-obvious bug)
- Pairs with
self-validate (final checklist before declaring done)
- Works with
ship-feature as the implementation discipline within it
References
| File | Contents |
|---|
references/red-green-refactor.md | Complete RED/GREEN/REFACTOR steps, bug-fix pattern, red flags, completion checklist, rationalizations |