执行计划

执行计划 是做什么的？

亲自执行计划，一个任务接一个任务，在当前会话中：每个任务没有实现者子代理，每个任务没有审查者。在最后对整个分支进行一次全新上下文的审查。

为什么选择内联： 子代理驱动开发为每个任务支付一个全新的实现者和一个全新的审查者，每个都从头重新阅读代码库。内联执行支付一个上下文（你的）加上最后的审查者。它放弃的是每个任务的上下文新鲜度和每个任务的第二双眼睛。本技能通过其他方式保留这两个东西带来的好处：简要就是规范，账本就是你的记忆，TDD是每个任务的关卡，最终的审查者是第二双眼睛。

核心原则： 计划已经完成了思考。精确执行它，用你亲眼看到失败然后通过的测试证明每一步，并留下一个在你忘记之后仍然存在的记录。

叙述： 在工具调用之间，最多叙述一行简短的话——账本和工具结果承载着记录。

持续执行： 不要在任务之间停顿与人类伙伴确认。他们选择内联执行是为了花费更少，而不是为了在每个任务之后回答“我应该继续吗？”。不间断地执行计划中的所有任务。

裁决，而非停滞。 冲突、歧义、计划缺陷——决定它们。规范是约束性的权威，计划是它的论证，你的判断解决两者都不回答的问题。将每个决定记录在账本中，格式为 Ruling: <你决定的内容> — <为什么> — <如果错了代价是什么>，然后继续。偏离计划而没有在账本中记录决策，就是在秘密中做出的决定。

只有以下四件事会阻止你：不可逆或破坏性操作；安全敏感操作；此工作树之外的副作用，按规范应首先询问（合并、推送到共享分支、发布）；以及计划太破碎以至于每条前进道路都是猜测。对于这些，停下来询问。

何时使用

• 你有一个来自 superpowers:writing-plans 的计划，并且你的人类伙伴在交接时选择了内联执行。
• 你的工具集没有子代理工具（参见 ../using-superpowers/references/ 中每个平台的参考）。切勿虚构调度；在此处运行计划。
• 任务大多是独立的——与 superpowers:subagent-driven-development 的前置条件相同。

一个完全指定的计划使内联执行转变为转录加测试：它在中等水平的会话模型上运行良好，而最强大模型的价值体现在最后的审查上，该技能将其单独调度。当你的人类伙伴选择内联时，请告知他们。

当你的人类伙伴希望每个任务都有审查关卡，或者计划足够长以至于后面的任务会在压缩的上下文上运行时，优先选择 superpowers:subagent-driven-development。在长计划上内联执行仍然有效——账本使其可恢复——但最后的任务获得的你的注意力最少。

流程

digraph process {
    rankdir=TB;

    subgraph cluster_per_task {
        label="每任务";
        "任务开始: brief + BASE; 阅读 brief" [shape=box];
        "按顺序执行步骤: TDD, 运行每个验证, 阅读每个输出" [shape=box];
        "步骤输出匹配计划的预期?" [shape=diamond];
        "计划错了? 裁决并记录。代码错了? 系统性调试" [shape=box];
        "按计划的提交步骤提交" [shape=box];
        "完成契约满足?" [shape=diamond];
        "任务完成: 运行测试, 记录结果; 标记待办完成" [shape=box];
    }

    "设置: 工作树, 工作空间 + 账本, 阅读计划 + 规范, 预检扫描" [shape=box];
    "还有更多任务?" [shape=diamond];
    "最终整个分支审查 (若有则用新审查者)" [shape=box];
    "重新评级, 然后: 严重/重要 → 一轮修复, 每个修复 RED→GREEN + 绿色套件; 次要 → 账本" [shape=box];
    "最终审查清理: 删除此计划的工作空间" [shape=box];
    "使用 superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];

    "设置: 工作树, 工作空间 + 账本, 阅读计划 + 规范, 预检扫描" -> "任务开始: brief + BASE; 阅读 brief";
    "任务开始: brief + BASE; 阅读 brief" -> "按顺序执行步骤: TDD, 运行每个验证, 阅读每个输出";
    "按顺序执行步骤: TDD, 运行每个验证, 阅读每个输出" -> "步骤输出匹配计划的预期?";
    "步骤输出匹配计划的预期?" -> "计划错了? 裁决并记录。代码错了? 系统性调试" [label="否"];
    "计划错了? 裁决并记录。代码错了? 系统性调试" -> "按顺序执行步骤: TDD, 运行每个验证, 阅读每个输出";
    "步骤输出匹配计划的预期?" -> "按计划的提交步骤提交" [label="是, 最后一步"];
    "按计划的提交步骤提交" -> "完成契约满足?";
    "完成契约满足?" -> "按顺序执行步骤: TDD, 运行每个验证, 阅读每个输出" [label="否 - 完成任务"];
    "完成契约满足?" -> "任务完成: 运行测试, 记录结果; 标记待办完成" [label="是"];
    "任务完成: 运行测试, 记录结果; 标记待办完成" -> "还有更多任务?";
    "还有更多任务?" -> "任务开始: brief + BASE; 阅读 brief" [label="是"];
    "还有更多任务?" -> "最终整个分支审查 (若有则用新审查者)" [label="否"];
    "最终整个分支审查 (若有则用新审查者)" -> "重新评级, 然后: 严重/重要 → 一轮修复, 每个修复 RED→GREEN + 绿色套件; 次要 → 账本";
    "重新评级, 然后: 严重/重要 → 一轮修复, 每个修复 RED→GREEN + 绿色套件; 次要 → 账本" -> "最终审查清理: 删除此计划的工作空间";
    "最终审查清理: 删除此计划的工作空间" -> "使用 superpowers:finishing-a-development-branch";
}

