plugins/superpowers-bd/skills/test-driven-development/SKILL.md
Use when implementing any feature or bugfix, before writing implementation code
npx skillsauth add schlenks/superpowers-bd test-driven-developmentInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
Always: New features, bug fixes, refactoring, behavior changes.
Exceptions (ask your human partner): Throwaway prototypes, generated code, configuration files.
Thinking "skip TDD just this once"? Stop. That's rationalization.
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Write code before the test? Delete it. Start over.
No exceptions:
Implement fresh from tests. Period.
For each TDD cycle, create three tracking tasks:
ENFORCEMENT:
Write one minimal test showing what should happen. One behavior, clear name, real code (no mocks unless unavoidable). See references/good-vs-bad-examples.md.
MANDATORY. Run test, confirm it fails for expected reason (feature missing, not typos). Test passes? You're testing existing behavior — fix test.
Write simplest code to pass the test. Don't add features, refactor other code, or "improve" beyond the test. See references/good-vs-bad-examples.md.
MANDATORY. Run test, confirm it passes and all other tests still pass. Output pristine (no errors, warnings). Test fails? Fix code, not test.
After green only: remove duplication, improve names, extract helpers, reduce nesting (flatten conditionals, early returns), eliminate redundant abstractions, prefer explicit over compact.
Keep tests green. Don't add behavior.
Conditional simplification dispatch: If >50 lines changed OR cyclomatic complexity >10, dispatch code-simplifier:code-simplifier agent on changed files. Re-run tests, verify green, commit as refactor: simplify [area]. If tests fail, revert.
| Quality | Good | Bad |
|---------|------|-----|
| Minimal | One thing. "and" in name? Split it. | test('validates email and domain and whitespace') |
| Clear | Name describes behavior | test('test1') |
| Shows intent | Demonstrates desired API | Obscures what code should do |
Before marking work complete:
Can't check all boxes? You skipped TDD. Start over.
references/tdd-cycle-diagram.dot: Visualizing the TDD cyclereferences/good-vs-bad-examples.md: RED/GREEN code examplesreferences/why-order-matters.md: Rationale for test-first and rebuttalsreferences/rationalizations-and-red-flags.md: Common excuses and stop signalsreferences/bug-fix-workflow.md: Bug fix example and debugging integrationreferences/when-stuck.md: Solutions for common TDD obstaclesreferences/testing-anti-patterns.md: Pitfalls with mocks, test-only methodsProduction code -> test exists and failed first
Otherwise -> not TDD
No exceptions without your human partner's permission.
<!-- compressed: 2026-02-11, original: 764 words, compressed: 594 words -->tools
Use when converting a Superpowers-BD implementation plan or Shortcut story into a beads epic with dependency-aware child tasks
development
Use when the user asks for /cr-style review of local changes, commits, a branch diff, or a GitHub PR outside subagent-driven development
development
Use when you have a spec or requirements for a multi-step task, before touching code
tools
Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions