newkayak12 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.