interrogate

审查

为 panel 行中的每个模型启动一名审查者，对代码更改进行对抗性审查。对抗性信号来自模型的多样性，而非分配的角色。交付内容是一份综合判定。不要自动应用更改。

第 1 步：范围

根据上下文确定要审查的内容：

• 如果用户指定了文件或差异，请使用这些内容。
• 如果当前位于功能分支上，请与默认分支（git diff $(git merge-base HEAD origin/HEAD)，否则使用 main 或 master）的合并基点进行比较，检查完整变更集，包括未提交的更改。
• 如果用户的消息提到了近期工作，请收集相关文件。

将差异或文件内容，以及审查者理解代码所需的任何上下文文件一并打包。

第 2 步：意图

启动审查者之前，根据用户的消息、提交消息（如有）、PR 描述（如有）和代码，用一段清晰的话说明意图。如果意图不明确，请说明你认为最可能的意图并继续。用户可以纠正。

第 3 步：启动审查者

同时启动所有审查者，每个审查者对应 ~/.config/ox/models.md 中 panel 行上的一个条目，并按条目数量依次标记为 Reviewer A、B 等。将每个条目的模型和推理力度传递给你的子代理工具。如果文件或该行不存在，或者 # harness 行指定了不同的 harness，请使用你自己的模型运行三名审查者，并说明这一点，建议用户运行 /setup-ox models：此时审查将失去模型多样性。如果工具拒绝某个条目，请使用其列出的最接近的模型运行该审查者，并说明这一点。不要因此阻塞审查。

每份简报都应说明只读：仅检查，不写入，也不运行 git 命令。为每名审查者以相同方式填写 REVIEWER-PROMPT.md，内容包括已说明的意图、差异或文件内容、RUBRIC.md 中的评审标准，以及 CODE-QUALITY.md 中的代码质量考量。

第 4 步：综合

随着结果返回，整理统一的观点。解析每名审查者的发现。合并不同表述但描述同一问题的发现，并注明提出该发现的模型。由两个或更多模型独立提出的发现，信号最强。阅读单个模型提出的发现，但应相应降低其权重。记录分歧。如果一个模型指出某问题，而另一个模型明确提出相反观点，这将构成判定的参考背景。

第 5 步：主审判定

你是主审，是务实的资深工程师，而非中立的信息汇总者。阅读 LEAD-JUDGMENT.md，了解完整框架。将每项发现归入以下四类之一，并注明提出该发现的模型及一行理由。

• 应处理。鉴于实际目标，会影响正确性、安全性或可维护性的真实问题。此类问题会阻碍正式 PR。
• 可考虑。问题合理，但不确定现在解决是否值得付出相应代价。值得提醒用户关注。
• 已记录。技术上成立，但不值得采取行动。取决于具体情境、优化为时过早，或影响较小。
• 不采纳。判断有误、过于吹毛求疵或缺少上下文，并简要说明原因。

输出格式

意图

[第 2 步中说明的意图段落]

审查者

• Reviewer [标签]：[模型名称]，[N 项发现]（每名审查者各占一条）

应处理

[每项：描述、提出该发现的模型，以及其重要性。]

可考虑

[每项：描述、提出该发现的模型，以及其中的权衡。]

已记录

[简要列表。]

不采纳

[逐项简要说明理由。]

共识图

[说明模型在哪些方面意见一致、在哪些方面存在分歧，以及这种模式反映了什么。]