pr-comments

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

PR Comments — Triage & Fix

PR评论 — 分类与修复

Fetch all unresolved PR review threads, deduplicate across bots, triage by severity, and produce a fix plan for human approval. After sign-off, resolve ignored threads and spawn subagents to fix real issues.
获取所有未解决的PR评审线程,去重来自不同机器人的重复评论,按严重程度分类处理,并生成修复计划供人工审批。审批通过后,标记忽略无需处理的线程,并启动子Agent修复实际问题。

Invocation

调用方式

  • /pr-comments
    — auto-detect PR from current branch
  • /pr-comments 608
    — specific PR number
  • /pr-comments
    — 从当前分支自动识别PR
  • /pr-comments 608
    — 指定PR编号

Phase 1: Fetch Unresolved Threads

阶段1:获取未解决的评审线程

1a. Identify the PR

1a. 识别目标PR

bash
undefined
bash
undefined

Auto-detect from current branch, or use the provided PR number

Auto-detect from current branch, or use the provided PR number

gh pr view --json number,headRepositoryOwner,title,headRefName,baseRefName
undefined
gh pr view --json number,headRepositoryOwner,title,headRefName,baseRefName
undefined

1b. Fetch ALL review threads via GraphQL

1b. 通过GraphQL获取所有评审线程

Use GraphQL to get thread resolution status — this is the only reliable source of truth.
bash
gh api graphql -f query='
{
  repository(owner: "{OWNER}", name: "{REPO_NAME}") {
    pullRequest(number: {PR_NUMBER}) {
      reviewThreads(first: 100) {
        nodes {
          id
          isResolved
          isOutdated
          path
          line
          comments(first: 20) {
            nodes {
              databaseId
              author { login }
              body
              path
              line
              originalLine
              createdAt
              url
            }
          }
        }
      }
    }
  }
}'
Paginate if
hasNextPage
is true. Collect every thread.
使用GraphQL获取线程的解决状态——这是唯一可靠的数据源。
bash
gh api graphql -f query='
{
  repository(owner: "{OWNER}", name: "{REPO_NAME}") {
    pullRequest(number: {PR_NUMBER}) {
      reviewThreads(first: 100) {
        nodes {
          id
          isResolved
          isOutdated
          path
          line
          comments(first: 20) {
            nodes {
              databaseId
              author { login }
              body
              path
              line
              originalLine
              createdAt
              url
            }
          }
        }
      }
    }
  }
}'
如果
hasNextPage
为true则分页查询,收集所有线程。

1c. Filter to unresolved threads only

1c. 仅筛选未解决的线程

  • Keep threads where
    isResolved == false
  • Note
    isOutdated
    — the diff may have moved; flag these for extra scrutiny
  • 保留
    isResolved == false
    的线程
  • 标记
    isOutdated
    的线程——代码差异可能已更新,需额外检查

1d. Also fetch issue-level comments (PR conversation tab)

1d. 同时获取Issue级别的评论(PR对话标签页)

bash
gh api --paginate "repos/{OWNER}/{REPO_NAME}/issues/{PR_NUMBER}/comments?per_page=100"
Filter to comments from human reviewers only (not bots). These are often the most important.
bash
gh api --paginate "repos/{OWNER}/{REPO_NAME}/issues/{PR_NUMBER}/comments?per_page=100"
仅筛选来自人工评审者的评论(排除机器人)。这些通常是最重要的反馈。

Phase 2: Deduplicate & Classify

阶段2:去重与分类

Multiple bots often flag the same underlying issue on the same file/line. Group them.
多个机器人经常会在同一文件/行标记相同的底层问题。将这些评论分组。

2a. Group by file + line range

2a. 按文件+行范围分组

Threads targeting the same file within a 5-line range likely address the same issue. Merge them into a single logical issue.
针对同一文件、行范围在5行以内的线程,很可能指向同一问题。将它们合并为一个逻辑问题。

2b. Parse severity from bot comments

2b. 从机器人评论中解析严重程度

