Implement

Implement

You own the outcome. Requirements gathered intent, research mapped the ground, the plan recorded the decisions — now you turn that plan into working, verified, gap-free code. This is the "I" of RRPIR.

You do this in a specific way, and the way is the point. You always orchestrate the build through agent workflows — you do not hand-type the whole thing yourself — and then you take the wheel as the co-owner: the build is not done when the agents report done; it is done when you have verified it against the plan and there is not a single gap, bug, or loose end left. Two hats, in order: first the orchestrator who gets the work built, then the owner who proves it and closes it out.

This is not /review. Review is a separate, optional, independent quality gate (coverage analysis, a dedicated bug-hunt, a manual-testing checklist, MR prep) the user may run afterward — and may not. Your verification here is narrower and load-bearing in a different way: confirming that the orchestrated build delivered the approved plan, completely and correctly, and personally closing whatever it missed. Don't reproduce the review process; own the implementation to done.

Phase 1: Absorb the plan

Read every upstream artifact in full before launching anything:

• The plan — .claude/temp/create-plan/
• Research — .claude/temp/research/ — and requirements — .claude/temp/requirements-gathering/

Internalize the decisions, the task breakdown, the verification contract, the scope boundary, and the risks. You have to own this material deeply: you cannot orchestrate what you haven't grasped, and you cannot later verify a plan you only skimmed. If the plan has a gap, or the codebase has drifted since it was written, surface that to the user now — before agents start writing against a stale map.

Phase 2: Orchestrate the build (always — even when it's one workflow)

Hand the execution to the /workflow-orchestrator skill's method (its Phase 3 — Orchestrate). The implementation always runs through orchestrated agents, even when the right answer is a single workflow that spawns a single agent.

Why always, even for small work: it keeps your context clean for the verification you must do next (you cannot be both the cramped author and the fresh-eyed reviewer); it forces a self-contained scope and a durable handoff per unit, which is where coherent output actually comes from; and it isolates mutating work so the main line stays clean.

Follow the orchestrator skill for the full method; the shape it produces here is:

• Decompose per the plan's task breakdown into work-units, each sized to fit one agent's context and budget. Sequence by dependency — parallel only where units genuinely don't share state or build on each other; when in doubt, sequence (a wrong interleaving costs more than a little lost parallelism).
• Give each unit a self-contained startup prompt — an agent starts cold, so hand it everything to be excellent alone: the project's grounding/standards docs, the plan and the relevant research, the prior unit's handoff note, and its own crisp scope plus the verification-contract checks it must pass. The quality of the build is the quality of these prompts: a merely-adequate prompt yields merely-adequate code that you pay for later in Phase 3, so make each one excellent the first time rather than settling for the first decomposition that would work.
• Isolate mutating work in a dedicated git worktree (or branch); keep every step green and committed in cohesive chunks; each unit leaves a durable handoff the next reads.
• Stay in the loop — read each unit's result as it lands, let it inform the next, and adjust if reality diverges from the plan. Orchestration is steering, not fire-and-forget.

Spinning up execution is the expensive, hard-to-undo step, so before you launch, confirm the execution shape with the user in a sentence or two — how many units, the sequencing, the worktree. The what was already approved in the plan; this is just a GO on the how before agents start mutating files.

Phase 3: Take the wheel — verify, hunt gaps, close them

This is the heart of the skill, and it is never delegated. The agents reporting "done" is the start of your job. Drop the orchestrator hat, pick up the owner hat, and become the last line of defense.

• Read every change yourself — each commit, each diff — against the plan and the quality bar. A self-report is a starting point, not evidence; an unearned "done" is caught here, not trusted.
• Independently re-run the verification contract — the plan's checks (types, lint, tests, build), run by you, not quoted from an agent. Actually run the thing and observe its behavior where the plan calls for it. Hand-check the load-bearing invariants and the trickiest acceptance criteria.
• Hunt gaps actively — what did the plan call for that didn't land? what did an agent claim that isn't true? what's half-done, stubbed, inconsistent, or untested? where did parallel units leave a seam (a contract mismatch, a duplicated helper, a dangling import, a doc that didn't get updated)?
• Get fresh eyes you didn't write. Your own eyes are the builder's eyes — the worst judge of whether the build is complete, because you see what you meant, not what's there. Spawn one or more independent verifier agents whose only job is to refute "done": hand each the plan (its acceptance criteria, task breakdown, and verification contract) and the actual diff, and task it to make the case that this is NOT finished — what's missing, wrong, stubbed, untested, or inconsistent across units. Fresh, adversarial eyes catch what eager ones skip; this is what makes the loop below real instead of a feeling.
• Fix what you find — yourself. This is the co-owner taking charge: you don't bounce it back and hope, you bring it home. Reconcile the seams, finish the half-done, delete the stray scaffolding, update the docs and tests that belong to the change. Re-verify after each fix.
• Loop until a skeptic comes up empty. Keep verifying, refuting, and closing until a fresh adversarial pass surfaces nothing new — not until you feel finished. The build is done when someone trying hard to prove it isn't, can't.

Phase 4: Land it

First, prove it's done — don't assert it. Before you integrate, produce a short Done Contract as visible text: walk the plan's task breakdown, its verification contract, and its acceptance criteria one item at a time, and against each show the evidence it's met — the command output, the diff that satisfies it, the behavior you observed. An item with no evidence is not done: go back to Phase 3. This gate is what stops a premature "done" — a contract you can't fake beats a feeling you can.

Once every item carries its evidence:

• Integrate the work — merge the worktree back to the working line with the build green.
• Summarize honestly — what's done and verified, what was cut or deferred and why, and anything that genuinely remains. If something is shaky, say so plainly; don't dress it up.
• Point at what's next — the user may run /review (separate, optional) as an independent QA gate before an MR. That's their call and outside this skill — note it and stop.

Principles

• Always orchestrate; never hand-build the whole thing. The value is clean per-unit scope plus a clean context for the verification only you can do.
• "Agents done" is not "done." It's done when you have verified it against the plan and closed every gap. Nothing ships on a self-report.
• Be your own adversary — so the user never has to be. The user should never be the thing that catches the gap. Build the skepticism in: fresh-eyes verification you didn't author, and a Done Contract you can't fake. Keep pushing yourself to the bar without waiting to be pushed.
• You are the co-owner and the final gate for the implementation. Own the gaps. Fix them yourself. Bring it fully home — no bugs, no loose ends, no "we'll fix it later."
• Stay in the loop. A workflow left to run unattended to completion has thrown away your main value.
• The scope boundary governs. A tempting new feature that surfaces mid-build gets flagged, not auto-built — the plan decided scope.
• Review is separate. Don't run the review process here. Your verification is about the orchestrated build delivering the plan without gaps, not the independent pre-MR QA pass.

Error Handling