ad-tdd

<background_information> Implements WORKFLOW.md §16 end-to-end. The skill is for the implementation phase when the change's behavior is known and expressible as a test up front. No file is written. The output of the skill is the verified implementation that lands in the repo through normal commits.

TDD is a deterministic LLM guardrail: a failing test is unambiguous, so "almost right" (the WORKFLOW §12 failure mode) cannot slip past. The skill keeps the agent inside red-green-refactor and blocks the named anti-pattern (horizontal slicing — bulk-write tests, then bulk-write code).

Good tests read like a specification. "User can checkout with a valid cart" tells you exactly what capability exists. Bad tests couple to implementation — mock internal collaborators, assert on private state, test the shape of things (data structures, function signatures) rather than user-facing behavior. A test that breaks on a rename but not on a behavior change was testing implementation, not behavior.

Distinction from ad-tdg: TDD focuses on driving code through one test at a time (behavior-known regime); TDG picks between three implementation candidates against one ground-truth pair (technique-known, implementation-strategy-uncertain regime). When both apply, use TDD as the outer loop and invoke ad-tdg inside the GREEN phase to pick the implementation strategy for that test cycle.

Codex auto-trigger on description keywords is less mature than Claude Code's. If auto-invocation does not fire when the user mentions TDD, red-green-refactor, test-first, tracer bullet, or behavior-not-implementation, invoke this skill manually. </background_information>

Route elsewhere when:

• The outcome is known but the implementation strategy has multiple plausible paths → ad-tdg (WORKFLOW §9).
• The technique itself is uncertain across multiple plausible approaches → ad-spike (WORKFLOW §14).
• The task is bug investigation, not behavior implementation → ad-diagnose (WORKFLOW §15).
• No test runner is wired → ad-hooks first to scaffold deterministic gates (WORKFLOW §11). TDD depends on a fast green/red signal.

Step 1 — plan vertically. Before writing a test or a line of code:

• Read CONTEXT.md if it exists — anchor test names and interface vocabulary in the project's ubiquitous language.
• Confirm the public interface. What is the smallest surface the caller needs to know? Types, ordering constraints, error modes.
• Identify deepening opportunities (small interface over deep implementation per WORKFLOW §8). Surface-area-light interfaces are easier to test against and survive refactors.
• List the behaviors to test, not the implementation steps. Pick the first behavior — the one that proves end-to-end the path works. The rest are deferred until the tracer bullet lands.
• Test Dependency Map (TDM) for existing code. If the change modifies existing code, list the tests already covering the surface and run them to establish the green baseline. New-code changes skip the TDM and write the first test fresh.
• Get user approval on the plan. One sentence — "I'll test behavior X first via interface Y, then iterate."

You cannot test everything. Confirm with the user which behaviors matter most; focus on critical paths and complex logic.

Step 2 — tracer bullet. Write ONE test that confirms ONE behavior through the public interface:

• RED: write the test → run → confirm it fails for the expected reason. The fail reason matters — a test that fails because the function is undefined is different from a test that fails because the assertion is wrong.
• GREEN: write the minimum code that makes the test pass → run → confirm green.

Do not write a second test until this one is green.