mcpField
I
interrogate

interrogate

github.com/backnotprop测试与质量3.1k6.1k 次安装今天更新
代码仓库

关于 interrogate

interrogate 是面向编码 Agent 的代码审查技能,通过多个模型独立审查并综合形成结论,不会自动应用修改。它还要求结合变更意图判断问题。

主要功能

  1. 01使用多个模型审查变更
  2. 02收集差异和相关上下文
  3. 03审查前明确变更意图
  4. 04综合并分类审查发现
  5. 05不自动应用修改

适用场景

  1. 01审查功能分支的变更集
  2. 02根据预期评估拉取请求
  3. 03对比多个模型的独立审查

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/backnotprop/pstack --skill interrogate

安装后在 Claude Code 中输入/interrogate确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

references/
code-quality-review.md
lead-judgment.md
reviewer-prompt.md
rubric.md

详细介绍

Interrogate

为每个已配置的模型启动一位审查者,以对抗性方式审查代码变更。对抗性信号来自模型的多样性,而非分配的角色。最终交付内容是一份综合裁决。切勿自动应用变更。

第 1 步:确定范围

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

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

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

第 2 步:明确意图

启动审查者之前,根据用户的消息、提交消息、PR 描述(如果有)以及代码,用一段清晰的话说明意图。如果你不确定意图,请先询问用户。

第 3 步:启动审查者

在一条消息中使用 Task 工具启动所有审查者,每个审查者对应 pstack 设置文件(Cursor 中为 ~/.cursor/rules/pstack-models.mdc,Claude Code 中为 ~/.claude/rules/pstack-models.md,其他运行环境中为 ~/.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 Aclaude-opus-5-5-xhigh
Reviewer Bgrok-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 项发现](每位审查者一条)
采取行动

[每项:描述、哪些模型提出了该问题、为何重要。]

考虑

[每项:描述、哪些模型提出了该问题、权衡因素。]

记录

[简短列表。]

驳回

[每项附简要理由。]

共识图

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

评论

支持 Markdown