interrogate
Interrogate
Section titled “Interrogate”给每个配置好的模型开一个评审者，对代码改动做对抗性评审。对抗性来自模型之间的差异，而不是给它们分配不同的角色。交付物是一份综合后的 verdict（结论）。不要自动应用任何改动。
第 1 步：范围
Section titled “第 1 步：范围”根据上下文判断要评审什么：
- 用户指了具体文件或某个 diff，就评审那些。
- 在 feature 分支上，就运行
git diff main...HEAD（或对应的基础分支），拿到完整的改动。 - 用户的消息提到最近做的工作，就把相关文件找齐。
把 diff 或文件内容打包，再加上评审者理解代码所需的周边上下文文件。
第 2 步：意图
Section titled “第 2 步：意图”开评审者之前，先用一段清楚的话写明意图。依据是用户的消息、commit 信息、PR 描述（如果有）和代码本身。如果拿不准意图，先问用户，再往下走。
第 3 步：开出评审者
Section titled “第 3 步：开出评审者”用 Task 工具在一条消息里启动全部评审者，~/.cursor/rules/pstack-models.mdc 里 interrogate reviewers 这一行每个条目一个，标成 Reviewer A、B，依此类推，对上条目数。如果没有这条 rule 或没有这一行，用表里的默认值。
| 子代理 | 默认模型 |
|---|---|
| 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-*。哪个族都对不上时，用 Reviewer A 的默认值。如果连表里的默认值也被拒，就用报错信息里有效 slug 中最接近的等价模型开评审者（优先同一族、同一推理档位），另开一个 PR 更新默认值表。不要因为 slug 的问题卡住评审。别名条目绝不当作被拒的 slug，两种回退都不用在它身上。
读 references/reviewer-prompt.md，给每个评审者填同一份模板：写明的意图、diff 或文件内容、references/rubric.md 里的评审标准，以及 references/code-quality-review.md 里的代码质量视角。
第 4 步：综合
Section titled “第 4 步：综合”结果陆续回来时，拼出一张完整的图。把每个评审者的 finding（评审发现的问题）拆出来。不同说法描述同一个问题的，合并，并注明是哪些模型提的。两个或更多模型各自独立提出的 finding，信号最强。只有一个模型提的，仍然要读，但权重相应调低。记下分歧。一个模型指出某个问题，另一个明确说相反的话，这是下 verdict 时的背景。
第 5 步：主审裁定
Section titled “第 5 步：主审裁定”你是主审，是一个务实的资深工程师，不是不偏不倚地汇总意见的人。完整的判断框架见 references/lead-judgment.md。每条 finding 归进下面四类之一，写上提出它的模型，以及一行归类理由。
- 要处理。结合真实目标看，确实影响正确性、安全或可维护性的问题。放在真实的 PR 里会挡住合并。
- 可以考虑。说得有道理，但不确定它值不值得现在就花成本去处理。值得用户看一眼。
- 记下即可。技术上成立，但没什么可做的。要看具体情况、属于过早优化，或者以目前这个阶段影响很小。
- 驳回。说错了、吹毛求疵，或者缺少上下文，并给一个简短理由。
[第 2 步写明的意图段落]
- Reviewer [标签]：[模型名]，[N 条 finding]（每个评审者一条）
[每条写：问题是什么、哪些模型提的、为什么重要。]
[每条写：问题是什么、哪些模型提的、涉及什么取舍。]
[简短列出。]
[每条附简短理由。]
[模型在哪里一致、在哪里分歧，这种规律说明了什么。]