PR Review Expert
Tier: POWERFUL
Category: Engineering
Domain: Code Review / Quality Assurance
Overview
Structured, systematic code review for GitHub PRs and GitLab MRs. Goes beyond style nits — this skill
performs blast radius analysis, security scanning, breaking change detection, and test coverage delta
calculation. Produces a reviewer-ready report with a 30+ item checklist and prioritized findings.
Core Capabilities
- Blast radius analysis — trace which files, services, and downstream consumers could break
- Security scan — SQL injection, XSS, auth bypass, secret exposure, dependency vulns
- Test coverage delta — new code vs new tests ratio
- Breaking change detection — API contracts, DB schema migrations, config keys
- Ticket linking — verify Jira/Linear ticket exists and matches scope
- Performance impact — N+1 queries, bundle size regression, memory allocations
When to Use
- Before merging any PR/MR that touches shared libraries, APIs, or DB schema
- When a PR is large (>200 lines changed) and needs structured review
- Onboarding new contributors whose PRs need thorough feedback
- Security-sensitive code paths (auth, payments, PII handling)
- After an incident — review similar PRs proactively
Fetching the Diff
GitHub (gh CLI)
GitLab (glab CLI)
Workflow
Step 1 — Fetch Context
Step 2 — Blast Radius Analysis
For each changed file, identify:
- Direct dependents — who imports this file?
- Service boundaries — does this change cross a service?
- Shared contracts — types, interfaces, schemas
Blast radius severity:
- CRITICAL — shared library, DB model, auth middleware, API contract
- HIGH — service used by >3 others, shared config, env vars
- MEDIUM — single service internal change, utility function
- LOW — UI component, test file, docs
Step 3 — Security Scan
Step 4 — Test Coverage Delta
Coverage delta rules:
- New function without tests → flag
- Deleted tests without deleted code → flag
- Coverage drop >5% → block merge
- Auth/payments paths → require 100% coverage
Step 5 — Breaking Change Detection
API Contract Changes
DB Schema Changes
Config / Env Var Changes
Ticket Linking Verification
Security note: for repeated Jira use, prefer a ~/.netrc entry
(machine your-org.atlassian.net login user@company.com password <token>,
chmod 600 ~/.netrc) and call curl -s --netrc … — no secret material in
the command at all.
Complete Review Checklist (30+ Items)
Structure your review comment as:
Common Pitfalls
- Reviewing style over substance — let the linter handle style; focus on logic, security, correctness
- Missing blast radius — a 5-line change in a shared utility can break 20 services
- Approving untested happy paths — always verify error paths have coverage
- Ignoring migration risk — NOT NULL additions need a default or two-phase migration
- Indirect secret exposure — secrets in error messages/logs, not just hardcoded values
- Skipping large PRs — if a PR is too large to review properly, request it be split
Best Practices
- Read the linked ticket before looking at code — context prevents false positives
- Check CI status before reviewing — don't review code that fails to build
- Prioritize blast radius and security over style
- Reproduce locally for non-trivial auth or performance changes
- Label each comment clearly: "nit:", "must:", "question:", "suggestion:"
- Batch all comments in one review round — don't trickle feedback
- Acknowledge good patterns, not just problems — specific praise improves culture