Executing Plans: Turning a Written Plan Into Verified, Done Work

Introduction: The Missing Middle of Agentic Work

Ask an AI coding agent to build something complicated without a plan and you get drift: half-finished features, changes outside scope, and a confident “done” that falls apart on first contact with the test suite. Write the plan first and you solve the direction problem — but a plan on disk is still just a promise. The Superpowers executing plans skill exists for the part everyone under-specifies: the disciplined middle, where each task in the plan gets executed, verified, and checked off, in order, until the work is actually complete.

This is the third installment in our Superpowers skills series: what the executing-plans skill does, how its task-and-checkbox loop works, and how we used it step by step to produce a real deliverable — a full Docker status report for a 32-container home server. If you have ever watched an agent rewrite its own plan halfway through to fit what it wanted to do anyway, this skill is the antidote.

What the Executing-Plans Skill Actually Does

At its core the skill is deceptively simple: load the plan, review it critically, execute every task, and report when complete. Four verbs, one contract. The skill lives in software-development/superpowers-executing-plans, and its SKILL.md states the core principle up front: follow the plan, use subagents to keep context clean, and stop when blocked — don’t guess.

That principle is the whole game. An agent without this discipline treats a plan as inspiration; an agent with the skill treats it as a work order. Deviations are not improvised around — they are recorded, or they trigger a stop-and-ask. The skill also draws a boundary around itself: when subagents are available, the recommended path is subagent-driven-development, which executes plans with an isolated agent and a reviewer per task. The executing-plans skill is the fallback for sequential, single-agent execution — and the foundation that the subagent variant is built on.

The Execution Loop: Tasks, Checkboxes, and Verified State

The unit of execution is the task, and the unit of truth is the checkbox. A plan written by the writing-plans skill is a markdown file in .hermes/plans/, and its header says so explicitly:

# Article Series: The Skills We Use

> **For agentic workers:** Use superpowers:executing-plans to
> implement this plan task-by-task. Steps use checkbox (`- [ ]`)

**Goal:** Write and deploy an article series about the 14
Superpowers skills and 5 cross-skill themes.

### Task 1: Create article template and directory structure
- [ ] **Step 1: Create article directory structure**
- [ ] **Step 2: Create the master index page**

The execution loop then runs for each task, and only that task:

Execute the task exactly as written — directly, or via delegate_task when isolation keeps the context cleaner.
Verify by running the verification step the plan specifies — a test command, a build, a grep, a diff.
Confirm completion by flipping - [ ] to - [x] in the plan file on disk.
Move on to the next task. Never two at a time, never out of order.

Checkbox tracking looks trivial, but it is load-bearing. The plan file is durable state that survives context-window compaction, session restarts, and handoffs. An agent that returns from a long task can’t rely on remembering where it was, but it can always re-read the plan and see exactly which steps are checked. For an agent, the list is the only honest memory of progress that exists.

The Four-Step Process in Detail

Step 1: Load and review — before executing anything

The skill reads the plan from .hermes/plans/ and reviews it critically, not approvingly. Questions, gaps, and concerns get raised with the user before any work starts. It is the cheapest moment in the lifecycle to discover the plan is wrong: one clarifying question can save an hour of confidently building the wrong thing.

Step 2: Execute tasks — sequential or dispatched

If tasks are independent, the skill dispatches them as a batch of parallel subagents (see dispatching-parallel-agents). If they are sequential, it executes one at a time. A dispatch for a single plan task looks like this:

delegate_task(
    goal="[Task title from plan]",
    context="""
    Plan task: [paste task details from plan]
    Files to modify: [list from plan]
    Verification: [command from plan]

    Constraints:
    - Follow the plan exactly
    - Do NOT make changes outside the specified files
    - Run verification before reporting completion
    """,
    toolsets=["terminal", "file"]
)

The constraints turn a vague “go do task 3” into a bounded contract: the subagent can’t wander outside the listed files, and can’t claim completion without running the plan’s own check.

Step 3: Checkpoint reviews

After each logical group of tasks, the skill stops and runs the plan’s verification commands against everything done so far, and checks the work against the spec. If reality has diverged from the plan, it stops and discusses — it does not silently reconcile. Checkpoints catch compounding errors early: a wrong assumption in task two is cheap to fix then, and ruinous by task eight.

Step 4: Complete the development

When all tasks are checked and verified, the skill hands off to finishing-a-development-branch: final verification, presenting options (merge, PR, keep, discard), and cleanup. Documentation is part of the finish line — decisions, deviations, and their reasons get written back into .hermes/plans/ alongside the plan, so the file records what actually happened, not just what was intended.

Real Example: The SYNAS Docker Status Report

Here is the Superpowers executing plans skill on a real job: a full status audit of SYNAS, a home file server running OpenMediaVault with 32 Docker containers across 26 networks. The plan was written with checkboxes; execution proceeded task by task, and the deliverable was a status report that stands as evidence, not vibes.

Task 1 — container health. Run the health sweep first, because everything downstream depends on it: docker ps -a --format ... returned 32 of 32 containers up, zero unhealthy, zero restarts in 48 hours. Checked off. The verification output became the executive summary’s opening claim.

