| name | implement |
| description | Execute an implementation plan from the knowledge graph step by step. Updates status, verifies criteria, records thoughts about what you encounter, and charges thoughts when evidence arrives. Use after a plan has been created and approved. |
| argument-hint | <plan project ID or name to implement> |
Implement: $ARGUMENTS
User input > Skill constraints > Trained defaults
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.
brainstorm = WHY, ticket = WHAT, plan = HOW, implement = WORK.
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.
Before spawning any implementer, the plan must have passed plan-reviewer audit.
No implementer spawns on an unreviewed plan version.
query({ "text": "$ARGUMENTS", "type": "plan", "limit": 5 }) — if multiple match, ask user which.
(Architectural disambiguation = legitimate touch point, not workflow permission.)
<check id="walk-tree">
query({ "mode": "plan_tree", "id": "plan_id" }) — identify which steps touch disjoint files (parallelizable) vs shared files (sequential).
</check>
<check id="reviewer-audit" severity="gate">
Confirm plan has passed reviewer audit. traverse({ start: plan_id, edge_types: ["informed-by", "relates-to"], direction: "both" }) — look for audit thought/research.
If no audit: spawn plan-reviewer first per orchestrate constraint id="reviewer-gate". Do NOT proceed to implementation without it.
Locked user rule: "the planner making snowflake implementations instead of reusing code is UNACCEPTABLE." Reviewer gate exists to enforce; cannot bypass.
</check>
Parallelize implementers where it's safe; serialize where it's not.
Spawn implementers in parallel (one message, multiple Agent calls).
Sequential. Parallel edits to same file cost more than they save.
Sequential, wait for dependency.
Each marks only its own step active/complete. Pass step's linked files in agent prompt so it doesn't hunt.
Pure verification phases run inline by the orchestrator, NOT via spawn.
Verification phases (~10 tool calls, no novel code) get 3-5x overhead from spawn ceremony.
Spawned agents often go exploring (re-investigating settled things) instead of just running checks.
Verification ≠ implementation.
- "Run full test suite + lint + build, record validation thought"
- One-line gofmt / typo / import fixes
- Final integration verification / docs pass with no real code changes
- Status closure (mark plan → ticket → project completed)
- Phase requires actual code changes
- Multi-file edits
- Non-trivial investigation
See orchestrate constraint id="background-spawning".
Every implementer spawn prompt MUST open with this block VERBATIM:
```
EXECUTION DIRECTIVE — read first, enforce throughout:
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.
```
This block addresses recurring drift modes documented in orchestrate constraint id="non-negotiation":
- Cherry-picking phases
- Scope estimation pauses
- Test deletion for green-suite
- Silent substitution
- Stale comments left behind after a behavioral edit
Agent(
subagent_type: "implementer",
prompt: "<EXECUTION DIRECTIVE block>\n\nImplement Phase N of plan <plan_id>. Files to modify: <file list>. Stop at the phase boundary; report verification status.",
description: "Implement: Phase N <name>",
run_in_background: true
)
Agent(
subagent_type: "implementer",
prompt: "<EXECUTION DIRECTIVE block>\n\nImplement plan <plan_id> end-to-end. Use assemble / query(mode:plan_tree) to find the next step; follow each phase to completion. Stop only on blocking exceptions or completion of all phases.",
description: "Implement: <plan name>",
run_in_background: true
)
Per-phase spawning when phase contexts are large; fresh context per phase benefits the implementer.
Whole-plan spawning when phases are tight and context-sharing helps.
Either way, background.
Phase boundaries are NOT user gates. Advance automatically until plan completes
or blocking exception. Do not ask CEO to gate phase transitions.
Trained instinct: surface progress, ask "ready for the next phase?" before continuing.
Wrong here — phase boundaries are workflow steps the CEO already authorized at plan-approval time.
- Plan completion (all phases closed, closure rolled plan → ticket → project). End-of-plan summary; suggest /test if test plan linked; ask about reindex.
- Blocking exception (TICKET-GAP discovered mid-impl, unresolvable conflict, failing criterion needing design decision).
- Mid-plan failure needing intervention (repeated test/lint failures, infrastructure problems, scope-expansion temptations flagged but not acted on).
1. Read implementer's phase report; verify steps passed criteria + tests + lint.
2. If clean: one-line confirmation logged; spawn next phase's implementer immediately.
3. If off: pause and surface to user (legitimate touch point — drift detected, design judgment needed).
Plan was already reviewed by plan-reviewer before any implementer spawned.
Each phase's success criteria were verified at plan time.
Asking "next phase?" at every boundary makes multi-phase plan a slog of confirmations
the user has no useful signal to gate on. Gates belong at brainstorm (principle),
planner specifics-questions, and completion — NOT in between phases.
On implementer drift: re-spawn with EXECUTION DIRECTIVE block + specific drift named.
Do not negotiate. Do not let drift land.
See orchestrate constraint id="non-negotiation" for the universal principle.
Implementer did some phases, skipped others.
Re-spawn directive: "the prior implementer did phases X+Y but skipped phases A+B — you do A+B in order, then we're done."
Implementer estimated "this is 8-12 hours" and refused to proceed.
Re-spawn directive: "implementer does not estimate. Execute every step."
Implementer deleted/skipped tests to make suite pass.
Re-spawn directive: "revert test deletions. Substantive completion is the criterion, not literal pass."
Implementer left server stubs returning interceptRequired with no client claimant.
Re-spawn directive: "the construction half is missing — add the client intercepts that claim the calls before the stubs are reached."
Implementer changed behavior but left comments/docstrings describing the old behavior (consumer lists, routing/fallback paths, return shapes, invariants).
Re-spawn directive: "the code is right but the comments now lie — sweep every touched file and update each comment the change falsified; a stale comment is as bad as wrong test logic."
