orchestrator-mode

Orchestrator 模式

将会话作为负责人来运行，把实现工作委派给并行运行、位于隔离 Git 工作树中的子 Agent。负责人掌控架构、集成和落地。

以下各节按会话生命周期顺序排列：访谈、设置、保持并行、审查、跟进、落地、清理。新接手的负责人可以按顺序执行这些内容，完成整个会话。具体机制位于 scripts/ 和 references/ 中；本文说明判断原则，并指向相关资料。

此技能仅在显式调用时启用：用户在 Claude Code 中调用它（/orchestrator-mode），或在 Codex 中调用它（$orchestrator-mode）时加载，不会自行启用。

适用场景

• “Act as orchestrator” / “orchestrate this with worktrees”
• “Run this as a fleet” / “fan this out to subagents”
• 并行构建或管理多个 PR，每个 PR 使用一个工作树
• 有多个独立工作流、适合并行推进的计划

角色

负责人负责架构、整体一致性、集成和长期方向：规范、合并、门槛。其他工作都委派给专注于特定任务的子 Agent。

• 集成前先审查。 负责人亲自审查对可维护性至关重要的部分：通过自己的审查流程，在落地前阅读，而不是接手构建者的工作。
• 保持响应。 负责人绝不亲自运行耗时的前台任务（构建、测试套件、审查、监视）。用户随时可能想与协调者交流，负责人若被前台任务阻塞，就无法回应。任何耗时任务都交给子 Agent 或作为后台命令运行，负责人自己的前台步骤应保持简短。

1. 分派前先访谈

创建任务看板或启动任何任务前，在同一条消息中向用户询问以下事项。跳过调用时已经回答的问题。每项都提出一个默认选项，让用户只需回复一个词即可。

确认仓库本身已经说明的事项，不要提出开放式问题：分支保护规则决定落地方式，CI 配置决定门槛。

1. 落地方式：只选一次的门槛。直接提交到主线（哪个分支？），还是先创建 PR？
   • 如果选择 PR，还要确定由谁合并。默认由用户合并，另外两种长期例外见 /pr-landing-discipline 技能。只有在用户明确委派、合并队列负责排序，或属于上述例外情况时，负责人才能合并。
   • 如果用户把合并工作整体委派出去，应改为建议直接提交。由负责人合并的 PR，本质上是多几步的直接提交；只有分支保护或合并队列要求通过 PR 时，才值得保留这种方式。
   • 不需要询问各工作轨道的基线分支。根据依赖关系图确定：独立轨道使用主线；依赖未落地内容的轨道使用依赖项的分支（参见 references/landing.md）。
   • 根据分支保护规则、CONTRIBUTING 文档和近期历史推断可能的门槛。不确定时，建议使用 PR（对受保护的仓库来说，这是更安全的推测）。
2. 隔离方式：每个构建者使用一个工作树（默认），还是所有人都在主检出目录中工作？共享工作树会触发 /worktree-hygiene 技能中的唯一所有权规则，并将并行范围限制为互不重叠的文件集。
3. 边界：除计划中隐含的范围外，是否有任何不在范围内或禁止触碰的目录、文件或配置？
4. 落地节奏：各轨道收敛后无需再次询问，立即落地（默认）；还是每次落地或合并前暂停并请求批准？无论选择哪种节奏，所有落地都必须通过审查后再执行，并订阅 CI 运行。

2. 拆解任务、建立看板、监控、安排构建者

1. 先绘制依赖关系图，并将任务拆解为最小的独立单元。只有真正独立的任务线才能并行运行，默认各自在自己的工作树中运行（在 Claude Code 中使用 isolation: "worktree"，或直接使用 git worktree add）。共用检出目录时，并行度受限于 /worktree-hygiene 技能所有权规则下互不重叠的文件集。
   • 一个例外：某个依赖任务线 MAY 以其依赖任务线的分支为基础（或以主线加上简报指定的接口桩为基础）并行开发，但要接受依赖变动后重新变基并重新设门槛。具体操作见 references/landing.md。
   • 为每个 Agent 明确指定文件白名单和禁止触碰的范围，确保分支合并时不会冲突。若多个部分共用文件，则由同一个 Agent 负责。
