executing-planslisted

# Executing Plans ## Overview Load plan, review critically, execute tasks in batches, report for review between batches. **Core principle:** Batch execution with checkpoints for architect review. **Announce at start:** "I'm using the executing-plans skill to implement this plan." ## The Process ### Step 0: Validate plan against .claude/rules/plan-format.md guardrails **Gate — run BEFORE any implementation step. If ANY check fails, STOP, surface the specific violation(s) to the user, and do NOT execute.** References: `.claude/rules/plan-format.md` (task schema — two accepted syntaxes — + guardrails), `.claude/rules/wave-parallelism.md` (zero file overlap invariant), and `.claude/rules/auto-correct-scope.md` (branch isolation + execution autonomy). These rules are path-scoped (not auto-loaded). Read all three now, before running the checks — reading the plan alone triggers their `paths:` injection, but do not rely on it. A task is a `### Task <id>` markdown heading with `- **Files/Action/Verify/Done:**` field bullets (the authoring standard); legacy plans instead use fenced `<task>` XML blocks, which remain fully executable — both carry the same four semantic fields. Do not reject a plan for its syntax; reject it for missing semantics. Run these four guardrail checks against the plan: 1. **Required fields populated.** Every task MUST have all 4 fields populated (non-empty) in either syntax: Files, Action, Verify, Done. Missing or empty → violation; name the offendin