address-pr-comments

检索当前分支 PR 中尚未解决的评审评论和一般讨论评论，向开发者解释每个问题并提出修复方案，允许开发者讨论和修改方案，然后组建一个协作开发者团队来实施修复。提交更改后，在 GitHub 上回复每条评论，说明如何处理了该问题。

用法：

• /address-pr-comments — 获取并处理当前分支 PR 中尚未解决的评论

说明：

1. 验证先决条件：

   • 通过 Bash 工具运行 gh auth status，验证 GitHub CLI 已安装并完成身份验证
   • 如果 gh 不可用或未完成身份验证，显示以下内容并停止：

     GitHub CLI (gh) is not installed or not authenticated.
     Please install gh and run `gh auth login` before using /address-pr-comments.
     

2. 确定当前分支对应的 PR：

   • 运行 git branch --show-current 获取当前分支名称
   • 运行 gh pr view --json number,title,url,state,baseRefName,author 查找与当前分支关联的 PR，并记录 PR 作者的登录名（author.login），供第 3b 步使用
   • 如果不存在 PR，显示以下内容并停止：

     No pull request found for branch "<current-branch>".
     Please create a PR first, then run /address-pr-comments.
     

   • 如果 PR 已关闭或已合并，向开发者发出警告：

     PR #<number> is <state>. Comments may no longer be actionable.
     

     使用 AskUserQuestion 询问他们是否仍要继续。

3. 获取所有 PR 评论（评审评论 + 一般评论）：

   a) 获取尚未解决的评审评论：

   • 使用 GitHub GraphQL API 获取所有评审讨论串及其解决状态：

     gh api graphql -f query='
       query($owner: String!, $repo: String!, $pr: Int!) {
         repository(owner: $owner, name: $repo) {
           pullRequest(number: $pr) {
             reviewThreads(first: 100) {
               nodes {
                 id
                 isResolved
                 comments(first: 20) {
                   nodes {
                     id
                     databaseId
                     body
                     path
                     line
                     author { login }
                     createdAt
                     url
                   }
                 }
               }
             }
           }
         }
       }
     ' -f owner='{owner}' -f repo='{repo}' -F pr={pr_number}
     

   • 仅收集尚未解决的讨论串。针对每个讨论串，记录：
     • 讨论串 ID（稍后用于回复）
     • 文件路径和行号
     • 完整评论串（原始评论 + 所有回复）
     • 作者
     • 讨论串中首条评论的 URL（用于在回复中添加链接）
   • 对于每个讨论串，忽略正文以 [Agent response] 结尾的回复——这些是先前的 Agent 回复，而不是需要处理的评审评论。但如果讨论串仍未解决，仍需处理该讨论串。 b）获取评审正文评论（全局评审评论）：
   • 评审者提交评审（批准、更改请求或评论）时，可以添加一条顶层正文评论，该评论不会关联到任何特定代码行。这些是“全局”评审评论。
   • 使用 GraphQL API 获取所有评审：

     gh api graphql -f query='
       query($owner: String!, $repo: String!, $pr: Int!) {
         repository(owner: $owner, name: $repo) {
           pullRequest(number: $pr) {
             reviews(first: 100) {
               nodes {
                 id
                 databaseId
                 body
                 state
                 author { login }
                 createdAt
                 url
               }
             }
           }
         }
       }
     ' -f owner='{owner}' -f repo='{repo}' -F pr={pr_number}
     

   • **筛选：**仅包含符合以下条件的评审：
     • body 非空（没有正文内容的评审无须处理）
     • body 不以 [Agent response] 结尾（之前的 Agent 回复）
     • state 为 CHANGES_REQUESTED 或 COMMENTED（跳过正文内容纯属祝贺的 APPROVED 评审，例如“Looks great!”、“LGTM”。如果 APPROVED 评审正文包含实质性且可执行的内容，则应包含）
     • 作者不是机器人
   • 对于每条符合条件的评审正文评论，记录：
     • 评审 ID（databaseId，供之后回复时使用）
     • 评审状态（CHANGES_REQUESTED、COMMENTED、APPROVED）
     • 作者
     • 评论正文
     • 创建日期
     • 评审的 url（用于在回复中添加链接）
   • **注意：**这些评论没有文件／代码行引用，而是针对整个 PR 的顶层反馈。

   c）获取常规对话评论：

   • 使用 REST API 获取常规 PR 评论（议题评论）：

     gh api repos/{owner}/{repo}/issues/{pr_number}/comments --paginate
     

   • 筛除不应处理的评论：
     • 机器人发表的评论（作者的 type 为 "Bot"，或登录名以 [bot] 结尾）
     • 正文以 [Agent response] 结尾的评论（之前的 Agent 回复，不是需要处理的新评论）
     • 纯属批准／确认的评论（例如“LGTM”、“Looks good”、“:+1:”）
   • PR 作者评论：默认不要排除 PR 作者。作者经常会留下供协作者或自动化处理的可执行对话备注（例如重新运行 CI、重新生成视觉快照、“请检查 X”）。应包含这些评论。
   • **可选：跳过作者的无关评论：**如果评论的 user.login 与步骤 2 中 PR 作者的 author.login 一致，且正文显然不可执行，则跳过；例如，只有一个提交 URL，只有“Done”／“Fixed”／“Pushed”且没有后续要求，或内容为空／只有表情符号。
   • 对于每条符合条件的常规评论，记录：
     • 评论 ID（供之后回复时使用的 id 字段）
     • 作者
     • 评论正文
     • 创建日期
     • 评论的 html_url（用于在回复中添加链接）
   • **注意：**常规评论没有文件／代码行引用，也没有解决状态。应包含所有通过上述筛选的评论。

   d）合并并检查：

   • 将三个列表合并为一个列表，按创建日期排序
   • 为每个条目标注其来源：review（来自步骤 3a）、review-body（来自步骤 3b）或 general（来自步骤 3c）
   • 如果两个来源都没有评论，则显示以下内容并停止：

     No unresolved review comments or actionable general comments on PR #<number>. Nothing to address!
     