2. 创建任务看板（任务列表），根据拆解后的任务线生成。
3. 先启动集群监控器：安排一个角色监控整个集群，汇报进展变化及耗时，并根据判断执行各项操作，所有操作均由负责人决策。references/fleet-monitor.md《One Role, Two Instruments》介绍的方案可提供两种工具，建议采用该方案。
   • 如果运行环境允许守护进程读取会话内容（Claude Code 负责人）：每个会话启动一次 fleet-events 守护进程（scripts/fleet-events.mts，此技能中 /session-events 技能所用守护进程的源文件），将其作为后台任务运行；然后在启动任何构建任务前运行 watch session --repo <root>。它会读取每个子 Agent 的对话记录和工作树；只有需要负责人判断的内容才会通过消息发送，其余内容会记录在日志中。
   • 其他情况（Claude Code 之外的负责人），或集群中的工作者不会生成 Claude 对话记录（Codex、Copilot、人类）：先启动监控子 Agent，并向其提供 references/fleet-monitor.md《The Monitor Subagent》中所述的简报，同时指定账本位置。它会定时运行 scripts/sweep.mts 并汇报状态变化。 Daemon 按会话运行：新一轮无需启动新的监控器。Subagent 按 FLEET 运行：当监控器已停止运行，而同一会话中之后又生成了新一轮 worker 时，先生成一个新的监控器，与会话开始时一样，并将其指向上一个监控器的账本以保持连续性。
   • references/fleet-monitor.md 记录了事件、两种监测手段都无法看到的情况（等待消息、权限提示、worker 正在编写大型修改时出现卡顿），以及判断规则。请严格遵循。scripts/sweep.mts 是一次性读取相同工作区的工具。
   • Lead 使用的监测工具，不得自行编写替代方案：用于检查内容声明的 scripts/probe.mts、用于记录状态和授权的 scripts/ledger.mts，以及在落地时使用的 scripts/baseline.mts。
   • 持续状态（已暂停的 worker、授权、标记及其撤销）必须写入 lead 在会话开始时创建的账本，不能只写在消息里；并且必须根据该账本解读两种监测手段产生的每条事件。规则位于 references/fleet-monitor.md 的 Reporting Discipline 部分。
   • Lead 在会话开始时编写该会话的 PII needle 文件（/tmp/fleet-<sessionId>/pii-needles.txt，位于仓库外；<sessionId> 是 harness 的会话 ID，或由 lead 生成）。使用该文件对该 track 新增的行和提交消息进行 grep：lead 在每次 builder 报告和每个落地门禁时执行，监控 subagent 在每次 head 发生变化的 sweep 中执行。具体配置见 references/fleet-monitor.md 的 PII at Every Report and Landing 部分。
4. 在 PR 门禁中，分派任务之前先阅读 references/landing.md。 基于依赖关系（堆叠）的 track 必须在生成 builder 之前初始化依赖链：每个依赖分支都从其依赖项的分支创建，并按照 landing.md 的堆叠小节记录创建时所基于的依赖项 tip。每份任务说明都必须注明由谁推送并创建每个草稿 PR。
5. 提前分析本轮任务可能失败的原因。 启动一轮任务之前，花五分钟回答：“现在是明天，这一轮任务失败了。为什么？” 将每个已确定的风险写成任务说明中的约束行：例如，风险“builder 会重新换行他们修改的每个段落”，对应的任务说明约束为“绝不重新换行段落；每段一行”。此要求适用于多任务轮次，不适用于简单的单项任务。
6. 多个 track 共用一份任务说明时，先进行试点。 如果 N 个相似任务都将从同一份任务说明启动，先启动一个试点，并按照会话的常规落地门禁（PR 审查或直接模式审查）对其进行审核。将所有修订纳入更正后的任务说明，然后再使用该说明分派剩余的 N-1 个任务。 生产环境的情形：一次性在 10 个表面同时发布一波文案，结果每个表面都出现了相同的三个简短缺陷，还需要向每位构建者实时广播修订。只需先做一次试点，就能在一次常规审查中发现这三个问题。简报不同的独立轨道无需试点：这条规则针对的是简报风险，而非并行执行。
7. 分派构建者处理独立轨道，并按照访谈所选的隔离方式执行。
   • 每份生成任务简报都必须按照 references/spawn-briefs.md 自成一体：内含完整的任务约定、范围白名单、门禁、信号格式、禁止停止并等待、禁止 TODO，以及测试规则（仅行为变更采用先红后绿）。如果已安装 /code-standards 技能，简报应引导构建者查阅该技能，了解注释规则和其余团队标准。
   • 简报要求在信号中报告的每项声明，都必须注明其回读命令（GraphQL 的 isResolved 读取、守护进程的 status 行、git ls-remote origin refs/heads/<branch>）；信号应引用回读结果，而非执行过的命令：references/spawn-briefs.md，Read-back reporting。
   • 如果运行框架会自动交付已完成 Agent 的输出，一次性监视器和门禁审查者应以未命名方式生成。命名监视器必须记得在 Agent 卡住的确切环节报告（详情见 references/spawn-briefs.md）。
