modelcontextprotocol/inspector
Watch
1
0
Fork
You've already forked inspector
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

docs: a reply does not resolve a review thread

Browse source 
Copilot review round 1 on #2273: the text said only a reply in the thread "can
resolve it", which is wrong — resolution is a separate act (the Resolve
conversation button, or the resolveReviewThread GraphQL mutation) and it is the
reviewer's to make. Reading it as satisfied by the documented REST reply is
exactly the wrong conclusion for a PR whose whole point is what a reply does.

State what the reply actually buys: it is the only thing a reviewer reading that
thread sees, and it is what makes resolving the thread defensible.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017nLLLTGc37hQiC8s3mNyhq
Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
cliffhall 2026-09-06 12:20:35 -04:00 • committed by Cliff Hall
commit 5a1b5900cf
2 changed files with 6 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

7
.claude/skills/pr-flow/SKILL.md
View file

@ -282,8 +282,11 @@ arrive late (see step 8).
- After making the changes, **reply to each review comment in its own thread**
with what was done, or why it was declined. That inline reply is the primary
response and it is not optional — each review comment is a discussion thread
with its own resolve state, and only a reply _in_ the thread can resolve it or
show a reviewer reading it that the finding was answered.
with its own resolve state, and a reply _in_ the thread is the only thing a
reviewer reading that thread sees. It does **not** resolve the thread:
resolving is a separate act — the "Resolve conversation" button, or the
`resolveReviewThread` GraphQL mutation — and it is the reviewer's to make. The
reply is what makes resolving it defensible.
```sh
# Fetch the round's comments by REVIEW id — the unpaginated /reviews listing

2
AGENTS.md
View file

@ -372,7 +372,7 @@ When asked to respond to a code review of a PR:
- it is not necessary to implement all suggestions
- you are free to implement suggestions in a different way, or to ignore one if there is a good reason
- after making the changes, respond to each review comment with what was done (or why it was ignored)
- **that response goes in the review comment's own thread — a rollup comment does not discharge it.** Each review comment is a discussion thread with its own resolve state, so a bullet posted elsewhere on the page cannot be connected back to the thread it answers: the thread stays open showing a finding and no reply, and the PR reads as though the review were ignored. Reply inline first, per comment; then post the PR-level summary **in addition**, because inline replies go hidden once the fix is pushed. A finding in the review's "Suppressed comments" block has no thread to reply into, so the summary is the only place it can be answered — that is the one exception. The `gh` calls are in the `pr-flow` skill, step 8.
- **that response goes in the review comment's own thread — a rollup comment does not discharge it.** Each review comment is a discussion thread with its own resolve state, so a bullet posted elsewhere on the page cannot be connected back to the thread it answers: the thread stays open showing a finding and no reply, and the PR reads as though the review were ignored. Replying does not itself **resolve** a thread — that is a separate act and the reviewer's to make — but it is what makes resolving it defensible. Reply inline first, per comment; then post the PR-level summary **in addition**, because inline replies go hidden once the fix is pushed. A finding in the review's "Suppressed comments" block has no thread to reply into, so the summary is the only place it can be answered — that is the one exception. The `gh` calls are in the `pr-flow` skill, step 8.
## Always test new or modified code