execute-plan

执行计划

推动已批准的连续计划直至完成：按依赖顺序分波并行执行独立任务，每项任务分配一名全新的实现子 Agent，对每项任务的差异进行双重评审，最后对整个分支进行评审——任务之间不暂停等待人工介入。

不适用此技能的情况：

意图	改用
Execution-mode: story-unit（需要人工把关的评审单元）	必需的子技能：使用 execute-story
不使用子 Agent／由控制器实现／用户选择内联执行	必需的子技能：使用 execute-inline

**为什么使用全新的子 Agent：**每位工作者只会收到其任务所需的上下文，不多不少。子 Agent 不会继承会话历史——由你构建它们的工作环境。批量材料以 .skills/ 下的文件路径传递，绝不粘贴文本。

**过程说明：**每次工具调用之间最多一行简短说明。记录簿和工具结果会留存过程记录。

模式门槛

Execution-mode 是 tasks.md 中的必填标头。只有值为 continuous 时，才能运行此技能。

标头	操作
continuous	继续执行下方的设置步骤
story-unit	不要运行此技能的循环。必需的子技能：使用 execute-story
缺失／unset／无效	询问用户；在 tasks.md 中写入 continuous 或 story-unit（如果已纳入版本控制，则提交）。如果用户选择 story-unit → 使用 execute-story。如果选择 continuous → 继续执行。绝不擅自默认使用 continuous。项目级无默认值

在此技能中，绝不要运行单元关卡、单元推导或人工单元停顿。 这些仅适用于 execute-story。

想法	实际情况
“execute-plan 过去会处理两种模式——我会继续处理 story-unit”	Story-unit 应使用 execute-story。继续留在此处就是双模式错误
“我会先推导单元，作为工作量参考，然后再用 continuous”	此技能中没有单元表。任务波次仅依据 Depends-on 确定
“负责人要求人工介入——我会保持 continuous，但还是暂停”	暂停策略由标头决定。写入 story-unit 并使用 execute-story，或者保持 continuous 且不暂停
“项目经理／站会——默认 continuous，不必询问”	模式为空表示尚未准备就绪；应询问并写入该字段

设置

1. 先检查模式门槛。 按照上表解析 Execution-mode:。完成条件： 当前处于 continuous 模式，或已交接给 execute-story。
2. 工作区检查——先询问。 如果尚无隔离工作区，询问：在 worktree 中隔离，还是在当前分支上实现？未经询问，不要创建 worktree。隔离 → 必需子技能：使用 worktrees。当前分支是 main/master → 实现前需另行明确征得同意；“不要使用 worktree”不代表同意修改 main/master。完成条件：明确工作区选择。
3. 进度台账检查。 将 .skills/ 设为仅本地使用： grep -qxF '.skills/' .gitignore 2>/dev/null || { printf '.skills/\n' >> .gitignore && git commit -m 'chore: ignore local skills artifacts' -- .gitignore; } 如果 .skills/progress.md 存在，则读取。该文件标记为完成的每项任务都视为已完成——从文件未列出的第一项任务继续。完成条件：明确下一项任务。
4. 阅读计划。 完整阅读一次 tasks.md。为每次评审派发逐字复制 Global Constraints。如果缺少 docs/agents/project.md，说明这一点并建议使用 setup-repo，从 Global Constraints 中提取验证命令。当 ## Team 中包含人员名单或档位时，只加载档位的 packaging——Solo 情况下绝不能跳过双重结论评审。完成条件：逐字记录约束。
5. 待办事项——门槛。 派发任何任务前，通过 TodoWrite 为每项任务创建一个待办事项。完成条件：待办列表与计划一致。
6. 派发前计划评审。 扫描一次，查找内部缺陷（矛盾、没有断言的测试、计划要求的复制粘贴逻辑）。派发前将所有发现汇总为一个问题询问用户。扫描无问题 → 不作评论。完成条件：排除冲突或确认没有冲突。
7. 波次规划。 阅读每项任务的 Depends-on: 行。指定的任务必须先完成；Depends-on: none = 无前置任务；缺少该行 → 依赖所有更早的任务。按拓扑顺序划分波次。没有 Depends-on 边 → 每个波次安排一个任务（严格串行）。完成条件：每项任务都归入一个波次。

