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

pr-review

测试与质量

查看项目

更新于 10-16 03:26

技能介绍

用途

该技能是一个「PR 审查编排协议」，目标是自动审查 GitHub 拉取请求并发布两类输出：行内（inline）评论，以及一条合并所有发现的 PR 级摘要评论。其核心定位是「与技术栈无关」（stack-agnostic）：技能本身不定义任何具体语言或框架的规则，而是先发现项目已经记录的内容（测试运行器、需求规格、架构约定、项目本地审查技能），再由各个子代理加载并应用该项目实际拥有的规则。它声明「从不发明特定技术栈规则，也不重复项目文档」。

主要能力

  • 六类子代理并行审查：通过 Task 工具并行启动六个通用子代理，分别负责安全性、需求与完成度（Definition of Done）、测试覆盖、架构与约定、回归与幻觉检测、以及性能。每个子代理拥有独立的免责上下文，提示词中携带 {REPO}、{PR}、{SHA}、diff、PR 意图、已有评论位置与发现地图（DISCOVERY MAP）。
  • 项目自适应发现：探测仓库并生成项目画像，包括测试运行器与布局、需求来源、架构/约定文档、项目本地审查技能路径，并以约定格式（TEST / REQS / CONVENTIONS / REVIEW_SKILLS）逐字传给每个子代理。
  • 统一的严重级别标签：🚨 Critical（会导致失败的缺陷或逻辑错误）、🔒 Security（漏洞或数据暴露）、⚡ Performance（显著性能问题）、⚠️ Warning（代码异味或可维护性问题）、💡 Suggestion（可选改进）。
  • 评论发布机制：支持对新增行发布行内评论、对已有评论线程回复，以及发布 PR 级摘要。要求将多行评论正文先写入临时文件，再用 --body-file 或 -F body=@file 发布。
  • 去重与已解决标记：若某 {path, line} 附近 ±3 行已有评论则跳过；若 diff 已修复某个已有评论所指问题，则通过 replies 端点在该线程回复「[RESOLVED] This appears resolved by the recent changes.」
  • 置信度门槛：仅在 ≥80% 置信度时才报告发现；不确定时保持沉默。
  • 正向提示：每个子代理在列出问题前至少指出一处做得好的方面。

使用方式

该技能需显式调用（声明 disable-model-invocation: true），在编码过程中绝不自动触发。执行分为三步：

  1. 初始化：从用户请求解析 PR 编号（缺失则询问）；通过 gh repo view --json nameWithOwner -q .nameWithOwner 获取仓库；通过 gh pr diff {PR} 获取 diff；通过 gh pr view {PR} --json headRefOid -q .headRefOid 获取 head SHA；通过 gh api repos/{REPO}/pulls/{PR}/comments 加载已有行内评论；通过 gh pr view {PR} --json title,body,headRefName 读取 PR 意图。随后进行项目发现并生成发现地图。
  2. 并行启动子代理：在一条消息中发起六个 Task 工具调用，同时启动。
  3. 启动合并子代理：将六个子代理的发现合并为一条摘要。

评论发布命令（技能原文要求逐字复制）：

对新增行发布行内评论：

gh api repos/{REPO}/pulls/{PR}/comments \
  -F body=@body.md -f commit_id={SHA} -f path={path} -F line={N} -f side=RIGHT

对已有评论线程回复：

gh api repos/{REPO}/pulls/{PR}/comments/{COMMENT_ID}/replies -F body=@body.md

发布 PR 级摘要：

gh pr review {PR} --comment --body-file body.md

其中 line={N} 指 head 文件中 RIGHT 侧的 1 基行号，从 hunk 头的 +c 起点起算，跨新增行与上下文行计数，而非 diff/hunk 偏移。-F/--field 会将 @file 展开为文件内容并对数字类型作处理，-f/--raw-field 则不会，因此正文应使用 -F body=@file 或 --body-file。

约束与规则

  • 仅编排，不自行分析：编排者必须不分析 diff、不读源文件、不亲自撰写任何审查发现，只负责收集上下文、启动子代理、启动合并子代理。即使为节省时间、即使 diff 很小，也禁止自行完成审查。
  • 禁用破坏性操作：绝不 --approve、绝不 --request-changes、绝不修改文件，仅使用 --comment。
  • 评论白名单：仅在以 + 开头的 diff 行（绝不 +++）发布行内评论，并锚定到作为证据的那一行 +。
  • 无归属署名：评论正文绝不提及 AI、助手、模型或任何工具，以审查者身份撰写。
  • 标记前缀：每条行内评论正文以 <!-- pr-review:{type} --> 开头，{type} ∈ security | requirements | tests | architecture | regression | performance。
  • 语气：具体、可执行、友善，始终解释原因（WHY）。

适用场景与限制

适用于使用 GitHub 托管、通过 gh CLI 操作的仓库拉取请求审查，可适配不同语言与框架的项目。限制包括：「技术栈无关」指语言与框架无关，而非宿主无关，GitLab/Bitbucket 托管的仓库（使用 MR 而非 PR）不在范围内。此外，技能为纯编排协议，其子代理数量、并行机制以及二级子代理（如性能子代理）的具体审查细则在所提供的资料中未完整给出，部分内容暂未提供。