4. 分析每条评论并提出修复方案：

   对于每条评论（评审评论或常规评论），向开发者清楚说明问题，并提出解决方案。

   对于评审评论（关联到代码），使用以下格式：

   ## Comment <N>/<total> — [Review] `<file>:<line>` — @<author>
   
   ### Reviewer said:
   > <full comment body>
   
   ### Context:
   <Read the referenced file and surrounding code. Explain the relevant code context
   so the developer understands the issue without having to look it up.>
   
   ### Analysis:
   <Explain what the reviewer is asking for and why. Categorize as one of:>
   - **Code change** — specific modifications needed
   - **Question** — reviewer asks for clarification; may not need a code change
   - **Suggestion** — an optional improvement worth considering
   - **Concern** — a potential issue that needs investigation
   
   ### Proposed fix:
   <Describe the concrete approach to address this comment. If it's a code change,
   describe exactly what will change and where. If it's a question, draft the reply.
   If no fix is needed, explain why.>
   

   对于评审正文评论（全局评审反馈，未关联到代码行），使用以下格式：

   ## Comment <N>/<total> — [Review Body] <state> — @<author>
   
   ### Reviewer said:
   > <full review body>
   
   ### Context:
   <Identify what the reviewer is commenting on. Review body comments often address the PR
   as a whole — architecture, approach, missing considerations, or cross-cutting concerns.
   Read the PR diff and relevant files to understand the context.>
   
   ### Analysis:
   <Explain what the reviewer is asking for and why. Categorize as one of:>
   - **Code change** — specific modifications needed
   - **Question** — reviewer asks for clarification; may not need a code change
   - **Suggestion** — an optional improvement worth considering
   - **Concern** — a potential issue that needs investigation
   - **Discussion** — a broader topic about approach or architecture
   
   ### Proposed fix:
   <Describe the concrete approach to address this comment. If it requires code changes,
   identify the files and describe exactly what will change. If it's a question or discussion,
   draft the reply. If no action is needed, explain why.>
   

   对于一般评论（PR 对话），请使用以下格式：

   ## Comment <N>/<total> — [General] — @<author>
   
   ### Comment:
   > <full comment body>
   
   ### Context:
   <Identify any files, functions, or areas of the codebase the comment refers to.
   If the comment mentions specific code, read the relevant files. If the comment is
   about the PR overall (architecture, approach, etc.), summarize the relevant changes.>
   
   ### Analysis:
   <Explain what the reviewer is asking for and why. Categorize as one of:>
   - **Code change** — specific modifications needed
   - **Question** — reviewer asks for clarification; may not need a code change
   - **Suggestion** — an optional improvement worth considering
   - **Concern** — a potential issue that needs investigation
   - **Discussion** — a broader topic about approach or architecture
   
   ### Proposed fix:
   <Describe the concrete approach to address this comment. If it requires code changes,
   identify the files and describe exactly what will change. If it's a question or discussion,
   draft the reply. If no action is needed, explain why.>
   

   对于看起来已解决或无效的评论：

   • 如果评论中描述的问题已在当前代码中修复，请归类为 已解决，并指出解决该问题的现有代码
   • 如果评论无效（引用了过时的代码、误解了实现等），请归类为 无效，并说明原因
   • 这些评论仍需在 GitHub 上回复（第 10 步）——回复应确认收到评论，并说明为何无需进一步处理

   呈现所有评论后，使用 AskUserQuestion 提问：

   我已呈现所有 条尚未解决的评论及建议的修复方案。你可以：

   • 询问任何具体评论的问题（例如：“详细说明评论 3”）
   • 请求修改建议的修复方案（例如：“对于评论 2，将 X 改为 Y”）
   • 批准全部方案并继续实施

   你希望怎么做？

