interrogate

审查

以粗体或反引号标出的技能名称，或以 /<name> 形式运行的技能，是此技能目录旁边的 ../<name>/SKILL.md 文件；不带前缀的原则名称对应 ../principle-<name>/SKILL.md。请阅读相应文件并遵循其中的要求。大多数 pstack 技能仅供用户使用，因此你的技能工具无法加载它们。每次 delegate_task 调用都遵循 ../poteto-mode/SKILL.md 的 Subagents 部分中的默认设置。

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

第 1 步：范围

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

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

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

第 2 步：意图

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

第 3 步：启动审查者

在一条消息中启动所有审查者；针对 ~/.config/pstack/pstack-models.md 中 interrogate reviewers 行的每个条目，启动一个 delegate_task 子任务，并按条目数量标记为 Reviewer A、Reviewer B 等。若该文件或该行不存在，则让父线程使用的模型担任 Reviewer A，并从 orchestrator_capabilities 报告的、canRunChildTask 为真的其他各个提供商中，选择该提供商最强的模型再启动一名审查者，最多三名。说明这一情况，并建议使用 /setup-pstack。

每位审查者的标题设为 interrogate reviewer <label>；任务说明须注明只读：仅检查，不写入，不运行 git 命令；并根据 Subagents 部分中的条目设置 target。如果条目为 auto 或 inherit-parent，则省略 target，使审查者使用父模型。

如果 delegate_task 拒绝某个已配置条目，就使用 orchestrator_capabilities 列出的同一提供商中最接近的模型来运行该审查者，并说明已进行替换。不要因此阻断审查。绝不要将别名条目视为遭拒条目，也不要对其应用后备方案。

阅读 references/reviewer-prompt.md，并为每位审查者填写相同模板，内容包括已说明的意图、差异或文件内容、references/rubric.md 中的评审标准，以及 references/code-quality-review.md 中的代码质量审查视角。根据 Subagents 部分中的要求，为每个子任务选择合适的推理级别和快速或标准速度。

第 4 步：综合

随着结果返回，逐步形成统一判断。解析每位审查者的发现。合并描述同一问题的不同发现，并注明指出该问题的模型。由两个或更多模型独立提出的发现，可信度最高。阅读单个模型提出的发现，但应相应降低其权重。指出意见分歧。如果一个模型提出问题，而另一个模型明确给出相反意见，这应作为判定的背景信息。

第 5 步：主审判断

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

• 应处理。根据实际目标，会影响正确性、安全性或可维护性的真实问题。此类问题会阻止 PR 通过。
• 酌情考虑。问题成立，但不确定现在处理是否值得其成本。值得提醒用户关注。
• 记录。技术上有效，但无需采取行动。与上下文相关、过早优化或影响较低。
• 驳回。判断有误、过于吹毛求疵或缺少上下文，并简要说明原因。

输出格式

意图

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

审查者

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

采取行动

[每项：描述、提出此问题的模型，以及其重要性。]

考虑

[每项：描述、提出此问题的模型，以及需要权衡之处。]

已记录

[简要列表。]

已驳回

[每项附简要理由。]

共识图

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