设置

确保工作在隔离的工作空间中进行：使用 superpowers:using-git-worktrees 创建一个或验证现有的。未经人类伙伴明确同意，切勿在主/主要分支上开始实现。

对话记忆无法在压缩后幸存。一个丢失位置的内联执行者会重新实现已存在的提交的任务——与控制者重新调度的失败相同，消耗的是你自己的上下文。使用账本文件而不是仅使用待办事项跟踪进度。工具集待办事项是实时视图；账本是记录。

工作空间和账本与 superpowers:subagent-driven-development 共享——相同目录，相同格式——因此计划可以在执行过程中更换执行者，而新的执行者可以从同一账本恢复。

• 每个计划拥有一个工作空间：在技能开始时，运行 ../subagent-driven-development/scripts/sdd-workspace PLAN_FILE —— 它打印该计划的 git-ignore 目录 (<repo-root>/.superpowers/sdd/<plan-basename>/)，这是此计划所有工件的家：账本、简要、审查包。其他计划的目录不是你的读写范围。
• 检查此计划的账本 <workspace>/progress.md。如果其第一行命名了你的计划文件，带有 Task <N>: complete 行的任务就是已完成的——不要重做它们；从第一个没有该行的任务恢复。它们的提交存在于 git 中，即使你的上下文不再记得创建它们：压缩后，相信账本和 git log 胜过你自己的记忆。第一行命名了不同计划文件的账本是另一个计划的进展：保留它，并开始你自己的新账本。
• 创建账本，其身份为第一行：# SDD ledger — plan: <plan file path>。
• git clean -fdx 会销毁工作空间（它是 git-忽略的临时区域）；如果发生这种情况，从 git log 恢复。

阅读计划一次，记下它的上下文和全局约束，并为每个任务创建一个待办事项。如果计划命名了一个规范，也要阅读它：规范是计划所依据的权威，计划内的冲突以规范为准。没有可达规范的计划在账本中注明——没有规范做出的裁决是暂时的。

必需的子技能： 现在加载 superpowers:test-driven-development，在任务 1 之前。它支配下面每个任务的每一步；一个步骤已经说“先写失败测试”的计划并不能免除你阅读它。

在任务 1 之前，扫描计划中任务之间的冲突。计划的 Interfaces 块告诉你查找位置：对于每个消费早期任务输出的任务，一条账本行——两个任务，一个产生什么，另一个消费什么，以及你发现了什么。没有任何共享的任务没有行；任务之间没有任何共享的计划得到单行 Pre-flight: no shared interfaces。对每一行暴露的冲突进行裁决，以规范为约束性权威，在其行旁边记录裁决，然后开始任务 1。每个任务自己的文本在你阅读其 brief 时检查，而不是在这里。

任务循环

你打印的每一件事，以及每个工具结果，都会在当前会话的剩余时间内保留在你的上下文中。将长测试输出重定向到工作空间中的文件并阅读其尾部；阅读 brief，而不是整个计划。

