executing plans
the counterpart to writing plans: load the plan, review it critically, then execute it exactly. the executor's discipline is fidelity, not creativity.
what it teaches
the loop is rigid: mark the task in progress, follow each step as written, run its verification, mark it complete. deviations are not improvements — a step that looks wrong is a signal to stop and raise it, not to improvise a better one.
why it exists
plans encode decisions the executor lacks context to revisit; every silent "improvement" is an unreviewed design change. stop conditions keep execution honest: blockers, unclear instructions, failing verifications, and plan gaps all halt work for a conversation rather than a guess.
the rules
- review the plan critically before starting; raise concerns first.
- follow steps exactly; never skip verifications.
- stop and ask when blocked, when instructions are unclear, or when verification fails repeatedly.
- isolate the workspace before implementation begins.
when to use
when a written implementation plan exists and execution happens in a session separate from planning. when subagents are available, subagent-driven development is the stronger variant — same fidelity, plus a review gate between tasks.
good and bad
bad
plan step: add appropriate error handlingexecutor action: choose a fallback while coding
the plan leaves a consequential design decision to an executor without context. left standing, each task silently forks into an unreviewed design change: the planner believes one behavior shipped while the tree contains another, verifications drift from the actual steps taken, and the next debugging session reconstructs decisions nobody recorded. the cost compounds because the discrepancy is invisible until a failure forces a diff between plan and reality.
good
plan step: return dependency-unavailable diagnostic from the provider adapter;verify the route returns its stable code
the step names the exact owner, behavior, and verification before execution. steps at this precision keep the plan the single record of decisions — a green verification proves the planned change, not whatever the executor preferred. over many tasks this makes execution auditable: anyone can compare marks and verification outputs against the written steps and trust the result.