| name | executing-plans |
| description | Use when partner provides a complete implementation plan to execute in controlled batches with review checkpoints - loads plan, reviews critically, executes tasks in batches, reports for review between batches |
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 plan file
- Review critically - identify any questions or concerns about the plan
- If concerns: Raise them with your human partner before starting
- If no concerns: Create TodoWrite and proceed
Step 2: Execute Batch
Default: First 3 tasks
For each task:
Mark as in_progress
Select appropriate agent using semantic understanding (NOT keyword matching):
Analyze task requirements:
- What is the task type? (implementation, debugging, review, docs)
- What is the complexity? (simple fix vs multi-component investigation)
- What technology? (Rust vs other languages)
Agent selection:
- Rust implementation →
cipherpowers:rust-agent - Complex, multi-layered debugging →
cipherpowers:ultrathink-debugger - Documentation updates →
cipherpowers:technical-writer - General implementation →
general-purpose
IMPORTANT: Analyze the task semantically. Don't just match keywords.
- ❌ "don't use ultrathink" → ultrathink-debugger (keyword match)
- ✅ "don't use ultrathink" → general-purpose (semantic understanding)
See selecting-agents skill for detailed selection criteria.
Dispatch agent with embedded following-plans skill:
Include in agent prompt:
IMPORTANT: You MUST follow the plan exactly as specified. Read and follow: @${CLAUDE_PLUGIN_ROOT}skills/following-plans/SKILL.md This skill defines when you can make changes vs when you must report BLOCKED. REQUIRED: Your completion report MUST include STATUS: - STATUS: OK (task completed as planned) - STATUS: BLOCKED (plan approach won't work, need approval for deviation) The plan approach was chosen for specific reasons during design. Do NOT rationalize "simpler" approaches without approval.Follow each step exactly (plan has bite-sized steps)
Run verifications as specified
Check agent completion status:
- STATUS: OK → Mark as completed, continue
- STATUS: BLOCKED → STOP, handle escalation (see Handling BLOCKED Status)
- No STATUS → Agent violated protocol, escalate
Step 3: Review Batch (REQUIRED)
After batch complete:
- Follow requesting-code-review skill to dispatch code-review-agent
- Fix BLOCKING issues before continuing to next batch
- Address NON-BLOCKING feedback or defer with justification
Code review is mandatory between batches. No exceptions.
Optional: If concerned about plan adherence, user can request /verify execute for dual-verification of batch implementation vs plan specification.
Step 4: Report
When batch complete:
- Show what was implemented
- Show verification output
- Say: "Ready for feedback."
Step 5: Continue
Based on feedback:
- Apply changes if needed
- Execute next batch
- Repeat until complete
Step 6: Complete Development
After all tasks complete and verified:
- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
- REQUIRED SUB-SKILL: Use cipherpowers:finishing-a-development-branch
- Follow that skill to verify tests, present options, execute choice
When to Stop and Ask for Help
STOP executing immediately when:
- Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
- Plan has critical gaps preventing starting
- You don't understand an instruction
- Verification fails repeatedly
Ask for clarification rather than guessing.
When to Revisit Earlier Steps
Return to Review (Step 1) when:
- Partner updates the plan based on your feedback
- Fundamental approach needs rethinking
Don't force through blockers - stop and ask.
Handling BLOCKED Status
Read the BLOCKED reason carefully
- What does agent say won't work?
- What deviation does agent want to make?
Review plan and design context
- Why was this approach chosen?
- Was the agent's "simpler" approach already considered and rejected?
Ask user what to do via AskUserQuestion:
Agent reported BLOCKED on: {task} Reason: {agent's reason} Plan specified: {planned approach} Agent wants: {agent's proposed deviation} Options: 1. Trust agent - approve deviation from plan 2. Revise plan - update task with different approach 3. Enforce plan - agent must follow plan as written 4. Investigate - need more context before decidingExecute user decision:
- Approve → Update plan, re-dispatch agent with approved approach
- Revise → Update plan file, re-dispatch agent
- Enforce → Re-dispatch agent with stronger "follow plan" guidance
- Investigate → Pause execution, gather more information
Never approve deviations without user input.
Related Skills
Agent selection guidance:
- Selecting Agents:
${CLAUDE_PLUGIN_ROOT}skills/selecting-agents/SKILL.md
Code review workflow:
- Requesting Code Review:
${CLAUDE_PLUGIN_ROOT}skills/requesting-code-review/SKILL.md
Finishing work:
- Finishing a Development Branch:
${CLAUDE_PLUGIN_ROOT}skills/finishing-a-development-branch/SKILL.md
Plan compliance:
- Following Plans:
${CLAUDE_PLUGIN_ROOT}skills/following-plans/SKILL.md
Remember
- Review plan critically first
- Embed following-plans skill in agent prompts
- Select the right agent using semantic understanding (not keyword matching)
- Check for STATUS in agent completions
- Handle BLOCKED status by asking user (never auto-approve deviations)
- Code review after every batch (mandatory)
- User can request
/verify executeif concerned about plan adherence - Don't skip verifications
- Reference skills when plan says to
- Between batches: just report and wait
- Stop when blocked, don't guess