interrogate

Interrogate

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

调度约定。 启动审查者之前，请先阅读 provider-dispatch.md。已配置条目是带有提供方限定信息的描述符；父级会直接启动原生和外部只读通道。在 Codex 上，请通过 codex-tools.md 解析其余 Claude 工具名称。

步骤 1：范围

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

• 如果用户指定了文件或差异，请使用这些内容。
• 如果当前处于功能分支，请运行 git diff main...HEAD（或相应的基准分支），获取完整变更集。
• 如果用户的消息提到了近期工作，请收集相关文件。

将差异或文件内容，以及审查者理解代码所需的周边上下文文件一并提供。

步骤 2：意图

启动审查者之前，根据用户的消息、提交消息（如有 PR 描述则也参考它）以及代码，用一个清晰的段落说明意图。如果不确定意图，请先询问用户再继续。

步骤 3：启动审查者

在一个并行扇出阶段中启动所有审查者，每个对应当前执行环境的 pstack 模型表中 interrogate reviewers 行的一个条目，按条目数量依次标记为 Reviewer A、Reviewer B 等。如果模型表或该行缺失，请使用其角色默认值。原生审查者使用父级子代理原语。外部审查者直接使用启动器，并且必须返回完整且经模型验证的回执。

为每个审查者的描述符设置 read-only 访问权限，并指定唯一的输出路径和回执路径。对于 auto 或 inherit-parent 条目，使用父级子代理原语且不覆盖模型，以便该审查者使用父级模型运行。

如果提供方、登录状态或模型不可用，请记录为退出，并继续使用已完成的审查者。绝不要选择最接近的模型，也不要静默回退；这会破坏跨提供方一致意见的意义。

阅读 references/reviewer-prompt.md，并为每位审查者填写相同模板，内容包括上述意图、差异或文件内容、references/rubric.md 中的评审标准，以及 references/code-quality-review.md 中的代码质量视角。根据任务为每个子代理选择合适的投入程度，参照 poteto-mode 技能的 Subagents 部分。

步骤 4：综合

随着结果返回，逐步形成统一判断。解析每位审查者的发现。合并描述同一问题但表述不同的发现，并注明提出各项发现的模型。由两个或更多模型独立提出的发现具有最高信号强度。阅读单个模型提出的发现，但应相应调整其权重。记录意见分歧。如果一个模型指出某个问题，而另一个模型明确表示相反观点，这将作为判定的参考背景。

步骤 5：主审判断

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

• 采取行动。 根据实际目标，确实影响正确性、安全性或可维护性的问题。它们会阻碍真实 PR 的合并。
• 考虑处理。 问题确实存在，但不确定现在解决它是否值得付出相应成本。值得提醒用户关注。
• 记录。 技术上成立，但无需采取行动。受上下文影响、优化过早或当前影响较小。
• 驳回。 错误、吹毛求疵或缺少上下文，并简要说明原因。

输出格式

意图

[步骤 2 中陈述的意图段落]

审查者

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

采取行动

[逐项说明：问题描述、提出问题的模型、问题的重要性。]

考虑事项

[每项包括：描述、提出该事项的模型，以及相应的权衡。]

注意事项

[简要列表。]

已排除

[每项附上简要理由。]

一致意见图

[模型达成一致和存在分歧之处，以及这些模式说明了什么。]