tddlisted

# Test-Driven Development (Red-Green-Refactor) TDD produces better designs because writing the test first forces you to think about the interface before the implementation. The test is the first caller — if it's awkward to test, the interface is awkward to use. See `${CLAUDE_PLUGIN_ROOT}/skills/tdd/references/tests.md` for good/bad test examples. See `${CLAUDE_PLUGIN_ROOT}/skills/tdd/references/mocking.md` for when (and when not) to mock. --- ## Step 0: Read the project context Before writing any code, do these in parallel: 1. **Read `CLAUDE.md`** — find the project's test command and any testing conventions. If none found, detect from project structure (see [Test runner detection](#test-runner-detection)). 2. **Read existing code** in the affected area — understand the domain language, existing interfaces, and conventions. Record: - `TEST_CMD` — the command to run tests (e.g., `dotnet test`, `npm test`, `go test ./...`) - `SRC_FILE` — file where implementation will live - `TEST_FILE` — file where tests will live --- ## Step 1: Plan before touching any code Planning prevents the biggest TDD trap: writing tests for imagined interfaces. Ask the user (or infer from the task if obvious): 1. **What is the public interface?** — the function/method/class signature the tests will call. Shape it for testability as you design it: see `${CLAUDE_PLUGIN_ROOT}/skills/tdd/references/interface-design.md`. 2. **Which behaviors matter most?** — list them in priority order Align te