Appearance
executing-plans 让 AI 直接读取你已经写好的实现计划，逐任务批量执行，执行过程中如果遇到阻塞、指令不清晰或验证失败，立刻停下来请求人工介入，而不是猜测或硬闯。核心价值在于：不需要子代理支持，在普通 AI 对话平台上也能实现相对可靠的计划驱动执行。
executing-plans skill：批量执行计划，设置人工检查点
有了实现计划，下一步是执行。最朴素的做法是把计划贴给 AI，然后一步一步手动指令。executing-plans 做的就是让 AI 自己读计划、自己推进任务、遇到真正需要人决策的时候才来打扰你。
这个工作流解决什么问题
手动逐条指令既低效又容易遗漏。但完全放手让 AI 连续执行又容易出问题：它可能在某个环节出了错还继续推进，或者对模糊的指令做了错误假设，等你发现时已经改了一大堆文件。
executing-plans 在这两个极端之间找到一个平衡点：
- AI 自主推进，不需要你每步都在线
- 遇到阻塞或不确定的地方，立刻停下来，不猜测，不硬闯
- 执行完毕后有完整的验证步骤，不是"跑完了就算完"
与 subagent-driven-development 的核心区别
这是两个面向不同场景的工作流，选错了会影响效果。
subagent-driven-development 依赖子代理机制：每个任务派发给上下文干净的新代理，执行完成后自动触发规格合规审查和代码质量审查，两道关卡都通过才进入下一个任务。整个过程在同一会话内完成，自动化程度高，适合 Claude Code 这类支持子代理的平台。
executing-plans 不依赖子代理：AI 在自身上下文中顺序执行任务，检查点由人工触发（而非自动审查），适合任何 AI 平台。代价是：没有自动的双阶段审查，上下文会随任务推进而积累，执行质量可能随时间有所下降。
简单判断标准：
- 用的是支持子代理的平台（如 Claude Code）→ 优先选 subagent-driven-development
- 用的是普通对话平台 → 选 executing-plans
- 任务之间高度耦合、需要人工控制节奏 → 选 executing-plans
三步执行流程
第一步：加载并批判性审阅计划
AI 读取计划文件后，不是直接开始做，而是先批判性地审阅一遍：
- 有没有指令模糊、前后矛盾的地方？
- 任务之间的依赖关系是否清晰？
- 有没有明显的遗漏（比如某个任务依赖一个还没定义的接口）？
如果发现问题，在开始执行之前提出来，等你确认或修正后再继续。如果没问题，建立任务列表，进入执行阶段。
这一步的价值在于：计划里的问题越早发现，修复代价越小。
第二步：顺序执行任务
对每个任务：
- 将任务标记为"进行中"
- 严格按照计划中的每一个步骤来做，不跳过，不自作主张增减
- 按计划指定的方式运行验证（测试、命令输出检查等）
- 验证通过后标记为"已完成"，进入下一个任务
关键规则是遇阻立停，不猜测，不强行推进：
- 依赖项缺失、测试持续失败
- 指令不清晰，不确定该怎么做
- 计划本身有无法跳过的关键漏洞
这些情况下 AI 会主动停下来，描述具体卡在哪里、已经尝试了什么、需要什么信息，然后等你给出方向。
第三步：完成开发分支
所有任务执行并验证完毕后，进入收尾流程（finishing-a-development-branch），包括最终测试、提交状态确认和合并前的准备工作。
什么时候需要回到第一步
如果你根据 AI 的反馈修改了计划，或者发现整体思路需要调整，可以要求 AI 重新审阅更新后的计划，然后从更新的地方继续执行。不需要从头开始，但需要确保 AI 理解了变化。
实际执行中的人工检查点
executing-plans 的检查点是被动的——AI 在遇到问题时停下来找你，而不是每完成一个任务都来问你。这意味着：
- 如果计划写得清晰、任务拆分合理，AI 可以连续推进很多任务不打扰你
- 如果计划有模糊地带或任务拆分太粗，你会被频繁打断
这给了你一个很有用的反馈信号：如果 AI 停下来的频率很高，说明你的计划需要细化。
反过来说，如果你希望在特定节点介入（比如第 5 个任务之后想看看方向是否正确），可以在计划里明确写"此处需要人工确认"之类的检查点，AI 会遵守。
配套工具链
executing-plans 作为执行工具，依赖两端的配合：
- 上游：superpowers:writing-plans——生成这个工作流所需要的计划文件。计划写得越细，执行越顺畅。
- 下游：superpowers:finishing-a-development-branch——所有任务完成后的收尾流程。
- 前置：superpowers:using-git-worktrees——在隔离的 worktree 里执行，不污染主分支。
三者组合成一个完整的 AI 辅助功能开发流水线。
使用建议
计划颗粒度：每个任务最好有明确的验证方法（比如"运行 npm test，确认 X 测试通过"），而不只是"实现功能 X"。验证步骤越具体，AI 越能自主判断任务是否真的完成。
任务大小：任务太大时（比如"实现整个认证模块"），AI 容易在中途出现方向漂移。建议每个任务聚焦在 1-3 个文件的改动范围内。
不要在主分支上执行：这是硬性要求。用 git worktree 建立隔离环境，避免不可逆的误操作。
FAQ
Q: 和直接让 AI 自由执行有什么区别？
A: 最大区别是"遇阻立停"。普通执行模式下 AI 倾向于想办法绕过问题继续推进，结果可能更难收拾。executing-plans 要求 AI 明确识别阻塞、描述阻塞、等待指令，而不是自作主张。
Q: 没有双阶段审查，质量怎么保证？
A: 质量保证主要依赖两方面：一是计划本身的验证步骤（每个任务有对应的测试或检查命令），二是人工在检查点的判断。如果你的平台支持子代理，用 subagent-driven-development 能获得更强的自动质量门禁。
Q: AI 执行到一半跑偏了怎么办？
A: 这是用这个工作流时最常见的问题。建议在几个关键任务之间主动要求 AI 汇报进展，不要等到全部做完。另外，任务颗粒度越细，跑偏的空间越小。
Q: 执行过程中发现计划有问题，能修改计划吗？
A: 可以。修改计划后告诉 AI 重新审阅受影响的部分，然后从修改点继续。但如果改动幅度很大，建议从第一步重新审阅整份计划，避免 AI 对计划的理解出现不一致。
Q: 计划文件用什么格式比较好？
A: Markdown 格式最常见，每个任务作为一个独立章节，包含：任务描述、具体步骤、验证方法。可以配合 superpowers:writing-plans 工具生成标准格式的计划文件。