1. 接手任务

• 运行此技能的 scripts/task-start PLAN_FILE N。它会一次性打印 brief 路径和 BASE（该任务范围切割的提交）。为每个任务阅读 brief，包括你从设置中记住的任务：你记住的是摘要，brief 包含精确的值、签名和测试用例。
• 将任务的待办事项标记为 in_progress。

每个工具调用都是一个重新读取整个上下文的回合。记账与工作一起进行——在同一个调用中附加账本和提交，而不是在自己的调用中进行。

2. 执行步骤

计划的步骤已经是 RED-GREEN 顺序；按照该顺序在 superpowers:test-driven-development 下执行，已在设置时加载。测试步骤的代码先编写并先运行。观察其失败是一个步骤，而不是一种形式——在实现存在之前就通过的测试，是有关测试的发现。

每个运行命令的步骤都有一个 Expected: 行。运行命令，读取其输出并比较。三种结果：

• 匹配。 下一步。
• 代码错了。 使用 superpowers:systematic-debugging。找到原因；切勿修补症状以使步骤的输出匹配。
• 计划错了——步骤与规范矛盾，早期任务的接口与此任务消费的不匹配，无法工作的命令。裁决满足规范的最小更改，将其记录在账本中，格式为 Task <N>: Ruling: <发现> — <你决定的内容和为什么>，然后继续。裁决是被承载的，而不是被记住的：后面触及同一接口的任务从账本中读取它。

按计划的提交步骤提交。跨多个提交的任务是允许的；BASE 是审查范围切割的地方，而不是 HEAD~1。

3. 完成契约

在任务的账本行之前，以下所有都为真，且有本次会话的证据——而不是从看起来正确的 diff 推断：

• brief 命名的每个测试都存在并在此任务中运行，并且你阅读了输出。
• 任务的最终测试运行通过——task-done 就是那次运行，它将命令和结果写入账本行。
• brief 中的每个 Expected: 行都与真实输出进行了比较。
• 与 brief 的每个偏差在账本中都有 Ruling: 行。

必需的子技能： superpowers:verification-before-completion 支配这一声明。如果缺少任何一项，任务未完成：完成它。

4. 完成任务

运行此技能的 scripts/task-done PLAN_FILE N BASE -- <test command>，使用 brief 为整个任务命名的测试命令。它运行测试，在工作空间中保留完整输出，打印尾部，并且——仅当通过时——将完成行附加到账本：

Task <N>: complete (commits <base7>..<head7>, tests: <command> → <result>)

失败的运行不记录任何东西；任务未完成。当它记录时，将待办事项标记为完成并接手下一个任务。

最终审查

运行 ../subagent-driven-development/scripts/review-package PLAN_FILE MERGE_BASE HEAD (MERGE_BASE = 分支开始的提交，例如 git merge-base main HEAD) 并从它打印的文件开始审查。

有子代理工具时： 使用最可用的模型调度审查者——整个分支的审查是一个判断任务——使用 superpowers:requesting-code-review 的 code-reviewer.md，包含包路径、计划和规范路径、计划的 Review Focus 部分的逐字内容（如果有的话：计划的测试未覆盖的输入类和失败模式——审查者故意检查每个），以及指向账本 Ruling: 行的指针，以便它权衡你做出的调用。明确指定模型；省略的模型会继承会话的模型，可能不是最强大的。这是整个运行购买的一个全新上下文。不要跳过它，也不要用你自己对 diff 的阅读来替换它。

没有子代理工具时： 阅读 code-reviewer.md 并针对包自行执行该审查，作为最后一个任务账本行之后的单独一次传递。将 Final review: self-review (no subagent tool) 写入账本，并在你的最终消息中说明：作者的自我审查比新的审查者弱，你的伙伴在合并前决定这是否足够。

在你对任何发现采取行动之前对它们进行排序。审查者的严重性标签是建议；关卡是你的。它的“拒绝判断”列表也是你的：该列表中的每一行都是你做出并记录在账本中的裁决，就像计划冲突一样——Final: Ruling: <审查者搁置的行为> — <使用此软件的普通人得到什么，以及为什么这成立或者为什么它现在是一个发现> — <如果错了代价是什么>。首先重新评级，根据效果：规范是一个愿景文档，一个发现的等级是，如果它发布，使用此软件的普通人会得到什么，

……

[此处截断用于翻译]