review-panel

评审面板

运行流水线：范围 → 简报 → 面板 → 合并 → 分类 → 发现报告 → 审批门禁 → 修复 → 验证 → 最终报告。

在运行开始时设置审批模式。默认模式为门控。/review-panel auto-fix 会设置为自动修复，即对分类为修复处置方式的发现授予长期审批。自动修复绝不会选择升级处理分支；升级处理始终需要用户之后作出决定。

1. 范围

使用 code-review 附带的解析器，为整个面板确定一个评审范围。请在仓库内通过绝对路径运行该解析器，并将 <code-review-dir> 替换为该技能的安装目录：python3 <code-review-dir>/scripts/resolve-scope.py [--scope <spec>]。严格按用户指定的范围执行，不包含相邻变更：将提交、范围、staged 或 worktree（未暂存和未跟踪）作为 --scope；分支使用 <base>...<branch>，因为单独的分支名称仅表示其最新提交；拉取请求则在获取两个引用后使用 <base>...<head>。提供的 diff 文件或指定文件就是给定的范围。未指定 --scope 时，解析器会依次选择第一个非空项：已暂存的变更；未暂存和未跟踪的变更；超前于上游的提交；或当前分支相对于默认分支合并基点的变更。退出码 1 表示没有需要评审的内容：停止并说明这一点。退出码 2 表示引用错误、存在多个合并基点、文件无法读取或输出目录不可写：修复原因，或手动确定范围。将打印出的 scope 和 diff 路径提供给每个评审方，并在简报中列出打印出的 excluded 文件，避免评审方标记仍在编辑中的代码。

2. 简报

从对话、工单或提交消息中收集验收标准。将评审简报写入暂存区。简报应包含意图、已满足的要求、有意为之的权衡、已知限制和声明的非目标，并说明权衡和非目标的依据。简报控制在一页以内。范围排除项应写入简报；结论不应写入：绝不要告诉评审方哪些问题不应标记，也不要限制严重性——由分类环节决定。只要陌生人能引用简报驳回超出范围的发现，简报就算完成。

3. 面板

根据用户指定的预设（/review-panel max）、用户明确指定的完整组成，或默认的 standard，组建评审角色。用户写明的组成优先于所有预设。新视角来自上下文，而非模型。使用父级模型的新上下文仍是新的评审方。

名单，按能力排名：

排名	成员	Harness	同门
1	fable 5	claude	opus 5
2	codex 5.6 sol	codex	terra
3	opus 5	claude	fable 5
4	grok 4.6	cursor	kimi k3

排名 3–4 的成员为后备成员。可作为同门、备用对手，或 ultra 的第二位对手加入。

相对于父级确定三个角色，父级指本次会话的 Harness 和模型：

• 对手：排名最高且使用不同 Harness 的成员，按排名顺序排列。standard 和 max 使用第一位对手；ultra 使用前两位。若未安装其他 Harness，则由同门充当对手；若 Harness 只有一个模型，则由孪生模型充当对手。
• 同门：父级所用 Harness 上除父级自身外能力最强的模型；名单中列出了每位成员的 Harness。若 Harness 只有一个模型，则由孪生模型充当同门。
• 孪生模型：在新上下文中运行的父级自身模型。

父级始终会在已确定的范围内内联运行 code-review（即父级角色），并加入预设指定的新角色：

预设	新启动的声音
standard（默认）	code-review：rival · adversarial：rival
max	code-review：rival、sibling · adversarial：rival、sibling、twin
ultra	code-review：两个 rival、sibling · adversarial：两个 rival、sibling、twin

第 7 步的验证始终交由第一个 rival 处理。在完整环境中，如果父级是 fable，rival 依次为 sol、grok，sibling 为 opus。standard 会让 sol 在两个角色中都进行审查；max 会在两个角色中都加入 opus，并在 adversarial 中加入 fable；ultra 会在两个角色中都加入 grok。

规则：

• 每个评审组都必须包含至少一个在全新上下文中运行的 adversarial-review 声音；adversarial-review 绝不会在父级上下文中运行。同一成员被列出两次时，会在两个彼此独立的全新上下文中运行。
• 推理强度。 在 standard 下，新启动的声音以 high 推理强度运行。在 max 和 ultra 下，默认使用 xhigh；fable 和 kimi k3 使用 high。Terra 始终使用 max。父级声音沿用当前会话的推理强度。用户可以覆盖任何声音的推理强度。
• 成员缺失。 当预设中指定的成员或用户指定的成员不可用时，停止并推荐由可用成员组成的方案。只有用户选择后才继续。指定的 rival 备用链无需确认。
• 如果某个声音所用的模型运行在父级自己的 harness 上，并且该 harness 有内置子 Agent 工具，则通过该工具调用；其他声音一律通过 spawn-agent 调用。无论哪种方式，都要在提示词中传入评审技能的 SKILL.md 路径，作为其章程。告知该声音自行执行评审，不要启动 Agent，也不要调用 review-panel。
• 用户可以指定名册以外的成员：环境能够运行的任何 harness 或模型都可以。对于 spawn-agent 没有对应配置的 harness，应按照该 harness 自身的惯例运行无头 CLI 会话（其 --help 是权威依据）；如果无法运行，则将其视为缺失成员。
• 启动前，向用户报告已确定的范围、简报中的意图和评审组组成。报告后继续；不要等待批准。
• 向每个声音逐字传递相同的范围和简报。并行启动所有新声音，并在它们工作期间执行父级评审。原样收集每份报告；不要淡化或预判其中的发现。同一范围重新运行时，将上一次运行的最终报告作为先前发现传递给每个声音。

