它能做什么
中文摘要
executing-plans 是 obra/superpowers 中的 Agent 工作流技能，用于在当前会话中由执行者本人逐步执行一份实现计划：不为每个任务派发实现子代理和评审子代理，只在最后对整条分支做一次全新上下文评审。它的核心原则是“计划已经完成了思考”——严格按计划执行，用先看到失败、再看到通过的测试证明每一步，并留下能抵御自身遗忘的记录。做法包括：在隔离 worktree 中建立每个计划专属的 workspace 与 ledger（进度账本，首行标识计划文件），读取计划与 spec，做 pre-flight 扫描检查任务间共享接口的冲突；随后逐任务循环，用 scripts/task-start 取 brief 与 BASE、按计划既有的 RED-GREEN 顺序执行每步并与 Expected 行比对真实输出，代码出错走 systematic-debugging，计划出错则作出 ruling 并记账，按计划提交，满足完成契约后用 scripts/task-done 跑测试并仅在通过时写入完成行。全部任务完成后生成 review-package 并派发一次整分支评审（无子代理工具时由作者自评审并声明其较弱），Critical/Important 发现只做一次修复（每个修复需测试 RED→GREEN 且全套件通过），Minor 记入 ledger 并在最终消息中上报；最后删除该计划的 workspace 并交由 finishing-a-development-branch。
为什么推荐
推荐理由
当你已经有一份明确的实现计划、并且希望由当前会话的执行者内联执行而非为每个任务派发子代理时，这个技能给出了完整的执行规范：以计划和 spec 为约束、以观测到的测试失败到通过为每步证据、以 ledger 记录进度以防上下文压缩后重复实现已提交的任务，并在结尾用一次整分支评审弥补内联执行失去的“每任务第二双眼睛”。它对长时间、任务大体独立的计划尤其有价值，因为 ledger 让执行可恢复、可中途更换执行者。
什么时候用
适用场景
- 已通过 superpowers:writing-plans 得到实现计划，且 human partner 在交接时选择内联执行
- 当前 harness 没有子代理工具，无法为每个任务派发实现/评审代理
- 计划中的任务大多是相互独立的
- 执行较长的计划、担心上下文压缩后丢失进度，需要 ledger 记录与恢复
- 希望严格执行计划并以每步测试证据和最终整分支评审作为质量门槛
使用前先看
主要亮点
- 01
按计划中既有的 RED-GREEN 顺序执行步骤，测试先写先运行，并强调“没有看到失败的测试证明不了任何东西”
- 02
每个运行命令的步骤都有 Expected 行，需要运行命令、读取输出并与之比对；三种结果分别为匹配、代码错（转 systematic-debugging）、计划错（作 ruling 并记账）
- 03
用 ledger 文件（<workspace>/progress.md，首行 `# SDD ledger — plan: <plan file path>`）记录进度，凡有 `Task <N>: complete` 行的任务即为已完成、不再重做
- 04
workspace 与 ledger 与 subagent-driven-development 共用同一目录和格式，计划可以在执行途中更换执行者并从同一 ledger 续接
- 05
仅四种情况会停下来询问：不可逆或破坏性操作、安全敏感操作、worktree 之外且惯例需先问的副作用（merge、push 到共享分支、publish）、以及每条前进路径都靠猜的坏计划
- 06
最终整分支评审用最强可用模型派发一次全新上下文评审；若无子代理工具则由作者自评审并向 human partner 声明其弱于独立评审
- 07
Critical/Important 发现只做一次修复，每个修复都需有先失败后通过的测试并跑整套件；Minor 发现只记入 ledger 并列为 deferred minors，不进入修复轮
- 08
结尾将全部含 `Ruling:` 的行按顺序汇总进最终消息并附上判断错误的代价，删除该计划的 workspace，然后使用 superpowers:finishing-a-development-branch
原始文档
原文摘录
Executing Plans Execute the plan yourself, task by task, in this session: no implementer subagent per task, no reviewer per task. One fresh-context review of the