Task 2 — service inventory. Enumerate every container and categorize it: monitoring (checkmk, portainer, Tactical RMM’s ten containers), game servers (DayZ, Ark, 7 Days to Die), AI/LLM (open-webui, rea-mcp, icarus), automation (n8n), storage/media (vaultwarden, plex). Each row carries status, CPU, and memory — captured straight from the commands, never paraphrased from memory.

Task 3 — resource utilization. Memory: 41 GiB used of 62.82, 2.7 of 32 GiB swap — comfortable. Disk: 31% full. Docker storage via docker system df: 27.5 GB of images, 531 MB of dead build cache. The report states verdicts (“very light swap pressure, system is comfortable”), not just numbers.

Task 4 — network topology. Map all 26 networks. This is where the discipline shows: the sweep found vaultwarden attached to two networks and portainer running on the host driver. The plan didn’t say whether that was a bug. The skill’s answer is to record it as an observation with an explicit ruling at the end of the report (“likely intentional if vaultwarden exposes to both a local network and the proxy network”) rather than guess or “fix” it unasked.

Task 5 — recommendations, tiered. No-action / nice-to-have / watch, because a flat list of 15 suggestions is noise. A checkpoint review during this task caught icarus sitting at 4.3 GB RAM with 1.87 GB written into its container filesystem. That finding didn’t trigger a mid-audit intervention; it became a “watch” item to monitor for a memory leak.

Final verification. Before claiming completeness, one last independent check — docker ps -a | grep -ci 'up' — returned 32, matching the report’s headline claim of 32/32 healthy. That single command, run fresh, is the difference between “I believe everything is running” and “here is the count, measured seconds ago.” The report itself was then committed to .hermes/plans/ as the completion artifact — plan, execution record, and evidence in one place, exactly as the skill prescribes.

When to Stop and Ask

The skill’s stop rules are non-negotiable: halt immediately on a missing dependency, a failing test, an instruction you don’t understand, a critical gap in the plan, or a verification that fails three or more times. Ask rather than guess. The economics are blunt: a question costs one round trip; a guess costs every downstream task that quietly builds on the wrong assumption. Agents are notoriously bad at noticing they are guessing.

Executing-Plans vs. Subagent-Driven Development

These two skills execute the same plans; choosing between them is a real decision:

Situation	Use
Sequential tasks, one agent, modest scope, trusted plan	executing-plans
Complex or high-stakes work where each task deserves a fresh context and an independent reviewer	subagent-driven-development
Tasks genuinely independent of each other (shared state — none)	dispatching-parallel-agents batch mode, orchestrated by either

The skill itself resolves the ambiguity with one line: prefer subagent-driven-development when subagents are available; executing-plans is the sequential single-agent fallback. The deeper criterion is review pressure. Subagent-driven development puts a spec-compliance reviewer and a quality reviewer behind every task, which is exactly what you want for risky code and overkill for a status sweep. Parallelism is an orthogonal axis — both skills can dispatch independent tasks concurrently; neither parallelizes tasks that share state or order dependencies. Anthropic’s guidance on building effective agents lands on the same point: add coordination complexity only when the task structure actually demands it.

Related Deep Dives in the Series

The Superpowers executing-plans skill does not stand alone — it is the hinge between planning and proof:

writing-plans produces the artifact this skill consumes: right-sized tasks, each with its own verification step.
verification-before-completion is the companion discipline: no completion claim without fresh evidence, enforced inside every task loop.
subagent-driven-development upgrades execution with isolated agents and two-stage review per task.
dispatching-parallel-agents and finishing-a-development-branch cover concurrency at the start and closure at the end.

Frequently Asked Questions

Q: Does the skill require subagents?
No. It runs perfectly as a single agent working the checkbox list in sequence. Subagent support is an accelerator, and once subagents are available the sibling skill subagent-driven-development becomes the recommended route for anything complex.

Q: What if the plan turns out to be wrong halfway through?
You stop and discuss it — that is a named stop condition, not a judgment call. If the user agrees the plan should change, the plan file gets updated with what actually happened, and execution continues against the corrected document. Silent divergence is the failure mode the skill is designed to prevent.

Q: How is this different from just “work through the TODO list”?
Three things: every checkbox flip requires running the plan’s verification first, checkpoints re-validate completed groups against the spec, and the stop rules make “I’m guessing now” an explicit trigger instead of an invisible accident.

Key Takeaways

The Superpowers executing plans skill covers the middle of the workflow: load, review critically, execute task-by-task, report with evidence.
Checkboxes in the plan file are durable, resumable state — the agent’s only trustworthy memory of progress.
Verification runs inside the loop, per task; the SYNAS audit’s final 32/32 container count was confirmed by a fresh command, not by memory.
Stop when blocked; ask rather than guess; record every deviation in the plan file.
Prefer subagent-driven-development for complex or high-stakes plans; use executing-plans for sequential work.

Next in this series: dispatching parallel agents — when running tasks side by side is worth the coordination cost. Browse the full Skills We Use series index for all nineteen articles.