关于 interrogate
interrogate 是一项协调多个已配置模型进行对抗式代码审查的技能。它向审查者提供相同上下文和评审标准，再综合结论；不会自动应用修改。
主要功能
- 01确定审查范围与意图
- 02为每个已配置模型启动审查者
- 03向审查者提供统一提示词和标准
- 04综合共识与分歧
- 05按可操作性归类发现
适用场景
- 01审查功能分支的变更集
- 02比较多个模型的独立代码评审
- 03生成分类结论而不自动修改代码
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/interrogate确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
LICENSEreferences/code-quality-review.mdlead-judgment.mdreviewer-prompt.mdrubric.md详细介绍
Interrogate
为每个已配置的模型启动一位审查者，对代码更改进行对抗式审查。每个模型收到相同的提示词和评审标准。对抗性信号来自模型的多样性，而非分配给模型的角色。
交付内容是一份综合结论。不要自动应用更改。
第 1 步：确定范围
根据上下文确定要审查的内容：
- 如果用户指出了特定文件或差异，就使用这些内容
- 如果当前位于功能分支，运行
git diff main...HEAD（或相应的基准分支），获取完整变更集 - 如果用户的消息提及近期工作，就收集相关文件
整理差异（或文件内容）以及审查者理解代码所需的周边上下文文件。
第 2 步：说明意图
启动审查者之前，明确说明意图。根据以下内容推断：
- 用户的消息
- 提交信息
- PR 描述（如有）
- 代码本身
写一段清晰的文字说明。如果不确定意图，先询问用户再继续。
第 3 步：启动审查者
使用 Task 工具，在一条消息中启动所有审查者。读取 ~/.cursor/rules/pstack-models.mdc 中的 interrogate reviewers 行，每个条目对应一位审查者，并根据配置的条目数量扩展或缩减下方的 Reviewer A/B/C 标签。如果该规则文件或对应行不存在，就使用表格中的默认值。
| 子 Agent | 默认模型 |
|---|---|
| Reviewer A | claude-opus-5-5-max |
| Reviewer B | gpt-5.6-sol-max |
| Reviewer C | grok-4.7-xhigh-fast |
每位审查者均需满足以下条件：
subagent_type：generalPurposemodel：已配置的interrogate reviewers条目；如果没有配置行，则使用表格中的默认模型。对于auto或inherit-parent条目，省略model，让审查者使用父模型运行。readonly：true
如果 Task 工具拒绝某个已配置条目，就让该审查者使用其所属系列的表格默认模型，并说明原因。系列按前缀划分：claude-*、gpt-* 和 grok-*。如果没有匹配的系列，就使用 Reviewer A 的默认模型。如果 Task 工具拒绝表格中的默认模型，请检查错误消息中的有效模型标识，选择最接近的替代项（优先选择同一系列中推理能力最高的档位），并使用该模型启动审查者，同时另行创建 PR 以更新默认模型表。不要让模型标识问题阻碍审查。绝不要把别名当作被拒绝的模型标识，也不要对别名应用上述回退规则。
阅读 references/reviewer-prompt.md，并填写模板，内容包括：
- 已说明的意图
- 差异或文件内容
references/rubric.md中的评审标准references/code-quality-review.md中的代码质量审查角度
所有审查者都使用同一份已填写的模板，因此每个模型都会应用代码质量审查角度。
第 4 步：综合结果
随着结果返回，形成统一结论：
- 解析所有发现
- 找出共识。由 2 个或更多模型独立提出的发现具有最高参考价值。
- 标出单个模型的发现。仍值得审阅，但应相应降低权重。
- 去重。不同模型可能会以不同方式描述同一问题。合并这些问题，并注明是哪些模型提出的。
- 记录分歧。如果一个模型指出某个问题，而另一个模型明确表示相反，这对结论很有参考价值。
第 5 步：主审判断
你是主审，一位务实的资深工程师，而不是中立的信息汇总者。
阅读 references/lead-judgment.md，了解完整框架。
将每条发现归入以下类别：
- 采取行动。根据实际目标，这些是真正影响正确性、安全性或可维护性的问题。它们会阻止真实 PR 合并。
- 考虑。这些观点有道理，但你不确定现在处理它们是否值得付出相应成本。值得引起用户注意。
- 记录。技术上成立，但不值得采取行动。鉴于当前阶段，这些问题依赖具体情境、优化为时过早，或影响较小。
- 驳回。错误、吹毛求疵或缺少背景。简要说明原因。
对于每条发现，请注明：
- 哪个模型提出了这条发现
- 类别（采取行动／考虑／记录／驳回）
- 用一句话说明将其归入该类别的理由
输出格式
按以下结构给出评审结论：
意图
[第 2 步中陈述的意图段落]
评审者
- 评审者 [标签]：[模型名称]，[N 条发现]（每位评审者列为一个项目）
采取行动
[应当处理的发现。对于每条发现，请说明具体内容、由哪些模型提出，以及它为何重要。]
考虑
[值得斟酌的发现。对于每条发现，请说明其中的权衡。]
记录
[有效但优先级较低的发现。简要列出。]
驳回
[附简要理由的驳回发现。]
一致性概览
[模型在哪些方面达成一致，在哪些方面存在分歧？一致与分歧的模式说明了什么？]