mcpField
I
interrogate

interrogate

github.com/michael-denyer测试与质量3.6k954 次安装今天更新
代码仓库

关于 interrogate

interrogate 是用于让多个已配置模型对代码变更进行对抗式审查的 Agent 技能。它适合需要综合审查结论的团队;技能会归纳发现并评估其优先级,不会自动应用修改。

主要功能

  1. 01确定差异和相关文件范围
  2. 02每个已配置模型分配一名审查者
  3. 03综合并归并审查发现
  4. 04按可操作性分类问题
  5. 05不自动应用修改

适用场景

  1. 01审查功能分支的变更集
  2. 02在提交拉取请求前评估代码变更

安装

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

$npx skills add https://github.com/michael-denyer/pstack-claude --skill interrogate

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

包含的文件

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

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

详细介绍

Interrogate

在 Codex 上,遵循此技能前,请阅读平台映射,包括其中针对各技能的说明。

在 GitHub Copilot 上,遵循此技能前,请阅读平台映射,包括其中针对各技能的说明。

在 Muse 上,遵循此技能前,请阅读平台映射,包括其中针对各技能的说明。

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

步骤 1:确定范围

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

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

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

步骤 2:明确意图

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

步骤 3:启动审查者

在一条消息中使用 Agent 工具启动所有审查者,每位审查者对应 pstack-models.md 中 interrogate reviewers 行的一个条目,并按条目数量标记为 Reviewer A、B 等。如果缺少该配置文件或该行,则使用表格默认值。

子 Agent默认模型
Reviewer Aopus
Reviewer Bfable
Reviewer Csonnet
Reviewer Dhaiku

每位审查者的 subagent_type 设为 "general-purpose",readonly 设为 true,并将 model 设为对应的已配置条目;如果没有已配置行,则使用表格中的默认值。对于 auto 或 inherit-parent 条目,省略 model,让该审查者使用父模型运行。

如果 Agent 工具拒绝某个已配置条目,请使用该模型所属系列的表格默认值运行该审查者,并说明这一点。系列按模型名称判断,例如 Opus、Fable 或 Sonnet。如果找不到对应系列,则使用 Reviewer A 的默认值。如果工具拒绝了表格默认值,请从错误消息列出的有效 slug 中选择最接近的项(优先选择相同系列和推理等级),并单独创建 PR 来更新默认值表。不要因 slug 问题而阻碍审查。切勿将别名视为被拒绝的 slug,也不要对别名应用这两种回退方式。

阅读 references/reviewer-prompt.md,并为每位审查者使用相同的模板,填入已说明的意图、差异或文件内容、references/rubric.md 中的评审标准,以及 references/code-quality-review.md 中的代码质量审查视角。根据 poteto-mode 技能的 Subagents 部分,为每个子 Agent 选择适合该任务的推理等级。

步骤 4:综合结果

随着结果陆续返回,汇总形成统一结论。解析每位审查者的发现,合并描述同一问题的不同发现,并注明提出该问题的模型。两个或更多模型独立提出的发现,信号最强。阅读仅由一个模型提出的发现,但应相应降低其权重。记录意见分歧。如果一个模型提出某个问题,而另一个模型明确给出相反判断,这也是判定的参考信息。

第 5 步:主审判断

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

  • 采取行动。根据实际目标,这是真正影响正确性、安全性或可维护性的问题。它们会阻碍真实 PR 的合并。
  • 考虑。这是合理的问题,但你不确定现在解决是否值得付出相应成本。值得引起用户注意。
  • 记录。技术上成立,但目前不可采取行动。它们取决于具体情况、属于过早优化,或在现阶段影响较小。
  • 驳回。错误、吹毛求疵或缺少上下文,并简要说明原因。

输出格式

意图

[第 2 步中陈述的意图段落]

审查者
  • 审查者 [标签]:[模型名称],[N 项发现](每位审查者各占一条)
采取行动

[每项:描述、提出该发现的模型、重要性。]

考虑

[每项:描述、提出该发现的模型、权衡因素。]

记录

[简短列表。]

驳回

[每项并简要说明理由。]

一致性映射

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

推理投入

覆盖表中的角色值可能会在模型后指定推理投入,例如 opus @xhigh。Claude Code 支持的级别:low、medium、high、xhigh、max。具体适用级别取决于模型。没有 @ 的值采用覆盖表中的 default effort 行所指定的级别或 session;如果表中没有该行,则采用 session。session 不设置推理投入,因此调度方式照常。读取模型名称前,先去掉后缀:inherit-parent 或 auto 在所有级别下仍会省略 model,模型名称则作为 model 传递。将级别作为调度的投入字段,并保留原本会使用的 subagent_type。在 Claude Code 的 Agent 调用中,该字段为 effort;在 Codex 的 spawn_agent 中,该字段为 reasoning_effort。在 Muse 中,该字段是 Workflow 子项上的 effort;subagent_spawn 调度则保留会话的推理投入。

评论

支持 Markdown