tdd

## Project Context

- git installed: !`git --version 2>/dev/null`
- current branch: !`git branch --show-current 2>/dev/null`
- 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 convention, asserting outcomes through the public
  interface — never private state. The behavior-naming and Given/When/Then
  protocol is in [references/bdd-framing.md](./references/bdd-framing.md); pull
  it when Step 2 needs it.
- **You will be tempted to fake this.** The specific ways an agent fakes TDD,
  and the discipline that catches each, are in
  [references/failure-modes.md](./references/failure-modes.md); pull it when a
  loop feels off (a test passes on first run, no red is shown, the
  implementation has outrun the test, refactor is being skipped).
- **YAGNI governs the refactor step and the test list.** Apply the rule in
  [../../references/yagni-rule.md](../../references/yagni-rule.md): remove
  duplication, but do not add abstractions, configuration, or indirection
  without evidence. Speculative structure added "for flexibility" during
  refactor is a YAGNI candidate. Speculative scenarios on the test list are
  deferred with a reopen trigger, never silently added.

# Test-Driven Development

## Step 1: Resolve Project Config and Confirm Scope

**Resolve commands.** Read CLAUDE.md's `## Project Discovery` section for the
test command (under `### Commands and Tests`, not `### Frameworks and
Tooling`), the lint command, the build command, language, and framework. If
absent, fall back to `project-discovery.md`. If still absent, run
`${CLAUDE_SKILL_DIR}/scripts/detect-tdd-context.sh` and parse its output for
git state and manifest-inferred commands. Store the resolved test, lint, and
build commands for use in every later step.

**Resolve standards and decisions.** Resolve the coding-standards directory and
ADR directory the same way: read CLAUDE.md's `## Project Discovery` section;
fall back to `project-discovery.md`; fall back to Glob defaults (`docs/`,
`docs/adr/`, `docs/coding-standards/`, `docs/decisions/`). Also check
`CLAUDE.md` and `AGENTS.md` for inline standards. **Read the standards and
ADRs whose titles, paths, or one-line summaries indicate they govern the area
being built. Cap at five documents; if more than five look relevant, list them
and read only the five with the strongest apparent relevance — defer the rest
until refactor surfaces a need.** These govern the green and refactor steps.
If none exist, state that plainly and plan to infer conventions from the
surrounding code instead.

**Report scope, then proceed (no gate).** This skill runs autonomously after
the initial request: it does not stop for confirmation. State to the user, in a
few lines: the behavior or feature to be built, the resolved test/lint/build
commands, the standards and ADRs found (or that none were), the current branch,
and that the skill will now write code in a red-green-refactor loop. If
`current branch` from Project Context is the repository's default branch
(`main` or `master`), recommend working on a branch, but do not wait for an
answer. This is a report the user reads while the work runs, not a gate.
Continue immediately to Step 2 without waiting for a response.

**The one exception.** If the initial request or the provided context
explicitly states the human wants to review, verify, or approve the plan or
test list before implementation, then this becomes a gate: build the test list
in Step 2, present it together with this scope report, and wait for approval
before starting the Step 3 loop. Absent an explicit request like that, the
skill runs to completion without further human input.

The one input that can still block is a missing test command: if it could not
be resolved from CLAUDE.md, `project-discovery.md`, the discovery script, or
manifest inference, ask the user for it, because TDD is impossible without a
way to run tests. Exhaust inference before asking; this is a hard dependency,
not a discretionary checkpoint.

## Step 2: Build the BDD Test List

Turn the requested feature or behavior into a test list (Kent Beck's "test
list" pattern). Each item is one observable behavior, phrased as a behavior
sentence, not as an implementation note. "Returns the unrounded fee for a
sub-dollar charge" is a list item; "use a BigDecimal" is not. Follow
[references/bdd-framing.md](./references/bdd-framing.md) for how to phrase and
name behaviors, and which test-naming convention to adopt (the project's
existing convention and any discovered coding standard win over a literal
"should" default).

Order the list outside-in by user value: the next item is the most important
thing the system does not yet do. For an item that is **user-observable
behavio