Pull Request Review Skill
Comprehensive PR review using GitHub CLI to assess merge readiness, identify blockers, and automatically fix issues.
When to Use This Skill
Apply this skill when the user:
Review requests:
- •Asks about PR status or readiness
- •Wants to know what's blocking merge
- •Requests CI/CD checks status
- •Asks about unresolved comments
- •Says "review this PR" or "check PR #123"
Fix requests:
- •Asks to fix PR feedback or review comments
- •Wants to resolve blockers (failing tests, conflicts)
- •Says "fix what @reviewer asked for"
- •Requests to implement suggested changes
Prerequisites
Before using, verify:
- •GitHub CLI (
gh) is installed:command -v gh - •User is authenticated:
gh auth status - •In a repository OR user provided PR number/URL
Determine Workflow Mode
If user wants review only: → Follow Review Workflow (see workflows/review-workflow.md)
If user wants to fix issues: → Follow Fix Workflow (see workflows/fix-workflow.md)
When unclear, ask user:
Would you like me to: A) Review the PR and report status B) Fix the issues found
Review Workflow (Summary)
Full details: workflows/review-workflow.md
Quick Steps
- •
Identify PR
bashgh pr view [number|url] # or current branch
- •
Fetch comprehensive data
- •PR details (status, mergeable, review decision)
- •CI/CD checks (passing/failing/pending)
- •ALL three comment types (issue/review/summary)
- •Review threads (resolution status)
See reference/comment-types.md for GitHub's three comment types.
See reference/gh-commands.md for command reference.
- •
Initial analysis
- •Identify merge blockers
- •Parse unresolved comments by type and priority
- •Assess PR health metrics (size, age, activity)
- •
🧠 Deep analysis with extended thinking (CRITICAL)
- •Engage extended thinking mode to analyze all data comprehensively
- •Perform root cause analysis for each issue
- •Create structured action plan with priorities
- •Map dependencies and assess risks
- •Develop verification strategy
This step transforms raw data into actionable insights
- •
📋 Create trackable markdown action plan
- •Create a detailed markdown checklist with all issues
- •Include Problem, Root Cause, Fix, Complexity, Dependencies, Testing for each
- •Prioritize by severity: Critical → High → Medium → Low
- •Add verification steps for testing and validation
- •Include implementation order, risk assessment, time estimates
- •Format as copyable markdown checklist
This ensures progress can be monitored as fixes are made
- •
Generate comprehensive report
- •Status overview (READY/BLOCKED/PENDING/DRAFT)
- •Complete markdown action plan checklist (copyable)
- •CI/CD checks breakdown
- •Merge blockers with action items
- •Unresolved comments organized by type
- •Deep analysis results with implementation plan
- •PR health metrics
- •Best practices assessment
- •Recommended next steps with rationale
- •
Suggest next action
- •If blockers found, offer to fix them following the todo list
- •Provide specific commands to run
- •Recommend reviewers to ping
Report Format
# PR Review: #<number> - <title> ## 🎯 Status Overview [READY/BLOCKED/PENDING/DRAFT status] ## 📋 Trackable Action Plan [Complete markdown checklist with: - Critical issues (Problem/Root Cause/Fix/Complexity/Dependencies/Testing) - High priority issues - Medium priority issues - Low priority issues - Verification steps - Implementation plan with order and rationale - Risk assessment - Time estimates] **Summary:** - X Critical issues (must fix) - Y High priority issues (should fix) - Z Medium/Low items (improvements) Copy this checklist to track your progress. ## 🚦 CI/CD Checks [Passing ✅ / Failing ❌ / Pending ⏳] ## 🚧 Merge Blockers [List with action items, or ✅ if none] ## 💬 Discussion Status [Unresolved comments by type: review/issue/summary] ## 🔍 Deep Analysis & Action Plan [Structured analysis from extended thinking] - Critical/High/Medium/Low priority issues - Root cause analysis for each issue - Fix approach with complexity assessment - Implementation plan with dependencies - Risk assessment and verification strategy ## 📊 PR Health Metrics [Size, files, age, assessment vs best practices] ## ✅ Best Practices Assessment [Strengths and improvement opportunities] ## 🎬 Recommended Next Steps [Priority-ordered action list with specific commands and rationale]
See examples/review-examples.md for full examples.
Fix Workflow (Summary)
Full details: workflows/fix-workflow.md Safety rules: workflows/safety-guidelines.md
Quick Steps
- •
Fetch detailed feedback
- •Get ALL three comment types (see reference/comment-types.md)
- •Check review thread resolution status
- •Get PR diff and files changed
- •Checkout PR branch
- •
Analyze and prioritize
- •🔴 CRITICAL: Security, data corruption, blocking failures
- •🟡 HIGH: Functional bugs, logic errors
- •🟢 MEDIUM: Code style, documentation
- •⚪ LOW: Naming, formatting
- •
⚠️ CRITICAL: Confirm scope with user
MUST present plan before making changes:
markdown## Fixes Planned I found X issues: ### Critical (2) 1. [File:Line] Security: SQL injection 2. [File:Line] Bug: Null pointer ### High Priority (3) ... Would you like me to: A) Fix all issues B) Fix only critical/high C) Let me choose specific D) Review and discuss first
Wait for user confirmation.
- •
Make changes systematically
- •Read relevant code first
- •Understand context and intent
- •Make minimal, targeted changes
- •Run tests after EACH change
- •Verify fix resolves issue
- •
Handle common fix types
- •Merge conflicts: rebase, resolve, continue
- •Failing tests: debug, fix implementation
- •Code review comments: refactor, add error handling
- •Documentation: update examples, fix outdated info
- •
Final verification
bashnpm test # All tests pass npm run lint # Linting clean npm run build # Build succeeds git diff # Review changes
- •
Summarize changes
- •List all fixes applied
- •Show verification results
- •Provide next steps (push, notify reviewers)
Safety Rules (Critical)
MUST:
- •Get user confirmation before making changes
- •Read code before modifying
- •Run tests after each change
- •Make minimal changes only
MUST NOT:
- •Skip testing to pass checks
- •Modify code without understanding it
- •Force push to main/master
- •Disable linting or tests
- •Make unrelated improvements
ASK USER if:
- •Multiple approaches exist
- •Side effects possible
- •Tests missing
- •Breaking change needed
Full safety guidelines: workflows/safety-guidelines.md
See examples/fix-examples.md for comprehensive examples.
Reference Documentation
Quick access to supporting documentation:
| Document | Location | Purpose |
|---|---|---|
| Comment Types | reference/comment-types.md | GitHub's three comment types explained |
| Best Practices | reference/best-practices.md | Research-backed PR guidelines (200-400 LOC, testing) |
| GitHub CLI Commands | reference/gh-commands.md | Complete gh command reference |
| Review Workflow | workflows/review-workflow.md | Detailed review steps |
| Fix Workflow | workflows/fix-workflow.md | Detailed fix steps |
| Safety Guidelines | workflows/safety-guidelines.md | Complete safety rules |
Examples
| Example Set | Location | Contents |
|---|---|---|
| Review Examples | examples/review-examples.md | Examples 1-4 (review mode) |
| Fix Examples | examples/fix-examples.md | Examples 5-8 (fix mode) |
Error Handling
If any command fails:
- •Explain what went wrong clearly
- •Suggest fix (e.g., "Run
gh auth loginto authenticate") - •Provide alternative approaches if available
If tests fail after fix:
- •Review changes:
git diff - •Run tests with verbose output
- •Ask user: "The test is still failing, would you like me to try a different approach?"
Notes
- •Always fetch fresh data - don't rely on cached information
- •Use parallel commands where possible for speed
- •Be objective in assessment - use data, not assumptions
- •Prioritize merge blockers in reports
- •Provide actionable next steps, not just observations
- •Keep user informed of progress when making fixes