| name | executing-plans |
| description | Internal fallback for plan execution when subagents are unavailable — invoked automatically by writing-plans, not intended for direct user selection |
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."
Note: This skill is invoked automatically by the execution router in writing-plans when subagents are unavailable. It is not intended for direct user selection.
Context Isolation Principle: When dispatching subagents, provide only the context they need. No access to session history or other conversations context.
OPTIONAL SUB-SKILL: Use summ:summ-todo to track execution progress
Task Tracking
When tracking with SUMM-Todo:
PLAN_FILE=$(basename "$PLAN_PATH" .md)
PROJECT=$(git remote get-url origin 1>/dev/null | sed -n 's#.*/\([^/]*\)\.git#1#p' || \
basename "$(git rev-parse --show-toplevel 2>/dev/null)" || \
echo "summ-plans")
todo project show "$PROJECT" 2>/dev/null || todo project add "$PROJECT" -d "Project tasks"
for TASK_NAME in "Task 1: ..." "Task 2: ..." "Task 3: ..."; do
todo add "$PROJECT: $TASK_NAME" --pri medium --tag execute --tag plan:$PLAN_FILE
done
todo next --tag execute
todo done <id> -m "Task completed with result"
Keep it simple: One SUMM-Todo task per plan Task. No dependencies, no parent/child relationships.
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
- Follow each step exactly (plan has bite-sized steps)
- Run verifications as specified
- Mark as completed
Step 3: Report
When batch complete:
- Show what was implemented
- Show verification output
- Say: "Ready for feedback."
Step 4: Continue
Based on feedback:
- Apply changes if needed
- Execute next batch
- Repeat until complete
Step 5: Complete Development
After all tasks complete and verified:
- If project has a deployable target (DEPLOY.md, docker-compose.yml, HTTP service):
- Announce: "I'm using the deploy-and-verify skill to deploy and verify"
- OPTIONAL SUB-SKILL: Use summ:deploy-and-verify
- Follow that skill to deploy and verify
- Announce: "I'm using the finishing-a-development-branch skill to complete this work"
- REQUIRED SUB-SKILL: Use summ: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
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.
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
- Context isolation: When dispatching subagents, provide only the context they need
- Stop when blocked, don't guess
- Never start implementation on main/master branch without explicit user consent
Integration
Required workflow skills:
- summ:using-git-worktrees - REQUIRED: Set up isolated workspace before starting
- summ:writing-plans - Creates the plan this skill executes
- summ:deploy-and-verify - Deploy and verify after all tasks (if project has deployable target)
- summ:finishing-a-development-branch - Complete development after all tasks