メニュー
Use when implementing any feature or bugfix, before writing implementation code
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| 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