每项任务的循环

对于任务 N：

1. 记录基准。 BASE=$(git rev-parse HEAD) —— 始终在派发前执行。
2. 构建任务说明。 将任务 N 区块和逐字复制的 Global Constraints 写入 .skills/task-N-brief.md。如果存在 docs/architecture/ 主干文档，则纳入相关的 **ARCH-N**。根据 Team 档位的 packaging 调整语气——绝不能省略评审要求。
3. 派发一位全新的实现者，使用本文件同目录下的 implementer-prompt.md。派发内容仅限清单：一句话说明任务位置；作为需求的任务说明文件路径；前序任务无法确定的接口/决策；歧义处理方式；报告路径 .skills/task-N-report.md；明确指定模型。绝不提供会话历史。绝不提供计划文件。
4. 在实现者继续前，完整回答所有问题。
5. 根据下表处理状态。 DONE 时工作必须已提交。
6. 打包差异 → .skills/review-<base7>..<head7>.diff： git log $BASE..HEAD --oneline、git diff --stat $BASE HEAD、 git diff -U10 $BASE HEAD。绝不使用 HEAD~1 作为基准。
7. 派发任务评审者，使用 task-reviewer-prompt.md，并提供任务说明、报告、差异包、逐字复制的 Global Constraints 和明确指定的模型。存在主干文档 → 还必须使用子技能：check-invariants；若出现 violates，则进入修复循环。
8. 修复循环。 Critical/Important → 修复子 Agent（在 tdd 下重新运行覆盖相关问题的测试，将结果追加到同一份报告）→ 重新评审。同一发现连续 3 轮仍存在 → 停止；计划/设计/需求失效 → 必需子技能：使用 correct-course；否则升级处理。绝不在控制器上下文中修复。Minor → 记入台账，供整个分支统一分流处理。
9. 处理 ⚠️ 项，即评审者无法通过差异验证的事项。
10. 记入台账。 Task N: complete (commits <base7>..<head7>, review clean)。将待办事项标记为完成。
11. 继续下一项。 按波次顺序推进（见 并行波次），而非按任务编号顺序。不需要在任务之间暂停并征求许可。

并行波次

单任务波次会在分支上运行任务循环，这是最常见的情况。包含两个或更多独立任务的波次会并发运行，每个任务都在自己的工作树中，但仅限 git worktree 可用时；否则串行运行。

1. 记录波次基准。 WBASE=$(git rev-parse HEAD)。
2. 确认操作范围互不重叠。 没有两份任务说明会创建或修改同一个文件。 如果重叠 → 改为串行；绝不并行处理操作范围重叠的任务。
3. 分派任务——每个任务一个工作树。 留在位于 WBASE 的主工作树中。 对每个任务：git worktree add .worktrees/<branch>-taskN -b <branch>-taskN WBASE， 在该工作树中运行任务循环步骤 1–9；暂缓更新任务台账和推进流程，直到屏障阶段。 实施者并发运行。
4. 屏障阶段，然后按任务顺序合并。 只有当波次中的每个任务都通过审查后，才将每个任务合并到功能分支（绝不合并到 main/master），并按任务编号升序执行（git merge --no-ff <branch>-taskN）。遇到冲突 → 停止并上报；绝不盲目解决波次合并冲突。
5. 更新一次任务台账，然后清理工作树。 每个任务记录：Task N: complete (merged <branch>-taskN at <merge7>, review clean)； 标记待办事项；对每个工作树运行 git worktree remove。

实施者状态处理

状态	处理方式
DONE	打包差异 → 审查任务。
DONE_WITH_CONCERNS	阅读问题，并阅读 .skills/implementation-notes.md。若偏离会推翻计划 → 必须使用子技能 correct-course。如果声称有偏离却缺少说明 → 重新派发，要求先记录说明。
NEEDS_CONTEXT	提供所需信息；使用同一模型重新派发。
BLOCKED	缺少上下文 → 提供上下文；达到能力上限 → 使用更强的模型；任务太大 → 拆分；计划有误 → 必须使用子技能 correct-course。

