interrogate

Interrogate

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

第 1 步：范围

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

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

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

第 2 步：意图

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

第 3 步：启动审查者

使用 Task 工具，在一条消息中启动所有审查者；每个 interrogate reviewers 角色条目对应一名，并按条目数量标记为 Reviewer A、Reviewer B 等。默认使用下表。使用 pstack-harness 技能启动。其 Spawn a role 部分会解析角色并构建此 CLI 的启动调用。

子 Agent	默认模型
Reviewer A	fable
Reviewer B	opus
Reviewer C	sonnet

对每名审查者：

• subagent_type：general-purpose
• 模型和推理力度：按照 Spawn a role 为该审查者解析出的配置。
• readonly：true

如果 Task 工具拒绝已配置的条目或表格中的默认值，请使用 pstack-harness 技能处理。如果它拒绝了表格中的默认值，还要在 pstack 仓库中单独开一个 PR，更新本步骤的默认模型表和 skills/setup-pstack/examples/pstack-models.md（解析器读取的文件）。不要因此耽搁审查。绝不要把别名条目当作被拒绝的 slug。

阅读 references/reviewer-prompt.md，并为每名审查者填写相同的模板，其中包含已说明的意图、差异或文件内容、references/rubric.md 中的评审标准，以及 references/code-quality-review.md 中的代码质量审查视角。

第 4 步：综合

随着审查结果陆续返回，建立统一的整体判断。合并任何内容之前，说明审查者使用的模型，并将使用同一模型的多个配置计为一名审查者。解析每位审查者的所有发现。合并描述方式不同但指向同一问题的发现，并标明提出每个发现的模型。由两个或更多模型独立提出的发现，信号最强。阅读仅由一个模型提出的发现，但应相应降低其权重。指出存在的分歧。如果一个模型提出问题，而另一个模型明确给出相反判断，这将构成评定的背景信息。

第 5 步：主审判断

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

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

输出格式

意图

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

审查者

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

采取行动

[每项：问题描述、提出该问题的模型、问题的重要性。]

考虑

[每项：问题描述、提出该问题的模型、权衡。]

记录

[简短列表。]

驳回

[每项简要说明理由。]

共识图

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