tddlisted

# Test-Driven Development Write the failing test first. Watch it fail. Write minimal code to pass. Refactor. A test that passes immediately proves nothing — you never saw it catch a bug. **Iron law:** No production code without a failing test first. If you wrote code before the test, delete it and start over. "Keep as reference" is testing-after in disguise — delete means delete. ## When to use - Implementing any new feature or behavior - Fixing a bug (reproduce it with a test first — the Prove-It Pattern) - Refactoring or changing existing behavior - Triggers on "tdd", "test-driven", "red green refactor", "测试驱动开发", "红绿重构", "测试驱动" **Not for:** generating tests for already-written code (use `test-generation`); have a spec and want slice-by-slice feature implementation (use `implement` — it drives TDD within each slice). **Exceptions (confirm with the user):** throwaway prototypes, generated code, pure configuration changes with no behavioral impact — for these, confirm with the user before skipping TDD rather than defaulting either way. ## Steps ### 0. Discover the stack first The cycle is universal; the commands are not. Before the first test, find how *this* repo tests: read `package.json` / `pyproject.toml` / `Cargo.toml` / `pom.xml` / `go.mod`, check for `./gradlew`, `Makefile`, CI workflows, and existing test-file naming. Never assume `npm test` — use the repo's own command for every RED, GREEN, and final verification. ### 1. RED — write one failing test One be