parallel-review

并行代码审查

我会同时让所有审查者检查本地差异，再把他们的发现合并成一个排序列表。这样既快，也不会让任何审查者看到其他人的工作，因此各项发现彼此独立。

工作流

第 1 步：确定范围

• 用户指定文件时，我会审查这些文件。
• 否则，我会通过 git diff HEAD 审查所有已暂存和未暂存的更改。
• 派发审查任务前，我会固定比较基准。如果调用方提供了 merge-base SHA（如 done），我就使用它。否则，我会通过 gh repo view --json defaultBranchRef 读取默认分支，然后解析 git merge-base HEAD origin/<default branch>。审查者需要将其作为上下文，以区分基准分支的行为与本分支先前提交引入的行为。它绝不会扩大审查目标；目标仍是第 1 步确定的范围。
• 如果存在先前的收敛产物，我会在派发前调用 converge-reviews，并提供当前基准、差异哈希、路径、请求、计划中的审查者名单和审查角度。我会复用未发生变化的结果。如果它返回 continue，我只会派发它指出的失效审查范围。对于其他任何结果，我都会直接应用，不再启动新一轮审查。

第 2 步：确定审查者名单，然后派发

我会先列出审查者名单，再通过 Agent 工具并行启动所有成员。

下面的成员 1 至 3 是 subagent_type 值，我会原样传给 Agent 工具。成员 4 是运行技能的 Agent。/web-interface-guidelines 和 /rams 是技能，不是 Agent 类型，因此不能用作 subagent_type。我会派发一个 general-purpose Agent，由它调用这些技能。

在列出名单前，我会根据差异大小确定审查者配置。每项任务完成后，done 都会运行这项技能，所以不按差异大小配置审查者，会让一次一行代码的修复承担重写级别的成本。如果用户指定了文件，我会用 git diff --shortstat HEAD -- <paths> 统计第 1 步的范围；否则使用不带路径参数的 git diff --shortstat HEAD。

• 如果只有一个文件且更改行数大约少于 50 行，或者用户要求快速审查，审查者名单就只有 pr-review-toolkit:code-reviewer，且本步骤其余内容不适用。
• 其他情况下，根据下方成员构建审查者名单。

以下成员始终在名单中：

1. 代码审查 Agent，subagent_type: "pr-review-toolkit:code-reviewer"。
2. CodeRabbit 审查 Agent，subagent_type: "coderabbit:code-reviewer"。

满足条件时，我会将以下成员加入名单：

3. 静默失败检查 Agent，subagent_type: "pr-review-toolkit:silent-failure-hunter"。如果差异涉及错误处理、try-catch 或回退逻辑，我就会加入它。
4. UI 审查 Agent，subagent_type: "general-purpose"。如果差异涉及前端或 UI 代码，我就会加入它。我会要求它针对差异调用 /web-interface-guidelines 和 /rams，并返回合并后的发现。

共享提示词和各 Agent 的审查角度如下：「审查这些已更改文件，检查错误、逻辑问题，以及是否遵循项目的 CLAUDE.md 规范：[files]。审查目标仅限于 [scope diff command]，即第 1 步确定的范围或修复增量。比较基准 [merge-base SHA] 仅作为检查产品意图的上下文：基准分支中的内容以 git show [merge-base SHA]:<file> 为准。」

每位审查者还会收到检查产品意图的指示。如果某项发现的修复会改变基准分支上已有的可观察行为（即固定的 merge-base 上的行为，而非本分支先前提交引入的行为），审查者会为其添加 product-intent 标签，并报告查到的内容：测试是否断言了当前行为，注释或文档是否说明了该行为，以及根据 git blame 或 git log -S 是哪个提交引入了该行为，包括“未找到”。审查者会按实际严重程度报告带标签的发现，不会修复它们。

派发前，我会说明审查者名单。第 3 步合并发现时会以此为核对清单。

步骤 3：合并

只要名单上还有任何审查者未完成审查，合并就尚未完成。我会逐一核对每位成员的状态，无论其已报告结果、审查失败还是已重新派发。

1. 我会合并所有发现，合并不同审查者报告的重复项。任何来源发现上的 product-intent 标签都会在合并后保留，其证据也会随之纳入合并后的发现。
2. 我会根据文件、所属符号、规范化后的缺陷类别和缺陷实例指纹，为每个合并后的发现分配稳定 ID。我会从最小的稳定语义代码锚点（例如被调用对象、访问的字段、分支标签或数据流端点）以及被违反的不变量推导指纹。如果两个缺陷仍共享同一锚点，我会将最近的不同语义父级或操作数纳入指纹。我会规范化无关紧要的格式、字面量和审查者措辞，并排除原始行号。只有这四个部分全部匹配时，我才会合并，并保留每位来源审查者的信息。这些 ID 及其处置方式由调用方负责。我不会建立统一的发现 ID 权威来源。
3. 排序：严重 > 较高 > 中等 > 轻微，然后整理成一份可追溯的清单。product-intent 标签与严重程度并列保留，绝不会降低严重程度。该标签具有约束力：未经用户批准，任何 Agent 都不得修复带此标签的发现；传递清单时，也不得移除或降级该标签。
4. 我会调用 converge-reviews，并提供发起审查的请求、本地基线与当前 diff 哈希、已审查的路径、审查者名单与审查视角、合并后的发现、处置方式以及先前的收敛产物。我会遵循其结果约定，然后将排序后的清单和收敛结果交还给调用方。