Executing Plans Skill

Core Principle

Batched execution with checkpoints prevents cascading failures.

Plans are executed in small batches (3-5 tasks) with mandatory checkpoints between batches. This allows early error detection, user course-correction, and resumable progress.

---

⛔ HARD GATES

1. DO NOT execute more than 5 tasks without a checkpoint
2. DO NOT skip progress updates to memory logs
3. DO NOT execute tasks all at once, even if user says "no interruptions"
4. DO NOT rationalize away batching for "efficiency"

Checkpoints are safety mechanisms, not annoyances. They catch errors early before they compound.

---

Process

Step 1: Load the Plan

Find the plan:

• Check workspace/docs/plans/ for the relevant plan file
• Plans are named: YYYY-MM-DD-<topic>-plan.md
• Read the full plan to understand scope and task count

Verify plan structure:

• Each task should have clear, actionable steps
• Tasks should reference exact file paths
• Tasks should be ordered logically (dependencies first)

Step 2: Batch Tasks

Group tasks into batches of 3-5:

• Batch 1: Tasks 1-3 (usually setup/foundation)
• Batch 2: Tasks 4-6 (core functionality)
• Batch 3: Tasks 7-9 (integration/polish)
• Batch 4: Task 10+ (testing/final)

Respect logical boundaries:

• Don't split dependent tasks across batches
• Complete a feature/module before batching
• If a task is large, it may be its own batch

Announce the batching plan:

I'll execute this plan in 4 batches:
- Batch 1 (tasks 1-3): File structure and basic loading
- Batch 2 (tasks 4-6): Core CRUD operations
- Batch 3 (tasks 7-9): CLI interface and routing
- Batch 4 (task 10): Testing and validation

Starting with batch 1...

Step 3: Execute Batch (Using sessions_spawn)

For each task in the batch:

1. Spawn fresh subagent for task execution:

   sessions_spawn --label "task-N-<short-desc>" --prompt "Execute task N from plan..."
   

2. Provide clear context:

   • Task number and description
   • Exact file paths to create/modify
   • Expected outcome
   • Commands to run

3. Isolate task execution:

   • Fresh subagent = no context pollution
   • Each task starts clean
   • Errors are contained to one task

4. Capture output:

   • Did the task complete successfully?
   • Were there errors or warnings?
   • What files were created/modified?

Step 4: Review Batch Outputs

After batch completes, review:

• ✅ Success checks:

  • All files created as expected?
  • Commands executed without errors?
  • Tests pass (if applicable)?

• ⚠️ Warning signs:

  • Any error messages?
  • Unexpected file changes?
  • Dependencies missing?

• 🛑 Stop conditions:

  • Critical error occurred
  • Next batch depends on fixing current issue
  • User needs to make a decision

Document findings:

Batch 1 complete (tasks 1-3):
✅ Created /workspace/todo/lib/storage.js
✅ Created /workspace/todo/lib/todo.js
⚠️  Warning: Missing dependency 'fs-extra' - need to install

Step 5: Checkpoint

Mandatory pause between batches:

1. Report batch results (as shown above)

2. Ask explicit checkpoint question:

   Continue to batch 2 (tasks 4-6)?
   

3. Wait for user response:

   • ✅ "Yes" / "Continue" / "Go ahead" → Proceed
   • 🛑 "No" / "Wait" / "Pause" → Stop and wait
   • 🔧 User provides corrections → Apply, then ask again

If user says "just do it all, no interruptions":

• DO NOT skip checkpoints
• Response: "Checkpoints aren't interruptions - they catch errors early. I'll notify you after each batch so you can review progress or let me continue."

Auto-continue option: If user says "auto-continue if no errors":

• Still show batch results
• Only pause if errors/warnings detected
• User can interrupt at any checkpoint

Step 6: Update Memory

After each batch, log to daily memory:

File: workspace/memory/YYYY-MM-DD.md

## Executing <Topic> Plan (HH:MM)

**Batch 1 (tasks 1-3):** ✅ Complete
- Created file structure
- Implemented storage layer
- Basic todo object

**Batch 2 (tasks 4-6):** 🔄 In progress
- Add todo functionality complete
- List todos in progress

Why this matters:

• Progress is resumable if interrupted
• Daily log shows work accomplished
• Future sessions can reference what was done