8. 依赖运行框架的完成通知来获知子 Agent 已完成（Claude Code 的任务通知、Codex 将子 Agent 的最终输出交给生成它的 Agent）：等待子 Agent 时，负责人绝不休眠或轮询，因为通知会重新调用负责人；简报也会将此规则传递给工作者。车队监视器的轮询和扫描则不同：它们报告等待和停滞，而非完成。
   • 唯一例外是工作者等待运行框架未跟踪的进程（审查启动器、队列空位）：按照 references/spawn-briefs.md 的 The Stop-and-Wait Ban，使用有时限的前台调用并重复执行。

3. 保持 Fleet 并行运转

• 清理积压事项（审查者提出的非阻塞问题、测试缺口、受阻任务中尚未完成的文档部分），找出可以与各条工作线并行开展的独立工作。只有一个 Agent 忙碌而负责人闲置，说明委派不足。存在未受阻工作却有闲置产能，是一种缺陷，绝不应让用户指出这一点。

  每当实时流数量减少时，重新检查看板和积压事项，寻找可以启动的工作：通过区域备注即可避免冲突的排队任务、只读检查（集成审查、审计），以及为下一阶段做准备的工作。

• 不得搁置到“下个周期”。“我们下轮再接手”不算一种状态。已识别的工作应立即列入看板，并在产能允许时尽快开始；暂时无法启动的工作，应在看板上标明具体的阻塞依赖项。禁止的是只写下延后备注、留在脑中的积压事项：工作只存在于文字中，却无处可见。

  用户的合并绝不会阻止构建或启动依赖工作线或下一轮工作。依赖工作以第 6 节为基础；只有仅限分支的链条，才需要等到合并后再开启下一个 PR。

• 绝不默默丢弃偶然发现的问题（工具失败、文档过时、无关 Bug、有缺陷的技能或记忆）。立即将其列入看板，并对范围内的问题进行分诊；超出本次会话范围时，则向用户报告。构建者应在完成信号中报告超出其负责区域的发现，而不是自行修复，以保持各区域整洁。

  • **首先，遵循 /never-twice 技能的最低标准。**通过其判定的问题，接着评估规模；未通过的问题则予以修复、在看板上跟踪，并记录在报告或 PR 正文中，不添加防护措施。判定不清楚，或低于最低标准但仍觉得值得修复时，应向用户提问，而不是开辟一条工作线。
  • **然后，若通过判定，再评估规模。**小型问题（范围明确、解决方案显而易见的修复）应单独开辟一条工作线，并按本次会话的关卡和节奏完成，不必就问题本身额外征求同意。
  • 大型问题（新增机制、更改契约、整个仓库的重组）应在开始任何工作前通过一条消息提交给用户；重组方案应采用 /code-standards 技能描述的目标布局。单个路径的移动属于小型改动；读取仓库外部路径的方式变更属于契约变更；涉及大部分目录树的移动则属于重组。

• 优先为每项任务安排新的 Agent，而不是让一个 Agent 持续处理任务队列。长期承担多项任务的工作者会累积上下文，直到表现退化或需要交接。只有并发开启的任务确实共用文件时，才有理由复用同一个 Agent；即便如此，每项任务仍须单独发出信号并完成落地。

• **当工作轮次不断扩大时，按负责区域拆分构建者。**如果一轮工作的范围扩大到大约 8-10 项以上，且涉及互不相干的区域，就不要继续把新增任务交给同一个正在工作的构建者。请其提供已完成／进行中／尚未开始的快照，让其继续负责已有交叉依赖的区域，并为完全未涉及的区域启动同级构建者，同时为共享文件授予区域级权限。

  工作轮次开始时也适用同样的原则：如果任务列表一开始就涉及多个区域，则每个区域安排一名构建者。

4. 审查循环

• 每个 worktree Agent 在汇报前都要自行完成审查循环。随后，负责人进行的落地门禁审查会针对变更最终集成后的状态（经过变基的分支或已更新到最新状态的 PR）决定是否允许落地：这是集成审查，而非初次审查。

  这两个循环是纵深防御，而非重复劳动。它们各自能发现对方无法发现的问题；跳过某个门禁时，必须明确指出剩余的哪个门禁会覆盖它所负责的问题类别。“另一个审查通过了”不算理由。如果已安装 /rubber-duck-review 技能，两个循环都要使用它：由不同模型执行只读审查。

