القائمة
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. |