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 — list all unresolved threads
• pr_review_parse_comments.sh — full detail by 1-based index including replies
• pr_review_parse_comments.sh --id — full detail by comment database ID
• pr_review_post_reply.sh "" — posts a reply to a comment thread
• pr_review_resolve_thread.sh — 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: 

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

Reason: 

Proposed reply: (must not open with "Good catch", "Great point", "Real bug", or similar — start with the substance)
""

Proposed code change: (if any)

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 ""

Wait for it to return. Then:

1. Apply any code changes

1. 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 or pr_review_parse_comments.sh $REPO $PR --id — NEVER call gh api directly to look up a comment body, NEVER pipe or grep the output of prreviewparse_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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: LunarCommand
• Source: LunarCommand/claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.