Each bot uses different severity markers:
BotFormatExample
coderabbitai[bot]
Emoji badge in body
🟠 Major
,
🟡 Minor
,
🔴 Critical
gemini-code-assist[bot]
SVG image alt text
![medium]
,
![high]
,
![low]
chatgpt-codex-connector[bot]
Shield badge
P1
,
P2
,
P3
devin-ai-integration[bot]
HTML comment metadataParse
devin-review-comment
JSON for severity
Map all to a unified scale: Critical > Major > Medium > Minor > Nitpick
When multiple bots flag the same issue at different severities, take the highest.
不同机器人使用不同的严重程度标记方式:
机器人格式示例
coderabbitai[bot]
正文中的表情徽章
🟠 Major
,
🟡 Minor
,
🔴 Critical
gemini-code-assist[bot]
SVG图片的替代文本
![medium]
,
![high]
,
![low]
chatgpt-codex-connector[bot]
徽章标记
P1
,
P2
,
P3
devin-ai-integration[bot]
HTML注释元数据解析
devin-review-comment
JSON获取严重程度
将所有标记映射到统一的严重程度等级:Critical(严重)> Major(主要)> Medium(中等)> Minor(次要)> Nitpick(细微优化)
当多个机器人对同一问题标记不同严重程度时,取最高等级。

2c. Classify each issue

2c. 对每个问题进行分类

For each deduplicated issue, determine:
  1. Category:
    security
    |
    bug
    |
    correctness
    |
    performance
    |
    accessibility
    |
    style
    |
    config
    |
    docs
  2. Severity: Critical / Major / Medium / Minor / Nitpick
  3. Confidence: How likely is this a real problem vs. a false positive?
    • Human reviewer comments → always high confidence
    • Multiple bots flagging the same thing → high confidence
    • Single bot, no context about codebase patterns → low confidence
    • Bot flagging a SKILL.md or config file → usually noise
针对每个去重后的问题,确定:
  1. 类别
    security
    (安全)|
    bug
    (漏洞)|
    correctness
    (正确性)|
    performance
    (性能)|
    accessibility
    (可访问性)|
    style
    (风格)|
    config
    (配置)|
    docs
    (文档)
  2. 严重程度:Critical / Major / Medium / Minor / Nitpick
  3. 置信度:这是真实问题还是误报?
    • 人工评审者的评论 → 始终为高置信度
    • 多个机器人标记同一问题 → 高置信度
    • 单个机器人标记,且不了解代码库模式 → 低置信度
    • 机器人标记SKILL.md或配置文件 → 通常是无效反馈

2d. Identify ignore candidates

2d. 识别可忽略的候选问题

Flag as ignore candidate if ANY of these apply:
  • Bot comment on a non-source file (
    .md
    , config, migrations) with no security implications
  • Style/nitpick-level feedback that contradicts project conventions (check AGENTS.md)
  • Bot flagging something that was intentionally designed that way (check git blame / PR description)
  • Outdated thread (
    isOutdated == true
    ) where the code has already changed
  • Duplicate of another issue already being addressed
  • Bot suggesting a pattern that contradicts a loaded skill or AGENTS.md convention
如果满足以下任一条件,标记为可忽略候选
  • 机器人对非源码文件(
    .md
    、配置、迁移文件)的评论,且无安全影响
  • 风格/细微优化级别的反馈与项目约定冲突(查看AGENTS.md)
  • 机器人标记的内容是有意设计的(查看git blame / PR描述)
  • 已过时的线程(
    isOutdated == true
    ),代码已修改
  • 与另一个已处理问题重复
  • 机器人建议的模式与已加载的Skill或AGENTS.md约定冲突

Phase 3: Write the Fix Plan

阶段3:编写修复计划

Write the plan to
.claude/scratchpad/pr-{PR_NUMBER}-review-plan.md
.
将计划写入
.claude/scratchpad/pr-{PR_NUMBER}-review-plan.md

Plan Format

计划格式

markdown
undefined
markdown
undefined

PR #{PR_NUMBER} Review Plan — "{PR_TITLE}"

PR #{PR_NUMBER} 评审计划 — "{PR_TITLE}"

Branch: {branch_name} PR URL: {pr_url} Threads fetched: {total} total, {unresolved} unresolved, {outdated} outdated Bot breakdown: {count per bot}

