TDD Task

The skill is a part of the coding-interview / timeboxed-task pipeline that can span multiple stages. Each stage runs the grill → spec → implement sequence. The spec grows cumulatively.

Spec-driven red-green implementation of one stage of a timeboxed coding task. Planning already happened in grill-with-docs-quick + to-task-spec, so there is no heavy approval gate — just a one-line confirm, then build in vertical slices. Each slice pauses three times: after RED (the interviewer must see the test fail), after minimal GREEN (the interviewer showcases the passing test before any refactoring), and after refactor (the interviewer approves the behaviour).

Philosophy (lean)

• Test observable behavior through the public interface, not implementation — tests survive refactors, and a good test reads like a specification. See tests.md.
• Vertical slices, not horizontal — drive one behaviour at a time → minimal code to pass → repeat. The slice unit is the behaviour, not a fixed test count. Never write tests for later behaviours up front; adding cases to the current one is fine.
• Minimal green is partial on purpose — write the least code that turns this test green, even if it looks embarrassingly incomplete. The complete, clean solution is the destination across all slices, never slice 1's output. A capable model's instinct is to write the whole obvious solution behind one happy-path test — resist it: no validation, dedup, collision handling, or locking exists until a behaviour's failing test demands it.
• Minimal essential tests — you can't test everything; implement every requirement, but only test the behaviours that carry real risk (happy-path tracer bullet, key edge cases, concurrency invariants).

Fail fast

Refuse to run unless docs/task-spec.md has a current ## Stage N section to implement.

Read first (full context)