Fetch all review threads on a pull request via GraphQL, ensuring no comments are missed — including general review comments and conversation threads that the REST endpoint omits.
Run the script on every PR before you merge it. Every time. No exceptions — not for tiny PRs, not for "obviously safe" changes, not when you're in a hurry. Comments can land between the time the PR opens and the time you click merge, including from automated reviewers (Copilot, CodeRabbit, etc.) that post asynchronously. Merging without checking means shipping work the reviewer flagged and never seeing the feedback.
Every single comment gets a threaded reply. Not "the important ones." Not "the ones I changed code for." Every one. Including:
Comments you fixed → reply explaining what you did and link the follow-up commit/PR.
Comments you decided NOT to address → reply with the reasoning. Silence is not a decision; it's invisible to the reviewer.
Comments that are questions → answer the question.
Comments from bots → still reply. The thread stays unresolved otherwise, and future reviewers can't tell whether it was considered.
Replying to a comment is part of addressing it. A fixed bug with no reply is half-done work — the reviewer has no way to know it was seen, let alone resolved.
sh
gh api -X POST \ /repos/OWNER/REPO/pulls/PR/comments/COMMENT_ID/replies \ -f body="Done — fixed in <commit-sha or PR link>"
For decline-with-reason replies, be specific about why — "intentionally not addressing X because Y" — so the rationale is captured in the thread, not lost in chat.
Reply to threads; never resolve them. Resolution is the reviewer's call, made once they have read your reply and agree the thread is settled.
Resolving your own thread removes it from the reviewer's unresolved queue before they have seen the reply, hiding work they explicitly asked about. It also reads as grading your own homework. Reply, then leave the thread open; the reviewer resolves it.
Concretely: use only the reply endpoint above (or the GraphQL addPullRequestReviewThreadReply mutation). Never call resolveReviewThread.
Use this when addressing PR review feedback. The REST endpoint (gh api repos/OWNER/REPO/pulls/PR/comments) only returns inline diff comments and misses general review comments and conversation threads. This script fetches everything.
Queries two separate GraphQL connections: reviewThreads for inline diff comments and reviews for top-level review bodies (e.g. request-changes notes with no inline comments)
Includes both inline diff comments and general review comments
Groups threads by resolved status (unresolved first)
Shows full context for each thread: author, body, file path, line number, diff hunk, and timestamps
Flags outdated threads that may reference old file versions
PR Review Comments
Fetch all review threads on a pull request via GraphQL, ensuring no comments are missed — including general review comments and conversation threads that the REST endpoint omits.
Hard rules — non-negotiable
These three rules are the entire point of this topic. Internalize them.
1. ALWAYS check for comments BEFORE merging
Run the script on every PR before you merge it. Every time. No exceptions — not for tiny PRs, not for "obviously safe" changes, not when you're in a hurry. Comments can land between the time the PR opens and the time you click merge, including from automated reviewers (Copilot, CodeRabbit, etc.) that post asynchronously. Merging without checking means shipping work the reviewer flagged and never seeing the feedback.
2. ALWAYS reply to EVERY comment
Every single comment gets a threaded reply. Not "the important ones." Not "the ones I changed code for." Every one. Including:
Replying to a comment is part of addressing it. A fixed bug with no reply is half-done work — the reviewer has no way to know it was seen, let alone resolved.
For decline-with-reason replies, be specific about why — "intentionally not addressing X because Y" — so the rationale is captured in the thread, not lost in chat.
3. NEVER resolve a thread yourself
Reply to threads; never resolve them. Resolution is the reviewer's call, made once they have read your reply and agree the thread is settled.
Resolving your own thread removes it from the reviewer's unresolved queue before they have seen the reply, hiding work they explicitly asked about. It also reads as grading your own homework. Reply, then leave the thread open; the reviewer resolves it.
Concretely: use only the reply endpoint above (or the GraphQL
addPullRequestReviewThreadReplymutation). Never callresolveReviewThread.When to use
Use this when addressing PR review feedback. The REST endpoint (
gh api repos/OWNER/REPO/pulls/PR/comments) only returns inline diff comments and misses general review comments and conversation threads. This script fetches everything.The pattern
Run the collocated script with a PR number:
Present the output directly — it is already formatted as markdown.
What the script does
reviewThreadsfor inline diff comments andreviewsfor top-level review bodies (e.g. request-changes notes with no inline comments)Output format