• 每轮都只运行有针对性的本地测试。开发者、门禁和负责人只运行变更及其验证所涉及的测试。完整测试套件和 lint 加构建的全面检查由 CI 在推送或 PR 时运行；如果 CI 会运行这些检查，就绝不在本地重复运行。references/spawn-briefs.md 中的第 3 项规定了每份任务说明都必须包含的规则。

  • 一次运行的门禁数量不得超过机器和审查后端能够流畅处理的上限（从三个左右开始比较稳妥）；每个长时间运行的任务都必须设置明确的超时。
  • 如果 CI 分钟数按量计费或较为有限（例如，按量计费方案中的私有仓库），则在推送前改为在本地运行一次完整检查。如果负责人不确定仓库属于哪种情况，应询问用户。

• 将审查发现的修复交回所属 Agent，由其直接修改。负责人绝不接手开发者的审查循环。当开发者卡在“等待”审查者时，应提醒它查看审查者已完成的结果，或自行启动新的审查者；绝不能由负责人代为审查。

• 如果门禁两次发现同一问题类别，下一道门禁的提示词必须明确提出泛化问题（“如果明天出现这个类别的新成员，修复是否仍然有效，还是会以同样的方式悄然通过？”）；悄然通过属于阻塞性问题。

  实战案例：针对一个名单遗漏，连续两次修复（先补上缺失成员，再对其加以约束）都看似完整，实际却只是针对单个情况的修补。这个问题揭示了两次修复的不足，并促成了彻底消除该问题类别的方案（编译时完备性检查）。看起来已完成的修复与能够消除问题类别的修复是不同的交付物，只有提出这个问题才能分辨。

• **开发者编写静态分析防护措施（如 AST 遍历、可达性分析、默认拒绝的扫描器）之前，任务说明必须用一句话明确保证的范围。**如果没有这句话，每轮审查都会不断扩大目标，开发者和审查者也会为无人明确写下的保证争论不休。

  实战案例：一个默认拒绝的子进程启动防护经过五轮落地门禁审查，每轮都发现另一种隐藏启动操作的方法；直到将保证范围缩小为“防止意外遗漏和分析缺口；故意隐藏不在范围内”才解决。

• 负责人的审查始终在后台运行，绝不以内联方式阻塞负责人。后台运行指非内联，而非不设门禁：负责人必须在落地前阅读审查结果，审查发现也可能阻止落地。将本技能中“编排审查标准”一节（见下文）纳入这些审查的提示词，使审查者在检查正确性的同时，也检查编排规范。

5. 持续跟进每个 PR，直至评论收敛

本次会话中的每个未关闭 PR 都要按照 /pr-landing-discipline 技能运行跟进循环：每轮审查都按同一周期进行分流，通过 GraphQL isResolved 读取线程状态，并在两个方向上切换草稿状态（收敛后设为就绪；需要提交代码的工作则改回草稿）。修复按“审查循环”（第 4 节）的规则分派。团队协作额外要求：

• 如果评论的修复属于其他工作线的职责范围，应回复并解决该评论，注明负责的工作线；接收方工作线的任务说明中也必须包含此事项。

6. 落地

实现过程可以并行，集成到共享基线则不行。“主线”指本次会话将变更集成到的分支：通常是 main，但用户可以指定任何分支，所有流程都适用，无须改动。

落地由两个独立选择决定：

• GATE：在访谈中选择一次——直接提交到主线，或先创建 PR。
• 每个轨道的 BASE：由依赖图决定——独立工作以主线为基线，堆叠工作以尚未落地的同级分支为基线。一次会话中可以混用任意组合。

各模式的流程，包括堆叠链循环及其相关工作树规则，见 references/landing.md。无论选择哪种 gate，以下内容都不变：

• 由谁合并（默认由人工处理）、两项长期例外、仓库定义的任何长期审批标签，以及以退出条件为依据的落地要求，均由 /pr-landing-discipline 技能定义；带有变更展示内容且经过脱敏的 PR 正文由 /pr-and-issue-discipline 技能定义。在 PR gate 模式下，这些要求全部适用。直接模式下没有 PR 正文，也没有合并操作，因此只有以退出条件为依据的落地要求继续适用。

