Pr Review

PR Review Skill

Reviews all open PR comment threads one at a time. For each comment, Claude proposes its verdict and reasoning, waits for your approval, then replies and resolves.

Bundled Scripts

All GitHub API interactions go through these scripts — never call gh api directly or use shell redirects:

• pr_review_parse_comments.sh <owner/repo> <pr_number> — list all unresolved threads
• pr_review_parse_comments.sh <owner/repo> <pr_number> <index> — full detail by 1-based index including replies
• pr_review_parse_comments.sh <owner/repo> <pr_number> --id <comment_id> — full detail by comment database ID
• pr_review_post_reply.sh <owner/repo> <pr_number> <comment_id> "<reply text>" — posts a reply to a comment thread
• pr_review_resolve_thread.sh <thread_node_id> — resolves a review thread by its GraphQL node ID

They ship in this skill's bin/ directory, which is on the Bash tool's PATH whenever the skill is installed. Invoke each by bare name — never by an absolute path. The bare form is the only spelling that works on both install routes, and it is what the permission rules match. The pr_review_ prefix is deliberate: these rules approve a command name, so a generic one like post_reply could be satisfied by an unrelated executable earlier on PATH.

The matching rules live in the toolkit's project-files/.claude/settings.json template and are not installed by either install route — the user merges them in. If every call prompts, that is unfinished setup, not a broken skill. Say so once and continue; it is never a reason to fall back to gh api directly.

Two failures are environment rather than defects: Missing required command: gh (exit 127) means the GitHub CLI is absent or unauthenticated — tell the user to install it and run gh auth login; and command not found on one of these scripts means the skill's bin/ is not on PATH, so the plugin is disabled or the session predates the install. Neither is a reason to edit a script.

Each script is invoked independently — never chain them.

Inputs

• $PR — PR number (e.g. 123)
  • If not provided, ask: "Which PR number should I review?"

Workflow

Step 1 — Detect Repo and Fetch Comments

First, detect the repo — never guess or hardcode it:

gh repo view --json nameWithOwner --jq '.nameWithOwner'

Store the result as $REPO. Then fetch PR details and comments:

gh pr view $PR --json number,title,headRefName,baseRefName

pr_review_parse_comments.sh $REPO $PR

# To get full detail on a specific comment (e.g. comment 6):
pr_review_parse_comments.sh $REPO $PR 6

Collect every top-level comment, noting for each:

• Comment ID (numeric, for posting replies)
• Node ID (for resolving threads)
• File and line
• Full comment body

Do not evaluate or act on any comment yet. Tell the user: "Found N unresolved threads on PR #$PR in $REPO. I'll go through them one at a time for your approval."

Step 2 — Process Comments One at a Time

For each thread, repeat this loop:

2a — Present the Comment

Show the user:

── Comment N of N ──────────────────────────────
File:    path/to/file.ts:42
Comment: <full comment text>

My verdict: ✅ Fix / ⚠️ Partial fix / ❌ No fix

Reason: <one or two sentences explaining why>

Proposed reply: (must not open with "Good catch", "Great point", "Real bug", or similar — start with the substance)
"<exact text Claude will post to the thread>"

Proposed code change: (if any)
<diff or description of change>

STOP. Do not post the reply, make any code changes, or resolve the thread yet.

Ask: "Approve? (yes / edit / skip)"

2b — Wait for User Response

• "yes" / "approve" / "looks good" → proceed to 2c
• "edit" or the user provides a revised reason/reply → update the proposed reply as directed, show it again, wait for approval again
• "skip" → leave the thread untouched, move to the next comment

STOP. Do not proceed until one of the above responses is received.

2c — Execute (only after approval)

Run these as separate, sequential bash tool calls. Never combine them with &&, ;, or any other operator — each must be its own invocation so the result is visible before the next runs:

1. Post the approved reply:

pr_review_post_reply.sh $REPO $PR $COMMENT_ID "<approved reply text>"

Wait for it to return. Then:

2. Apply any code changes

3. Resolve the thread:

pr_review_resolve_thread.sh $THREAD_NODE_ID

Confirm: "Done — thread resolved. Moving to next comment."

Combining any of these into a single command is a violation of this skill, even after approval.

Then loop back to 2a for the next thread.

Step 3 — Final Summary

PR #$PR Review Summary
──────────────────────────────────────────────────────
✅ Fixed (N):
  • file.ts:42 — removed unused import

⚠️ Partial fix (N):
  • utils.ts:17 — applied intent but not CoPilot's exact suggestion

❌ No fix (N):
  • config.ts:5 — intentional project constant, not a magic number

⏭️ Skipped (N):
  • auth.ts:88 — skipped at your request

Total threads resolved: N

Rules

• ALWAYS detect $REPO from gh repo view — never hardcode or guess the org/repo
• ALWAYS use the bundled scripts for all GitHub API calls — never call gh api directly, never use shell pipes or redirects
• To read a specific comment in full use pr_review_parse_comments.sh $REPO $PR <index> or pr_review_parse_comments.sh $REPO $PR --id <comment_id> — NEVER call gh api directly to look up a comment body, NEVER pipe or grep the output of pr_review_parse_comments.sh
• Never post a reply, make a code change, or resolve a thread without explicit user approval
• Always comment before resolving — never silently close a thread
• Never fix things Claude disagrees with just to clear the queue
• One commit at the end covering all changes, not one per comment
• If a thread is skipped, leave it completely untouched
• Reply text must never open with sycophantic acknowledgments ("Good catch", "Great point", "Real bug", "Nice find", "You're right", "Thanks for catching", etc.). Start the reply with the substantive response directly.