tdd

## Project Context

- git installed: !`which git 2>/dev/null || echo "not installed"`
- current branch: !`git branch --show-current 2>/dev/null || echo unknown`
- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
- personal config directory: !`bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"`
- project .han/config.md: !`cat .han/config.md 2>/dev/null || echo ""`

As your first action, use the Read tool on `.han/config.md` inside the `personal config directory` path above. A read
that returns no file is no personal configuration: continue silently. When that file or the `project .han/config.md`
probe supplies content, apply it per [config-rule.md](../../references/config-rule.md), which governs precedence
between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

## 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.
- **The scope gate is the observed-failure gate's companion.** The observed-failure gate proves a red is genuine. It
  does not prove the test deserved to exist in this build. No production-code change outside the scope boundary recorded
  in Step 1, and least of all in shared or cross-application code other consumers depend on. A list item whose green
  requires an out-of-scope edit is a stop, never an implement; Step 2 carries the resolution ladder that Step 3 works.
- **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.

**Resolve the scope boundary.** Name, in files and directories, what this work is allowed to change, because the scope
gate tests every candidate edit against it. Inside the boundary: the files, directories, or module the request names,
plus the tests that cover them. Outside it: everything the named code merely reaches, meaning shared libraries, engines,
packages, and any code a second application or consumer also uses, plus code another team owns per `CODEOWNERS`. When
the request names no files, take the application or package the requested behavior lives in as the boundary and treat
its dependencies as outside it. Record the boundary; you will test list items and production edits against it.

**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, **whether this is net-new behavior
or a fix to existing broken behavior** (a reported bug, a failing case, a fix being driven