tdd-http-firstlisted

## When to use You are about to implement or change endpoint behavior — a new route, a new request/response field, new validation, or a bugfix on an existing route — and you want to drive it test-first (RED → GREEN → REFACTOR), in a project whose testing rule is **HTTP-layer-only** (see the global `~/.claude/CLAUDE.md` "HTTP-layer testing rule": every test for an HTTP service goes through the HTTP layer via `supertest` / the project's route harness; no `tests/services|validators|utils` unit tests that bypass the route). This skill exists because of a **collision**: the generic test-driven loop's reflex is "write a failing **unit** test first," but the HTTP-layer-only rule forbids exactly that. So here, RED = a failing **HTTP-layer** test. A fresh assistant doing "TDD" will reach for a unit test and violate the rule — that is the mistake this skill prevents. Division of labor: - **The loop discipline itself** (one behavior at a time, watch it fail for the *right* reason, write the *minimal* code to go green, then refactor) → the standard TDD RED/GREEN/REFACTOR discipline. Apply it; this skill doesn't restate it. - **Binding that loop to the HTTP-layer-only rule** (where the RED test lives, what counts as a real RED, the escape hatch) → this skill. ## Steps 1. **(RED) Write one failing HTTP-layer test.** Decide WHERE it goes first: **add to the existing test file for that route/area** (a new `describe(...)` block); create a new file only when none builds that router/area.