diff --git a/.claude/skills/pr-flow/SKILL.md b/.claude/skills/pr-flow/SKILL.md
index 786b5c37..d7d1a06e 100644
--- a/.claude/skills/pr-flow/SKILL.md
+++ b/.claude/skills/pr-flow/SKILL.md
@@ -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
diff --git a/AGENTS.md b/AGENTS.md
index ca30281a..a416da3f 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -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