Back to Details

resolve-pr-threads

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Plan PR Thread Resolution

PR会话解决计划

Input (optional)

输入（可选）

reviewers
: string | string[] | empty
  • empty → all authors
  • provided → only those authors
  • replies must tag actual thread/comment author 
    @<author>
reviewers
: string | string[] | empty
  • 空 → 所有作者
  • 已指定 → 仅包含指定作者
  • 回复必须@实际的线程/评论作者 
    @<author>

You are in PLAN MODE

你当前处于计划模式

Make a plan to resolve all selected unresolved conversations. Output plan only. Do not execute changes.
制定解决所有选中未解决会话的计划，仅输出计划，不要执行变更。

Steps (planning)

步骤（规划阶段）

1) Fetch ALL PR conversations

1) 获取所有PR会话

The most common failure mode is missing feedback that lives outside of "unresolved review threads." GitHub PRs have three distinct conversation surfaces. You must query all three — skipping any surface means silently ignoring real feedback.
Surface A — Review threads (inline comments + replies) Fetch via 
gh api
on the pull request review comments endpoint. These are inline code comments and their reply chains. Filter to threads where 
isResolved == false
or where the thread has no resolution status (regular comments).
Surface B — Review body comments Fetch all reviews via 
gh api
on the pull request reviews endpoint. A review can have a non-empty 
body
containing feedback (nitpicks, suggestions, summaries) that is NOT posted as an inline thread. These are invisible to thread-only queries. Filter to reviews whose 
body
is non-empty and non-boilerplate (skip empty bodies and pure "APPROVED"/"CHANGES_REQUESTED" status-only reviews with no substantive body text).
Surface C — PR-level comments (issue comments) Fetch via 
gh api
on the issue comments endpoint (
/repos/{owner}/{repo}/issues/{pr_number}/comments
). These are top-level PR comments not tied to any review. Include any that contain actionable feedback.
After fetching all three surfaces:
  • Deduplicate (a comment might appear in both a review body and as a thread)
  • Apply 
    reviewers
    filter if set
  • Exclude already-resolved threads (but include everything from Surface B and C that hasn't been explicitly addressed)
Key rule: If a review is marked "COMMENTED" and has body text with actionable feedback, it counts — regardless of whether GitHub considers it an "unresolved thread." Bots like CodeRabbit, Copilot, Sweep, etc. often put their feedback here.
最常见的失败情况是遗漏了「未解决评审线程」之外的反馈。GitHub PR有三个不同的会话场景，你必须查询全部三个——跳过任何一个都意味着默默忽略了真实反馈。
场景A — 评审线程（行内评论 + 回复） 通过PR评审评论端点的
gh api
获取，这些是行内代码评论及其回复链。筛选出
isResolved == false
的线程，或者没有解决状态的线程（常规评论）。
场景B — 评审正文评论 通过PR评审端点的
gh api
获取所有评审内容。评审可能包含非空的
body
，其中的反馈（小修改建议、提议、总结）没有作为行内线程发布，仅查询线程的话会看不到这些内容。筛选出
body
非空且非模板内容的评审（跳过空正文，以及仅包含「APPROVED」/「CHANGES_REQUESTED」状态、无实质性正文内容的评审）。
场景C — PR级别评论（Issue评论） 通过Issue评论端点（
/repos/{owner}/{repo}/issues/{pr_number}/comments
）的
gh api
获取，这些是不关联任何评审的顶层PR评论，包含所有带有可执行反馈的内容。
获取完三个场景的所有内容后：
  • 去重（同一条评论可能同时出现在评审正文和线程中）
  • 如果设置了
    reviewers
    筛选条件则应用
  • 排除已解决的线程（但包含场景B和C中未被明确处理的所有内容）
核心规则: 如果一个评审标记为「COMMENTED」且正文包含可执行反馈，就算有效——不管GitHub是否将其视为「未解决线程」。CodeRabbit、Copilot、Sweep等机器人通常会把反馈放在这里。

2) Triage (for the plan)

