implement

Smith — Implementation Skill

smith is one skill, not four. Every real invocation runs the same TDD pipeline through implementer: read the task's acceptance criteria, write a failing test, confirm red, write the minimal implementation, confirm green, commit — then mutator and reviewer gate the batch before exit-gate runs the final adversarial check.

The frontmatter description also triggers on "generate tests for X," "explain what this code does," and "refactor this without changing behavior." None of those have dedicated agent behavior — no agent here writes tests without implementation, produces a plain-language explanation, or runs a refactor-only mode. A request framed that way still routes to implementer's standard TDD cycle; if that's not a fit (there is no failing test to write for "explain this"), say so rather than forcing the pipeline to produce something no agent actually defined.

---

Consumes: plan@1 (preferred) or spec@1 directly if no plan exists.

Produces: committed code, and per-task criteria_evidence (exact test and implementation file/line for each criterion proven). No smith agent assembles a changeset@2 itself — that schema is produced by changeset-analyzer when shipping. The caller aggregates each task's criteria_evidence across the run and hands the collection to changeset-analyzer alongside the diff, so courier uses smith's exact evidence instead of reconstructing approximate locations from the diff.

---

<tdd_cycle>

For every implementation task:

1. Write the failing test exactly as specified.
2. Run the test — confirm it fails with the expected error (red phase required; a test that passes before implementation is broken).
3. Write the minimal implementation to make it pass — no more.
4. Run the test — confirm it passes (green).
5. Commit with the conventional commit message specified in the task.

</tdd_cycle>

---

<mutation_gate>

After each implementation task commits, mutator runs mutation testing scoped to the files changed in that task. It detects language from the workspace root (Cargo.toml → cargo-mutants; package.json → Stryker) and analyzes every mutant the test suite failed to catch.

For each surviving mutant, mutator designs a precision test that would kill it and returns those tests to implementer as additional failing tests. The implementer writes them and makes them green before any further tasks proceed.

When the mutation tool is unavailable, mutator reports tool_unavailable and exit-gate records the gap rather than blocking.

</mutation_gate>

---

<exit_gate>

After all tasks are complete and mutator has run, exit-gate runs the sentinel protocol against the spec independently. It reads the spec from spec_file_path on disk — not from spec content forwarded through conversation context. It reads the current code state from scratch, assumes the implementation is incomplete, and confirms that mutation testing ran (or was noted as unavailable). It returns a verdict@1. A spec without spec_file_path set is a hard block.

The caller passes the aggregated per-task criteria_evidence to exit-gate alongside the manifest. The gate uses each entry as a pointer to check — reading exactly the named file and line — rather than searching the codebase cold for every criterion. This makes verification faster without making it less adversarial: the gate still reads the actual location itself and confirms the criterion holds; it does not accept the pointer's existence as ranger.

</exit_gate>

---

<subagent_dispatch_matrix>

Agent	Role	Tier	When to delegate
recon	Workspace manifest & baseline	haiku / low	Before any code is written — detect language, test runner, inventory plan files, confirm baseline passes.
implementer	TDD batch execution	sonnet / medium	Executes a Subsystem Batch (or single task) from plan@1 — full red/green/commit cycle adhering to YAGNI (Ponytail layer).
mutator	Mutation testing gate	sonnet / medium	After each Subsystem Batch commits — verify the test suite catches real faults; returns precision tests for survivors.
reviewer	Pre-gate review	sonnet / medium	After batch mutation gate passes — neutral review of batch scope, non-negotiables, sibling gaps, test quality.
exit-gate	Adversarial exit verification	opus / high	After all batches complete — independent sentinel check against spec; produces verdict@1.