plan-execution

# Plan Execution Turn an accepted plan into reviewable evidence while preserving the user's work and authority boundaries. ## Preconditions - Confirm the requested action includes implementation. A plan alone is not authorization to mutate the repository. - Re-read the original request, accepted plan, repository instructions, and current status before the first edit. - Preserve staged, unstaged, and untracked user work. Never reset, clean, stash, overwrite, or reformat unrelated files. - Treat commit, push, pull request, issue mutation, deployment, infrastructure apply, external messaging, and publication as separate authorities. - Stop rather than weaken an assertion, skip a gate, broaden an exclusion, or hide a warning. ## Workflow 1. **Reconcile the plan:** Verify that paths, symbols, dependency versions, commands, and assumptions still match the checkout. Amend the execution notes when reality differs; request direction if the required outcome would materially change. 1. **Capture the baseline:** Record branch, HEAD, status, relevant test state, and known external boundaries. Identify which existing edits belong to the user. 1. **Order the work:** Follow the dependency graph and critical path. Choose the smallest vertical slice that produces independently useful behavior and proof. 1. **Establish red evidence:** Use [test-driven-development](../test-driven-development/SKILL.md) for behavior changes or create a characterization test when changing legacy behavior. For ...