| name | executing-plans |
| description | 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". |
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
- Read the plan file completely
- 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
- If concerns exist: Raise them with your partner before proceeding. Getting alignment now saves many hours of wrong execution
- 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:
- Mark it as in_progress in your tracker
- Follow the plan's steps exactly — they're designed to be small and verifiable
- Run the specified verifications before marking done — this catches mistakes early
- If verification fails: stop, report it, and wait for guidance
- 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:
git worktree add ../feature-work -b feature/my-feature
This prevents accidents on main and lets you abandon bad experiments cleanly.
