关于 interrogate
interrogate 是面向多模型代码审查的技能,指导独立审查并汇总结论;它不会自动应用修改。
主要功能
- 01使用配置的模型审查变更
- 02界定审查范围和意图
- 03综合独立审查结果
- 04按可操作性分类问题
- 05不自动应用代码修改
适用场景
- 01审查功能分支的变更
- 02评估多个模型提出的问题
- 03提交拉取请求前形成结论
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ q-qp-p/ pstack --skill interrogate安装后在 Claude Code 中输入/interrogate确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
references/code-quality-review.mdlead-judgment.mdreviewer-prompt.mdrubric.md详细介绍
Interrogate
为每个已配置的模型启动一名审查者,对代码更改进行对抗式审查。对抗性信号来自模型的多样性,而非分配的角色。交付内容应为综合判定。不要自动应用更改。
第 1 步:确定范围
根据上下文确定要审查的内容:
- 如果用户指定了文件或差异,请使用指定内容。
- 如果当前处于功能分支,请运行
git diff main...HEAD(或相应的基准分支),获取完整变更集。 - 如果用户提到了近期工作,请收集相关文件。
将差异或文件内容与审查者理解代码所需的上下文文件一并打包。
第 2 步:明确意图
启动审查者之前,根据用户消息、提交消息(如有)、PR 描述(如有)和代码,用一个清晰的段落说明意图。如果不确定意图,请先询问用户。
第 3 步:启动审查者
在一条消息中使用 Task 工具启动所有审查者,每个条目对应 pstack 设置文件(在 Cursor 中为 ~/.cursor/rules/pstack-models.mdc,在其他运行环境中为 ~/.agents/pstack-models.md)中 interrogate reviewers 行上的一个条目,并按条目数依次标记为 Reviewer A、Reviewer B 等。如果该文件或对应行不存在,请使用表中的默认值。
其他运行环境。 此技能中的启动方式使用 Cursor 的 Task 工具。在其他运行环境中,请使用相应的子 Agent 工具:Claude Code 中的 Agent(subagent_type: general-purpose)、OpenCode 中的 task(subagent_type: general)、Codex 中的 spawn_agent。保留提示词和模型。省略工具不支持的参数。如果运行环境没有子 Agent 工具(例如未安装扩展的 Pi),则依次自行执行每位审查者的审查。
| 子 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。
如果子 Agent 工具拒绝已配置的条目,请使用其所属系列的表中默认模型执行该审查者,并说明这一点。系列按前缀判定:claude-*,以及 grok-*(包括 cursor-grok-* 和 composer-*)。被拒绝的 composer-* 条目应改用 Reviewer B 的默认模型。如果没有匹配的系列,则使用 Reviewer A 的默认模型。如果工具拒绝表中默认模型,请根据错误消息或运行环境的模型列表,选择最接近的有效模型标识(优先选择相同系列和推理等级),并另开一个 PR 更新默认值。不要因模型标识问题而阻塞审查。切勿将别名条目视为被拒绝的模型标识,也不要对别名应用上述回退规则。
阅读 references/reviewer-prompt.md,并为每位审查者填写相同的模板,其中包含已说明的意图、差异或文件内容、references/rubric.md 中的评审标准,以及 references/code-quality-review.md 中的代码质量审查视角。根据 poteto-mode 技能的 Subagents 部分,为每项工作选择推理等级以及快速或标准速度。
第 4 步:综合
随着审查结果返回,整合出统一结论。解析每位审查者的发现,合并描述同一问题的不同发现,并注明每项发现由哪些模型提出。至少有两个模型独立提出的发现,信号最强。阅读仅由一个模型提出的发现,但应相应降低权重。记录存在的分歧。如果一个模型标记了某项问题,而另一个模型明确给出了相反判断,这将作为判定的背景信息。
第 5 步:主审判断
你是主审,一位务实的资深工程师,而非中立的信息汇总者。阅读 references/lead-judgment.md,了解完整框架。将每项发现归入以下四类之一,并注明提出该发现的模型以及一句话理由。
- 采取行动。结合实际目标来看,影响正确性、安全性或可维护性的真实问题。它们会阻碍真实 PR 的合并。
- 考虑。问题确实存在,但你不确定现在解决是否值得付出相应成本。值得提醒用户关注。
- 记录。技术上成立,但不可采取行动。可能取决于具体情境、优化为时过早,或现阶段影响较小。
- 驳回。错误、吹毛求疵或缺少上下文,并简要说明原因。
输出格式
意图
[第 2 步中陈述的意图段落]
审查者
- 审查者 [标签]:[模型名称],[N 项发现](每位审查者一条)
采取行动
[每项:描述、哪些模型提出了该问题、为何重要。]
考虑
[每项:描述、哪些模型提出了该问题、权衡因素。]
记录
[简短列表。]
驳回
[每项附简要理由。]
共识图
[模型在哪些方面达成共识、存在哪些分歧,以及这种模式说明了什么。]