pr-comments

PR 评论 — 分类与修复

获取所有未解决的 PR 审查线程，跨机器人去重，按严重程度分类，并生成供人工审批的修复计划。获批后，解决忽略的线程，并启动子 Agent 修复实际问题。

调用方式

• /pr-comments — 根据当前分支自动检测 PR
• /pr-comments 608 — 指定 PR 编号

阶段 1：获取未解决的线程

1a. 确定 PR

# Auto-detect from current branch, or use the provided PR number
gh pr view --json number,headRepositoryOwner,title,headRefName,baseRefName

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

使用 GraphQL 获取线程解决状态，这是唯一可靠的事实来源。

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. 仅筛选未解决的线程

• 保留 isResolved == false 的线程
• 记录 isOutdated——差异可能已变动；将这些线程标记为需要额外审查

1d. 同时获取 issue 级评论（PR 对话选项卡）

gh api --paginate "repos/{OWNER}/{REPO_NAME}/issues/{PR_NUMBER}/comments?per_page=100"

仅筛选人工审查者（非机器人）的评论。这些评论通常最重要。

阶段 2：去重与分类

多个机器人经常会在同一文件/行上指出同一个根本问题。将它们归为一组。

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

针对同一文件且行范围在 5 行以内的线程，很可能讨论的是同一问题。将它们合并为一个逻辑问题。

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

各机器人使用不同的严重程度标记：

机器人	格式	示例
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. 对每个问题进行分类

对于每个去重后的问题，确定：

1. 类别：security | bug | correctness | performance | accessibility | style | config | docs
2. 严重程度：Critical / Major / Medium / Minor / Nitpick
3. 置信度：这是真实问题而非误报的可能性有多大？
   • 人工审查者的评论 → 始终为高置信度
   • 多个机器人指出同一问题 → 高置信度
   • 单个机器人，且缺少关于代码库惯例的上下文 → 低置信度
   • 机器人指出 SKILL.md 或配置文件的问题 → 通常是噪声

2d. 识别建议忽略的项

符合以下任一条件时，将其标记为建议忽略：

• 机器人在非源代码文件（.md、配置文件、迁移文件）上的评论，且不涉及安全问题
• 风格/小问题级别的反馈与项目惯例相矛盾（检查 AGENTS.md）
• 机器人指出的是有意采用的设计（检查 git blame / PR 描述）
• 过时线程（isOutdated == true），且代码已发生变更
• 与正在处理的其他问题重复
• 机器人建议的模式与已加载的 skill 或 AGENTS.md 惯例相矛盾

阶段 3：编写修复计划

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

计划格式

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

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

---

## 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.

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

- **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}

---

### 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}`

- **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}

### I2. ...

---

## Summary

- **{N} issues to fix** across {M} files
- **{K} comments ignored** ({reasons breakdown})
- Estimated complexity: {low/medium/high}

呈现给用户

写好计划后，告知用户：

审查计划已写入 .claude/scratchpad/pr-{PR_NUMBER}-review-plan.md。 {N} 个问题待修复，{K} 个已忽略。请审阅并确认后继续。

在此停止。 等待用户审阅并批准。未经确认，不得继续。

阶段 4：执行（经人工批准后）

用户批准后（用户可能会先编辑计划——执行前请重新读取计划）：

4a. 解决已忽略的讨论串

对于每个已忽略的问题，请在 GitHub 上解决讨论串，并简短说明原因：

# 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}

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

请使用简洁、具体的忽略理由。示例：

• “已确认——项目约定是不写显式返回类型（参见 AGENTS.md）。正在解决。”
• “已确认——讨论串已过时，代码已重构。正在解决。”
• “已确认——这是有意为之；sessionStorage 仅在客户端访问。正在解决。”

4b. 使用子 Agent 修复真实问题

将涉及同一文件或逻辑单元的相关问题分组。然后使用 Task 工具启动并行子 Agent（每个文件或逻辑组启动一个）：

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."

• 每组使用 subagent_type: "general-purpose"
• 涉及不同文件的分组应并行启动
• 涉及同一文件的分组应依次处理

4c. 所有子 Agent 完成后

1. 在 GitHub 上解决已修复问题对应的讨论串（使用与 4a 相同的 GraphQL mutation，并附上类似“已在最新推送中修复。”的评论）
2. 向用户报告结果

已知的机器人噪声模式

这些情况几乎总是可以忽略——但请先核实再忽略：

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. 机器人对迁移文件的评论——几乎总是假阳性（自动生成的代码）