分支: {branch_name} PR链接: {pr_url} 获取的线程总数: {total} 条,未解决 {unresolved} 条,已过时 {outdated} 条 机器人分布: {各机器人数量统计}

Issues to Fix (ordered by severity)

待修复问题(按严重程度排序)

Only include issues that will actually be fixed. Items classified as ignored in Phase 2 go EXCLUSIVELY in the Ignored section below — never list them here.
仅包含实际需要修复的问题。阶段2中标记为忽略的问题仅出现在下方「忽略列表」中——请勿在此处列出。

1. [{SEVERITY}] {Short description of the issue}

1. [{SEVERITY}] {问题简短描述}

  • File:
    path/to/file.ts#L{line}
  • Category: {category}
  • Flagged by: @bot1, @bot2
  • Comment URL: {url to first comment}
  • What's wrong: {1-2 sentence explanation in plain english}
  • Suggested fix: {concrete description of what to change}
Original comment (from @bot1): {relevant excerpt — strip boilerplate/badges}

  • 文件:
    path/to/file.ts#L{line}
  • 类别: {category}
  • 标记者: @bot1, @bot2
  • 评论链接: {第一条评论的链接}
  • 问题说明: {1-2句通俗易懂的解释}
  • 建议修复方案: {具体的修改描述}
原始评论(来自@bot1): {相关摘录 — 去除模板内容/徽章}

2. [{SEVERITY}] ...

2. [{SEVERITY}] ...



Ignored (with reasoning)

忽略列表(附原因)

Each ignored item appears ONLY here — not duplicated in the Issues to Fix section above.
每个忽略的问题仅出现在此处——请勿在上方「待修复问题」中重复列出。

I1. @{bot} on
path/to/file.ts#L{line}

I1. @{bot} 在
path/to/file.ts#L{line}

  • Why ignored: {specific reason — e.g., "contradicts project convention in AGENTS.md to not use explicit return types", "outdated thread, code already changed", "style nitpick on a config file"}
  • Original comment: {link to comment}
  • 忽略原因: {具体原因 — 例如:「与AGENTS.md中省略显式返回类型的项目约定冲突」、「线程已过时,代码已重构」、「配置文件的风格细微优化建议」}
  • 原始评论: {评论链接}

I2. ...

I2. ...



Summary

总结

  • {N} issues to fix across {M} files
  • {K} comments ignored ({reasons breakdown})
  • Estimated complexity: {low/medium/high}
undefined
  • 需修复 {N} 个问题,涉及 {M} 个文件
  • 忽略 {K} 条评论({原因分类统计})
  • 预估复杂度:{低/中/高}
undefined

Present to user

提交给用户

After writing the plan, tell the user:
Review plan written to
.claude/scratchpad/pr-{PR_NUMBER}-review-plan.md
. {N} issues to fix, {K} ignored. Please review and confirm to proceed.
STOP HERE. Wait for the user to review and approve. Do not proceed until they confirm.
编写完计划后,告知用户:
评审计划已写入
.claude/scratchpad/pr-{PR_NUMBER}-review-plan.md
需修复 {N} 个问题忽略 {K} 条评论。请评审并确认后继续。
在此处暂停,等待用户评审并批准。获得确认前请勿继续。

Phase 4: Execute (after human approval)

阶段4:执行(人工批准后)

Once the user approves (they may edit the plan first — re-read it before executing):
用户批准后(他们可能会先编辑计划 — 执行前请重新阅读):

4a. Resolve ignored threads

4a. 标记忽略线程为已解决

For each ignored issue, resolve the GitHub thread with a brief comment explaining why:
bash
undefined
针对每个忽略的问题,在GitHub线程中添加简短说明后标记为已解决:
bash
undefined

Post a reply comment on the thread

在线程中回复评论

gh api -X POST "repos/{OWNER}/{REPO_NAME}/pulls/{PR_NUMBER}/comments"
-f body="Acknowledged — {reason}. Resolving."
-F in_reply_to={COMMENT_DATABASE_ID}
gh api -X POST "repos/{OWNER}/{REPO_NAME}/pulls/{PR_NUMBER}/comments"
-f body="已确认 — {原因}。标记为已解决。"
-F in_reply_to={COMMENT_DATABASE_ID}

