implement-plan

Implement Plan

Overview

Turn an agreed plan into merged, reviewed, tested, documented code — hands-free where possible, never deciding for the user what is theirs. The orchestrator (you) plans the split, dispatches executors, checks their work against the plan thoroughly, cleans up the comments and shape of the code it merged, runs the one adversarial review the user chose, fixes what it finds, and keeps going until the plan is done.

The executor discipline (minimum sufficient change, the four-line mini-plan, pause-and-confirm, "done means") is adapted from @voxyz_ai; the orchestration around it — worktrees, conformance, adversarial review, model routing, capacity, keep-going — is this skill's own.

These rules bind everything below:

1. The plan is the spec. Work is measured against what was agreed, item by item — never against "does it look right".
2. Technical direction is yours; operational and functional direction is the user's. Never assume for them. The table under Two Authorities decides which is which.
3. Keep going. Stop only at the named gates; a stop is a single word to resume and complete on its own — under a goal loop it is all the user sees.
4. This skill's labels never reach the repository. Gate IDs (G1–G4), slice and wave names, round, pass, finding, and step numbers, ticket titles, and Pending mean nothing after this run, and the plan file that defines them is usually ignored by git. None appears in code, comments, test names, docs, or commit messages; the conformance review greps for them.
5. Nothing an agent writes counts things that live elsewhere. Docs, comments, the decisions log, and messages never say how many there are ("the 24 handlers", "all seven tests"): the next one added makes the number wrong. List the items or state the rule that finds them. A number stays only when it is itself the fact: a limit or threshold the code enforces, a quantity the work must use, a version, or a measurement with what it measured.
6. Every subagent is one-shot; more work on the same thing is a new subagent. An executor, reviewer, verifier, or validator gets one self-contained packet, does it, returns its report, and ends. It never waits for a reply, for the user, or for your next instruction, and you never resume, message, or continue it (SendMessage in Claude Code, or the equivalent elsewhere): a slice sent back after conformance, a slice whose G3 question the user just answered, a fix round, and a re-check each get a new subagent whose packet carries everything, including the slice branch, the commits already on it, and the gap or answer that sends it out. A subagent left idle loses its prompt cache within minutes, so the next message re-reads its whole history at full price — hundreds of thousands of tokens per turn on a real codebase — and a judge that has already ruled is no longer fresh.
7. Long commands keep a heartbeat no more than three minutes apart. A subagent's prompt cache expires about five minutes after its last model request, and while it waits on a command it makes no requests, so a silent wait past five minutes re-reads its whole history at full price. Any command that may run past three minutes (a full test suite, a build, an E2E run, a container start) starts in the background with its output and exit code going to a log, for example ( <command>; echo "EXIT=$?" ) > <log> 2>&1 &. The subagent checks it with a foreground loop capped at three minutes, for i in $(seq 18); do grep -q '^EXIT=' <log> && break; sleep 10; done; tail -n 3 <log>, and repeats until the log shows EXIT=. A bare sleep may be refused by the tool; the loop is not. It never waits on a monitor or notification with no cap, and never ends its run while the command is still going. If the expected wait is longer than about 40 minutes, it skips the checks: one cold restart is cheaper. Do not act on a subagent until its final report arrives; a notice that it is still waiting on its own work is not a result.