每个任务最多重新派发 2 次；如果仍未达到 DONE → 上报给用户。绝不在没有任何改变的情况下，强迫同一模型重试。

模型分层

每次派发都要明确指定模型——省略模型会继承会话所用的模型（通常是最昂贵的）。

• 低成本： 转录 / 单文件机械性修复。
• 中等层级的最低要求： 所有审查者；所有根据说明执行工作的实施者。
• 最高层级： 设计判断、对整个代码库的广泛理解、整条分支的审查。

根据差异规模和风险调整审查者的模型层级。

审查提示词规范

• 绝不预先限定发现的问题（例如“不要标记 X”“最多算轻微问题”“计划就是这么选的”）。
• 计划要求导致的缺陷仍然算问题——询问应以哪个为准。
• 没有具体任务相关原因时，不要笼统地要求“检查所有内容”。
• 不要重新运行实施者已在报告中提供证据的测试。

持久化进度

对话记忆在压缩后不会保留。待办事项是当前会话视图；任务台账可在压缩后保留。绝不能让其中一个成为跳过另一个的理由。

• 开始时，阅读 .skills/progress.md；从最后一个已完成任务之后继续。
• 压缩后，以任务台账和 git log 为准，不要依赖记忆。
• 绝不重新派发任务台账标记为已完成的任务。
• 在波次中途崩溃 → 丢弃未合并的工作树；从 WBASE 重新运行整个波次。
• .skills/ 被 Git 忽略；如果被清除，则根据 git log 重建。

最后一个任务完成后

1. 审查整条分支。 必须使用子技能 code-review，基准为 git merge-base main HEAD——绝不使用分支中途的 sha。提供任务台账中的 Minor 项。 使用最高模型层级。
2. 由一名修复者处理完整的问题列表 → 重新审查。绝不为每个问题分别安排一名修复者。
3. 润色。 必须在验收前使用子技能 polish 润色整条分支的差异。
4. 验收。 必须使用子技能 acceptance-check。如果失败 → 使用 debug， 然后将测试提升为带有提交 ID 标签的测试。可选：/allocate-attention （不是门槛）。
5. 准备。 必须使用子技能 prepare-change。
6. 结束。 必须使用子技能 finish-branch。

Inline 路由

控制器端的顺序执行（不使用实现者子 Agent）由 execute-inline 负责。如果用户选择了 inline，或环境无法分派 实现者：必须使用 execute-inline。不要在没有分派的情况下，半途运行本 技能的子 Agent 循环。

红线 — 绝不可

• 当 Execution-mode 为 story-unit 时运行本技能的循环（转交给 execute-story）
• 用户选择 inline / 不使用子 Agent 时仍停留在本技能（转交给 execute-inline）
• 在 continuous 模式下运行单元屏障、单元推导或人工单元暂停
• 在任务之间暂停并询问是否继续
• 因为缺少标头而臆造 Execution-mode: continuous
• 在同一个工作树中运行两个实现者，或在没有隔离工作树和不重叠表面检查的情况下并行运行
• 在并行波次中的每项任务都通过审查之前合并该波次或记入台账
• 将整个计划文件交给子 Agent——任务简报就是它的全部上下文
• 使用 HEAD~1 作为审查基准
• 修复后跳过重新审查，或接受缺少任一裁定的审查
• 在仍有未解决的 Critical/Important 发现时转到下一项任务
• 让实现者的自我审查代替任务审查
• 告诉审查者不要标记哪些问题，或在派发时预先评定严重程度
• 未提供差异包就派发审查者
• 重新派发台账中已标记为完成的任务
• 待办列表尚未创建就派发第一项任务
• 在控制器上下文中修复审查者发现的问题
• 未经明确同意就在 main/master 上开始实现
• 未经询问就创建工作树，或将“当前分支”视为对 main/master 的同意