soleri-executing-plans

name	soleri-executing-plans
tier	default
description	Triggers: "execute my plan", "run the plan", "start executing", "implement the plan". Sequential task execution with review checkpoints. Use parallel-execute for concurrent.

Executing Plans

Load plan, review critically, execute tasks in batches, report for review between batches.

Announce at start: "I'm using the executing-plans skill to implement this plan."

The Process

Step 1: Load and Review Plan

YOUR_AGENT_core op:get_plan
YOUR_AGENT_core op:plan_list_tasks
  params: { planId: "<id>" }
YOUR_AGENT_core op:plan_stats

If no tracked plan exists, read from docs/plans/. Review critically — raise concerns before starting.

Step 2: Start Execution Loop

YOUR_AGENT_core op:loop_start
  params: { prompt: "<plan objective>", mode: "custom" }

Step 3: Execute Batch (default: first 3 tasks)

For each task:

1. op:update_task — mark in_progress
2. Follow each step exactly
3. Run verifications as specified
4. op:update_task — mark completed
5. op:loop_iterate — track progress

Step 4: Report

Show what was implemented, verification output, loop status. Say: "Ready for feedback."

Step 5: Continue

Apply feedback, execute next batch, repeat until complete.

Step 6: Complete Development

1. Run final verification (use verification-before-completion skill)
2. YOUR_AGENT_core op:loop_complete
3. YOUR_AGENT_core op:plan_reconcile — compare planned vs actual
4. YOUR_AGENT_core op:plan_complete_lifecycle — extract knowledge, archive
5. YOUR_AGENT_core op:session_capture — save session context

Capture mid-execution learnings with op:capture_quick as they happen — don't wait until the end.

When to Stop

• Hit a blocker (missing dependency, unclear instruction, repeated test failures)
• Plan has critical gaps
• Don't understand an instruction

Ask for clarification rather than guessing.

Common Mistakes

• Not reviewing the plan critically before starting
• Skipping verifications to save time
• Guessing through blockers instead of stopping to ask
• Forgetting to reconcile the plan after execution (drift data improves future plans)
• Starting implementation on main/master without explicit consent

Rationalization Prevention

Do NOT rationalize away failures. If a verification step fails, the task is not complete.

• HARD-GATE: Each task's verification must pass before marking it completed.
• HARD-GATE: Final verification (Step 6) must pass before plan_reconcile. Do not reconcile a failing plan.
• Do not say "this task is basically done" when its verification has not run.
• Do not skip verification steps "to save time" -- they exist for a reason.
• Do not mark a task completed while its tests fail, even if the code "looks right."
• If a task is blocked or failing, leave it in_progress and report honestly.
• Do not treat reconciliation drift as permission to ignore failures.

Quick Reference

Op	When to Use
get_plan / plan_list_tasks / plan_stats	Load plan
update_task	Mark task status
loop_start / loop_iterate / loop_complete	Validation loop
plan_reconcile	Post-execution drift report
plan_complete_lifecycle	Extract knowledge, archive
session_capture	Save session context
capture_quick	Mid-execution learnings

Related skills: writing-plans, verification-before-completion, test-driven-development