# Executing Plans Skill

A plan's value is realised or destroyed at execution time. The two failure modes: *rigid* execution (following a plan reality has invalidated) and *drift* (quietly improvising until the work no longer resembles the plan and nobody decided that). The discipline is the same for both: deviations are decisions, made visibly.

## What This Skill Produces

- The work, executed step-by-step with per-step verification actually run
- An **execution log**: step → result → verification outcome → any deviation with its reason
- A **plan feedback note**: what the plan got wrong (feeds the next plan)

## Execution Method

1. **Load the plan and check it's still true.** Before step 1: do the plan's assumptions still hold (the branch, the data, the constraint)? A plan written yesterday can be stale today; two minutes of validation beats an hour of executing a fiction.
2. **One step, then its verification — actually run.** The verification isn't decoration: run the command, check the observable, record the result. Advancing on "that probably worked" is how step 6 fails mysteriously because step 3 silently didn't.
3. **Classify every divergence out loud.** When reality disagrees with the plan, stop and classify:
   - **Plan-preserving detail** — the plan's intent holds, the mechanics differ slightly → note it in the log, continue
   - **Plan deviation** — the approach must change for this step → *amend the plan visibly* (strikethrough + new step), state why, continue
   - **Plan invalidation** — a stop condition hit, or the goal itself is now wrong → STOP; report; replan with the human before another line of work
   The cardinal sin is treating an invalidation as a detail because stopping feels like failure.
4. **Respect the stop conditions absolutely.** They were written calm; you are now in flow and biased toward momentum. The "must not do" list doesn't bend for convenience — if it should, that's a visible plan amendment, decided, not slid into.
5. **Checkpoint on schedule.** At each planned checkpoint (or ~every 30-45 min of work): where am I vs the plan, what's the log show, is the remaining plan still right? Multi-session work ends each session with a state note: done through step N, next action, open questions — the resume beats re-derivation.
6. **Close with the feedback loop.** At completion: run the plan's DONE test (not your feeling of doneness). Then write the plan feedback: which estimates were off, which risk fired, which verification caught something. Plans improve only if execution reports back.

## Output Format

**Per step (in the log):**
`Step N: [action] → [result] · verify: [check run → outcome] · [deviation? classified + reason]`

**On completion:**
### Execution report: [plan name]
**Done test:** [the plan's test → passed/failed, evidence]
**Deviations:** [each, with classification and reason — or "none"]
**The plan was wrong about:** [feedback for the next plan]
**Follow-ups discovered (not done, not forgotten):** […]

## Quality Checks

- [ ] Every step's verification was actually executed, result recorded
- [ ] Every divergence was classified (detail / deviation / invalidation) — none absorbed silently
- [ ] Stop conditions were honoured; any override was a visible, stated decision
- [ ] Completion was declared by the plan's done-test, not by fatigue
- [ ] The plan-feedback note exists

## Anti-Patterns

- [ ] Do not improvise around a broken plan — amend it visibly or stop; silent drift is unaccountable work
- [ ] Do not skip verifications when steps "obviously worked" — the mysterious step-6 failure was born at step 3
- [ ] Do not push through a stop condition on momentum — it was written calm precisely because you wouldn't be
- [ ] Do not declare done without running the done-test — feeling-finished and being-finished diverge exactly when it matters
- [ ] Do not end a session without the state note — re-derivation is the tax on every resumed task