5. 互动讨论：

   开发者可以：

   • 针对任何评论或建议的修复方案提出澄清问题
   • 要求修改建议的处理方案
   • 不同意某项修复并提出替代方案
   • 决定某条评论不需要修改代码（只需回复）

   继续讨论，直到开发者明确批准计划，例如说“开始吧”“批准”“看起来不错”“实施”等。

   持续记录每条评论最终获批的处理方案：

   • 评论 #N： <获批的修复方案描述> 或 <仅回复——不修改代码>

6. 创建开发者团队：

   开发者批准后，组建一个协作团队来实施修复。

   a) 创建团队：

   • 使用 TeamCreate，团队名称为 pr-comments-<pr-number>（例如 pr-comments-142）

   b) 创建共享任务列表：

   • 使用 TaskCreate，为每条需要修改代码的评论创建一个任务，另外创建一个协调任务：
     • 每条代码修改任务：“修复评论 #N：<简短说明>”
     • “协调：验证各项修复之间没有冲突”作为跟踪任务

   c) 确定团队规模：

   • 统计需要修改代码的评论数量
   • 根据数量启动 2 至 4 名开发者：
     • 1–3 条评论 → 2 名开发者
     • 4–6 条评论 → 3 名开发者
     • 7 条或更多评论 → 4 名开发者

   d) 分配工作：

   • 将涉及同一文件或密切相关文件的评论分配给同一名开发者，以避免冲突
   • 各开发者的工作量应大致均衡
   • 清楚记录分工（每名开发者负责哪些评论） e）生成开发者：使用 Task 工具（subagent_type: general-purpose），并设置 run_in_background: true：
   • 告知每位开发者团队名称，以便他们彼此沟通
   • 每位开发者的提示词必须包含：
     • 用于 Agent 间沟通的团队名称
     • 分配给他们的评论及完整的已批准修复说明
     • 相关文件路径和当前代码上下文
     • 协调说明：

       你是团队 <team-name> 中的 Developer 。你负责处理评论 。 团队中的其他开发者正在并行处理其他评论。

       开始修改前：

       • 阅读你计划编辑的文件的最新版本（其他开发者可能已经修改过）
       • 通过 SendMessage 查看团队消息，了解其他开发者的协调说明

       完成修改后：

       • 向团队发送消息，准确说明你修改了哪些文件和行范围
       • 格式：“Developer completed: edited lines - for comment #”
       • 如果发现你的修改与其他开发者的任务重叠或产生影响，请立即发送提醒

       不要提交。 只进行代码修改。团队负责人会处理提交。 完成后，通过 TaskUpdate 将任务标记为已完成。

7. 监控和协调：

   • 等待所有开发者完成任务
   • 所有开发者完成后，检查合并后的修改：
     • 运行 git diff 查看所有修改
     • 检查冲突：多个开发者是否编辑了相同行，或引入了相互矛盾的修改
     • 如果发现冲突，请解决（如果解决方案不明确，则请开发者提供指导）
   • 进行最终完整性检查：阅读每个修改过的文件，确认修改连贯合理

8. 展示修改并等待确认：

   向开发者展示合并后的修改：

   ## Fixes Implemented
   
   ### Comment #1 — `<file>:<line>` — @<author>
   **Fix:** <description of what was changed>
   **Files modified:** `<file>` (lines <start>-<end>)
   
   ### Comment #2 — `<file>:<line>` — @<author>
   **Fix:** <description> (or "Reply only — no code change")
   
   ...
   
   ### Files Modified
   - `path/to/file.ts`
   - `path/to/other.ts`
   

   然后显示：

   所有修复均已完成。请检查修改，并在准备好提交时予以确认。 提交前，你也可以要求我调整任何修复。

   请等待开发者明确确认后再提交。 不要自动提交。

