implement

name	implement
description	Implement a planned ticket on its own branch using test-first development, updating docs as part of the change, looping change→verify→fix until the suite is green. Use when a ticket has a plan and is ready to build, or the user says "implement X" / "build the ticket" / "make it pass".
model	sonnet
effort	medium
allowed-tools	["Read","Edit","Write","Grep","Glob","Bash"]
argument-hint	<ticket id>
triggers	["implement","build the ticket","write the code","make it pass"]
tags	["implementation","tdd","build","pipeline"]

Implement

Build one ticket, tests first, on its own branch, and don't stop until the verify signal is green. This is pipeline step 3 (plan → track → implement → review → pr). Execution is throughput work — mid model, medium effort.

Start

1. Load the plan and context:

node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" show <ticket-id>
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" reply "<ticket keywords>"
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" step <ticket-id> implement in_progress

If there's no plan yet, stop and run plan-feature first.

2. Work on the ticket branch — before any code:

BR=$(node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" branch <ticket-id>)
git rev-parse --verify --quiet "$BR" && git checkout "$BR" || git checkout -b "$BR"

Build — test-first

For each unit in the plan's file map, in dependency order:

1. Write the failing test first for the acceptance criterion. Run it, confirm it fails for the right reason.
2. Implement the smallest code that makes it pass. Run the full suite — no regressions, not just the new test.
3. Update docs as part of the change — README, API docs, comments the change invalidates. Docs are part of the ticket, never a follow-up.
4. Commit coherent chunks on the branch (don't push — open-pr pushes).

The verify loop

Use the agentic-loop skill's discipline. Read the cap and command from ${CLAUDE_PLUGIN_ROOT}/config.json (loop.max_iterations, loop.verify_command); if no command is set, infer the project's (npm test, pytest, cargo test, make check) and confirm it.

loop (bounded by loop.max_iterations):
  run verify → pass? stop, green.
  fail? read the top failure, fix the smallest thing, re-run.

• Never weaken a test to go green (no deleting/skipping/swallowing). If a test is genuinely wrong, stop and say so.
• No progress after 2 iterations on the same failure → stop and escalate.

Persist

# green:
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" step <ticket-id> implement done --note "suite green"
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" keep "<ticket-id>: <what was built + any gotcha>" --kind summary --tags implement
# blocked/failed: record why
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" step <ticket-id> implement blocked --note "<reason>"

Rules

• Tests first, always. Code without a failing test that drove it is a smell.
• Smallest change that passes. Big speculative rewrites hide regressions — see code-reducer if the result is bloated.
• Docs travel with the code.
• Stay on the ticket branch; never commit to the default branch.

Finish

Report: branch, what was built, tests passed, docs touched, verify result. Next step: review-changes. Under ship, return a one-line summary + branch.