interrogate

Interrogate

为每个已配置的模型启动一位审查者，以对抗性方式审查代码变更。对抗性信号来自模型多样性，而非分配的角色。交付内容为综合结论。请勿自动应用变更。

Step 1，范围

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

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

将差异或文件内容与审查者理解代码所需的上下文文件一起打包。

Step 2，意图

启动审查者之前，根据用户消息、提交消息（如有）、PR 描述（如有）和代码，用一段清晰的话说明意图。如果不确定意图，请先询问用户。

Step 3，启动审查者

在一条消息中使用 Task 工具启动所有审查者，为 ~/.cursor/rules/pstack-models.mdc 中 interrogate reviewers 行的每个条目启动一位，并按条目数量标记为 Reviewer A、B 等。如果规则或该行缺失，请使用表格中的默认值。

子 Agent	默认模型
Reviewer A	claude-opus-5-5-xhigh
Reviewer B	grok-4.7-xhigh-fast

每位审查者都应设置 subagent_type: generalPurpose、readonly: true，并将 model 设为其已配置的条目；如果没有配置行，则使用表格中的默认值。对于 auto 或 inherit-parent 条目，请省略 model。

如果 Task 工具拒绝某个已配置条目，请让该审查者改用其所属系列的表格默认模型，并说明这一点。系列按前缀划分：claude-*，以及 grok-*（包括 cursor-grok-* 和 composer-*）。被拒绝的 composer-* 条目应使用 Reviewer B 的默认模型。没有匹配系列时，使用 Reviewer A 的默认模型。如果表格默认模型也被拒绝，请从错误消息中的有效 slug 里选取最接近的模型（优先选择相同系列和推理等级），并单独创建一个 PR 来更新默认模型表。不要因 slug 问题而阻塞审查。切勿将别名条目视为被拒绝的 slug，也不要对别名应用上述回退规则。

阅读 references/reviewer-prompt.md，并为每位审查者填写相同的模板，其中包含所述意图、差异或文件内容、references/rubric.md 中的评审标准，以及 references/code-quality-review.md 中的代码质量审查视角。根据 poteto-mode 技能的 Subagents 部分，为每位子 Agent 选择适合此工作的推理等级和快速或标准速度。

Step 4，综合

随着结果返回，建立统一的判断。解析每位审查者的发现。合并描述同一问题但表述不同的发现，并注明提出该发现的模型。由两个或更多模型独立提出的发现具有最高信号。阅读单个模型的发现，但应相应权衡其分量。记录分歧。如果一个模型指出某个问题，而另一个模型明确提出相反观点，应将此作为判断的背景信息。

Step 5，主审判断

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

• 采取行动。鉴于实际目标，这是影响正确性、安全性或可维护性的真实问题。它会阻碍真实 PR。
• 考虑。问题合理，但不确定现在解决是否值得付出成本。值得提醒用户关注。
• 记录。技术上有效，但不可采取行动。属于依赖上下文、时机过早或影响较低的问题。
• 驳回。判断有误、吹毛求疵或缺少上下文，并简要说明原因。

输出格式

意图

[Step 2 中说明的意图段落]

审查者

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

立即行动

[每项：描述、哪些模型提出了该项、它为何重要。]

考虑

[每项：描述、哪些模型提出了该项、权衡之处。]

已记录

[简要列表。]

已驳回

[每项附简要理由。]

共识图谱

[模型在哪些方面达成共识、在哪些方面存在分歧，以及这些模式说明了什么。]