# Executing Plans > Use when a written implementation plan is about to be run — critically review it, set each step's pass bar, then route to the right executor. Triggers: "계획 실행해줘", "plan 실행", "이 계획 검토하고 진행", "execute this plan", "plan 리뷰하고 가자", "실행 전에 기준 잡아줘". - Skill: `newkayak12/executing-plans` (Agent Skill) - Install (CLI): `npx skillmds@latest add newkayak12/executing-plans` - Raw SKILL.md: https://api.skillmd.com/api/skills/newkayak12/executing-plans/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: newkayak12 (https://skillmd.com/u/newkayak12) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/newkayak12/executing-plans --- # Executing Plans ## Overview A plan is a set of intentions written against an assumed state. Handing it straight to an executor skips the two things that decide whether it succeeds: **is the plan still sound**, and **what does "done" mean for each step**. This skill is the pre-flight gate between a plan and its execution — it does not run the steps itself. It reviews the plan critically, fixes or stops on defects, stamps a pass bar on every step, then routes the work to the executor that fits. **Core principle:** nothing gets executed until the plan is proven sound and each step carries an explicit pass bar. This is the harness *SetGoal + QualityGate* brought down to a single session — where the six-stage engine derives acceptance criteria and gates on them automatically, here you do it by hand before dispatch. ## The Iron Law ``` NO HAND-OFF WITHOUT A CLEAN PLAN AND A STATED PASS BAR PER STEP ``` If the plan has an unresolved gap, or a step has no observable "done" condition, it is not ready to execute — resolve it or stop and ask. Never route a broken plan downstream. ## The Gate ``` 0. LOAD Read the plan in full. Do not skim into execution. 1. REVIEW Critically review before anything runs: → gaps (a step depends on something no prior step produces) → ambiguity (a step you couldn't hand to someone else as-is) → drift (a precondition the plan assumes no longer holds) Any of these → STOP, raise it, don't hand off. (sequential-thinking) 2. GATE For each step, state its QualityGate level = the pass bar: the observable check that proves that step is done. No bar → stand one up before routing. (verify-level; see verification-before-completion) 3. HAND-OFF Route execution — this skill does not execute: → steps are independent → agents:dispatching-parallel-agents → steps are sequential/dependent → agents:subagent-driven-development Each step's done-verdict is settled against its step-2 bar by completion:verification-before-completion, not the executor's word. ``` ## 1. REVIEW — what makes a plan unfit to execute Read the plan as an adversary, not an implementer. Three defects block hand-off: | Defect | Symptom | Action | |--------|---------|--------| | Gap | Step N needs an artifact/decision no earlier step yields | STOP — the plan is incomplete | | Ambiguity | You couldn't dispatch the step to a stranger without guessing | STOP — pin the intent first | | Drift | The plan assumes a state (file, API, schema) that changed | STOP — the plan is stale | If none are present, the plan is fit. Note any assumptions you *accepted* so the executor inherits them. ## 2. GATE — a pass bar per step Every step gets one observable check that proves it's done — the same discipline as `completion:verification-before-completion`, applied ahead of time: - *"Add endpoint X"* → bar = a request to X returns the specified shape, exit 0. - *"Fix the failing test"* → bar = that test now passes AND fails without the change. - *"Refactor module Y"* → bar = full suite still green, no behavior diff. A step whose bar you cannot state is a step you cannot verify — treat that as a REVIEW defect (ambiguity) and stop. The bars travel with the plan to the executor. ## 3. HAND-OFF — route, don't run This skill's output is a **gated plan** (reviewed, bars attached) plus a routing decision. It never edits code itself. ``` independent steps (no shared files, no causal order) → agents:dispatching-parallel-agents (fan out, one persona-matched agent per step) sequential / dependent steps → agents:subagent-driven-development (one fresh subagent per step, in order) ``` Default when unsure: sequential. A wrong parallel call costs more than running in order would have. Whichever executor runs it, each step is closed out against its step-2 bar via `completion:verification-before-completion`. ## When to STOP and ask - The plan has a gap, ambiguity, or drift you can't resolve yourself. - A step has no statable pass bar. - The plan's assumed state no longer matches reality. - The partner updates the plan mid-review → return to REVIEW from the top. **Ask rather than guess. Never hand a broken plan to an executor.** ## Red flags — stop - Skimming the plan and starting to route before REVIEW is done. - Handing off a step whose "done" you can't describe as a check. - Assuming the plan's preconditions still hold without looking. - Picking parallel execution to feel fast when the steps are actually dependent. ## What Claude does / What you do - **Claude:** loads and adversarially reviews the plan, states a pass bar per step, stops on any defect, and routes fit plans to the matching executor. - **You:** supply the plan and any missing pass bar; confirm accepted assumptions when the plan is ambiguous rather than blocking. ## Related - `write:writing-plans` — produces the plan this skill gates (upstream). - `agents:dispatching-parallel-agents` — executor for independent steps (downstream). - `agents:subagent-driven-development` — executor for sequential/dependent steps. - `completion:verification-before-completion` — settles each step's done-verdict against the bar set here. - `harness:harness` — the six-stage engine; this skill is the solo counterpart of its SetGoal + QualityGate stages. ## Bottom line Review the plan until it's sound, stamp a pass bar on every step, then route it to the executor that fits — and never before. Gating is the whole job; execution belongs to someone else.