Implement

The plan has been drafted, challenged, and approved. Delegate implementation to a subagent, then orchestrate a review-fix loop until the code is clean.

Prerequisites

This skill expects a plan that has been:

1. Designed via the waterfall-design skill and detailed via the waterfall-plan skill.
2. Challenged via the waterfall-challenge skill.
3. Approved by the user.

If no approved plan exists in the conversation, ask the user what to implement.

It also expects a clean working tree. Run git status before Step 3; if uncommitted changes exist, stop and ask the user to commit, stash, or discard them. Per-increment commits assume the tree is clean so unrelated changes do not get swept into the increment's commit.

Step 1: Extract the plan

Pull the final, approved plan from the conversation, including any revisions made during the challenge phase. Identify:

• The execution order (which changes to make, in what sequence).
• The file manifest (what to create, what to modify).
• The test strategy.
• Any surviving risks to keep in mind.

Step 2: Identify refactoring opportunities

Run the waterfall-refactor skill at the tactical level. This identifies code that should be cleaned up before or during implementation to give the feature a better foundation, and assesses each opportunity's magnitude and shape.

Most refactoring flows straight into implementation — keep the bar for stopping high. Pass pre-work refactors to the subagent as a first step before the planned changes; pass incorporated refactors alongside the relevant plan steps. A refactor large enough to deserve its own commit is not a reason to stop — that is just how it gets sequenced.

Refactoring gate

Halt only for a refactor that is large in magnitude (spread across many files, or structural) or risky in shape (it changes a contract other code depends on, however small the diff). Do not fold it in or pre-work it silently. Stop and present it to the user, per refactor:

• Defer: build the feature on the current foundation. Record the refactor as a backlog item and surface it in Step 8.
• Refactor now: promote it to its own increment ahead of the feature — its own commit and its own review pass. Steps 3-6 run on the refactor first, then the feature increments.
• Escalate to design: if the refactor implies the approved approach itself is wrong, stop and return to waterfall-design / waterfall-plan rather than deciding here. A tactical refactor this big is a sign the strategic refactor pass missed something.

Do not arbitrate these yourself; the user decides per refactor.

Step 3: Delegate implementation

Build the feature one increment at a time, following the plan's increment list. For each increment, spawn a subagent. Pass it IMPLEMENTOR_BRIEF.md as its persona and IMPLEMENTOR_REPORT_FORMAT.md as its output specification.

Send it as initial input:

• The increment's scope (which files change, what behavior to add, the commit message it will ship under).
• Any pre-work refactors from Step 2 that apply to this increment.
• Key codebase context: relevant file paths, patterns, conventions.

The orchestrator delegates rather than building directly so it can retain broader context — the plan, surviving risks from challenge, the operating-context summary — for the review-fix loop that follows. The implementor's narrow context keeps it focused on the increment without scope creep; the orchestrator keeps the bigger picture for triage and oversight. This separation holds regardless of model choice.

If the harness supports per-subagent model or profile selection, prefer a cost- and throughput-efficient model/profile for the implementor. The implementor executes an already-approved plan; the strategic reasoning happened in design, plan, and challenge. If model selection is unavailable, or subagents already inherit the caller's model, use the harness default.

The subagent makes the changes, writes tests, runs the suite, and returns a structured report. After it returns and tests pass, commit the increment using the planned commit message. Then move to the next increment.

If the plan is a single increment, treat it as one commit.

Implementor findings

The report's Findings are the implementor's passing observations — things it noticed while writing that the diff will not show. Do not act on them directly, and never feed them into the auto-fix path (Step 5) — that reintroduces the scope creep increments exist to prevent. Route by where the finding sits:

• In this increment's changed code: leave it for the Step 4 review. The reviewers read these same files and surface the issue independently if it is real; only a reviewer's own finding enters triage and the fix path, so the implementor's note is never triaged or fixed on its own.
• In adjacent code the implementor only passed through: carry it to Step 8 for the user as a backlog item. Fixing it is not this increment's job.

Iteration cap

The implementor may return a plan gap (status plan-gap) instead of a completed increment. If you re-dispatch after adjusting scope or context, cap at 3 attempts per increment. After 3 returns with gaps, stop and surface the issue to the user — do not keep re-dispatching in an attempt to bridge the gap without their input.

Step 4: Review

After the subagent returns, follow the waterfall-review skill on the files changed during this increment:

1. Determine what to review (the changed files).
2. Determine the operating context.
3. Select and dispatch relevant reviewers in parallel.
4. Triage findings: Fix / Judgement call / Dismiss.
5. Deduplicate.

Do NOT present findings to the user yet. First, handle fixes.

Step 5: Fix confirmed issues

For findings classified as Fix (verified, clearly correct):

• Apply the fix yourself. These are issues the reviewers confirmed with evidence.
• After applying all fixes, run the test suite again to confirm nothing broke.

For findings classified as Judgement call:

• Collect them for the user. Do not apply or dismiss these on your own.

Step 6: Re-review if needed

If you applied any fixes in Step 5, re-run Step 4 on the affected files only. Repeat Steps 4-6 until a review round produces no new Fix findings.

Cap at 3 review rounds. If issues persist after 3 rounds, include the remaining findings in the report for the user.

Step 7: Retrospective challenge

Once every increment is committed, run the waterfall-challenge skill at the retrospective level over the whole change. Step 4 asked whether the code is correct; this asks whether it is the change that should have been made — whether it still matches what survived the earlier challenge, and whether it sits at the depth the problem lives at.

Run it once over the accumulated change, not per increment. An increment is a slice of the plan, and judging a slice for fit reports gaps that a later increment fills.

This step reports; it does not rework. Carry its open items into Step 8 with their dispositions and let the user choose per item.

Step 8: Present results

Summarize for the user:

1. What was built: a short summary of the change. Read the file list from git diff --stat rather than the report; add any plan deviations the implementor reported.
2. Review findings: What was found, what was auto-fixed, what was dismissed.
3. Judgement calls: Present each one with the reviewer's reasoning, the relevant code, and why you are unsure. Ask the user "Fix it", "Ignore", or let them provide direction. Batch related calls (2-4 at a time).
4. Retrospective findings: open items from Step 7 — drift from what survived challenge, and fixes that sit at the wrong depth. Each carries accept as built, fix now, or backlog. The user picks.
5. Remaining issues: Anything that persisted after 3 review rounds.
6. Implementor findings: adjacent-code observations the implementor surfaced while writing, outside this increment's scope. Present as backlog items, not fixes.
7. Deferred refactors: any refactors gated in Step 2 that the user chose to defer, as backlog items.

End with a one-line count: "N findings across M files (K auto-fixed, J dismissed, L for user review)."