working-with-tddlisted

# Test-driven development (TDD) Write the test first. Watch it fail. Write minimal code to pass. Refactor. > **THE IRON LAW:** NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST. Write production code before the test? Delete it. Start over. Do not keep it for "reference" or "adapt" it. Delete means delete. > **Violating the letter of the rules is violating the spirit of the rules.** > **REQUIRED PREREQUISITE:** You must have already completed `slow-powers:working-in-isolation` — establish an isolated workspace before writing any test or production code. > **REQUIRED NEXT SKILL:** You must complete `slow-powers:verifying-development-work` next, after the TDD implementation work is done and before claiming the task is complete or handing work back to the user. --- ## Red-green-refactor cycle 1. **RED — Write a failing test:** * Write one minimal, focused test showing what the behavior *should* do. * Use real code and real inputs; avoid mocks unless absolutely unavoidable. Before committing a test, scan it against the **Testing anti-patterns** table below; if it matches a row, read the named section of the [testing anti-patterns reference](references/testing-anti-patterns.md) first. 2. **Verify RED — Watch it fail:** * Run the test command: `npm test` / `pytest` / `go test`. * **MANDATORY:** Verify it fails for the expected reason (for example, a function is undefined or a value is incorrect), not because of a typo or build error. 3. **GREEN — Wr