Bound comment-triggered docs reviews

.claude/skills/docs-review/SKILL.md

@@ -156,6 +156,8 @@ Structure your review as:
 
 Before including any finding, apply the **independent reviewer test**: would a different competent tech writer independently flag the same issue? If two phrasings are equally clear and correct, don't flag one as better. The goal is a stable review - running the skill twice on the same document should produce essentially the same findings.
 
+For each proposed change, identify the reader's likely misunderstanding, failed task, or concrete style-guide violation. If you can only explain why you prefer the alternative, omit it. The exclusions below also apply to feedback labeled "optional," "nonblocking," or "nit"; those labels don't make cosmetic suggestions useful. A review with no findings is a valid outcome.
+
 **Primary issues** (address before merge):
 
 - Accuracy: documented behavior contradicts CLI reference, API spec, or upstream source

.claude/skills/review-docs-pr/SKILL.md

@@ -28,9 +28,16 @@ Before drafting, look at reviews and threads already on the PR:
 Apply the docs-review skill's criteria (information architecture, LLM-pattern table, accuracy, style guide compliance). Invoke `/docs-review` for the full criteria if not already loaded. In addition:
 
 - **Verify factual claims at the source.** For content documenting product behavior, the code is the primary source and the docs are what's being verified: check flags, fields, defaults, and API routes against the upstream repo at the relevant tag, not against other docs or memory.
+- **Match the verdict to the evidence available.** If upstream source is inaccessible, continue with an editorial and documentation-consistency review and state that limit. Distinguish claims you verified directly from author-supplied evidence and claims you could not verify. Agreement between pages is not proof of product behavior: don't recommend broadening a factual claim just to make wording consistent. Identify any material verification still needed for a source-capable reviewer, without presenting an unverified claim as an error or claiming technical sign-off.
 - **Check the PR's own claims.** If the PR body says "build passes" or "links verified", spot-check rather than trusting it.
 - **Scope findings to the PR.** Pre-existing issues in surrounding content can be noted as out-of-scope observations or follow-up issue candidates, not blocking findings.
 
+## Review a follow-up revision
+
+Unless the requester asks for a fresh full review, check the changes since the previous reviewed commit, whether they resolve the prior findings, and any affected surrounding content. Report newly introduced material problems, but don't use each follow-up as another search for wording improvements across the whole PR. Reopen a settled point only when new evidence shows a concrete correctness or reader-task problem, and explain that evidence.
+
+When the prior findings are resolved and no material problems remain in the reviewed changes, say so and stop. There is no quota of new findings, optional suggestions, or nits. Keep outstanding source verification or release dependencies separate from editorial findings; repeating a review cannot resolve unavailable evidence.
+
 ## Draft the review
 
 Structure the draft as:

.github/workflows/claude.yml

@@ -82,3 +82,4 @@ jobs:
             actions: read
           claude_args: |
             --allowedTools "Bash(npm run build),Bash(npm run prettier),Bash(npm run prettier:fix),Bash(npm run eslint),Bash(npm run eslint:fix)"
+            --append-system-prompt "For documentation review requests, read .claude/skills/review-docs-pr/SKILL.md and .claude/skills/docs-review/SKILL.md before reviewing. Apply their finding threshold, source-access limits, and follow-up review scope. A review can finish with no findings; do not add cosmetic suggestions to fill it out. Keep these review rules scoped to review requests."