executing-planslisted

# Executing Plans ## Overview Take a finished plan and build it, in small batches with a review checkpoint after each one. The batching is the point: a checkpoint every few tasks lets a reviewer catch a wrong turn while it's cheap to fix, instead of after twenty tasks have been built on top of it. **Announce at start:** "I'm using the executing-plans skill to implement this plan." ## Commits By default, hold commits until a batch has been reviewed, so the full diff is available to review. The reviewer gives feedback, then the approved work is committed. If you'd rather commit per task (useful for unattended runs), pass `--auto-commit`. ## The process ### 1. Load and review the plan Read the plan and review it critically before touching code. If it has a blocking gap or ambiguity that would force you to guess, raise it with the partner first, guessing here is how execution silently diverges from intent. If it's clear, make a task list and start the first batch in the same response. ### 2. Execute a batch Default to three tasks per batch. For each task: 1. Mark it in progress. 2. Follow the plan's steps exactly, they're already bite-sized. 3. For code, use the test-first cycle: write the test, watch it fail for the right reason, write the minimal code, watch it pass, refactor if needed. 4. Run the verifications the task specifies. 5. Prove the output is real: run the feature with representative input and confirm it produces actual computed data, not an empty or hardc