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)
CODEBLOCK0
GitLab (glab CLI)
# View MR diff
glab mr diff <MR_IID>
# MR details as JSON
glab mr view <MR_IID> --output json
# List changed files
glab mr diff <MR_IID> --name-only
# Download diff
glab mr diff <MR_IID> > /tmp/mr-<MR_IID>.diff
Workflow
Step 1 — Fetch Context
CODEBLOCK2
Step 2 — Blast Radius Analysis
For each changed file, identify:
- 1. Direct dependents — who imports this file?
CODEBLOCK3
- 2. Service boundaries — does this change cross a service?
CODEBLOCK4
- 3. Shared contracts — types, interfaces, schemas
CODEBLOCK5
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
CODEBLOCK6
Step 4 — Test Coverage Delta
CODEBLOCK7
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
CODEBLOCK8
DB Schema Changes
CODEBLOCK9
Config / Env Var Changes
CODEBLOCK10
Step 6 — Performance Impact
CODEBLOCK11
Ticket Linking Verification
CODEBLOCK12
Complete Review Checklist (30+ Items)
CODEBLOCK13
Output Format
Structure your review comment as:
CODEBLOCK14
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
- 1. 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
PR Review Expert
层级： 强大
类别： 工程
领域： 代码审查 / 质量保证
概述
针对 GitHub PR 和 GitLab MR 的结构化、系统化代码审查。超越风格细节——该技能执行影响范围分析、安全扫描、破坏性变更检测和测试覆盖率增量计算。生成一份包含 30 多项检查清单和优先排序发现的、可供审查者使用的报告。
核心能力
- - 影响范围分析 — 追踪哪些文件、服务和下游消费者可能被破坏
- 安全扫描 — SQL 注入、XSS、认证绕过、密钥泄露、依赖漏洞
- 测试覆盖率增量 — 新代码与新测试的比例
- 破坏性变更检测 — API 契约、数据库模式迁移、配置键
- 工单关联 — 验证 Jira/Linear 工单存在且与范围匹配
- 性能影响 — N+1 查询、打包体积回归、内存分配
使用时机
- - 在合并任何涉及共享库、API 或数据库模式的 PR/MR 之前
- 当 PR 较大（超过 200 行变更）且需要结构化审查时
- 为新贡献者的 PR 提供全面反馈时
- 安全敏感代码路径（认证、支付、PII 处理）
- 事故发生后——主动审查类似的 PR
获取差异
GitHub (gh CLI)
bash
在终端查看差异
gh pr diff
获取 PR 元数据（标题、正文、标签、关联问题）
gh pr view --json title,body,labels,assignees,milestone
列出变更的文件
gh pr diff --name-only
检查 CI 状态
gh pr checks
下载差异到文件进行分析
gh pr diff NUMBER> > /tmp/pr-NUMBER>.diff
GitLab (glab CLI)
bash
查看 MR 差异
glab mr diff
MR 详情为 JSON 格式
glab mr view --output json
列出变更的文件
glab mr diff --name-only
下载差异
glab mr diff IID> > /tmp/mr-IID>.diff
工作流程
第一步 — 获取上下文
bash
PR=123
gh pr view $PR --json title,body,labels,milestone,assignees | jq .
gh pr diff $PR --name-only
gh pr diff $PR > /tmp/pr-$PR.diff
第二步 — 影响范围分析
对于每个变更的文件，识别：
- 1. 直接依赖者 — 谁导入了这个文件？
bash
查找所有导入变更模块的文件
grep -r from [\].changed-module[\] src/ --include=.ts -l
grep -r require([\].changed-module src/ --include=.js -l
Python
grep -r from changedmodule import\|import changedmodule . --include=*.py -l
- 2. 服务边界 — 此变更是否跨越服务？
bash
检查变更文件是否跨多个服务（单体仓库）
gh pr diff $PR --name-only | cut -d/ -f1-2 | sort -u
- 3. 共享契约 — 类型、接口、模式
bash
gh pr diff $PR --name-only | grep -E types/|interfaces/|schemas/|models/
影响范围严重性：
- - 严重 — 共享库、数据库模型、认证中间件、API 契约
- 高 — 被超过 3 个其他服务使用的服务、共享配置、环境变量
- 中 — 单个服务内部变更、工具函数
- 低 — UI 组件、测试文件、文档
第三步 — 安全扫描
bash
DIFF=/tmp/pr-$PR.diff
SQL 注入 — 原始查询字符串插值
grep -n query\|execute\|raw( $DIFF | grep -E \$\{|f|%s|format\(
硬编码密钥
grep -nE (password|secret|apikey|token|privatekey)\s=\s[\][^\]{8,} $DIFF
AWS 密钥模式
grep -nE AKIA[0-9A-Z]{16} $DIFF
代码中的 JWT 密钥
grep -nE jwt\.sign\(.*[\][^\]{20,}[\] $DIFF
XSS 向量
grep -n dangerouslySetInnerHTML\|innerHTML\s*= $DIFF
认证绕过模式
grep -n bypass\|skip.auth\|noauth\|TODO.auth $DIFF
不安全的哈希算法
grep -nE md5\(|sha1\(|createHash\([\]md5|createHash\([\]sha1 $DIFF
eval / exec
grep -nE \beval\(|\bexec\(|\bsubprocess\.call\( $DIFF
原型污染
grep -n proto\|constructor\[ $DIFF
路径遍历风险
grep -nE path\.join\(.req\.|readFile\(.req\. $DIFF
第四步 — 测试覆盖率增量
bash
统计变更的源文件与测试文件数量
CHANGED_SRC=$(gh pr diff $PR --name-only | grep -vE \.test\.|\.spec\.|tests)
CHANGED_TESTS=$(gh pr diff $PR --name-only | grep -E \.test\.|\.spec\.|tests)
echo 变更的源文件数：$(echo $CHANGED_SRC | wc -w)
echo 变更的测试文件数：$(echo $CHANGED_TESTS | wc -w)
新逻辑行数 vs 新测试行数
LOGIC_LINES=$(grep ^+ /tmp/pr-$PR.diff | grep -v ^+++ | wc -l)
echo 新增行数：$LOGIC_LINES
本地运行覆盖率
npm test -- --coverage --changedSince=main 2>/dev/null | tail -20
pytest --cov --cov-report=term-missing 2>/dev/null | tail -20
覆盖率增量规则：
- - 新函数无测试 → 标记
- 删除测试但未删除代码 → 标记
- 覆盖率下降超过 5% → 阻止合并
- 认证/支付路径 → 要求 100% 覆盖率
第五步 — 破坏性变更检测
API 契约变更
bash
OpenAPI/Swagger 规范变更
grep -n openapi\|swagger /tmp/pr-$PR.diff | head -20
REST 路由删除或重命名
grep ^- /tmp/pr-$PR.diff | grep -E router\.(get|post|put|delete|patch)\(
GraphQL 模式删除
grep ^- /tmp/pr-$PR.diff | grep -E ^-\s*(type |field |Query |Mutation )
TypeScript 接口删除
grep ^- /tmp/pr-$PR.diff | grep -E ^-\s*(export\s+)?(interface|type)
数据库模式变更
bash
新增迁移文件
gh pr diff $PR --name-only | grep -E migrations?/|alembic/|knex/
破坏性操作
grep -E DROP TABLE|DROP COLUMN|ALTER.*NOT NULL|TRUNCATE /tmp/pr-$PR.diff
索引删除（性能回归风险）
grep DROP INDEX\|remove_index /tmp/pr-$PR.diff
配置 / 环境变量变更
bash
代码中引用的新环境变量（生产环境可能缺失）
grep ^+ /tmp/pr-$PR.diff | grep -oE process\.env\.[A-Z_]+ | sort -u
删除的环境变量（可能破坏运行中的实例）
grep ^- /tmp/pr-$PR.diff | grep -oE process\.env\.[A-Z_]+ | sort -u
第六步 — 性能影响
bash
N+1 查询模式（循环内的数据库调用）
grep -n \.find\|\.findOne\|\.query\|db\. /tmp/pr-$PR.diff | grep ^+ | head -20
然后检查周围的 forEach/map/for 循环上下文
大型新