2) 分类（规划阶段）

For each unresolved conversation decide 
fix
or 
reply-only
. Capture:
  • conversation type: 
    thread
    | 
    review-body
    | 
    pr-comment
  • thread/comment URL or ID
  • file + line (if applicable; review-body and pr-comments may not have one)
  • author to tag
  • 1-line summary of what's being asked
对每个未解决会话判定是
fix
还是
reply-only
，记录以下内容：
  • 会话类型: 
    thread
    | 
    review-body
    | 
    pr-comment
  • 线程/评论URL或ID
  • 文件 + 行号（如果适用；评审正文和PR评论可能没有该信息）
  • 需要@的作者
  • 需求的1行摘要

3) Make the plan

3) 制定计划

The plan must explicitly state:
计划必须明确说明：

Fix/commit phase (for 
fix
items)

修复/提交阶段（针对
fix
项）

  • /tdd
    per issue (RED → GREEN → REFACTOR → COMMIT)
  • Atomic rule: 1 issue = 1 commit; no mixed commits
  • Record commit hash per fixed conversation (conversation → commit mapping). The executor performs the commit, captures the hash, and substitutes it into the reply's 
    {{COMMIT_HASH}}
    placeholder before posting.
  • 每个问题执行
    /tdd
    流程（红 → 绿 → 重构 → 提交）
  • 原子规则: 1个问题 = 1次提交；不允许混合提交
  • 记录每个已修复会话对应的提交哈希（会话→提交映射）。执行者完成提交后捕获哈希，在发布回复前将其替换到回复的
    {{COMMIT_HASH}}
    占位符中。

Push phase

推送阶段

  • Push once after all fix commits are completed
  • 所有修复提交完成后统一推送一次

Reply/resolve phase (for ALL items: 
fix
+ 
reply-only
)

回复/解决阶段（针对所有项: 
fix
+ 
reply-only
）

  • Reply inline on the exact thread, review, or comment
  • Tag 
    @<author>
  • Pre-write the reply text in the plan (executor must not re-fetch to draft replies)
  • If 
    fix
    : reply must include the placeholder 
    {{COMMIT_HASH}}
    where the commit SHA should go. The executor will substitute this with the actual hash after committing. Example: 
    "Fixed in {{COMMIT_HASH}}."
    → executor posts 
    "Fixed in a1b2c3d."
  • If 
    reply-only
    : concise technical answer or justification (no placeholder needed)
  • Close/resolve the thread (for threads that support resolution)
  • For review-body and pr-comments that can't be "resolved" via GitHub's thread resolution, reply to acknowledge and mark as addressed
  • 在对应的线程、评审或评论下直接回复
  • @
    <author>
  • 在计划中预先写好回复文本（执行者无需重新拉取内容来起草回复）
  • 如果是
    fix
    : 回复必须包含占位符
    {{COMMIT_HASH}}
    ，用于填写提交SHA。执行者提交后会将其替换为实际哈希值。示例: 
    "Fixed in {{COMMIT_HASH}}."
    → 执行者发布为
    "Fixed in a1b2c3d."
  • 如果是
    reply-only
    : 给出简洁的技术回答或理由（无需占位符）
  • 关闭/解决线程（针对支持解决功能的线程）
  • 对于无法通过GitHub线程解决功能标记为「已解决」的评审正文和PR评论，回复确认并标记为已处理

Coverage

覆盖范围

  • Every selected unresolved conversation must appear in the plan
  • No conversation omitted — threads, review body comments, and PR comments alike
  • No final sweep
  • No PR-wide summary comment
  • 所有选中的未解决会话都必须出现在计划中
  • 不得遗漏任何内容——线程、评审正文评论、PR评论均适用
  • 无需最终扫尾
  • 无需PR全局总结评论