# Executing Plans > Execute a written implementation plan with review checkpoints and structured progress tracking. Use when you have a spec or plan ready to implement, when user says "execute this plan", "implement this spec", "carry out these steps", or "start working on the plan". - Skill: `ckorhonen/executing-plans` (Agent Skill) - Install (CLI): `npx skillmds@latest add ckorhonen/executing-plans` - Raw SKILL.md: https://api.skillmd.com/api/skills/ckorhonen/executing-plans/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: ckorhonen (https://skillmd.com/u/ckorhonen) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/ckorhonen/executing-plans --- # 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 1: Load and Review Plan 1. Read the plan file completely 2. Review it critically — this is where you catch flaws before they become expensive rework. Look for: - Steps that seem vague or contradictory - Missing dependencies or setup - Assumptions that don't hold in your actual codebase - Technical choices you'd question 3. If concerns exist: Raise them with your partner before proceeding. Getting alignment now saves many hours of wrong execution 4. If the plan looks solid: Create a todo tracker and proceed to Step 2 ### Step 2: Execute Batch **Default: First 3 tasks per batch** The checkpoint-driven approach (3 tasks, pause for feedback, continue) gives your partner visibility and prevents you from building on a flawed foundation. For each task in the batch: 1. Mark it as in_progress in your tracker 2. Follow the plan's steps exactly — they're designed to be small and verifiable 3. Run the specified verifications before marking done — this catches mistakes early 4. If verification fails: stop, report it, and wait for guidance 5. If verification passes: mark as completed and move to the next task Keep focus tight. Executing 3 tasks well and getting feedback is faster than executing 10 tasks blind and discovering you went the wrong direction halfway through. ### Step 3: Report When the batch is done, report clearly: - Show what was implemented (what changed, new files, modified code) - Show verification output (test results, error messages if any) - Summarize any unexpected findings or minor deviations from the plan - End with: "Ready for feedback." This pause-to-report is critical. It gives your partner a chance to course-correct before you invest more work. ### Step 4: Continue Your partner will respond. They might: - Approve and ask you to continue (execute next batch) - Point out an issue and ask for changes (go back to Step 1 or Step 2) - Change the plan based on new information (return to Step 1) Follow their guidance. The loop (Execute → Report → Feedback → Continue) prevents you from diverging. Once you've completed all batches and your partner approves, move to Step 5 (Complete Development). ### Step 5: Complete Development After all tasks complete and verified, finalize the branch. Verify all tests pass, ensure the working tree is clean, and then present options to the user: merge to main, open a PR, or keep the branch for further review. - Run the full test suite one final time - Confirm no untracked or uncommitted changes remain - Ask the user: merge now, open a PR, or leave for manual review ## When to Stop and Ask for Help Execution should pause for clarification when: - You hit a blocker mid-batch (missing dependency, test fails, instruction unclear) — continuing blind wastes effort - The plan has critical gaps preventing starting — you can't execute what doesn't exist - You don't understand an instruction — guessing is slower than asking - Verification fails repeatedly — this signals the plan may have flawed assumptions **Why this matters:** Stopping early prevents wasted work and lets your partner give you the right guidance. It's faster to pause and clarify than to build on a wrong foundation. ## When to Revisit Earlier Steps **Return to Review (Step 1) when:** - Your partner updates the plan based on your feedback — old review isn't valid anymore - Fundamental approach needs rethinking — new information changes strategy **Forcing through blockers creates debt.** A pause to reconsider is faster than fixing mistakes later. ## Remember - Review plan critically first - Follow plan steps exactly - Don't skip verifications - Reference skills when plan says to - Between batches: just report and wait - Stop when blocked, don't guess - Never start implementation on main/master branch without explicit user consent ## Common Pitfalls ### Agent Skips Review and Starts Executing Immediately **The problem:** Jumping straight to Step 2 (Execute Batch) without doing Step 1 (Load and Review Plan). This skips your chance to catch plan flaws before wasting work. **Why it happens:** Execution feels more productive than reading; the urge to "just start" is strong. **How to avoid it:** Force yourself to read the plan, write down questions, and raise them before marking the first task in_progress. Your review step is the highest-leverage time to prevent rework. ### Batch Size Too Large Causes Confusion **The problem:** Trying to execute 10+ tasks in a batch makes it hard to track what's done, what's blocked, and where verification failed. You lose the checkpoint benefit. **Why it happens:** Wanting to move fast, or misunderstanding "default: first 3 tasks" as a minimum instead of a safe default. **How to avoid it:** Stick to 3 tasks per batch unless the plan explicitly says otherwise. After you report and get feedback, you'll know if you should do bigger batches. Smaller batches = clearer reporting = faster feedback loops. ### Verification Failures Ignored **The problem:** A verification fails (test doesn't pass, output doesn't match expected), but you mark the task completed anyway and move on. This compounds — later tasks depend on earlier ones working. **Why it happens:** The temptation to "mark it done" and push forward. Verification feels like optional polish. **How to avoid it:** If verification fails, that task is not done. Stop the batch, report the failure, and wait for guidance. The plan may have a flaw or you may have misunderstood a step. Your partner needs to know. ### Plan Becomes Stale Mid-Execution **The problem:** You're halfway through executing, and your partner realizes the plan needs updating (scope changed, tech choice was wrong, new blocker discovered). But you keep executing the old plan. **Why it happens:** You're focused on the tasks in front of you; you don't realize the plan has been superseded. **How to avoid it:** After reporting each batch, read your partner's response carefully. If they mention plan changes, go back to Step 1 (Review) even if you're already partway through. Fresh context beats forward momentum. ## Integration **Related workflow skills:** - **writing-plans** — Generates the plan that this skill executes. This skill assumes a well-structured plan exists; if you need to create one, refer to that skill first. - **brainstorming** — Produces the design that feeds into writing-plans. Run brainstorming → writing-plans → executing-plans for the full workflow. **Git worktree tip:** Before executing a plan, consider running in an isolated git worktree so your work is sandboxed from main: ```bash git worktree add ../feature-work -b feature/my-feature ``` This prevents accidents on main and lets you abandon bad experiments cleanly.