/execute

Execute an approved plan with precision — follow the plan exactly, surface any judgment calls, declare completion explicitly.

Structured execution spec: 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.