원클릭으로
executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when executing an implementation plan with four or more independent tasks touching different files, via the experimental agent-teams flag — parallel implementer teammates plus continuous async reviewers. Higher token cost; requires CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1.
Use when starting creative work — adding features, building components, adding functionality, modifying existing behavior, or any time the user describes a new idea or capability they want to build.
Use when adding, modifying, or removing database tables, columns, indexes, views, functions, or RLS policies — any schema change targeting a shared or production database
Use when facing two or more independent investigations or research tasks in the current session — debugging multiple unrelated failures, exploring different solution approaches, or running parallel reads. Not for executing implementation plans (use subagent-driven-development, agent-team-development, or tmux-parallel-development for those).
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 the app is slow, a specific operation takes too long, bundle size is too large, or you need to optimize resource usage — requires a measurable problem, not premature optimization
| name | executing-plans |
| description | Use when you have a written implementation plan to execute in a separate session with review checkpoints |
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."
Default: First 3 tasks
For each task:
When batch complete:
package.json, pyproject.toml, Cargo.toml, go.mod, Gemfile), prompt: "New dependency added — update tech_stack.md to reflect it?" Accept "skip" for incidental dev-only additions.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.
| Excuse | Reality |
|---|---|
| "The plan looks fine — I'll just start" | Critical review before execution catches gaps before sunk cost makes them costly to fix. Review first. |
| "This step is obvious — I can skip the verification" | The verification is the safety net for the obvious steps too. Run it. |
| "I'm on a roll — I'll do 6 tasks before reporting" | The 3-task batch is for review pacing, not throughput. Bigger batches mean later, harder course corrections. |
| "I hit a blocker but I think I can work around it" | Working around blockers hides root causes. Stop, ask, get unblocked the right way. |
| "Step 3 is ambiguous, but I'll pick what seems best" | Ambiguity is a bug in the plan. Ask, don't guess — guessing makes the plan author's intent invisible. |
| "I don't need to reference the skill the plan mentions — I know it" | Knowing ≠ using. Plans reference skills because that skill encodes the discipline the task needs. |
| "The plan needs an update — I'll just patch it as I go" | Stop and revisit Step 1 (review) with the partner. Silent in-place edits to the plan defeat checkpointing. |