Reviewer-Side Posture - Do not edit, commit, push, or rewrite the PR branch unless the user explicitly asks. Your default job is verification, review, reply, and resolution of the user's own review threads.
Evidence Before Replying - Verify replies and code changes against the current diff, current files, relevant tests, CI, docs, or runtime behavior. Do not resolve or challenge based only on the author's claim.
Own Threads Are Actionable - If the user opened the review thread and the author replied or changed code, decide whether the concern is resolved. Resolve only after verification confirms it; otherwise continue the challenge in the thread.
Ignored Own Threads Get Reminders - If the author has continued work after the user's comment but did not reply to or address the thread, post a concise follow-up reminder in that thread.
Other People's Threads Are Advisory - Inspect other reviewers' comments. Add a reply only when you can contribute verified agreement, extra evidence, or a materially different concern. Never resolve threads opened by others.
PR Discussion Comments Follow the Same Logic - Bottom-of-PR comments are evaluated the same way, but they are not resolvable review threads. Reply with a mention and a quoted excerpt when follow-up is useful.

Quick Start

User: Follow up on my review comments on https://github.com/owner/repo/pull/123

Workflow:

Fetch the PR, viewer login, author login, review threads, PR discussion comments, commits, and latest review activity.
Classify conversations as:
- own-thread: opened by the viewer
- other-thread: opened by another reviewer
- own-pr-comment: bottom PR comment authored by the viewer
- other-pr-comment: bottom PR comment authored by someone else
Verify the author's replies and changes with file reads, diff review, tests, CI, or docs as appropriate.
Act according to ownership and evidence:
- Own review thread resolved by evidence: reply if useful, then resolve.
- Own review thread not resolved: reply with a challenge or reminder.
- Other review thread: reply only if adding useful verified signal; never resolve.
- PR discussion comment: reply only; there is no thread resolution state.
Report what was verified, challenged, reminded, resolved, or skipped.

Decision Matrix

Conversation	Evidence	Action
Own review thread	Author replied and concern is fixed	Reply briefly if needed, then resolve
Own review thread	Author replied but concern remains	Reply with evidence and keep open
Own review thread	Author changed related code but ignored thread	Reply with a reminder and keep open
Own review thread	No reply and no related author activity	Skip or report as waiting
Other review thread	You verified the concern and can add value	Reply with concise agreement or extra evidence
Other review thread	You disagree or see another risk	Reply with evidence, framed as additional review input
Other review thread	No meaningful extra signal	Skip
PR discussion comment	Follow-up is useful	Post a PR comment with `@author` and a quoted excerpt
PR discussion comment	No follow-up is useful	Skip

Required Evidence

Use the cheapest reliable verification available:

Read the referenced code and current diff before judging code review threads.
Check commits after the user's comment before saying the author ignored it.
Use CI status when the concern is already covered by a relevant check.
Run targeted tests or reproduction commands when the claim depends on behavior.
Use official docs or local repo docs when the disagreement is about API or project convention.

If evidence is incomplete, say what is missing and ask before posting a strong challenge.

Resolve Policy

Resolve only review threads opened by the viewer, and only after the concern is verified as handled.
Do not resolve threads opened by other reviewers, even when you agree the issue is fixed.
Do not resolve bottom PR discussion comments; GitHub does not provide a review thread resolution state for them.
If GitHub denies resolution, report the API failure and leave the thread open.

GitHub Operations

Detailed GraphQL queries, mutations, and classification steps live in workflow.md.

Reply wording examples live in reply-templates.md.

Common Mistakes

Treating any author reply as enough to resolve without checking the code.
Posting "+1" on another reviewer's thread without adding new verified signal.
Resolving another reviewer's thread because the issue looks fixed.
Using gh pr comment for a review-thread reply; that posts to the PR bottom, not the review thread.
Forgetting that PR discussion comments need mention-and-quote context because they are linear conversation comments.

Summary Report

End with a concise report:

## PR Review Follow-up Summary

**PR:** #<number> - <title>
**Checked:** <n> conversations

| Status | Count |
|--------|-------|
| Resolved own threads | <n> |
| Challenged own threads | <n> |
| Reminded own threads | <n> |
| Replied on others' threads | <n> |
| Replied to PR comments | <n> |
| Skipped | <n> |

### Notes
- <short evidence-backed note>

vp-pr-review-followup

PR Review Follow-up

Core Principles