tdd

## Project Context - git installed: !`which git 2>/dev/null || echo "not installed"` - current branch: !`git branch --show-current 2>/dev/null || echo unknown` - CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f` - project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f` ## Constraints (read before anything else) This skill writes production and test code in your working tree. It is an execution skill, not a document generator. These constraints shape every step and override any instinct to move faster. - **The observed-failure gate is load-bearing.** No production-code change until a test has been run and observed to fail for the intended reason in this loop. A test that passes on first run is a stop-and-diagnose signal, not progress. This single rule is what separates real TDD from TDD-flavored code. The verbatim Three Laws and Canon TDD steps it derives from are in [references/tdd-loop.md](./references/tdd-loop.md); pull that reference when a step needs the canon or the implementation gears. - **Two hats.** Never refactor while any test is red. See [references/tdd-loop.md](./references/tdd-loop.md) for the canonical statement. - **One behavior at a time.** Exactly one test list item becomes one runnable test per loop. Newly discovered scenarios are written to the list and deferred, never implemented in the current loop. - **BDD framing.** Tests describe observable behavior, named in the project's existing test-naming ...