4. 合并

将各份报告合并为一个发现列表。将根本原因和修复方式相同的发现合并为一条，并列出所有受影响的位置；可独立处理的缺陷则分开保留。保留最高严重性、最具体的失败场景，以及一致性标签（由 2/3 个声音标记）。发现来源不影响权重。父级声音的发现与其他发现同等计入，而一致性可体现可信度，并影响分诊时的置信度。只有在没有两条发现具有相同的根本原因和修复方式时，合并才算完成。

5. 分类处理

在本次会话中，对合并后的发现内联调用 review-triage。在此处进行分类处理，可以保留对话、审查简报，以及审查期间找回的任何作者背景信息。

提供完整的分类处理报告，包括每项处置、拟议修复方案和升级分支。

在需审核模式下，报告后要针对每项 修复 和 升级 发现进行 决策轮次——这些发现需要用户作出决定。延后和拒绝处置按报告所述执行；用户可在同一轮次中推翻其中任一项。通过框架提供的多选题工具收集决定，每项发现一个问题，批量数量不超过工具的限制；如果没有此类工具，则用文字提问。每个问题都在自身文本中附上发现的具体情况，让用户无需回看报告即可作出决定：

• 用一两行说明问题
• 拟议修复方案
• 修复的预估成本：涉及的文件和函数、粗略的改动行数，以及修复本身引入的任何风险

修复发现提供“批准修复”（标记为推荐）、“延后”和“拒绝”选项；升级发现提供其 A/B/C 分支，并标记分类处理的推荐选项。拒绝需要用户说明理由——从自由文本选项中获取，或主动询问；此理由要随该发现一并写入最终报告。

在自动修复模式下，提供报告后，对每项 修复 处置继续执行；如果报告中有 升级 处置，则在任何修复工作开始前停止，并通过相同格式的决策轮次将其分支交由用户决定。不带 auto-fix 的 /review-panel 调用仅授权审查、分类处理和决策轮次；只有决策轮次的答案才授权修复。

在与决策类型相对应的原生记录中写入持久决策。 如果拒绝理由仅在本地适用且不明显，则在发现所在位置添加注释，说明代码的理由——导致该发现的困惑本身就是一个缺陷，而注释就是它的修复。对于延后，按照分类处理中规划的注释或工单执行；等待证据的延后仅保留在报告中。如果仓库维护 ADR 日志，则将已决定的升级写入 ADR。范围拒绝仅写入最终报告。每条注释都应以代码自身的口吻书写（“已在解析边界验证”），而不是记录审查过程。报告拟议的记录编辑并继续执行。只有当用户授权涵盖这些具体编辑时，才能应用它们；批准无关的修复并不授权这些编辑。否则，将它们保留为报告中的提议。它们不需要第 7 步裁定。

如果没有发现被处置为 修复 或 升级，则在用户批准的任何记录编辑完成后，分类处理报告即完成整个流程。

6. 修复

在需审核模式下，决策轮次的答案决定已批准的修复集合。在自动修复模式下，所有 修复 处置均已获批准。将已批准的修复作为一个批次应用，并遵循分类处理确定的范围：不得超出已批准的发现和升级选项。未获批准的发现仍保持待处理状态。

并行修复器需要根据文件重叠情况进行隔离。启动前，先将批次划分为互不重叠的文件所有权列表；只有划分干净时才能共享工作树，并且每个修复器只能编辑其拥有的文件。若文件重叠，或修复器需要执行破坏性 Git 操作（会还原文件的变更检查），则应改用顺序批次或为每个修复器创建独立工作树。在共享工作树上，将执行期间的完整套件结果视为噪声——相邻修复器编辑到一半的文件会导致测试失败，但这些并非实际故障；真正的门槛是在所有修复器完成后，对组装好的工作树运行一次完整测试套件。

7. 验证修复

验证是一次封闭检查，而不是重新审查。将其交给一个全新的首位对手上下文，而不是整个评审组，也绝不要交给父级：到这一步，父级已经编写了修复批次，而作者自行判定为 resolved 是唯一总能通过的检查。

在父级中整理好证据，让验证者直接阅读，而不是重新推导：

• 已批准的发现，每项都映射到声称修复该问题的差异块
• 修复差异
• 父级在移交前对组装后的代码树运行的全套测试结果

对每项发现，都要求给出 resolved 或 unresolved，并提供具体证据，同时列出修复引入的任何阻塞问题。将未解决的问题和修复引入的阻塞问题交由 review-triage 处理，提交其报告，然后返回第 5 步的审批关卡：门控模式会再进行一轮决策，而自动修复模式可以自动再进行一轮修复批次。**修复后最多进行两轮验证。**达到上限后，报告仍未解决的发现，不要继续修复。

8. 报告

报告以下内容：

• 最终结论和已应用的修复
• 评审组构成及任何替换情况
• 尚未获批的发现
• 延后和驳回的发现，以及各自的证据
• 升级处理事项及其决策方式
• 达到周期上限时仍未解决的事项

当每项已批准的发现都经验证确认已解决，或已明确报告为未解决时，流水线即告完成。只有当修复批次解决了多项高危或严重问题，或重做了大部分范围时，才建议基于新状态重新运行 /review-panel。由用户再次调用构成外层循环。