Executing Plans

Indexed Reference Map

• @[SKILL.md#L1-L100] Frontmatter, trigger rules, SOP, output contract.
• @[references/INDEX.md#L1-L17] Reading order and reference inventory.
• @[references/execution-loop.md#L1-L14] Phase-by-phase execution loop.
• @[references/checkpoint-discipline.md#L1-L8] Rules for stop points, approvals, and verification gates.
• @[references/scope-guard.md#L1-L7] How to avoid improvisational scope drift.
• @[references/examples.md#L1-L11] Example execution patterns.

Scope

• In-scope:
  • Executing a pre-existing written plan.
  • Following ordered steps with checkpoints and verification.
  • Reporting progress against the plan rather than freeform implementation logs.
• Out-of-scope:
  • Writing the initial plan from scratch.
  • Ad-hoc coding with no plan artifact.
  • Final review/merge workflow after execution is complete.

KB Mode Notes

• Reading order:
  1. references/INDEX.md
  2. references/execution-loop.md
  3. references/checkpoint-discipline.md
  4. references/scope-guard.md
  5. references/examples.md
• Coverage Matrix:
  • Core execution flow -> execution-loop.md
  • Checkpoints/gates -> checkpoint-discipline.md
  • Scope containment -> scope-guard.md
  • Example patterns -> examples.md
• Portability note:
  • The skill assumes a plan already exists. If the plan is weak or missing, hand back to planning instead of improvising.

Trigger Rules

• Positive:
  • User already has a written plan and wants it executed.
  • Prompt contains intent like: execute this plan, follow the plan, do phase 1, continue with the roadmap, implement according to the plan.
  • The main need is disciplined execution with checkpoints, not creating a plan.
• Negative:
  • No actual plan exists yet.
  • The user is asking for a plan, not execution.
  • The task is mostly debugging or review-handling rather than plan execution.
• Escalation:
  • If the supplied plan is incomplete or unsafe, stop and repair the plan before execution.
  • If a checkpoint requires approval or evidence before continuing, pause at that boundary.

SOP

1. Load the plan
   • Identify objective, scope, phases, checkpoints, and verification hooks.
2. Restate the current phase
   • Execute one bounded phase at a time.
3. Verify prerequisites
   • Confirm required inputs/state before mutating anything.
4. Execute only the current scoped step
   • Do not silently pull in adjacent work.
5. Run the planned verification
   • Treat verification as part of the phase, not optional follow-up.
6. Record status against the plan
   • Mark done / blocked / partial with reason.
7. Pause at checkpoints
   • Especially before risky changes, live cutovers, or external actions.
8. Escalate drift early
   • If reality diverges from the plan, stop and request a plan update instead of improvising.

Error Handling

• Plan missing critical details:
  • Return to planning and fill the gap before proceeding.
• Phase blocked by missing dependency/evidence:
  • Mark blocked and state the exact unblocker.
• New issue appears mid-execution:
  • Contain it to the current phase if possible; otherwise pause and re-plan.
• User pressures for shortcut past checkpoint:
  • State the risk and required verification/approval.

Output Contract

• Deliverable:
  • Plan Objective: what is being executed.
  • Current Phase: the bounded step.
  • Execution: actions taken.
  • Verification: proof for the current phase.
  • Status: DONE|PARTIAL|BLOCKED.
  • Next Checkpoint: what gates the next move.
  • Plan Drift: none / observed issue.
• Validation:
  • Must stay anchored to the provided plan.
  • Must not skip verification that the plan depends on.
• Compliance Verdict:
  • PASS when execution remains plan-bound and verified; otherwise PARTIAL or FAIL.