9. 提交修改：

   开发者确认后：

   • 仅暂存作为修复一部分而修改的文件（使用 git add <file1> <file2> ...，不要使用 git add -A）
   • 按照仓库现有风格创建提交消息。建议格式：

     Address PR #<number> review comments
     
     - <Comment #1 short description>
     - <Comment #2 short description>
     - ...
     
     Co-Authored-By: Claude Opus 4.6 <[email protected]>
     

10. 在 GitHub 上回复评论：

    提交后，使用 gh CLI 回复 GitHub 上的每条评论。

    a）对于审查评论——如果已进行代码修复：

    • 在审查评论线程中回复，说明如何处理了该评论
    • 如果修复较短（约 20 行以内），请附上修复代码；使用围栏代码块
    • 如果修复较长，请引用文件路径和行号：

      已在 <file>（第 – 行）修复。<简要说明修改内容。>

    • 使用 gh api 命令回复：

      gh api repos/{owner}/{repo}/pulls/{pr_number}/comments -f body='<reply>' -f in_reply_to=<comment_id>
      

    b）对于审查评论——如果无需代码修复（仅提问或回复）：

    • 发布已批准的回复，解释为何无需修改代码
    • 具体说明：引用现有代码、设计决策或文档，以回应审查者的疑虑 c）对于评审正文评论——回复评审：
    • 使用 REST API 在评审中发表评论：

      gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews/{review_id}/comments -f body='<reply>'
      

    • 回复格式应回应评审者的总体反馈：

      关于您的评审：

    • 如果已修复代码，请包含与行内评审评论回复相同的详细信息（文件路径、行号或简短代码块）

    d）对于一般评论——在 PR 对话中回复：

    • 发布一条新的 issue 评论，回复原评论。引用原评论以提供上下文：

      gh api repos/{owner}/{repo}/issues/{pr_number}/comments -f body='<reply>'
      

    • 回复格式应提及原评论作者和评论：

      关于 @ 的评论：

    • 如果已修复代码，请包含与评审评论回复相同的详细信息（文件路径、行号或简短代码块）

    e）回复格式（适用于所有评论类型）：

    • 回复应专业且简洁
    • 以简短总结开头（例如“已修复——……”“提醒得好——……”“无需更改——……”）
    • 适用时，包含带行号的代码引用
    • 始终在每条回复末尾另起一行添加 [Agent response]。 此标签用于标识自动回复，方便后续运行跳过已处理的评论
    • 对于已处理的评论，回复说明问题已解决（引用相关代码或提交）
    • 对于无效评论，礼貌地说明该评论为何不适用

11. 清理并汇报：

    • 关闭开发团队：
      • 通过 SendMessage 向每位队友发送 shutdown_request
      • 等所有人确认后，调用 TeamDelete
    • 提供最终总结：

      ## 已处理的 PR 评论
      
      **PR：** #<number> — <title>
      **已处理的评论数：** <N>
      **提交：** <short SHA>
      
      ### 修复内容
      - 评论 #1（`<file>:<line>`）— <简要说明> — 已在 GitHub 上回复
      - 评论 #2（`<file>:<line>`）— <简要说明> — 已在 GitHub 上回复
      ...
      
      ### 后续步骤
      - 推送提交：`git push`
      - 确认 CI 通过
      - 如有需要，请求重新评审
      

12. 处理边缘情况：

    • 如果评论引用的文件已不存在，请在分析中注明，并考虑回复评审者，说明该文件已被移除（如能从 git 历史中确定原因，也请说明）
    • 如果自评审以来评论引用的行已发生变化，请阅读当前文件，并根据当前代码调整修复
    • 如果两条评论相互冲突，请在步骤 4 中指出冲突并请开发者决定
    • 如果评论含糊不清，请提出你认为最合理的解释，并在步骤 5 中请开发者确认
    • 如果开发者拒绝所有提议的修复，请跳过实现，并可选择发布回复说明决定
    • 如果开发者 Agent 失败或产生了错误的更改，请尝试自行修复或向开发者寻求指导
    • 如果一般评论很含糊或未明确引用任何代码（例如“我们可以讨论一下方案吗？”），请将其归类为 讨论，并根据 PR 的更改提出回应问题的回复
    • 如果其他人已在评论线程中回复了一般评论，请跳过该评论，并注明其已处理
    • 如果 PR 作者的评论仅与工作流有关（例如更新快照、重新运行视觉测试、触发 CI），请根据代码库将其视为 代码更改 或 建议：检查 package.json / CI 配置后，提出确切的命令或测试目标（例如 Playwright --update-snapshots、Percy 等）