Back to Details

review-github-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Read-only: Do not modify any files. Your job is to review, report, and submit feedback on GitHub. Do not to make local changes.
Before proceeding, verify prerequisites:
  • Run 
    gh auth status
    to confirm GitHub CLI is authenticated. If not, stop and tell the user to run 
    gh auth login
    .
  • Confirm you have a PR or diff to review. If unclear, ask the user what to review before proceeding.
只读： 不要修改任何文件。你的职责是在GitHub上审核、上报并提交反馈，不要进行本地修改。
继续操作前，请先确认前置条件：
  • 运行
    gh auth status
    确认GitHub CLI已完成认证。如果未认证，停止操作并告知用户运行
    gh auth login
    。
  • 确认你有要审核的PR或差异内容。如果不明确，先询问用户审核对象再继续。

Instructions

使用说明

Review a GitHub pull request, generate prioritized inline comments, and submit them as a batch review.
Use when: reviewing, evaluating, critiquing, auditing, or assessing a GitHub PR. Triggers on requests like "review this PR", "review PR #123", or when given a PR URL to review.
All GitHub interactions must use the 
gh
CLI tool. Do not use 
curl
, direct API URLs, or web fetching. Always use 
gh pr
, 
gh api
, or other 
gh
subcommands.
审核GitHub拉取请求（PR），生成按优先级排序的行内评论，然后以批量审核的形式提交。
适用场景：审核、评估、评析、审计或核验GitHub PR。触发场景包括收到「审核这个PR」、「审核PR #123」之类的请求，或者用户提供了待审核的PR URL。
所有GitHub交互必须使用
gh
CLI工具。 不要使用
curl
、直接调用API URL或网页抓取，始终使用
gh pr
、
gh api
或其他
gh
子命令。

1. Fetch the PR diff

1. 获取PR差异内容

Use 
gh
CLI to get the full diff and PR metadata:
bash
gh pr view <PR> --json number,title,body,baseRefName,headRefName
gh pr diff <PR>
If the user provides a URL, extract the repo and PR number from it. For private repos, always use 
gh
CLI rather than fetching URLs directly.
使用
gh
CLI获取完整diff和PR元数据：
bash
gh pr view <PR> --json number,title,body,baseRefName,headRefName
gh pr diff <PR>
如果用户提供了URL，从中提取仓库和PR编号。对于私有仓库，始终使用
gh
CLI，不要直接抓取URL。

2. Analyze the entire diff

2. 分析全部差异内容

  • Read the complete diff, not just individual chunks. Understand the full scope of changes.
  • Consider how changes across multiple files relate to each other.
  • Check for correctness, security, performance, readability, and maintainability.
  • Do not include fluff, praise, or "LGTM"-style commentary. Only include actionable findings: critical issues (P0/P1) and nits (P2/P3). Every comment must point to a specific problem or concrete suggestion. Comments that merely note something is "a good change" or compliment the author are not actionable — omit them entirely.
  • 阅读完整diff，不要只看单独的片段，理解变更的全部范围。
  • 考虑多个文件的变更之间的关联关系。
  • 检查正确性、安全性、性能、可读性和可维护性。
  • 不要加入无意义内容、赞美或“LGTM”类的评论。 只包含可落地的发现结果：严重问题（P0/P1）和细节优化建议（P2/P3）。每条评论都必须指向具体问题或明确的建议。仅仅说明“这是个好的变更”或者赞美提交者的评论没有可落地性，请完全省略。

3. Generate prioritized comments

3. 生成按优先级排序的评论

Organize all findings into priority levels:
  • P0 — Blocking: Bugs, security vulnerabilities, data loss risks, broken functionality. These must be fixed before merge.
  • P1 — Important: Logic errors, missing edge cases, poor error handling, test gaps. Strongly recommended to fix.
  • P2 — Suggestion: Code style improvements, better naming, minor refactors, documentation gaps.
  • P3 — Nit: Trivial style preferences, optional improvements, minor observations.
Before finalizing, review all findings — including P3 nits — and deliberately decide whether each is worth including. Do not silently drop nits; either include them or note that they were considered and omitted. Try to frame feedback as questions.
Present the full list of comments to the user, grouped and sorted by priority, before submitting. Each comment should include:
  • An index of the feedback to be used in step 4 below.
  • Priority level (P0/P1/P2/P3).
  • File path and line number.
  • The comment text.
将所有发现结果按优先级分层：
  • P0 — 阻塞问题： Bug、安全漏洞、数据丢失风险、功能损坏。合并前必须修复。
  • P1 — 重要问题： 逻辑错误、缺失边界场景处理、错误处理不完善、测试覆盖缺口。强烈建议修复。
  • P2 — 优化建议： 代码风格改进、更合理的命名、小规模重构、文档缺口。
  • P3 — 细节优化： 琐碎的风格偏好、可选的改进、次要的观察结果。