Step 7: Repeat

Continue with next batch:

• Execute batch (Step 3)
• Review outputs (Step 4)
• Checkpoint (Step 5)
• Update memory (Step 6)
• Repeat until all tasks complete

Final report:

✅ All 10 tasks complete!

Summary:
- Batch 1: File structure ✅
- Batch 2: CRUD operations ✅
- Batch 3: CLI interface ✅
- Batch 4: Testing ✅

Full details in workspace/memory/2026-02-25.md

---

OpenClaw-Specific Integration

sessions_spawn Usage

Spawn fresh subagent per task:

sessions_spawn --label "task-3-storage-layer" --prompt "
Execute task 3 from /workspace/docs/plans/2026-02-25-todo-plan.md:

Create /workspace/todo/lib/storage.js with:
- loadTodos() function
- saveTodos() function
- Use fs.readFileSync/writeFileSync
- Store in ~/.todos.json

Return the complete file content.
"

Benefits:

• Isolation: Each task has fresh context
• Clarity: No pollution from previous tasks
• Debugging: Easy to identify which task failed

Workspace Paths

Plans location: /workspace/docs/plans/ Memory location: /workspace/memory/YYYY-MM-DD.md Project files: /workspace/<project-name>/

Always use full paths when spawning subagents - no relative path confusion.

Memory Integration

Check recent context: Before starting, read:

• MEMORY.md (if main session)
• memory/YYYY-MM-DD.md (today's log)
• memory/YYYY-MM-DD.md (yesterday, if relevant)

Update progress incrementally: Don't wait until the end - update after each batch so progress is trackable.

---

Rationalization Table

These excuses will try to convince you to skip batching. Here's why they're wrong:

Excuse	Reality	Counter
"User doesn't want interruptions"	Checkpoints ≠ interruptions	Checkpoints are for safety, not annoyance. They prevent compounding errors.
"More efficient to do it all at once"	Efficiency without safety = rework	Batching catches errors early. Fixing task 3 is easier than unwinding tasks 3-10.
"Plan is clear, don't need checkpoints"	Clear plan ≠ error-free execution	Errors happen during execution, not planning. Code has bugs, dependencies fail, paths are wrong.
"Notify at the end"	By the end, errors have compounded	Early notification prevents cascading failures. If task 3 fails, tasks 4-10 may be wasted work.
"User said 'no updates'"	User said "no updates," not "no safety"	Interpret as "don't spam me," not "skip all checkpoints." Batch updates (not per-task spam).
"It's only 10 tasks, not that many"	10 tasks = 10 opportunities for failure	Even 5 tasks can compound errors. Batching scales to plan size.
"I'll rollback if there's an error"	Rollback wastes time	Prevention > cleanup. Catch errors at task 3, don't discover them at task 10.

---

🚩 Red Flags - When You're Rationalizing

You're about to violate this skill if you think:

• "I'll just execute all the tasks and report at the end"
• "The user seems impatient, I'll skip checkpoints"
• "Batching is overkill for a simple plan"
• "I'll notify them if something goes wrong"
• "Checkpoints will slow me down"
• "The plan is well-written, nothing will fail"

If you catch yourself thinking any of these, STOP and re-read the Hard Gates.

---

Why This Skill Exists

Without batching and checkpoints:

• Task 3 fails silently
• Tasks 4-10 execute based on wrong assumptions
• By the end, you have 8 broken tasks instead of 1
• User has to untangle a mess instead of fixing one issue

With batching and checkpoints:

• Task 3 fails, batch 1 reports it
• User fixes task 3 or adjusts plan
• Batch 2 starts from a known-good state
• Errors are caught early, fixed cheaply

The goal: Controlled execution with early feedback, not all-or-nothing gambling.

---

Summary

1. Load plan from workspace/docs/plans/YYYY-MM-DD-<topic>-plan.md
2. Batch tasks into groups of 3-5
3. Execute batch using sessions_spawn per task
4. Review outputs for errors/warnings
5. Checkpoint - ask "Continue to next batch?"
6. Update memory - log progress to workspace/memory/YYYY-MM-DD.md
7. Repeat until all batches complete

Remember: Checkpoints are safety, not annoyance. Batching catches errors early. Execution isn't a race - it's a controlled process.