• 先审查再落地，绝不在落地后审查：审查结果必须能够阻止落地。审查范围应是即将落地的确切内容，并在落地前保持冻结：工作提交后，审查分支或 PR 差异（base...HEAD）；落地尚未提交的补丁时，审查暂存差异。绝不能只审查“工作树”，因为合并时工作树处于干净状态会使审查失去意义。

  如果已安装，/rubber-duck-review 技能会定义审查及其收敛流程。在审查收敛之前，任何内容都不得落地。

• 每次落地前都要进行 PII 检查，PR gate 和直接模式均适用：使用会话的 needle 文件，按照 /pr-landing-discipline 技能中的 READY grep，检查每个提交自身新增的行及提交消息、整个替换用 fixture，以及（对于 PR）标题、正文和每条评论。绝不能只检查净差异：某个 fixture 在一个提交中添加、在下一个提交中删除，它仍然会通过第一个提交被发布。

  在直接模式下，检查采用 references/fleet-monitor.md 中的落地 gate 变体，即“每份报告和每次落地都检查 PII”：检查分支分叉点之后每个提交的消息和新增行，以及冻结树中的整个替换用 fixture。对于尚未提交的补丁，则检查暂存的 fixture、暂存差异中的新增行，以及拟定的提交消息。

  needle 文件应包含用户本人，以及会话涉及其设备或账户的任何人的真实标识符；如果变更要替换一个基于真实数据测量的 fixture，还应包含旧文件中的所有完整精度比率和 4 位或更多位的整数。

  如有命中，按 Review Loops (4) 的规定，将问题退回给负责的构建者。若 fixture 含有注明真实数据来源的溯源注释，或包含引用的真实配置或日志，这就属于审查发现，必须用手工编写的替代内容修复。

  规则本身（发布的任何内容都不能让读者知道用户或会话涉及其设备或账户的任何人是谁、如何工作或其设备如何配置），以及替代内容的要求，均由 /pr-and-issue-discipline 技能定义。

• 每次落地前都要进行行数核算，具体要求由 /pr-landing-discipline 技能定义：按类别阅读冻结差异，并对照所述目的、目的与规模对照表，以及按是否符合目的归入 PR 正文的行数汇总。

  负责人在落地 gate 处与审查同时进行核算，直接模式也一样（汇总写入落地报告，而不是 PR 正文）。如果不匹配，按 Review Loops (4) 的规定退回给负责的构建者，以便精简或说明原因。优质变更即使规模有所增长，也仍然可以落地，但用户应能看到增长原因。

  fleet 还会进行 wave 级别的核查，因为规模会随着一次次合理的 PR 逐渐累积。一个 wave 落地后，以及追溯检查规则生效前已落地的 wave 时，提取每次落地的行数：每个 PR 使用技能中的 pulls/<n>/files 格式；每个直接提交使用 git diff --numstat <sha>^..<sha>。 将每次合入的总和与其自身目的进行核对，并将波次总和与波次目的进行核对，然后报告不匹配之处及其原因。

• 每次推送或合并后（直接合入、PR 更新或 PR 合并），都要使用 /watch-github 技能的 watch 订阅 PR 或主线分支，并让判定结果以消息形式返回，其中要指出失败的作业和步骤。绝不要推送后就不管，也绝不要在行内监视 CI。

  在一个集群中，负责人会话将守护进程作为自己的后台任务运行，--mode 与会话模式一致，并监视集群中的每个 PR（watch owner/repo#n）；构建者绝不运行 watch。负责人希望构建者处理某条评审意见时，会通过一条消息转发该意见（Claude Code 的 SendMessage）。

  合并后，判定的 SHA 是主线上的 PR 合并提交，绝不是工作树中的 git rev-parse HEAD：HEAD 仍指向主题分支的最新提交，而 squash 或合并提交只存在于主线上。监视一次主线分支目标，就会报告该提交及其判定结果；对于直接合入，git fetch <base-remote> <mainline> && git rev-parse FETCH_HEAD 会指向该提交。

  如果已安装，/watch-github 技能会定义订阅方式（两种目标形式、门禁工作流和事件文本）。

  每个会话运行一个守护进程，将其作为后台任务启动，并随会话结束而退出：有活动时，间隔为 60 s，且没有任何 Agent 在旁轮询。如果主线上的运行共用一个并发组键，则只有最新的主线提交会得到判定结果（较新的推送会取消较旧提交待运行的任务）。

  生产环境中：按 gh 默认的 3 s 刷新间隔运行的并行监视器耗尽了 GitHub 每小时 5000 次请求的 REST 配额，导致 45 分钟内所有 CI 判定结果都无法获取。

