| name | pr-review |
| description | Review a GitHub or GitLab pull request from a PR URL or number. |
PR Review Skill
Review a Pull Request comprehensively by analyzing the diff against the upstream merge base.
Prerequisites Check (MUST verify first)
Before proceeding, verify:
git rev-parse --is-inside-work-tree
gh auth status
If either check fails, STOP and inform the user:
- Not in git repo โ "This skill requires a git repository. Please navigate to a git project."
- gh not authenticated โ "Please run
gh auth login first."
Input
The user provides a PR link in one of these formats:
- Full URL:
https://github.com/owner/repo/pull/123
- Short form (if in repo):
#123 or 123
Workflow
Step 1: Extract PR Information
gh pr view <PR_URL> --json number,title,body,state,author,baseRefName,baseRefOid,headRefName,headRefOid,additions,deletions,changedFiles,files,commits,reviewDecision,reviews,labels,milestone,createdAt,updatedAt
gh pr diff <PR_URL>
gh pr diff <PR_URL> --name-only
gh api repos/{owner}/{repo}/pulls/{number}/files
Step 2: Analyze the Merge Base
BASE_REF=$(gh pr view <PR_URL> --json baseRefOid -q .baseRefOid)
HEAD_REF=$(gh pr view <PR_URL> --json headRefOid -q .headRefOid)
git fetch origin $BASE_REF $HEAD_REF 2>/dev/null || true
git merge-base $BASE_REF $HEAD_REF 2>/dev/null || echo $BASE_REF
Step 3: Deep Code Analysis
For each changed file, analyze:
- Read the full diff - Understand every change
- Read surrounding context - Use
gh api or local files to understand the code being modified
- Identify patterns - What coding patterns does this codebase use?
- Check for tests - Are there corresponding test changes?
Output Format (MANDATORY)
Your review MUST include ALL of the following sections in this exact order:
๐ PR Summary
Title: [PR Title]
Author: [Author]
Branch: [head] โ [base]
Files Changed: [N] | Additions: +[N] | Deletions: -[N]
What This PR Does
[2-5 sentences explaining the purpose and scope of this PR. Be specific about what functionality is added/changed/removed.]
Key Changes
- [Bullet point 1: specific change]
- [Bullet point 2: specific change]
- [...]
๐ Review Guidelines
Based on the type of changes in this PR, reviewers should focus on:
| Area | Priority | What to Check |
|---|
| [Area 1] | ๐ด High | [Specific guidance] |
| [Area 2] | ๐ก Medium | [Specific guidance] |
| [Area 3] | ๐ข Low | [Specific guidance] |
๐จ Issues Found
Issues are sorted by severity (Critical โ High โ Medium โ Low โ Nitpick).
๐ด Critical (Must Fix)
[Issues that will cause bugs, security vulnerabilities, or data loss]
[Issue Title]
- File:
path/to/file.ts:L123
- Problem: [Clear description]
- Impact: [What will go wrong]
- Suggestion: [How to fix]
๐ High (Should Fix)
[Issues that may cause problems or violate important patterns]
๐ก Medium (Consider Fixing)
[Code quality issues, minor bugs, or pattern violations]
๐ข Low (Nice to Have)
[Style issues, minor improvements]
๐ญ Nitpicks
[Purely stylistic suggestions, optional improvements]
๐งช Test Coverage Analysis
Test Changes in This PR
| Test File | Type | Coverage |
|---|
| [file] | [unit/integration/e2e] | [what it tests] |
Coverage Assessment
- New code tested: [Yes/No/Partial] - [explanation]
- Edge cases covered: [Yes/No/Partial] - [explanation]
- Regression tests: [Yes/No/N/A] - [explanation]
Recommended Additional Tests
- [Specific test case that should be added]
- [Another test case]
โ Questions & Uncertainties
Things I'm not certain about and would like clarification on:
-
[Question about design decision]
- Context: [Why I'm asking]
- My assumption: [What I think the answer might be]
-
[Question about edge case]
- Context: [Why this matters]
- Potential issue: [What could go wrong]
โ
Review Verdict
| Aspect | Status | Notes |
|---|
| Code Quality | ๐ข/๐ก/๐ด | [Brief note] |
| Security | ๐ข/๐ก/๐ด | [Brief note] |
| Performance | ๐ข/๐ก/๐ด | [Brief note] |
| Test Coverage | ๐ข/๐ก/๐ด | [Brief note] |
| Documentation | ๐ข/๐ก/๐ด | [Brief note] |
Overall: [APPROVE / REQUEST CHANGES / NEEDS DISCUSSION]
Review Checklist (Internal - Use for Analysis)
Code Quality
Security
Performance
Breaking Changes
Documentation
Important Notes
- Be Specific: Always reference exact file paths and line numbers
- Be Constructive: Suggest fixes, don't just point out problems
- Prioritize: Critical issues first, nitpicks last
- Context Matters: Consider the codebase's existing patterns
- Ask Questions: When uncertain, ask rather than assume