一键导入
executing-plans
Use when executing written implementation plans linearly after written plan approval
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when executing written implementation plans linearly after written plan approval
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | executing-plans |
| description | Use when executing written implementation plans linearly after written plan approval |
Start only from an approved written implementation plan path. Read the plan, referenced spec, and codebase from disk. Do not rely on prior conversation context, even in same-session mode after plan approval.
Before each task commit, inspect staged files. If any path under docs/superpowers/ is staged, unstage it unless the user explicitly requested committing local Superpowers docs.
Use:
git diff --cached --name-only
git restore --staged docs/superpowers 2>/dev/null || true
Load plan, review critically, execute all tasks, report when complete.
Announce at start: "I'm using the executing-plans skill to implement this plan."
Note: If subagents are available and the plan's tasks are mostly independent, use superpowers:subagent-driven-development instead of this skill. Use this skill for linear plans, no-subagent runtimes, or tasks that require tight sequential control.
For each task:
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.
Required workflow skills:
Use when starting a new project from scratch or establishing project operating contracts, root CONTEXT.md, stack decisions, architecture summary, domain language, and a high-level roadmap before feature brainstorming
Use when executing implementation plans with mostly independent tasks in a fresh or same session after written plan approval
Use when an approved local design spec exists and an exact implementation plan is needed before code changes
Use when starting a conversation to route new-project setup requests to project-setup and make/build/create/implement app, site, tool, component, UI, API, workflow, or behavior requests to brainstorming before frontend, design, framework, or implementation skills
Use before make/build/create/implement requests for apps, sites, tools, components, UI, APIs, workflows, feature work, architecture changes, behavior changes, or unclear requirements; writes a local design spec before planning or coding
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.