Executing Plans

Overview

Take a finished plan and build it, in small batches with a review checkpoint after each one. The batching is the point: a checkpoint every few tasks lets a reviewer catch a wrong turn while it's cheap to fix, instead of after twenty tasks have been built on top of it.

This skill itself runs on opus, as the orchestrator: reviewing the plan, judging blockers and ambiguity, and verifying what comes back. It is not where most of the coding happens — each task is delegated to a subagent, picking the cheapest model that task can trust, per the table in "Execute a batch" below.

Announce at start: "I'm using the executing-plans skill to implement this plan."

Commits

By default, hold commits until a batch has been reviewed, so the full diff is available to review. The reviewer gives feedback, then the approved work is committed by you (the orchestrator), not by whichever subagent wrote the code — tell each subagent to skip the plan's Step 5 (Commit) and leave the diff staged for your review. If you'd rather commit per task (useful for unattended runs), pass --auto-commit; then the subagent commits as the plan specifies.

The process

1. Load and review the plan

Read the plan and review it critically before touching code. If it has a blocking gap or ambiguity that would force you to guess, raise it with the partner first, guessing here is how execution silently diverges from intent. If it's clear, make a task list and start the first batch in the same response.

2. Execute a batch

Default to five tasks per batch. Drop to three (or fewer) when a task carries real risk, an unfamiliar external integration, concurrency, security-sensitive logic, or anything the plan already flags as assumption-heavy or likely to need a judgment call. The batch size is a checkpoint cadence, not a quota: size it to how much could go wrong before a reviewer next looks.

Default to delegating, not coding it yourself — that's what keeps your own (opus) attention free for the judgment calls. Pick the model per task, not a blanket default:

For each task:

1. Mark it in progress.
2. Pick the row above. For haiku/sonnet, delegate to a subagent (Agent tool, model set accordingly). Hand it everything it needs to stand alone: the task's files, behavioral contract, and steps verbatim from the plan, the plan's Language Rules block, and instructions to follow the plan's steps exactly, use the test-first cycle (write the test, watch it fail for the right reason, write the minimal code, watch it pass, refactor if needed), run the verifications the task specifies, and report what failed rather than quietly route around it. Run tasks in a batch one at a time unless their Files sections are confirmed disjoint — two subagents must never touch the same file.
3. For the opus row, do the task yourself instead of delegating. Don't iterate a wrong result from a cheaper model through more cheap-model attempts — redo it yourself rather than re-prompt the same tier.
4. Verify a subagent's work yourself before trusting it — its report is a claim, not proof. Read the diff, re-run the test it says passes, and prove the output is real: run the feature with representative input and confirm it produces actual computed data, not an empty or hardcoded value. A task that "passes" but returns nothing isn't done. If a haiku or sonnet result comes back wrong or implausible, don't patch it — redo that one task a tier up.
5. Mark it complete and update its marker in the plan.

3. Report

Before reporting, if earlier batches exist, re-run their tests as a regression check. If something now fails, run it once more to rule out flakiness, then surface it, don't quietly fix it; the reviewer decides what to do at the checkpoint.

Then report the batch:

• What you built.
• The verification output.
• The output-substance proof (real input, real output) for each task.
• "Ready for feedback."

4. Continue

Apply the feedback, run the next batch, repeat until every task is done.

5. Finish

When all tasks are complete and verified, say so, and recommend a review before merging: run the skeptic over what got built (and a code/security pass if you have one), address anything real, then review and merge. Don't merge straight off the last green test.

Logging: assumptions and blockers

Keep one execution log, EXECUTION-LOG.md, next to the plan. Two kinds of entry:

Assumption, you hit a gap or a contradiction in the plan, made a call, and kept going. Log it before proceeding, so it can be reviewed rather than discovered later. The pre-decision state is the useful part.

## A-003 | Task 4 | assumption | OPEN
Plan doesn't specify config format. Assumed YAML, matching the existing codebase.
(gap-fill, plan was silent)

## A-007 | Task 6 | assumption | OPEN
Plan says validate JWT on every request, but the contract schema has no auth field.
Validated at the handler layer and flagged. (conflict, two directives disagreed)

Blocked, a task genuinely can't proceed (missing dependency, impossible requirement, a failure with no viable fix). Log it, mark the task ⚪ BLOCKED in the plan, and stop. Don't invent your way past a blocker.

## B-001 | Task 3 | blocked | OPEN
Can't proceed: `db.Connect()` needs package `internal/pgpool`, which doesn't exist yet.
Root cause: plan assumes it exists; nothing created it. Fix: add a task to create it before Task 3.

Progress tracking

Update the plan as you go, it's the source of truth, and a stale marker sends the next executor to the wrong place. Move markers in place (🔴 → 🟡 → 🟢, or ⚪ when blocked), and write progress notes that are specific and evidence-based:

When a batch is done, make sure the markers match git state before reporting.

When to stop and ask

Stop and ask the moment you hit a real blocker, a critical gap, an unclear instruction, or a verification that keeps failing. A quick question beats a confident wrong guess.

When to revisit the plan

Go back to review (step 1) if the partner updates the plan, or if execution shows the fundamental approach needs rethinking.

Quick reference

• Review the plan critically first.
• Delegate per task (haiku for mechanical, sonnet for most, opus/yourself for risky or already-wrong) — never a blanket default.
• Test-first for all code changes.
• Follow the plan's steps exactly.
• Verify a subagent's work yourself — its report is a claim, not proof.
• Update the plan after each task.
• Report and wait for feedback between batches.
• Stop and ask when blocked.

Related skills