메뉴
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | sr-executing-plans |
| description | Use when you have a written implementation plan to execute in a separate session with review checkpoints |
Upstream Superpowers' executing-plans skill dropped its "execute a
batch of 3, report, continue" pattern in early March 2026 (commit
3bdd66e), based on regression data showing batch-and-stop added
~25 min of overhead without measurably improving plan quality. Their
replacement flow is "execute all tasks, report when complete."
Super-Ralph deliberately preserves the 3-task batch pattern here.
sr-executing-plans is the dedicated "parallel session with
human-checkpoint fallback" path offered in sr-writing-plans's
Execution Handoff. Harnesses that don't have good subagent support
(e.g., bare terminals, plugin-less Gemini CLI, headless CI without
Task tool access) rely on this serialized, checkpoint-driven flow —
that's the UX contract we're preserving. Harnesses with good subagent
support should prefer sr-subagent-driven-development and get the
single-pass behavior Superpowers upstream adopted.
If you're extending this skill, keep the batch pattern intact. If you
want unbatched execution, use sr-subagent-driven-development.
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 sr-executing-plans skill to implement this plan."
Default: First 3 tasks
For each task:
When batch complete:
Based on feedback:
After all tasks complete and verified:
STOP executing immediately when:
Ask for clarification rather than guessing.
Return to Review (Step 1) when:
Don't force through blockers - stop and ask.
Stop and reassess if you catch yourself:
Use when starting any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when the user explicitly requests a code review, or during subagent-driven development where review is part of the workflow
Use when executing implementation plans with independent tasks in the current session
