Developer pack
Claude Skill
Test-Driven Development
Drives a feature or bugfix test-first — write the failing test, watch it fail, write the minimal code to pass, then refactor.
What it does
Guides the red-green-refactor discipline: write a failing test that pins the behavior, confirm it fails for the right reason, write the minimal code to pass, then clean up while staying green. The point isn't coverage after the fact — it's knowing the test tests the right thing because you watched it fail first.
When to use
- ✓Implementing a new feature or fixing a bug where the behavior is specifiable
- ✓You want a regression caught the moment it reappears
- ✓Refactoring — the tests are the safety net that lets you move fast
When not to use
- ✗A throwaway prototype or spike you'll delete (ask first if unsure)
- ✗Generated code or config where a behavioral test adds nothing
Install
Download the .zip, then unzip into your Claude skills folder.
mkdir -p ~/.claude/skills
unzip ~/Downloads/test-driven-development.zip -d ~/.claude/skills/
# Restart Claude Code session.
# Skill is now available — Claude will use it when relevant.SKILL.md
SKILL.md
---
name: test-driven-development
description: Use when implementing a feature or bugfix, before writing implementation code. Triggers on "TDD", "test first", "write the test first", "red-green-refactor", or any feature/bugfix where behavior can be specified.
---
# Test-Driven Development
Write the test first. Watch it fail. Write the minimal code to pass. The core reason: if you didn't watch the test fail, you don't know it tests the right thing — a test that passes before you wrote any code is testing nothing.
## The iron law
No production code without a failing test first. If you wrote the implementation before the test, the honest move is to delete it and re-implement from the test — not keep it "as reference" and adapt it. Reimplementing fresh from a failing test is the whole point; adapting existing code quietly skips the step.
## Red-green-refactor
1. **Red** — write one small failing test that describes the next increment of behavior.
2. **Verify the failure.** Run it. Confirm it fails, and fails for the *right reason* (the behavior is missing — not a typo or import error). A test that fails for the wrong reason is worse than no test.
3. **Green** — write the minimal code to make it pass. Not the elegant version, the minimal one.
4. **Verify green.** All tests pass.
5. **Refactor** — clean up implementation and tests while staying green. Then loop.
## When to use it
Default to TDD for features, bug fixes, behavior changes, and refactors. Reasonable exceptions — throwaway prototypes, generated code, config — are worth a quick check with the user first. "Skip TDD just this once" is usually rationalization; notice it.
## Good tests
- Test behavior through the public interface, not private internals
- One reason to fail per test; a clear name that states the expected behavior
- For a bug: the test reproduces the bug first (red), then the fix turns it green
## Anti-patterns
- Writing the code, then the test (you've lost the signal the test gives)
- Not watching the test fail — you don't know it's wired up
- A "test" so broad it can't tell you what broke
- Refactoring while red — get to green first, then clean up
Example prompts
Once installed, try these prompts in Claude:
- Implement this validation rule test-first — write the failing test, show me it fails, then the minimal code.
- There's a bug where empty carts still charge shipping. Write the failing test that reproduces it, then fix it.