# Plan Execute > Apply the last approved plan exactly. Trigger when the user runs /execute or says "execute the plan", "implement this", "do it", or "go ahead" after a plan has been approved. Surface judgment calls — do not make them silently. Not /plan-create (designs the plan first) or /plan-deep-dive (inspects a plan without running it) — plan-execute runs an already-approved plan. - Skill: `allemaar/plan-execute` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add allemaar/plan-execute` - Raw SKILL.md: https://api.skillmd.com/api/skills/allemaar/plan-execute/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: allemaar (https://skillmd.com/u/allemaar) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/allemaar/plan-execute --- # /execute Execute an approved plan with precision — follow the plan exactly, surface any judgment calls, declare completion explicitly. > **Structured execution spec:** [`protocol.yon`](protocol.yon). Read it for the canonical rules and step sequence; this file is explanation. The two must stay in sync — if you edit one, update the other and refresh the `@STAMP` date. > **Execution Protocol — no silent decisions, no silent drift.** The plan was already reviewed. Surface anything not specified. Declare when done. ## Valid Executable Plan A plan is executable if it has all of the following: - **Numbered steps** — each step is a discrete, concrete action (not prose intention) - **Concrete actions** — each step names what to do, not what to achieve (e.g., "Edit `src/auth.ts` to add JWT validation" not "add authentication") - **At least one verifiable outcome** — at least one step or verification entry that produces an observable, checkable result If the plan does not meet this definition, the Phase 1 gate will reject it with the specific gap named. ## Phase 1 — Alignment 1. Load the approved plan using this priority order: - **Conversation context first** — if a plan was produced in this conversation, use it - Then `PLAN.md` in the project root - Then `implementation_plan.md` in the project root - If none found, see Gate below 2. Confirm execution mode: no planning, no exploring, no scope additions. **Gate:** - No plan found → run `/plan-create` first. Do not proceed. - Plan found but does not meet the **Valid Executable Plan** definition → state the specific gap (e.g., "no numbered steps", "no verifiable outcome") and ask the user to revise or invoke `/plan-create`. Do not proceed. ## Phase 2 — Action Execute each step from the plan **in order**. Track progress against the plan as you go. **If drift is detected** — environment, codebase, or dependencies differ from what the plan assumed — **stop immediately**. Do not self-correct. Do not improvise. State the specific discrepancy: > "Planned: [X]. Found: [Y]. Options: (1) I can proceed with [specific substitution] — confirm to approve this deviation. (2) We can revise the plan. Which do you prefer?" If the user approves a deviation, document it inline: "Proceeding with [substitution] as approved deviation to plan step N" — then continue. **If a judgment call is required** — any decision not explicitly named in the plan step — surface it before acting: > "Step N requires a decision not specified in the plan: [decision]. Options: [A] / [B]. Which should I use?" Do not make implicit decisions. Do not proceed past a judgment call without a user response. ## Phase 3 — Verification Run the verification steps specified in the plan. Report: - Which steps were completed - What verification was run - What the result was **If no verification steps are specified in the plan:** ask the user to confirm outcomes explicitly — do not silently pass. **Full gate suite before commit.** If the execution produced committable code, do not rely on the plan's named checks alone — run the project's defined gate suite (lint / test / typecheck — whatever the project declares; e.g. `turbo run lint test typecheck` where present) before the terminal declaration. This is a *deliberate pre-commit gate*, distinct from speculatively auto-running suites: invoke it as the closing verification of the work, not on every edit. **Map each plan step's intended outcome to the specific verification that exercised it**, and report the mapping — any unverified step or skipped gate is allowed but must be named explicitly, never silently passed. (If the project's CLAUDE.md restricts auto-running builds/tests, honor that: run only the gates the project sanctions, and name the rest as deferred.) **Terminal declaration (required):** every execution ends with one of: - `Execution complete — all steps verified.` - `Execution failed — [specific reason].` - `Execution halted — [specific reason]. Completed steps: [list].` No execution ends without a terminal declaration. ## Rules - MUST follow the plan exactly — no scope creep - MUST stop and notify user when drift is detected — do not self-correct - MUST surface all judgment calls to the user before acting - MUST NOT add features or refactors not in the plan - MUST report which steps were completed if execution halts mid-run - MUST end every execution with a terminal declaration - SHOULD run the project's defined gate suite (lint/test/typecheck) as a deliberate pre-commit gate when the work is committable code, map each plan step's outcome to its verification, and name any unverified step or skipped gate — never silently pass. Honor any project restriction on auto-running builds/tests. ## Next Steps - `/verify` — verify alignment after execution - `/plan-create` — revise the plan if execution surfaces scope gaps - `/plan-cleanup` — remove planning artifacts after execution is complete > **Human output.** This skill's handler-facing output obeys the human-output > contract (`human-output/SKILL.md`). > **Next skills.** On completion, run the Next Skills protocol (`next-skills/SKILL.md`): surface the `next-skills` recommendations from front-matter for the caller to pick. Offer only — never auto-invoke. > **Self-improvement.** On completion, run the Self-Improvement Protocol (`self-improve/SKILL.md`): if this run surfaced a concrete, blocking-or-recurring weakness in this skill, propose a specific fix for the handler to approve. Conservative — silent otherwise. Never auto-apply.