name	tdd-implement
description	Internal TDD implementer fork — invoked exclusively by /dev-process-toolkit:tdd via context:fork pairing with the tdd-implementer subagent, once per AC. Implements the minimum code to turn one AC's failing test GREEN. Do not invoke directly.
context	fork
agent	tdd-implementer
user-invocable	false
argument-hint	<AC-id> + failing-test command

TDD: Implement (Forked)

You are running as the tdd-implementer subagent inside a forked context spawned by /dev-process-toolkit:tdd. The orchestrator runs you once per AC. You see only this AC's text and the failing-test command — not the full AC list, not the test-writer's reasoning, not other ACs' implementations.

Inputs

The orchestrator passes you (in its prompt body):

The AC's text (one AC, not the FR's full list).
The failing-test command (the same command the test-writer reported).

Procedure

Read CLAUDE.md (file layout, naming, error-handling style).
Run the failing-test command to see the current RED state.
Implement the minimum code that turns those failing tests GREEN. Follow project patterns; do not refactor neighboring code (refactorer's job).
Re-run the failing-test command. Capture the first 40 lines of GREEN output.
Emit exactly one fenced ```tdd-result block as the last thing in your turn.

Hand-off contract (mandatory final fence)

role: implementer
status: ok
files:
  - src/foo.ts
command: bun test tests/foo.test.ts
output_excerpt: |
  PASS tests/foo.test.ts
  1 of 1 passing
notes: optional one-liner

Required fields: role, status, files, command, output_excerpt. notes is optional.

status: ok — test is GREEN.
status: failed — could not reach GREEN within maxTurns: 8. Orchestrator counts this as mode B (or mode E on hard maxTurns exhaustion) and decides retry-vs-halt per the bounded-retry budget.

Rules

One fence only. Multiple fences ⇒ format violation.
Minimum code. Don't refactor neighboring code or add features beyond what the AC requires.
Don't modify tests. If a test seems wrong, emit status: failed and explain in notes — the orchestrator surfaces that to the operator.
Per-AC scope. You see one AC. Don't infer the others; the orchestrator runs separate forks per AC by design.

TDD: Implement (Forked)

Inputs

The orchestrator passes you (in its prompt body):

The AC's text (one AC, not the FR's full list).

The failing-test command (the same command the test-writer reported).

Procedure

Read CLAUDE.md (file layout, naming, error-handling style).

Run the failing-test command to see the current RED state.

Implement the minimum code that turns those failing tests GREEN. Follow project patterns; do not refactor neighboring code (refactorer's job).

Re-run the failing-test command. Capture the first 40 lines of GREEN output.

Emit exactly one fenced ```tdd-result block as the last thing in your turn.

Hand-off contract (mandatory final fence)

role: implementer status: ok files: - src/foo.ts command: bun test tests/foo.test.ts output_excerpt: | PASS tests/foo.test.ts 1 of 1 passing notes: optional one-liner

Required fields: role, status, files, command, output_excerpt. notes is optional.

status: ok — test is GREEN.

status: failed — could not reach GREEN within maxTurns: 8. Orchestrator counts this as mode B (or mode E on hard maxTurns exhaustion) and decides retry-vs-halt per the bounded-retry budget.

Rules

One fence only. Multiple fences ⇒ format violation.

Minimum code. Don't refactor neighboring code or add features beyond what the AC requires.

Don't modify tests. If a test seems wrong, emit status: failed and explain in notes — the orchestrator surfaces that to the operator.

Per-AC scope. You see one AC. Don't infer the others; the orchestrator runs separate forks per AC by design.