tdd-coachlisted

# Tdd Coach ## When to use this skill - You are implementing new functionality - You are refactoring existing code - You need to ensure high test coverage - You are following the TDD cycle --- ## Ground rules (apply to ALL phases) 1. Write the least amount of code that satisfies the requirements and makes the tests pass 2. Prefer simple solutions over clever ones — three similar lines are better than a premature abstraction 3. Do not add error handling, validation, or abstractions for scenarios not covered by requirements or tests 4. Do not add docstrings, comments, or type annotations beyond what the task requires 5. Treat the requirements as the maximum scope and the tests as acceptance criteria — satisfy both, then stop 6. Do not touch code unrelated to the task — no drive-by refactors or incidental cleanups 7. Follow existing patterns in the codebase — no new conventions --- ## The TDD cycle The commands below are from a pnpm/Vitest project — substitute the project's own commands (see "Project commands" in the tools-and-scripts rules). ### 1. RED PHASE **Write tests first (based on requirements)** ```bash # Step 1: Read existing tests to understand patterns and fixtures # Step 2: Write tests that verify the requirements # Step 3: Run the tests pnpm test -- --run <test-file> # Step 4: Verify that tests FAIL on assertions (not on import errors) # Step 5: Stop and ask for confirmation ``` **Rules for RED:** - Write minimal, focused tests with one assertion per t