• 每次变基都要检查共享文件的内容（“风险在变基，而不在意图”）：干净的重放可能会悄无声息地丢弃先前合入的内容，这些内容位于双方都会编辑的文件中，也不会留下冲突标记来提醒任何人。该检查是可执行的，而不是用散文描述的令牌配方：scripts/baseline.mts pin/check 用于检查整个文件的归属，scripts/probe.mts tokens 用于检查共享文件中特定行的声明。接入方式见 references/fleet-monitor.md 的 Verifying a Landing。

每次合入主线后，以及所有流都合入后再次针对合并后的整体差异，启动一次评审，专门查找已合并部分之间的集成问题。各流的评审无法发现跨流衔接处的问题，而这一步能捕捉到每轮各流评审都会遗漏的高严重性问题。绝不可跳过。

7. 清理并收尾

在阶段边界处（波次完成、合入时），停止已完成交付的子 Agent，并删除已完成的任务，让可见列表中只显示仍在进行的工作。

• 停止 Agent 前，确认没有任何待交付内容，并先将后续步骤所需的交接信息复制到仍未关闭的任务中。
• 守护进程是会话的后台任务，绝不是子 Agent：/session-events 技能在该技能的 fleet-events 来源上，以及 /watch-github 技能上的守护进程。每个守护进程都会随会话结束而退出（在 Claude Code 收件箱之外，该技能的 file-sink 形式会通过 --pid 或 stop 结束）。监控子 Agent（references/fleet-monitor.md，The Monitor Subagent）是长期运行的服务 Agent，会一直运行到满足退出条件，即负责人在整个集群完成合入后下令停止。
• 工作树交接、移除和扇出式文件归属都存在破坏性故障模式。请遵循 /worktree-hygiene 技能中的相关规则。

Harness 的变体

调用编排器模式即表示长期选择启用多 Agent 操作：生成子 Agent 和 Agent 集群无需每次单独询问。

当 Harness 提供工作流工具（例如 Claude Code 的 Workflow 工具）时，如果其形式比手动分派 Agent 更合适，就使用该工具：例如，对大量 fixture 进行审计或审查、对抗性验证、迁移式分派、评审小组。负责工作树并管理评审循环的构建者仍然是普通 Agent。

为工作流 Agent 设定小范围任务和精简的输出格式：按目录大小划分任务范围，限制列表和字符串的长度，明确说明精简输出是硬性要求，且零条发现也是有效答案。Agent 因重试而卡住，且 token 数量巨大，说明其交付内容过大。终止该 Agent 并重新划分任务，不要继续等待。

当宿主 Agent 无法生成子 Agent 时，保留整体结构，取消并行执行：

• 实现工作在线性流程中完成，按依赖顺序一次处理一个任务，并使用普通的 git worktree add 隔离。
• 仅保留通过后台只读 CLI 调用其他 Agent（codex exec、claude -p），用于 REVIEW 阶段。只读意味着无法编辑，因此不能替代构建者。
• 保留所有关卡：合并前审查、串行集成、每次推送或合并后监控 CI，以及合并后的集成审查。

编排审查标准

• 差异中的任何位置出现 TODO、FIXME、XXX 或 HACK 标记：任务简报禁止出现这些标记。应在变更中完成工作或升级处理，绝不能将其搁置在注释中。
• 超出负责构建者声明范围的编辑（未在任务简报中拦截的文件白名单违规）。
• 遗留的编排产物：keepalive 标记文件、计划在变基时删除的 wip 提交、泄露到配置或脚本中的工作树路径。
• 多个文件中重复出现的近似相同代码块，这是任务分派时所有权范围重叠的典型迹象。

根据上文第 2 节（分解、看板、监控、构建者）和第 7 节（扫描与收尾），以及 /worktree-hygiene skill，对发现的问题进行分流。此处故意不使用 ## Review Criteria 作为标题：这些检查会纳入负责人的评审流程，而不会被自动发现并加入每次 /rubber-duck-review 运行。

参考资料

• references/spawn-briefs.md：生成任务简报的检查清单（禁止停下等待、禁止 TODO、测试规则、未命名的一次性监视器、测试套件的 git fixture 卫生）
• references/fleet-monitor.md：监控角色的两个工具（守护进程的事件、监控子 Agent 的简报）和判断规则；用于一次性读取的 sweep.mts；以及负责人使用的探针、账本和基线
• references/landing.md：两个合并关卡（直接提交，以及带有各轨道基线的 PR，包括堆叠链流程及其相关工作树规则）