| name | update-pr-review |
| description | Given fresh review findings (from a prior review skill) and a PR number, fetch previous Claude inline comments, cross-reference findings, and update the PR in a thread-aware way. Resolves addressed issues, replies to active threads, and posts only genuinely new findings as new inline comments. Never posts the same issue twice. |
| argument-hint | ["PR-number"] |
| context | fork |
| agent | general-purpose |
| allowed-tools | Bash(gh *), Bash(jq *), Bash(grep *), Bash(head *), Read, Grep, Glob |
Update PR Review
You are the second phase of a two-phase PR review pipeline. The first phase (a review skill)
already produced a fresh list of findings from the diff. Your job is to reconcile those findings
with the existing inline comment threads on the PR and take the right action for each one.
Hard rule: Never post the same finding as a new inline comment if it was already flagged
in a previous Claude review. Each issue must appear at most once as an inline comment.
Step 1 — Parse Inputs
$ARGUMENTS is the PR number.- The fresh review findings are in the conversation context above (output from the prior skill).
Extract each finding: file path, relevant line, and a concise description of the issue.
Step 2 — Fetch Previous Inline Review Comments
REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
gh api --paginate "repos/$REPO/pulls/$ARGUMENTS/comments" | jq -s 'add // []' > /tmp/prev_comments.json
From the JSON, build the following picture:
Claude root comments — entries where all of these are true:
user.login == "claude[bot]"in_reply_to_id is null (i.e. they are thread roots, not replies)
These represent issues flagged in previous Claude reviews.
Thread replies — entries where in_reply_to_id is non-null.
Group replies under the root comment they belong to (follow in_reply_to_id chains to the root).
Human replies to Claude — within a Claude-rooted thread, any reply where
user.login != "claude[bot]". These are the developer's responses.
For each Claude root comment, record:
id — used for reactions and repliespath — file pathline — line number (may have shifted due to rebasing)body — the text of the findinghuman_replies — list of {id, body} for any human replies in the thread, ordered by id
ascending (GitHub returns comments in creation order; IDs are monotonically increasing,
so the last element is always the most recent reply)
Step 3 — Cross-Reference Findings
For each finding from the fresh review, check if it matches a previous Claude root comment:
Matching criteria (use both together):
- Same
path (exact file path match)
- Same logical issue — compare the finding description to the Claude comment body
semantically. Line numbers may have shifted due to rebasing; do not require an exact
line match.
Then determine which scenario applies and act accordingly:
Scenario A — Issue is addressed in the new diff AND the developer replied
The flagged code no longer exists or the problem is corrected in the new diff,
and there is at least one human reply in the thread (e.g. "Done", "Fixed", "Implemented").
gh api "repos/$REPO/pulls/comments/$HUMAN_REPLY_ID/reactions" \
-X POST -f content="+1"
gh api "repos/$REPO/pulls/$ARGUMENTS/comments/$CLAUDE_COMMENT_ID/replies" \
-X POST -f body="Resolved ✓ — addressed in this revision."
Do NOT create a new inline comment for this finding.
Scenario B — Issue is addressed in the new diff, no developer reply
The problem is fixed in the new diff, but the developer did not reply to Claude's comment.
gh api "repos/$REPO/pulls/$ARGUMENTS/comments/$CLAUDE_COMMENT_ID/replies" \
-X POST -f body="Resolved ✓ — addressed in this revision."
Do NOT create a new inline comment for this finding.
Scenario C — Issue is NOT fixed AND the developer replied
The flagged code still has the problem in the new diff, and the developer replied in the thread.
gh api "repos/$REPO/pulls/$ARGUMENTS/comments/$CLAUDE_COMMENT_ID/replies" \
-X POST -f body="<concise explanation of why the issue is still present and what needs to change>"
Do NOT create a new inline comment for this finding.
Scenario D — Issue is NOT fixed AND the developer did not reply
The problem remains and no one replied to Claude's original comment.
Do nothing. Skip silently.
Do NOT create a new inline comment for this finding.
Scenario E — Genuinely new finding (no previous Claude comment matches)
This issue was not flagged in any prior review.
Return this finding to the caller so it can be posted as a new inline comment via the MCP tool.
Include: path, line, and the full finding description.
Step 4 — Output
Return a structured list of actions taken and genuinely new findings:
## Thread Updates
- [path:line] <what was done> (Scenario A/B/C/D)
...
## New Findings (post as inline comments)
- [path:line] <finding description>
...
The caller (workflow) will use mcp__github_inline_comment__create_inline_comment to post
the new findings as inline comments on the PR diff.
