| name | executing-plans |
| description | 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 리뷰하고 가자", "실행 전에 기준 잡아줘". |
| scenarios | ["이 구현 계획 그대로 진행해도 될지 보고 실행 붙여줘","Plan 파일 있는데 실행 전에 검토하고 기준 잡아줘","Execute this implementation plan step by step","계획대로 가기 전에 갭 없는지 확인하고 각 단계 통과 기준 정해줘","Review this plan and kick off the work","이 plan 실행 준비 됐는지 확인하고 넘겨줘"] |
| compatibility | {"recommended":["sequential-thinking"],"optional":["think-tool"],"remote_mcp_note":"sequential-thinking이 있으면 plan의 일관성·의존성 갭을 실행자에게 넘기기 전에 체계적으로 검토할 수 있습니다. Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요."} |
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.
