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
Plan directory format (.claude/plans/<plan-id>/):
- Read orchestration plan at
plan.mdand manifest atmanifest.json - For each task in the current batch, read its briefing file from
briefings/task-NN.md - Only load briefings for the current batch (default 3), not all tasks at once
- 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
Legacy monolithic format (docs/plans/*.md):
- Read the plan file directly
- Follow the same review and batch process below
Format detection: If the path contains manifest.json or points to a directory, use plan directory format. If it points to a .md file, use legacy format. If no path given, check .claude/plans/ for the most recent directory, fall back to docs/plans/ for the most recent .md.
Step 2: Execute Batch
Default: First 3 tasks
For each task:
- Mark as in_progress
- Follow each step exactly (briefing files have bite-sized steps)
- Run verifications as specified in the briefing's Success Criteria
- 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 (load next batch's briefing files)
- Repeat until complete
Step 5: Complete Development
After all tasks complete and verified:
- If using plan directory format, clean up:
- Optionally write
.claude/plans/<plan-id>/summary.mdwith execution notes - Delete the plan directory:
rm -rf .claude/plans/<plan-id>/ - If deletion fails, warn but do not block
- Optionally write
- Announce: "I'm using the git-workflow skill to complete this work."
- REQUIRED SUB-SKILL: Use git-workflow stack
- Follow that skill to verify tests, present options, execute choice
Guardrails
Stop and ask when blocked — don't guess. See references/guardrails.md for full stop conditions and checklist.
Integration
Required workflow skills:
- git-workflow - REQUIRED: Worktrees for isolated workspaces, stack for completing development
- writing-plans - Creates the plan this skill executes
More from hjewkes/agent-skills
self-improve
Use when a session produced reusable insights, when the user says "learn from this", "remember this", or "improve yourself", or after completing a complex task where patterns were discovered
65md-render
Use when asked to render, preview, or view a markdown file in the browser. Triggers on "render markdown", "preview this", "show me this document", "open in browser".
21code-review
Unified code review system — dispatches the right review agents for the situation. Use when reviewing code for quality, bugs, compliance, or before merging.
17skills-management
Use when creating, finding, installing, reviewing, or managing Claude Code skills — covers skill authoring, discovery, conventions, and lifecycle management
14github-pr
GitHub PR workflow — creating PRs, posting automated review comments, managing PR feedback cycles. Use when code is reviewed and ready for GitHub.
14buildkite
Buildkite CI/CD integration. Use when the user needs to check build status, trigger builds, read build logs, debug failures, manage pipelines, or any Buildkite workflow. Triggers include "buildkite", "build", "pipeline", "CI", "deploy", "build log", "build failed".
14