Executing Plans

Execute the plan yourself, task by task, in this session: no implementer subagent per task, no reviewer per task. One fresh-context review of the whole branch at the end.

Why inline: Subagent-driven development pays for a fresh implementer and a fresh reviewer on every task, each re-reading the codebase from zero. Inline execution pays for one context (yours) plus one reviewer at the end. What it gives up is a fresh context per task and a second pair of eyes per task. This skill keeps what those two things bought, by other means: the brief is the spec, the ledger is your memory, TDD is the per-task gate, and the final reviewer is the second pair of eyes.

Core principle: The plan already did the thinking. Execute it exactly, prove each step with a test you watched fail and then pass, and leave a record that survives your own forgetting.

Narration: between tool calls, narrate at most one short line, the ledger and the tool results carry the record.

Continuous execution: Do not pause to check in with your human partner between tasks. They chose inline execution to spend less, not to answer "should I continue?" after every task. Execute all tasks from the plan without stopping.

Rulings, not stalls. Conflicts, ambiguities, plan defects, decide them. The spec is the binding authority, the plan is its argument, and your judgment settles what neither answers. Record every decision in the ledger as Ruling: <what you decided>, <why>, <what it costs if wrong>, and keep going. Deviating from the plan without a ledgered ruling is a decision made in secret.

Four things stop you, and only these: an irreversible or destructive operation; a security-sensitive action; a side effect outside this worktree that norms say you ask about first (a merge, a push to a shared branch, a publish); and a plan so broken that every path forward is a guess. For those, stop and ask.

When to Use