mcpField
C
code-review-panel

code-review-panel

github.com/gitbobobo测试与质量041 次安装1 天前更新
代码仓库

关于 code-review-panel

code-review-panel 是一套在本地变更阶段组织多模型代码审查的技能，适用于高风险改动或需要独立复核的常规改动。它综合审查意见并由主审分类判断，不会自动应用修改。

主要功能

  1. 01按变更风险选择一名或两名审查者
  2. 02为不同模型提供相同提示与审查准则
  3. 03以只读子 Agent 分派审查
  4. 04合并重复发现并标记共识与分歧
  5. 05由主审分类所有发现并给出结论

适用场景

  1. 01审查并发、安全或公共接口等高风险改动
  2. 02对常规变更获取独立复核
  3. 03比较不同模型对同一差异的发现
  4. 04整理代码审查结论供变更负责人处理

MCP 相关

技能可通过 t3-code MCP 的 delegate_task 派发只读审查子 Agent；也可使用 harness 自带的只读子 Agent 机制。

安装

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

$npx skills add https://github.com/gitbobobo/skills --skill code-review-panel

安装后在 Claude Code 中输入/code-review-panel确认已加载。

包含的文件

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

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

详细介绍

代码审查面板

对于高风险变更（并发、取消、播放、安全或公共接口），使用两名审查者。小型变更由负责人处理；需要独立审查的常规变更，则使用一名来自不同系列的审查者。为选定的每个模型启动一名审查者，对代码变更进行对抗式审查。每个模型收到相同的提示词和评审标准。对抗式信号来自模型多样性，而非分配给模型的角色。

交付内容是一份综合判定。不要自动应用变更。

第 1 步：确定范围

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

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

打包差异（或文件内容），以及审查者理解代码所需的周边上下文文件。

第 2 步：说明意图

启动审查者之前，明确说明变更意图。根据以下内容推断：

  • 用户的消息
  • 提交消息
  • PR 描述（如果存在）
  • 代码本身

写一段清晰的文字。如果不确定意图，请先询问用户。

第 3 步：启动审查者

使用 t3-orchestrator 技能的 route.mjs select --task review 选择审查者模型；选择第二个模型时使用 --exclude-model <first reviewer's model=>，确保面板使用两个不同的模型，而不是同一模型搭配两个运行框架。所有审查者都使用同一份已填充的模板，因此每个模型都会应用代码质量审查视角。

默认情况下，审查者会阅读代码和已有的原始证据。将重型检查请求交由唯一的最终验证负责人处理；审查者不得重复启动构建。通过 t3-code MCP delegate_task，或通过不运行命令的工作所用运行框架自身的只读子 Agent 机制，分派每名审查者为只读子 Agent。

如果模型不可用或运行失败，请遵循 t3-orchestrator 中的重新路由规则；不要在此另行编造备用方案链。

阅读 references/reviewer-prompt.md，并填充模板，内容包括：

  1. 已说明的意图
  2. 差异或文件内容
  3. references/rubric.md 中的评审标准
  4. references/code-quality-review.md 中的代码质量审查视角
  5. 原始证据路径和源代码状态、最终验证负责人，以及之前的发现／回应／未解决的异议和变更范围（或注明是首轮审查）

合格的审查面板即为该轮的最终本地审查；不要针对同一差异再增加审查者。后续轮次应审查已修复的问题、变更范围及相关回归，仅在出现新风险时扩大审查范围。完整传递原始意图、之前的发现、回应和未解决的异议。在 T3 中，每一轮都要新建 delegate_task，使用不同的 clientRequestId（重试时保持稳定），保留其 taskId，并使用异步完成事件。

第 4 步：综合结果

随着审查结果陆续返回，形成统一结论：

  1. 解析所有发现
  2. 识别共识。由 2 个或更多模型独立提出的发现具有最高信号强度。
  3. 识别单一模型的发现。仍值得审阅，但应酌情调整权重。
  4. 去重。不同模型可能以不同方式描述同一问题。合并这些问题，并注明是哪些模型提出的。
  5. 记录分歧。如果一个模型标记了某个问题，而另一个模型明确表达相反意见，这对判定很有参考价值。

步骤 5：负责人判断

你是首席审查者，是一位务实的资深工程师，而非中立的信息汇总者。

阅读 references/lead-judgment.md，了解完整框架。

使用以下类别对每项发现进行归类：

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

对于每项发现，请包含：

  • 提出该问题的模型
  • 类别（采取行动 / 考虑 / 记录 / 驳回）
  • 对分类理由的一句话说明

与 pr-review-loop 的分工

此技能在推送前运行，此时更改仍在本地。PR 创建后，仅在用户要求或更改显著扩大风险时才重复本地评审。由云端机器人（Codex、Code Bot 等）在 PR 上留下的审查意见，按照 pr-review-loop 的收敛规则处理。

输出格式

按以下结构给出结论：

意图

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

审查者
  • 审查者 [标签]：[模型名称]，[N 项发现]（每位审查者各列一项）
采取行动

[应处理的发现。每项包括：描述、提出该问题的模型，以及问题的重要性。]

考虑

[值得斟酌的发现。每项包括：描述、提出该问题的模型，以及其中的权衡。]

记录

[有效但优先级较低的发现。简要列出。]

驳回

[简要说明被驳回的发现及理由。]

一致性概览

[模型在哪些方面达成一致，在哪些方面存在分歧？一致或分歧的模式说明了什么？]

评论

支持 Markdown