build-in-waves

暂存路径：先解析 FEATURE_CODE / <CODE>，然后遵循 templates/skills-ephemera-paths.md（功能根目录 .skills/<CODE>/）。按以下顺序解析包种子，使用第一个存在的路径：(1) 与此 SKILL.md 同级的 templates/；(2) 设置了 ${CLAUDE_PLUGIN_ROOT} 时使用 ${CLAUDE_PLUGIN_ROOT}/templates；(3) 相对于此 SKILL.md 的 ../../../templates。

分波构建

通过一个感知依赖关系的调度器，推动已批准的连续计划直至完成。一个就绪任务集按串行方式运行；就绪集中相互独立且涉及不同代码表面的任务，可在并行工作树中运行。同一依赖链中的相关任务可以复用有界的工作者和审阅者租约。每个任务都有自己的提交、报告、证据和两项判定；任务之间不需要人工暂停。

上下文规则： 默认在语义单元边界或触发硬性租约条件后启用新上下文。在有效的依赖链租约内，恢复角色上下文，并仅传递任务增量。批量产物以 .skills/ 下的文件路径传递，绝不粘贴文本。

说明： 工具调用之间最多一行简短说明。记录由台账和工具结果承载。

共享控制器流程： 必须使用子技能 execute-common。当 Setup 预检 / 台账 / 待办事项或 After the Last Task 开始时，加载 ../execute-common/SKILL.md。该文件是这些步骤以及关闭序列判定条件的唯一依据。 此文件负责连续模式的调度和屏障。共享任务生命周期位于 ../execute-common/task-lifecycle.md，只加载一次。

模式归属

调用此技能即选择连续执行。将 tasks.md 与该执行路径保持一致并继续：

tasks.md 中的 Execution-mode:	操作
continuous	继续
story-unit	必须使用子技能 build-by-story
缺失 / unset / 无效	在 tasks.md 中写入 Execution-mode: continuous（若受版本控制则提交）。继续

单元屏障、单元推导和人工单元停顿仅属于 build-by-story。

想法	实际情况
“标头写着 story-unit——留在这里照样分波运行”	移交给 build-by-story
“我先推导单元作为规模信号，然后连续执行”	波次仅根据 Depends-on 划分
“负责人要求人工停顿——在连续模式中暂停”	人工门控停顿属于 build-by-story
“任务很小且规格完整——我自己来写”	规模不会改变执行路径。由控制器编写代码属于 build-inline；在此处，每个任务都必须单独派发实施者，并单独进行审查。基准测试中，4 次运行有 2 次由控制器编写了所有 4 个任务，然后才派发审阅者——一名审阅者在一次批处理中审查了全部任务

设置

1. 模式归属。 应用上表。完成条件：标头为 continuous，并且你留在此技能中，或已移交给 build-by-story。
2. 会话预检。 应用 ../execute-common/SKILL.md 中的 Session preflight。 完成条件：该部分的完成条件已满足。
3. 台账检查。 应用 ../execute-common/SKILL.md 中的 Ledger check。 完成条件：已知下一项任务。
4. 阅读计划。 完整阅读一次 tasks.md。记录 Global Constraints 的路径和内容哈希，以便分派；简报指向规范章节，而不是将其粘贴到每条审查者提示词中。如果缺少 docs/agents/project.md，请说明这一点，建议使用 configure-repo，并从 Global Constraints 获取验证命令。 当 ## Team 有成员名单／级别时，仅加载级别 packaging——即使是 Solo，也绝不可跳过双重裁决审查。完成条件：已逐字记录约束。
5. 待办事项 — GATE。 应用 ../execute-common/SKILL.md 中的 Todos — GATE。 完成条件：列表与计划一致，并且包含 Close 分支待办事项。
6. 计划预审。 扫描一次，检查内部缺陷（矛盾、没有断言的测试、计划要求的复制粘贴逻辑）。将所有发现汇总成一个问题，在分派前询问用户。扫描无问题 → 不作评论。 完成条件：冲突已排除或不存在。
7. 就绪集规划。 阅读每项任务的 Depends-on: 和 Files: 块。指定的任务必须先落地；Depends-on: none 表示没有前置任务；缺少该行表示所有更早的任务都是前置任务。根据依赖图计算下一个就绪集。只有当各任务涉及的内容互不重叠，且运行时提供安全的工作树隔离时，就绪集才可并行展开。若存在经批准的 Max-concurrency 上限，则应用该上限；若缺少，则为 auto。 完成条件：每项任务都有依赖位置、内容重叠评估结果以及有效的通道／并发决策。

持续调度器

加载 ../execute-common/task-lifecycle.md，以获取唯一的任务循环。调度器提供任务 ID、通道、当前基准修订、简报路径、报告路径、审查包路径和活动租约 ID；生命周期负责分派、状态、审查、修复、证据和台账规则。

每次恢复工作者或审查者之前，运行 ../execute-common/SKILL.md 中的租约预检：

1. 语义边界： 在限定单元结束时轮换，或在下一项任务实质性改变角色所需上下文时轮换。
2. 上下文安全： 根据活动上下文上限，估算系统指令、工具、保留历史、上下文包、任务增量和输出预留。
3. 价格安全： 应用注明日期的提供商／模型 pricing_policy。如果预计请求会触及全令牌断崖，或继续执行的成本明显高于启用全新角色上下文的成本，则在分派前轮换。
4. 强制轮换： 在压缩、大范围的作用域／不变量变更、运行框架变更或首次出现上下文混淆信号后轮换。记录原因，并通过上下文包和台账保持连续性。

