pr-review

PR Review

Full review-giving workflow for a GitHub pull request. Reads the code, drafts inline review comments, and submits after user approval.

When to Activate

• "review PR #123", "review this PR"
• "give a review on PR", "look at PR #456"
• "check this PR for issues"

Quick Links

• gh-pr-review CLI reference

Prerequisites

First, invoke the pr-check-deps skill to validate the environment. If it reports a failure, stop and show the remediation instructions.

Workflow

Phase 1: Setup

Step 1: Resolve the PR

The user provides a PR number, URL, or you can ask them. Determine the repo:

gh repo view --json nameWithOwner -q .nameWithOwner

Fetch PR metadata:

gh pr view <PR_NUMBER> -R <owner/repo> --json number,title,headRefName,baseRefName,url,author,body,additions,deletions,changedFiles

Report to the user: "Reviewing PR #N: by @author (<additions>+/<deletions>-, <changedFiles> files)"

Step 2: Verify branch

Check the current branch and compare it to the PR branch:

git rev-parse --abbrev-ref HEAD
git fetch origin <headRefName>

Compare the local HEAD against the remote PR branch:

git rev-list --left-right --count HEAD...origin/<headRefName>

There are three possible states:

A) Current branch matches <headRefName> and is up to date: Proceed to the next step.

B) Current branch matches <headRefName> but is behind the remote: Inform the user their branch is behind and use AskUserQuestion with options:

• Pull — Run git pull origin <headRefName> to update the local branch.
• Ignore — Continue with the local state as-is.

C) Current branch does NOT match <headRefName>: Inform the user and use AskUserQuestion with options:

• Checkout the PR branch — Run git checkout <headRefName> (or git checkout -b <headRefName> origin/<headRefName> if the branch doesn't exist locally). Then pull to ensure it's up to date.
• Ignore — Continue working on the current branch as-is. The user is responsible for ensuring the correct code is checked out.

Phase 2: Analyze

Step 3: Read the PR diff

gh pr diff <PR_NUMBER> -R <owner/repo>

Step 4: Read changed files for context

For each file in the diff, read the full file to understand the surrounding context.

Focus on understanding:

• What the code does and why
• Correctness: logic errors, edge cases, off-by-one errors
• Design: naming, structure, separation of concerns
• Clarity: readability, comments where needed
• Testing: are changes tested?
• Security: injection, auth issues, data exposure

Phase 3: Draft Review

Step 5: Draft inline comments

For each issue found, prepare an inline comment with:

• path: file path relative to repo root
• line: the line number in the diff (use the NEW file line numbers)
• body: the review comment text — be specific, constructive, and explain why

Step 6: Draft overall summary

Write a review summary covering:

• What the PR does (1-2 sentences)
• Overall assessment
• Key concerns if any

Choose a recommended event:

• APPROVE — code is good, no blocking issues
• COMMENT — observations/questions but not blocking
• REQUEST_CHANGES — issues that should be fixed before merge

Phase 4: Present to User

Step 7: Show the draft review

Present each inline comment with the surrounding code context so the user can evaluate. Then show the overall summary and recommended event.

Use AskUserQuestion to let the user:

• Approve and submit as-is
• Edit specific comments (remove, modify, or add new ones)
• Change the event (APPROVE/COMMENT/REQUEST_CHANGES)
• Cancel the review entirely

Iterate until the user approves.

Phase 5: Submit

Step 8: Submit the review

See gh-pr-review CLI reference for exact commands.

# Start pending review
gh pr-review review --start -R <owner/repo> <PR_NUMBER>
# Returns: { "id": "PRR_..." }

# Add each inline comment
gh pr-review review --add-comment \
  --review-id <PRR_...> \
  --path <file> \
  --line <line> \
  --body "<comment>" \
  -R <owner/repo> <PR_NUMBER>

# Submit with event and summary
gh pr-review review --submit \
  --review-id <PRR_...> \
  --event <EVENT> \
  --body "<summary>" \
  -R <owner/repo> <PR_NUMBER>

Report: "Review submitted on PR #N: "

Constraints

• Never auto-submit. Always present the complete review for user approval before submitting.
• Work in current directory. All work happens in the current working directory. Never modify files outside of it.
• Constructive feedback. Review comments should be specific, actionable, and explain the reasoning.