implement

Implement: $ARGUMENTS

For universal orchestration discipline (background spawning, signal routing, reviewer gate, drift detection, user touch points, non-negotiation), reference .claude/skills/orchestrate/SKILL.md — already loaded in your context.

This skill is implement-specific. The implementer agent definition (.claude/agents/implementer.md) carries the agent-facing execution mandate.

By the time implement runs: brainstorm captured WHY, ticket nailed WHAT, plan locked HOW. Implementer's job is to execute — not to decide. Decisions surfacing during implementation = upstream artifacts inadequate; route back, do not invent.

See orchestrate constraint id="dispatch".

```
EXECUTION DIRECTIVE — read first, enforce throughout:

BEFORE YOUR FIRST WRITE, verify this brief's picture of the environment. Whatever
it tells you about the working tree and about which steps remain was true when it
was written and may not be true now. One call each: the tree against what the brief
says is there, the step statuses against what it says is left. If they disagree,
STOP and report — do not write, and never revert, stash, or clean uncommitted work
that is not yours to reach the base the brief promised. A tree already carrying your
task's changes means another worker is live on it.

Execute every step of every phase in the order the plan specifies. Do not skip
steps. Do not cherry-pick phases. Do not estimate scope. Do not pause to ask
for sequencing direction. Do not freelance a "better" approach.

If you cannot complete a step (provable blocker — broken dependency, missing
symbol, criterion that's wrong), STOP at that step and report. Do not skip
ahead. Do not "do other things while stuck."

If your work would leave any path returning interceptRequired/not-implemented
that prior steps depended on remaining functional, you have introduced a
regression. Fix it in-phase or surface the blocker. Do not delete tests to
make the suite green — substantive completion is the criterion, not literal pass.

Updating comments is part of the change, NOT optional cleanup. When your edit
changes what code does, how it routes, what it consumes or returns, or which
invariant holds, fix every comment and docstring the edit makes wrong in the
SAME step — especially comments that list consumers, describe a routing/fallback
path, or name a return shape. A stale or misleading comment is as bad as
incorrect test logic: both assert something false the next reader trusts. A
touched file whose comments still describe the old behavior is a FAILED step.

If you run out of context, capture precise resumption state (what's done,
what's pending, exact file state) so a successor agent picks up cleanly. Do
not self-truncate by pausing "to be safe."

Just do the work, every step, in order. Mark each step completed in the graph
as you go. Report at the END.
```