tddlisted

# TDD One rule above all others: **the test is the specification. Implementation changes to satisfy the test — never the reverse.** If a test looks wrong, stop and raise it with the user as a spec question. Editing a test to make it pass destroys the only evidence the code works. This skill orchestrates two existing skills — do not re-derive what they cover: - **`write-test`** — how to write tests here: `require('../hooks')`, supertest, fixture ids, emulator/webhook patterns, mocks, prerequisites. Load it before writing any test. - **`backend-engineer`** — how to implement here: layering, repository pattern, conventions. Load it before writing implementation. Its "do NOT run tests" rule does **not** apply inside this skill; running tests is the whole point. ## Vertical slicing — the loop Do **not** write all the tests, then all the code. Bulk-written tests describe *imagined* behaviour and, when context gets tight, invite rewriting tests instead of code. One `it` per cycle, each cycle closed before the next opens: ``` cycle 1: write test 1 → run (RED) → implement → run (GREEN) → refactor cycle 2: write test 2 → run (RED) → implement → run (GREEN) → refactor cycle 3: write test 3 → run (RED) → implement → run (GREEN) → refactor ... ``` Rules of the loop: - **One `it` at a time.** Never add the next test while the current one is red. - **Run just that test** with mocha's `-g`, so the red/green signal is unambiguous: ```bash npm run