最终确定前，审核所有发现结果（包括P3级别的细节优化），主动判断每一项是否值得包含。不要默默丢弃细节优化建议：要么包含它们，要么说明已经考虑过但决定省略。尽量把反馈表述为问题形式。
提交前，将完整的评论列表按优先级分组排序后展示给用户。 每条评论应该包含：
  • 供下方第4步使用的反馈索引编号
  • 优先级（P0/P1/P2/P3）
  • 文件路径和行号
  • 评论文本

4. Ask for review disposition

4. 询问审核处理方式

Ask the user if they want to submit all feedback, or just some, and how they want to submit the review:
  • Approve — approve the PR with the comments.
  • Request changes — request changes (appropriate when there are P0 or P1 items).
  • Comment — submit comments without approving or requesting changes.
The user may skip submitting certain feedback by index (provided in part 3).
询问用户是否要提交全部反馈，还是仅提交部分，以及想要的审核提交方式：
  • 批准 — 附带评论批准PR
  • 请求修改 — 请求修改（存在P0或P1项时适用）
  • 仅评论 — 提交评论，不批准也不请求修改
用户可以通过第3步提供的索引跳过提交特定反馈。

5. Submit as a single batch review

5. 作为单次批量审核提交

Construct a JSON payload and submit all comments as a single review using 
gh api
with 
--input
.
Always write the JSON to a temp file rather than piping via 
echo
— comment bodies often contain single quotes, backticks, and other characters that break shell quoting:
bash
cat <<'PAYLOAD' > /tmp/pr_review.json
<json_payload>
PAYLOAD
gh api repos/{owner}/{repo}/pulls/{number}/reviews --method POST --input /tmp/pr_review.json
JSON payload format:
json
{
  "event": "APPROVE|REQUEST_CHANGES|COMMENT",
  "body": "",
  "comments": [
    {
      "path": "relative/file/path.ext",
      "line": 42,
      "side": "RIGHT",
      "body": "**[P0]** Comment text here"
    }
  ]
}
Every comment body must start with the priority as a bold prefix: 
**[P0]**
, 
**[P1]**
, 
**[P2]**
, or 
**[P3]**
.
For the review body/summary, leave it empty (
"body": ""
). Do not include summaries, priority counts (e.g. "1 P1, 3 P2"), fluff, filler, or praise. All feedback belongs in inline comments only.
Important — use 
line
and 
side
, NOT 
position
:
  • line
    : The actual file line number in the new version of the file on the PR branch. Do NOT try to calculate this from diff hunk headers — hunk offsets are error-prone. Instead, fetch the real file from the PR branch to confirm each line number before submitting:
    bash
    gh api "repos/{owner}/{repo}/contents/{path}?ref={head_branch}" --jq '.content' | base64 -d | cat -n | sed -n '{start},{end}p'
  • Only fetch files whose paths appear in the diff. Do not guess or infer file paths that are not explicitly listed in the 
    gh pr diff
    output — they may not exist, leading to 404 errors.
  • side
    : Always 
    "RIGHT"
    for comments on new/changed lines.
  • Do not use the deprecated 
    position
    field — it refers to a line's offset within the diff hunk and is error-prone across multi-hunk files.
Return the review URL to the user when complete.
构建JSON payload，使用带
--input
参数的
gh api
将所有评论作为单次审核提交。
始终将JSON写入临时文件，不要通过
echo
管道传输——评论正文通常包含单引号、反引号和其他会破坏shell引号的字符：
bash
cat <<'PAYLOAD' > /tmp/pr_review.json
<json_payload>
PAYLOAD
gh api repos/{owner}/{repo}/pulls/{number}/reviews --method POST --input /tmp/pr_review.json
JSON payload格式：
json
{
  "event": "APPROVE|REQUEST_CHANGES|COMMENT",
  "body": "",
  "comments": [
    {
      "path": "relative/file/path.ext",
      "line": 42,
      "side": "RIGHT",
      "body": "**[P0]** Comment text here"
    }
  ]
}
每条评论正文必须以加粗的优先级前缀开头：
**[P0]**
、
**[P1]**
、
**[P2]**
或
**[P3]**
。
审核正文/摘要请留空（
"body": ""
）。不要包含摘要、优先级统计（例如“1个P1，3个P2”）、无意义内容、填充内容或赞美。所有反馈仅放在行内评论中。
重要提示——使用
line
和
side
，不要用
position
：
  • line
    ：PR分支上文件新版本的实际文件行号。不要尝试从diff块头计算这个值——diff块偏移容易出错。提交前，请从PR分支拉取真实文件确认每个行号：
    bash
    gh api "repos/{owner}/{repo}/contents/{path}?ref={head_branch}" --jq '.content' | base64 -d | cat -n | sed -n '{start},{end}p'
  • 仅拉取diff中出现过路径的文件。 不要猜测或推断
    gh pr diff
    输出中没有明确列出的文件路径——它们可能不存在，会导致404错误。
  • side
    ：针对新增/变更行的评论始终设为
    "RIGHT"
    。
  • 不要使用已弃用的
    position
    字段——它指的是行在diff块内的偏移，在包含多个diff块的文件中容易出错。
操作完成后将审核URL返回给用户。