AC
Methodology & Process4.2 KBMIT licensed

executing-plans

Rewritten from patterns in obra/superpowers (MIT)

Execute a written implementation plan task by task with verification at every step. Use when a plan file exists and the work is now implementation, especially in a fresh session. Not for writing the plan: use writing-plans. Not for designing the feature: use brainstorming. Not for merge, PR, or cleanup decisions after the last task: use finishing-a-development-branch.

  • executing
  • plans

SKILL.md

Executing Plans

Load the plan, challenge it, then execute it exactly. The plan is the contract: you follow it step by step, and when it breaks, you stop and ask instead of improvising.

Workflow

  1. Read the whole plan file. Not the first task, the whole file. You need the shape of the work before touching anything.
  2. Review it critically. Look for missing dependencies, unclear instructions, steps that contradict the current codebase state. Concerns exist: raise them with the user before starting, do not silently "fix" the plan. No concerns: create one todo per plan task.
  3. Confirm the workspace. Never implement on main or master without explicit user consent. Work on a feature branch or an isolated worktree.
  4. Execute each task in order. Mark it in progress, follow the steps exactly as written, run every verification the plan specifies, mark it complete. Verifications are not optional even when the code "obviously works".
  5. Stop when blocked. Missing dependency, failing test, an instruction you do not understand, a verification that fails twice: stop and ask. Guessing past a blocker converts one broken task into five.
  6. Hand off. All tasks complete and verified: invoke finishing-a-development-branch to verify the suite and decide merge, PR, keep, or discard. That skill owns everything after the last task.

When to go back

Return to step 2 when the user updates the plan or when execution reveals the approach itself is wrong. A plan that needs rework mid-flight is a review problem, not something to patch task by task.

Good vs bad

Bad: Task 4's verification fails. You tweak unrelated code until it passes, skip the plan's test step because "it's covered", and merge to main directly since the change felt small.

Good: Task 4's verification fails twice. You stop, report exactly what failed and what you tried, and ask whether the plan's assumption about the schema is stale. The user fixes the plan, you resume from the corrected task.

Verification

After the final task, run the project test suite (npm test, pytest, cargo test, whatever the project uses). Expect: all green and every plan task's own verification already recorded as passing. If not, the plan is not executed, go back to the failing task and stop-and-ask if it fails again.

Completion checklist

  • [ ] Entire plan read before starting
  • [ ] Concerns raised before execution, not during
  • [ ] Not on main/master without explicit consent
  • [ ] Every task's verification actually run, none skipped
  • [ ] No steps improvised beyond the plan without user sign-off
  • [ ] Full test suite green at the end
  • [ ] Handed off to finishing-a-development-branch

Any box unchecked: not done. Fix or say so.

Red flags

Verbatim excuses that mean the contract is about to be broken:

  • "The plan is close enough, I'll adapt as I go"
  • "This verification step is redundant"
  • "I'll just work around the blocker and mention it later"
  • "It's a tiny change, main is fine"
  • "The instruction is ambiguous but I'm pretty sure they meant X"

Closure rule: any deviation from the plan that the user has not approved in writing is unauthorized, no matter how reasonable it feels in the moment.

Footguns

  • Skimming the plan. Executing task 1 before reading task 6, which changes the same file differently. Fix: full read first, always.
  • Silent plan edits. "Improving" a step during execution hides the change from the user and from the plan's history. Fix: propose plan changes, get approval, then execute.
  • Blocker tunneling. Two failed attempts at a verification becomes twenty. Fix: two strikes, then stop and ask.

More in Methodology & Process

brainstormingTurn a raw idea into an approved design before any code exists. Use before creating features, building components, addin...doubt-driven-developmentSubject every non-trivial decision to a fresh-context adversarial review before it stands, while course-correction is st...git-workflow-and-versioningGit discipline for every code change: atomic commits, short-lived branches, trunk-based flow, semver, tags, and changelo...
All skills