Executing Plans Is About When to Stop Thinking

There's a failure mode I've fallen into more times than I want to admit.

I write a plan. I start executing it. Somewhere around task three, I notice something I didn't account for in the design. It's small. I could just adjust — right here, mid-execution, without stopping.

By task five, the implementation looks nothing like the plan. I've made four micro-decisions that felt reasonable in isolation and now have to figure out how they fit together. The plan is a historical document.

The executing-plans skill from obra/superpowers is specifically designed to prevent this.

The Separation of Sessions

The skill's core premise is that planning and executing are different cognitive modes, and mixing them is expensive.

When you're planning, you're making tradeoffs, considering alternatives, and reasoning about system-wide coherence. When you're executing, you're following steps, running verifications, and staying in a tight feedback loop.

Doing both simultaneously means you're doing neither well.

The skill separates them by design. The plan is written in one session. Execution happens in a separate session. The executing-plans skill begins by loading the plan and reviewing it critically — not to redesign, but to identify genuine blockers before work starts. If there are concerns, you raise them before touching any code. If there aren't, you create your task list and start executing.

That review step is not optional. It's the last moment for design thinking before you shift into implementation mode.

Following Steps Exactly

The instruction that required the most adjustment for me was: follow each step exactly.

I read that as a lack of trust in my judgment. It's actually the opposite.

When the plan was written, the person writing it had full context: the design document, the architecture decisions, the known constraints. The executor has the plan. Following the plan exactly is how the executor benefits from all of that context without having to reconstruct it.

When I deviate from a plan step because something "seems better" mid-execution, I'm making a local decision without the global context that was present when the plan was written. Sometimes that's fine. But often it introduces inconsistencies that accumulate — naming that doesn't match, interfaces that drift from the design, test coverage that misses the original intent.

The rule isn't follow steps exactly because the plan is always right. It's follow steps exactly so that when you deviate, you do it consciously, stop, and ask.

The Most Useful Part: When to Stop

The skill's instructions on when to stop are more specific than most workflow guidance I've seen.

Stop when you hit a blocker. Stop when the plan has a gap that prevents starting. Stop when you don't understand an instruction. Stop when verification fails repeatedly.

The explicit list matters because the pressure to continue is real. You're in execution mode. You've built momentum. Stopping feels like losing that momentum.

But the skill frames it differently: don't force through blockers — stop and ask.

Forcing through a blocker means making an undocumented decision under time pressure without the context that informed the original design. That decision will be buried in the implementation and invisible to anyone reviewing the work. The plan will say one thing; the code will do another.

Stopping and asking keeps the deviation visible and intentional.

The Worktree Requirement

There's a detail in the skill's integration notes that says: using-git-worktrees is REQUIRED — set up an isolated workspace before starting.

I used to skip this.

Working in an isolated branch, in a separate directory, with no connection to whatever else is happening on main — it sounds like overhead. It's actually protection against the most common execution failure: the mid-task context switch.

When execution happens in the same workspace as everything else, the boundary between "I'm executing a plan" and "I just thought of something else I should fix" is entirely mental. That mental boundary doesn't hold. The worktree makes the boundary physical.

You can only work on one thing inside that worktree. When you're done, you leave it.

What the Skill Is Actually Training

The deeper thing the executing-plans skill is building is the habit of honoring the boundary between thinking time and doing time.

Most good work requires both. The problem is that thinking feels like progress, and doing also feels like progress, so we don't notice when we're doing both badly at the same time.

The skill installs a simple check: is the plan written? Is it reviewed? Are there blockers on the table? If yes to all three, stop thinking and start building. If no, stop building and start thinking.

I now think of execution mode as a kind of protected context. I'm not available for design decisions. I'm following steps, running commands, and reading output. Everything else waits.

That switch is harder to make than it sounds. The skill makes it easier by being explicit about what each mode requires.

---

Part of the Superpowers series — 14 specialist skills from obra/superpowers.