Resolve the thread via GraphQL

通过GraphQL标记线程为已解决

gh api graphql -f query=' mutation { resolveReviewThread(input: { threadId: "{THREAD_NODE_ID}" }) { thread { isResolved } } }'

Use concise, specific dismiss reasons. Examples:
- "Acknowledged — project convention is to omit explicit return types (see AGENTS.md). Resolving."
- "Acknowledged — outdated thread, code has been refactored. Resolving."
- "Acknowledged — this is intentional; sessionStorage is only accessed client-side. Resolving."
gh api graphql -f query=' mutation { resolveReviewThread(input: { threadId: "{THREAD_NODE_ID}" }) { thread { isResolved } } }'

使用简洁、具体的驳回原因。示例:
- "已确认 — 项目约定为省略显式返回类型(查看AGENTS.md)。标记为已解决。"
- "已确认 — 线程已过时,代码已重构。标记为已解决。"
- "已确认 — 此为有意设计;sessionStorage仅在客户端访问。标记为已解决。"

4b. Fix real issues with subagents

4b. 通过子Agent修复实际问题

Group related issues that touch the same file or logical unit. Then launch parallel subagents (one per file or logical group) using the Task tool:
Launch a Task subagent (subagent_type: "general-purpose") for each group:

Prompt template:
"Fix the following PR review issue(s) on branch {BRANCH}:

Issue: {description}
File: {path}#{line}
What's wrong: {explanation}
Suggested fix: {fix description}

Read the file, understand the surrounding context, and make the fix.
After fixing, verify the change is correct.
Do NOT touch unrelated code."
  • Use
    subagent_type: "general-purpose"
    for each group
  • Launch groups in parallel where they touch different files
  • Sequential if they touch the same file
将涉及同一文件或逻辑单元的相关问题分组。然后使用Task工具启动并行子Agent(每个文件或逻辑组一个):
为每个分组启动一个Task子Agent(subagent_type: "general-purpose"):

提示模板:
"修复分支 {BRANCH} 上的以下PR评审问题:

问题:{描述}
文件:{path}#{line}
问题说明:{解释}
建议修复方案:{修复描述}

请阅读文件,理解上下文,然后进行修复。
修复后请验证更改是否正确。
请勿修改无关代码。"
  • 每个分组使用
    subagent_type: "general-purpose"
  • 涉及不同文件的分组可并行启动
  • 涉及同一文件的分组需按顺序启动

4c. After all subagents complete

4c. 所有子Agent完成后

  1. Resolve the fixed threads on GitHub (same GraphQL mutation as 4a, with a comment like "Fixed in latest push.")
  2. Report results to the user
  1. 在GitHub上标记已修复的线程为已解决(使用与4a相同的GraphQL突变,评论内容如"已在最新推送中修复。")
  2. 向用户报告结果

Known Bot Noise Patterns

已知机器人误报模式

These are almost always ignorable — but verify before dismissing:
  1. coderabbit on SKILL.md / AGENTS.md files — flags markdown structure, irrelevant
  2. gemini suggesting explicit return types — check project AGENTS.md or lint config before accepting
  3. devin HTML comment metadata — often duplicates what coderabbit already found
  4. codex P3 style suggestions — usually preferences, not bugs
  5. Any bot suggesting
    as
    casts or non-null assertions
    — check project conventions before accepting
  6. vercel[bot] deployment comments — pure noise, never actionable
  7. Bot comments on migration files — almost always false positives (auto-generated code)
这些情况几乎总是可以忽略 — 但在驳回前请先验证:
  1. coderabbit对SKILL.md / AGENTS.md文件的评论 — 标记markdown结构问题,无关紧要
  2. gemini建议添加显式返回类型 — 接受前请查看项目AGENTS.md或lint配置
  3. devin的HTML注释元数据 — 通常与coderabbit的发现重复
  4. codex的P3级风格建议 — 通常是个人偏好,而非漏洞
  5. 任何机器人建议使用
    as
    类型转换或非空断言
    — 接受前请查看项目约定
  6. vercel[bot]的部署评论 — 纯无效信息,无任何可执行性
  7. 机器人对迁移文件的评论 — 几乎都是误报(自动生成的代码)