Executing Plans (Batch Execution + Checkpoints)

Goal

Reliably turn a "written plan file" into implementation results, avoiding drift or accumulated risk from doing everything at once.

Core strategy: Batch execution + pause for feedback after each batch.

Input/Output (Recommended for Chaining)

Input (pass paths only):

• plan_path: Plan file (usually in run_dir/03-plans/)
• repo_root
• run_dir

Output (persisted):

• Plan execution status: logs/state.json (or 03-plans/<plan>-status.md)
• Per-batch verification evidence: append to the corresponding plan file or 05-final/ summary

Execution Flow

Step 1) Read and Review Plan (Critical Review First)

1. Read plan_path
2. Review if the plan has these issues:
   • Missing dependencies (packages to install/env vars/external services)
   • Task granularity too large (can't verify, hard to rollback)
   • Missing acceptance criteria or verification commands
   • Obviously wrong task ordering
3. If critical issues found: Stop first, present concerns as 1-3 bullet points, let human confirm before starting execution.

Rule: Don't "guess while doing". Clarify when plan is unclear.

Step 2) Batch Execution (Default 3 Tasks per Batch)

Execute the first 3 tasks from the plan, then stop and report.

For each task:

1. Mark as in_progress
2. Execute strictly per plan (don't expand scope)
3. Run verification per plan (tests / build / typecheck / lint / manual verification steps)
4. Mark as completed

Status recording (choose one, prefer structured):

• Update task status in logs/state.json
• Or maintain checklist in plan_path ([ ]→[x]), recording verification results alongside

Step 3) Batch Report (Must Pause for Feedback)

After each batch, report three things:

• What changed: Which files changed/what was implemented (brief)
• Verification: What verification was run, what were the results (key info only, no long logs)
• Next batch: Which 3 tasks are next

Optional but recommended:

• Use review-merge-readiness for a conclusive review on this batch (especially for cross-module changes, risky changes, or approaching merge)

Last line must be:

Ready for feedback.

Then wait for human feedback—don't automatically continue to next batch.

Step 4) Continue Based on Feedback

• If feedback requests changes: fix first, re-verify, then continue next batch
• If feedback is OK: continue to next batch (still default 3 tasks)

Step 5) Wrap Up (After All Complete)

When all tasks are complete and verified:

• Run full tests/build (per project conventions)
• Write 05-final/summary.md (what was done/how verified/risks & rollback/next steps)
• Do a skill-evolution Evolution checkpoint (3 questions); if user chooses "want to optimize", run skill-improver based on this run_dir to produce minimal patch suggestions
• If finishing-a-development-branch skill exists: follow that skill to complete merge/PR/cleanup options

When to Stop and Ask for Help (Hard Rules)

Encounter any of these, stop execution immediately and report the issue:

• Blocked mid-way (missing dependency, wrong environment, permission issues)
• Tests/verification failed and can't quickly identify the cause
• Plan step unclear (can't determine correct implementation approach)
• Action that could cause data loss or wide-ranging side effects appears but plan doesn't include confirmation point

Remember

• Review plan critically before starting
• Small batch execution (default 3 tasks)
• Every batch requires verification and reporting, then wait for feedback
• When blocked, stop—don't guess