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

review-github-pr

编程与开发

查看项目

更新于 10-15 10:10

技能介绍

review-github-pr 是一个面向 GitHub Pull Request 审查场景的技能，来源于 afollestad/personal-ai-skills。它的核心定位是只读审查：不修改任何文件，不进行本地更改，只负责审查、报告并向 GitHub 提交反馈。

用途 该技能用于审查、评估、批评、审计或评价一个 GitHub PR。当用户提出“review this PR”“review PR #123”或直接给出一个 PR URL 时触发。

前置条件 在开始之前，需要先验证前置条件：运行 gh auth status 确认 GitHub CLI 已认证；如果未认证，应停止并提示用户运行 gh auth login。同时需要确认存在可审查的 PR 或 diff；如果不明确，应先询问用户要审查什么。

主要能力

  • 通过 gh CLI 获取 PR 的完整 diff 和元数据，包括编号、标题、正文、基础分支和头分支。
  • 分析整个 diff，而不仅是单个代码块，理解跨多个文件的变更之间的关系。
  • 检查正确性、安全性、性能、可读性和可维护性。
  • 生成按优先级分组的行内评论：P0 为阻塞级（缺陷、安全漏洞、数据丢失风险、功能损坏，合并前必须修复）；P1 为重要级（逻辑错误、缺失边界情况、错误处理不佳、测试缺口，强烈建议修复）；P2 为建议级（代码风格改进、更好的命名、小型重构、文档缺口）；P3 为细节级（琐碎的样式偏好、可选改进、次要观察）。
  • 不包含空话、赞美或“LGTM”式评论，只包含可操作的发现。每条评论必须指向具体问题或具体建议。
  • 在最终确定前，会逐一审视所有发现（包括 P3 细节），明确决定是否值得纳入，不会静默丢弃细节。反馈尽量以提问方式表述。

使用方式

  1. 获取 PR diff：使用 gh CLI 获取完整 diff 和 PR 元数据，例如 gh pr view <PR> --json number,title,body,baseRefName,headRefName 和 gh pr diff <PR>。如果用户提供 URL，则从中提取仓库和 PR 编号。对于私有仓库，始终使用 gh CLI 而非直接抓取 URL。所有 GitHub 交互必须使用 gh CLI 工具，不使用 curl、直接 API URL 或网页抓取。
  2. 分析整个 diff：阅读完整 diff，理解变更全貌，考虑跨文件关系，检查正确性、安全性、性能、可读性和可维护性。
  3. 生成优先级评论：将发现整理为 P0/P1/P2/P3 四个级别。在提交前，向用户展示完整评论列表，按优先级分组排序。每条评论包含：用于后续步骤的索引、优先级、文件路径和行号、评论文本。
  4. 询问审查处置：询问用户是提交全部反馈还是部分反馈，以及希望以何种方式提交审查：批准（Approve）、请求更改（Request changes，适用于存在 P0 或 P1 项时）或评论（Comment，不批准也不请求更改）。用户可以通过索引跳过某些反馈。
  5. 以单次批量审查提交：构造 JSON 载荷，使用 gh api 配合 --input 提交所有评论为一次审查。始终将 JSON 写入临时文件，而不是通过 echo 管道传递，因为评论正文常包含单引号、反引号等会破坏 shell 引用的字符。JSON 载荷格式包含 event（APPROVE|REQUEST_CHANGES|COMMENT）、body（留空）和 comments 数组，每个评论包含 path、line、side（始终为 RIGHT）和 body。每条评论正文必须以加粗优先级前缀开头，如 [P0]。审查正文/摘要留空，不包含摘要、优先级计数、空话、填充或赞美，所有反馈只放在行内评论中。

重要细节

  • 使用 line 和 side，而不是 position。line 是 PR 分支上新版本文件的实际行号，不要试图从 diff 块头计算，因为块偏移容易出错。应通过 gh api 从 PR 分支获取真实文件以确认每个行号。只获取 diff 中出现的文件路径，不要猜测或推断未在 gh pr diff 输出中明确列出的文件路径，否则可能导致 404 错误。
  • 处理 diff 块之间的行：如果评论目标行位于 diff 块之间（即未在任何块中作为上下文显示的未更改代码），基于行的审查评论会被拒绝并返回 422 错误。此时应使用单个评论端点将该评论作为文件级评论单独提交，并在评论正文中引用具体行号。绝不要为了绕过此限制而将多条评论合并到一条评论正文中，始终将每个发现作为独立评论提交。
  • 完成后向用户返回审查 URL。

适用场景 适用于需要审查 GitHub PR 的开发者、维护者或团队，尤其是希望获得结构化、按优先级排序、可操作的行内反馈，并以批量方式提交审查的场景。

限制 该技能为只读，不修改任何文件。依赖 GitHub CLI 且需已认证。评论行号需从 PR 分支真实文件确认，diff 块之间的行需改用文件级评论端点。关于收费、价格、平台支持范围等信息，资料中暂未提供。