| name | test-driven-development |
| description | Use when implementing any feature or bugfix, before writing implementation code — enforces RED-GREEN-REFACTOR cycle |
| argument-hint | <feature or bugfix description> |
| allowed-tools | ["Read","Write","Edit","Bash","Grep","Glob"] |
Test-Driven Development (TDD)
Overview
Write the test first. Watch it fail. Write minimal code to pass.
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
Violating the letter of the rules is violating the spirit of the rules.
When to Use
Always:
- New features
- Bug fixes
- Refactoring
- Behavior changes
Exceptions (ask your human partner):
- Throwaway prototypes
- Generated code
- Configuration files
- Documentation-only wording and layout changes
Integration with myrmidon-swarm: apply this cycle to each test sub-task. A specialist writes
failing tests before an executor writes implementation.
Thinking "skip TDD just this once"? Stop. That's rationalization.
The Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Write code before the test? Remove only the newly written, in-scope implementation you authored for
this task, then start over. If its provenance or scope is unclear, preserve it and request human
direction.
No exceptions:
- Don't keep it as "reference"
- Don't "adapt" it while writing tests
- Don't look at it
- Do not delete pre-existing or user-authored work
Implement fresh from tests. Period.
Red-Green-Refactor
RED — Write Failing Test
Write one minimal test showing what should happen.
Requirements:
- One behavior per test
- Clear descriptive name
- Test real code (no mocks unless unavoidable)
- Assert a computable product outcome, data contract, security property, or executable artifact
structure; never freeze documentation prose, headings, counts, or paragraph presence
Verify RED — Watch It Fail
MANDATORY. Never skip.
Discover the target repository's focused test command from its guidance, task runner, manifests,
lockfiles, and required CI, then run <repository-focused-test-command>.
Confirm:
- Test fails (not errors)
- Failure message is expected
- Fails because feature is missing (not typos)
Test passes? You're testing existing behavior. Fix the test.
Test errors? Fix the error, re-run until it fails correctly.
Do not invent production code or a test harness to force a RED phase for documentation-only work.
Use existing markdown lint and link validation for syntax and navigation. A link checker may prove a
target resolves; a text assertion must not dictate what the documentation says.
GREEN — Minimal Code
Write the simplest code to pass the test. No more.
Don't add features, refactor other code, or "improve" beyond what the test demands.
Verify GREEN — Watch It Pass
MANDATORY.
Run the repository's discovered full relevant suite: <repository-test-command>.
Confirm:
- The new test passes
- All other tests still pass
- No errors or warnings
Test fails? Fix code, not test.
Other tests fail? Fix now before continuing.
REFACTOR — Clean Up
After green only:
- Remove duplication
- Improve names
- Extract helpers
Keep tests green throughout. Don't add behavior.
Repeat
Next failing test for next behavior.
Repository tooling
Discover commands from AGENTS.md, task runners, manifests, lockfiles, and required CI. Prefer the
same entry points CI uses. Record the focused test, relevant suite, coverage, typing, and lint
commands when applicable. If repository sources conflict or no safe command is discoverable, ask
the user; never substitute another repository's commands into an unrelated target.
Good Tests
| Quality | Good | Bad |
|---|
| Minimal | One thing. "and" in name? Split it. | test('validates email and domain and whitespace') |
| Clear | Name describes behavior | test_1 |
| Shows intent | Demonstrates desired API | Obscures what code should do |
Common Rationalizations — All Wrong
| Excuse | Reality |
|---|
| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
| "I'll test after" | Tests passing immediately prove nothing. |
| "Tests after achieve same goals" | Tests-after = "what does this do?" Tests-first = "what should this do?" |
| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is technical debt. |
| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |
| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
Red Flags — STOP and Start Over
- Code written before test
- Test passes immediately without implementation
- Can't explain why test failed
- "Tests added later"
- Rationalizing "just this once"
All of these mean: Delete code. Start over with TDD.
Verification Checklist
Before marking work complete:
Can't check all boxes? You skipped TDD. Start over.
After Completion
Verify with fresh runnable evidence per the evidence-integrity policy before claiming work
complete; a prior run or implementation diff is not evidence of the current state.
Run learn when the session produced a durable testing lesson; it must publish through a PR.
Adapted from obra/superpowers under the MIT License. Copyright (c) 2025 Jesse Vincent.
