菜单
Use to execute an implementation plan yourself, inline in this conversation, with review checkpoints. The simpler alternative to subagent-driven-development - use it for small plans or when the agents feature is off. Works in an isolated git worktree.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | Executing Plans |
| description | Use to execute an implementation plan yourself, inline in this conversation, with review checkpoints. The simpler alternative to subagent-driven-development - use it for small plans or when the agents feature is off. Works in an isolated git worktree. |
Load the plan, review it critically, execute every task in order, and report when complete. This is the inline path — you do the work yourself rather than dispatching sub-agents. For larger plans, or to keep context lean and run cheaper, prefer the subagent-driven-development skill instead.
Announce at start: "I'm using the executing-plans skill to implement this plan."
open_skill → using-git-worktrees) to create and cd into .worktrees/<branch>. Never start on main/master without explicit user consent.The plan is your checklist — its steps use - [ ] checkboxes, and the plan file on disk is your durable source of truth (it survives a context compaction; your memory does not).
For each task, in order:
msbuild__build_* tool for a .NET solution, otherwise the project's configured command via command__run. Don't skip them.- [ ] to - [x] in the plan file with files__edit. After a compaction or a fresh start, re-read the plan — checked steps are done; resume at the first unchecked one. Don't re-do completed, already-committed work.After all tasks are done and verified, invoke the finishing-a-development-branch skill (open_skill → finishing-a-development-branch).
Stop immediately and ask the user — don't guess — when you:
If the user updates the plan in response, return to Step 1's critical review before continuing.
main/master without explicit consent.Use this when the user wants to draft a third-party vendor or product privacy and security review document for consumer use.
Use when implementation is complete and tests pass, to integrate the work. Verifies the build/tests, then presents clear options - merge locally, open a pull request, keep as-is, or discard - and carries out the choice, including cleaning up the git worktree.
Use to execute an implementation plan task-by-task by dispatching a fresh sub-agent per task with a review gate after each. Preferred when the agents feature is on - it keeps the main conversation's context lean and cheap. Works in an isolated git worktree.
Use this before any creative or building work - new features, components, behavior changes, or non-trivial fixes. Explores intent, requirements, and design through dialogue, then writes an agreed spec before any implementation begins.
Use before implementing a plan, to set up an isolated git worktree to work in. Creates a linked worktree under .worktrees/ and changes into it, so the feature's work never touches the main checkout - and a second conversation can work a different feature in parallel.
Use when you have an agreed spec or requirements for a multi-step task, before touching code. Turns the spec into a bite-sized, test-driven implementation plan with exact files, code, and commands - then hands off to execution.