就绪集、并行通道与屏障

1. 根据 Depends-on: 计算下一个就绪集。只有所有前置任务都已记录为干净通过，该任务才就绪。
2. 如果就绪集中只有一个任务，则在功能分支上执行共享任务生命周期。
3. 如果就绪集中有多个任务，则证明每对任务的 Files: 范围互不重叠，并检查 worktree_isolation。存在重叠或缺少隔离时，将有效集合降为串行；在运行时 sidecar 中记录这一降级。
4. 对于并行集合，记录 WBASE。每条通道在整个运行期间使用一个 worktree，以保持其构建缓存处于热状态——每个任务新建一个 worktree 会导致从冷缓存重新构建。首次使用： git worktree add .worktrees/<branch>-lane<k> -b <branch>-taskN WBASE； 后续就绪集： git -C .worktrees/<branch>-lane<k> switch -c <branch>-taskN WBASE。 调用共享生命周期。worker/reviewer 租约只有在自身依赖通道内才能跨就绪集延续。
5. 集合中的每个任务都通过 Standards 和 Spec 审核后，按确定的任务顺序合并。发生冲突时，调度器必须停止；绝不可盲目解决冲突。然后在合并后的 HEAD 上运行波次门禁：对工作区中的每个目标执行编译和 lint（使用 project.md 中的 Wave gate；否则使用其中的类型检查和 lint 命令），并依据 lint 基线判定。未通过 → 不写入 ledger；必需子技能：使用 root-cause，进行一次修复调度，再次运行门禁。通过 → 每个任务写入一条 ledger 记录。最后一个就绪集完成后，删除各通道的 worktree。
6. 重新计算就绪集。连续模式下，任务之间无需暂停等待许可；只要审核屏障尚未关闭，任务就不得推进。

实施者状态处理

状态	你的操作
DONE	打包 diff → 进入任务审核。
DONE_WITH_CONCERNS	阅读 concerns 以及 .skills/<CODE>/implementation-notes.md。条目必须符合 implementer-prompt.md 中的九字段 Deviations 规范。缺少 notes 路径、字段不完整，或声称存在偏差却只填写五个字段 → 不完整 — 重新调度以先记录说明。映射影响为 reroute-plan / realign-spec 或会推翻计划 → 必需子技能：使用 reroute-plan（不得将其作为干净的 DONE 接受）。
NEEDS_CONTEXT	提供所列内容；使用同一模型重新调度。
BLOCKED	缺少上下文 → 提供；达到能力上限 → 使用更强模型；任务过大 → 拆分；计划有误 → 必需子技能：使用 reroute-plan。

每个任务最多重新调度 2 次；仍未达到 DONE → 升级给用户。若没有任何变化，绝不可强迫同一模型重试。

操作人员的消息会改变计划 — 添加约束、缩减范围、删除要求 → 在进行任何规范或代码编辑前，必需子技能：使用 reroute-plan。

模型分级

每次调度都要明确写出模型 — 未指定模型时，将继承会话中的模型（通常是最昂贵的模型）。

• **低成本：**转录 / 单文件机械性修复。
• **中等下限：**所有审核者；所有依据 prose 开展工作的实施者。
• **最高：**设计判断、对整个代码库的广泛理解、整个分支的审核。

根据 diff 大小和风险调整审核者的模型等级。

审核者提示词规范

• 计划要求的缺陷仍然是发现项 — 询问应以哪个为准。
• 没有具体且针对任务的理由时，不要要求进行开放式的“全面检查”。
• 不要重新运行实施者已在报告中提供证据的测试。

持久进度

Todos 是当前会话的视图；ledger 在压缩后仍会保留。压缩后，以 ledger 和 git log 为准，而不是依赖对话记忆。

• 波次中途崩溃 → 丢弃尚未合并的任务分支，将各通道的 worktree 切回 WBASE，然后从 WBASE 重新运行整个波次；如果 .skills/（被 git 忽略）被清除，则根据 git log 重建。

最后一个任务之后

完整执行 ../execute-common/SKILL.md 中的 Close sequence。此处不要重述或摘取其中的步骤。

完成条件：该节的 Done when 条件成立。

内联路径

控制器端的顺序执行（不使用实现子代理）由 build-inline 负责。如果用户选择了内联模式，或环境无法分派实现者：必须使用 build-inline。不得在没有分派的情况下，只运行本技能的部分子代理循环。

危险信号——切勿

• 当 Execution-mode 为 story-unit 时运行此循环（交接给 build-by-story）
• 用户选择了内联模式／不使用子代理时仍留在本技能中（交接给 build-inline）
• 在 continuous 模式下运行单元门禁、推导单元或设置人工单元停顿
• 在任务之间暂停并询问是否继续
• 在同一工作树中运行两个实现者，或在未使用相互隔离的 isolate-workspace 且未检查表面是否互不重叠的情况下并行运行
• 在并行波次中的每项任务都通过评审之前合并该波次，或在波次门禁通过之前将其记入台账
• 将整个计划文件交给子代理——任务简报就是它的全部上下文
• 修复后跳过重新评审，或接受缺少任一结论的评审
• 在仍有未解决的 Critical/Important 发现时进入下一项任务
• 由控制器编写任务代码，而不是分派给实现者
• 在一次评审者分派中评审多项任务
• 让实现者自我评审替代任务评审
• 告诉评审者不要标记哪些问题，或在分派中预先评定严重程度
• 未附带差异包就分派评审者
• 重新分派台账中已标记为完成的任务