SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场panel-review

panel-review

编程与开发

查看项目

更新于 10-16 11:29

技能介绍

用途

panel-review 用于对任意变更边界（change boundary）进行组合式多智能体代码审查。它把每一个审查视角都实现为一个已安装的技能，每个视角由独立的子智能体运行，拥有隔离的上下文。编排器负责组合审查阵容、分发视角节点、对每条发现进行对抗性验证，并综合成一份按严重程度排序的报告。视角不是硬编码的：默认值只是约定，最终阵容由用户决定。

审查目标是任意变更边界、任意阶段：未提交的开发中工作、当前分支累积的 diff、某个堆叠层，或一个实际的 pull request。PR 只是目标之一，并非前提条件——在 PR 存在之前进行审查是一等用例。PR 就绪证据门是当边界准备进入 PR 时才加载的视角，而不是运行审查的前提门。

该技能是 graph-engineering 的一个实例；通用的节点/拓扑/运行时机制由 graph-engineering 提供。

主要能力

  • 组合式视角：每个视角都是一个已安装的技能，运行在独立子智能体中。无硬编码视角，默认值是约定，阵容完全可配置。
  • 多目标支持：可审查未提交的 WIP、当前分支 diff、堆叠层或实际 PR。
  • 自动检测：默认视角加上基于项目特征自动检测的条件视角。
  • 对抗性验证：每条存活的发现都由独立的、被要求反驳的节点进行验证，区分「不可验证」与「已反驳」，并呈现跨视角冲突双方的论点而非静默选择一方。
  • PR 就绪证据门：包含变更路径分类（TDD/重构/缩减）与变异证据新鲜度模型，用于判断边界是否可提交 PR。
  • 报告：输出按严重程度排序的统一报告，并附带执行账本。

使用方式

调用语法：/panel-review [target] [modifiers] [lens...]

令牌 含义
(无) 审查当前分支的工作——与默认分支 merge-base 的 diff，加上未提交变更；使用默认 + 自动检测视角
wip 仅审查相对 HEAD 的未提交变更（工作树 + 已暂存）——开发中检查
#123 或 PR URL 审查该 GitHub PR（gh pr diff / gh pr view）
hexagonal-architecture（任意已安装技能名） 把该技能添加为一个视角
only <names...> 仅使用指定视角——不加默认、不做自动检测
-<name> 从阵容中移除某视角（如 -functional）
thorough 扩大阵容（包含所有检测到的条件视角）并使用多票对抗性验证
post 审查后把报告发布到 GitHub PR（需要 PR 目标）

示例：/panel-review · /panel-review #482 thorough · /panel-review hexagonal-architecture domain-driven-design structure-codebase · /panel-review only xstate react-testing · /panel-review -testing post

无法匹配已安装技能的未知令牌：会说明并列出近似匹配，不会猜测。

工作流概要：

  1. 解析目标 diff（PR / 分支 / wip / 堆叠边界）。diff 为空或目标无法解析时停止并报告，而非继续审查。
  2. 内联侦察：用少量廉价工具调用对变更文件分类（生产/测试/配置/文档），读取项目 CLAUDE.md 与关键配置以获取特征，并收集自动检测所需信号。同时捕获变更自身的声明（PR 标题/正文、计划切片、提交信息或用户声明的意图）——审查是拿 diff 与它自己的声明对照。
  3. 组合阵容：内置视角（readiness、quality）+ 核心默认 + 自动检测条件视角，再应用用户的 only/添加/移除令牌。启动前用一行展示最终阵容与大致规模；阵容较大（>8 节点）时先与用户确认，除非用户说了 thorough。
  4. 运行图：按 graph-engineering 运行时执行——可用时使用 Workflow 工具，否则用 Agent 工具扇出，顺序降级模式作为带标记的最后手段。每个视角节点恰好加载一个技能，接收 diff 范围与同级视角列表（保持边界不重叠），按需读取周边代码，返回带 file:line 证据的结构化发现。视角节点为只读。
  5. 验证与综合：按 file/line/claim 去重（多视角一致是信号——会标注），对每条存活发现用独立节点做对抗性验证，保持「不可验证」与「已反驳」区分，并呈现跨视角冲突双方的论点。
  6. 报告：包含阵容、规模、运行时、各视角裁决表、建议（APPROVE / REQUEST CHANGES / NEEDS DISCUSSION）、按严重程度排序的发现、冲突、不可验证声明、清洁区域与未覆盖范围。建议规则：任何确认的 critical → REQUEST CHANGES；未解决的视角冲突或就绪门失败 → NEEDS DISCUSSION；否则 APPROVE 并列出次要项。
  7. 发布（仅在要求时）：带 post 令牌且有 PR 目标时，写入草稿文件并用 gh pr comment <number> --body-file <file>（或正式的 gh pr review）发布，标题为 ## 🤖 /panel-review 并列出阵容——绝不用 shell 参数插入报告正文。没有显式令牌绝不发布；绝不用 --approve 代替用户做决定。

适用场景

  • 评审开发中的工作、分支、diff 或 PR，在合并之前。
  • 用户要求通过指定技能进行审查。
  • 需要多种视角（架构、设计、结构、类型严格等）覆盖同一变更边界时。
  • 判断某变更边界是否已具备提交 PR 的条件（就绪视角）。

限制与边界

  • 开发期间应使用聚焦型智能体（tdd-guardian、ts-enforcer、refactor-scan）；本技能是结尾的整体边界审查。
  • double-check 回答的是不同问题。本技能是通过自有标准实现广度：多个同供应商子智能体，各自对 diff 应用一个用户已安装的技能，发现经验证后合并为一份报告——覆盖广，但每个节点共享宿主模型的盲区。double-check 是独立性：一位强审查者，最好来自不同供应商，冷启动、无继承上下文，对照原始需求检查范围保真度，并跨轮次争论发现直至真正收敛。用 /panel-review 扇出获取覆盖；当风险在于用户及其所有子智能体以同样方式出错时（高风险、有争议的判定，或发布前的最终独立门），引入 double-check。二者可组合：先 /panel-review，最后 double-check。
  • /code-review（内置）运行 Anthropic 固定的议题类视角；本技能存在的意义正是组合用户自己的技能。
  • 审查会读取目标仓库自身的约定（其 CLAUDE.md、术语表、ADR）作为侦察的一部分；与明确本地约定相矛盾的视角发现会作为冲突报告，而不是强制执行。

补充说明

该技能的参考文档包括：references/lenses.md（组合阵容——默认视角、自动检测信号、视角简报模板）、../graph-engineering/references/model-policy.md（选择能力层级、应用供应商映射与预算、记录实际运行时用量）、references/pr-readiness.md（判断变更路径证据——TDD/重构/缩减分类、变异证据新鲜度模型、验证门）、references/workflow-template.md（执行图——具体动态工作流脚本与 Agent 工具回退）。