想象你是一位乐高建筑师，花了一整晚设计了一张超详细的「城堡搭建计划图」——每一步要搭什么零件、用什么颜色、甚至螺丝（其实是卡扣）拧多紧都写好了。
现在你累了，想把计划交给一位AI 施工队长去执行。这位队长不会自己设计，但他最擅长的事就是严格按图纸干活，而且每干完一步都会停下来让你检查，绝不乱改。
这位队长手里拿着的“工作手册”就是 executing-plans Skill。
今天我们就来拆开这本手册，看看他是怎么做到 听话、细心、不翻车 的。
📘 实现原理（队长的大脑）
executing-plans 的核心思想只有一句话：别想，照着干，卡住就问。
它不像设计师那样天马行空，而是一个超级自律的执行器。
1️⃣ 加载计划 —— 把图纸钉在脑门上
队长先找到你写的计划文件（比如 plan.md），从头读到尾。
原理：他并不理解“为什么要这样搭”，只关心“下一步要做什么”。
关键动作：他会批判性地审查计划 —— 如果发现逻辑漏洞（比如“第 3 步要用红色 2x4 砖，但第 2 步没说要先找到它”），他会立刻举手：“老板，这里缺材料，我没法开工。”
2️⃣ 创建任务清单（TodoWrite）
如果计划没问题，队长会在自己的小本本上生成一个 Todo 列表，每个步骤对应一项。
原理：这相当于把长计划拆成可追踪的原子任务，每完成一项就打勾，避免遗漏。
3️⃣ 串行执行每个任务
队长从不并行工作，因为图纸上第 5 步依赖第 4 步的结果。
原理：顺序执行 + 每步后运行验证（比如“测试是否搭建稳固”）。
如果某步验证失败，他会反复重试，直到成功或确认无解。
4️⃣ 遇到障碍立即停止
最重要的原理：队长绝不“猜测”或“脑补”。
如果遇到：
- 缺少依赖（没找到指定颜色的砖块）
- 指令模糊（“把塔楼弄高一点” —— 多高？）
- 验证失败 3 次仍不行
他会立刻停工并大喊：“老板，卡在第 4 步了，请指示！”
这比那些自作聪明、瞎搭一气导致全拆的 AI 可靠 100 倍。
5️⃣ 完成所有任务后，移交验收专员
所有步骤打勾后，队长不会直接说“结束”。他会召唤另一位专家 —— finishing-a-development-branch Skill。
这位专家负责：检查整体测试、帮你选择合并还是清理、最后把工作成果安全归档。
原理：把“执行”和“收尾”分离，避免队长因为太兴奋而忘了运行全量测试。
🧠 最佳用法
✅ 什么时候请这位队长？
- 你已经写好了非常详细的实施计划（每步都有明确动作和验证命令）
- 你想让 AI 独立干活，但又不放心它乱发挥
- 你希望每一步都能中断、检查、纠正（计划可以边执行边修改）
❌ 什么时候别用？
- 你只有模糊的想法（比如“优化一下代码”）
- 你想让 AI 自己设计解决方案（那应该用
writing-plans或subagent-driven-development） - 你赶时间，不想分步骤确认（队长会频繁停下来问你）
🌟 黄金三原则（来自手册）
- 计划必须“可验证”
每个步骤要写清楚如何验证成功。例如：
✅ 好：“运行npm test，输出All tests passed”
❌ 差：“确保功能正常” - 遇到模糊或缺失，立刻问
作为人类，你收到问题后要直接回答（不要反问“你觉得呢？”）。队长不擅长猜。 - 永远在独立工作区干活
队长开工会先执行using-git-worktrees—— 创建一个隔离的临时目录，避免污染主分支。
这是安全气囊，搭坏了扔掉工作区即可，主项目毫发无损。
⏱️ 时序图（队长的一小时）
下面用 mermaid 画一个完整的调用过程，从你下达命令到交付成果。
🧩 核心要点速记（给健忘的你）
| 角色 | 类比 | 职责 |
|---|---|---|
| 你（人类） | 建筑设计师 | 提供无歧义、可验证的详细计划 |
| executing-plans | 施工队长 | 严格按计划顺序执行，卡住就问，绝不创造 |
| using-git-worktrees | 隔离工地 | 每次都在全新临时环境干活，失败无损主项目 |
| finishing-a-development-branch | 验收专家 | 整体测试 + 帮你决定最终合并或丢弃 |
🚨 最后一句提醒
这个 skill 不解决“做什么”，只解决“怎么做已经规定好的事”。
如果你自己都没想清楚步骤，先去找writing-plans帮你设计；
如果你有多个 subagent 可用，直接上subagent-driven-development—— 那个更强大，但executing-plans永远是最稳定、最可控、最透明的备胎。
现在，你可以放心把乐高图纸交给这位队长，自己去喝咖啡了 ☕
