pr-review

PR Review Skill

通过分析相对于上游合并基点的差异，全面审查 Pull Request。

前置条件检查（必须先验证）

继续之前，请验证：

# 1. Check if in a git repository
git rev-parse --is-inside-work-tree

# 2. Check if gh CLI is available and authenticated
gh auth status

如果任一项检查失败，请停止并告知用户：

• 不在 git 仓库中 → “此技能需要 git 仓库。请切换到 git 项目目录。”
• gh 未通过身份验证 → “请先运行 gh auth login。”

输入

用户会以下列格式之一提供 PR 链接：

• 完整 URL：https://github.com/owner/repo/pull/123
• 简写（在仓库中）：#123 或 123

工作流

步骤 1：提取 PR 信息

# Get comprehensive PR metadata
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

# Get the diff
gh pr diff <PR_URL>

# Get list of changed files
gh pr diff <PR_URL> --name-only

# Get detailed file changes with additions/deletions
gh api repos/{owner}/{repo}/pulls/{number}/files

步骤 2：分析合并基点

# Get base and head commits
BASE_REF=$(gh pr view <PR_URL> --json baseRefOid -q .baseRefOid)
HEAD_REF=$(gh pr view <PR_URL> --json headRefOid -q .headRefOid)

# Find merge base (requires local clone)
git fetch origin $BASE_REF $HEAD_REF 2>/dev/null || true
git merge-base $BASE_REF $HEAD_REF 2>/dev/null || echo $BASE_REF

步骤 3：深入分析代码

对于每个有更改的文件，请分析：

1. 阅读完整差异 - 理解每项更改
2. 阅读上下文 - 使用 gh api 或本地文件了解正在修改的代码
3. 识别模式 - 此代码库使用了哪些编码模式？
4. 检查测试 - 是否有对应的测试更改？

输出格式（必须遵守）

审查内容必须按以下确切顺序包含所有部分：

---

📋 PR 摘要

标题：[PR 标题] 作者：[作者] 分支：[head] → [base] 更改文件：[N] | 新增：+[N] | 删除：-[N]

此 PR 的作用

[用 2-5 句话说明此 PR 的目的和范围。具体说明新增、更改或移除了哪些功能。]

主要更改

• [要点 1：具体更改]
• [要点 2：具体更改]
• [...]

---

📖 审查指南

根据此 PR 的更改类型，审查者应重点关注：

领域	优先级	检查内容
[领域 1]	🔴 高	[具体指导]
[领域 2]	🟡 中	[具体指导]
[领域 3]	🟢 低	[具体指导]

---

🚨 发现的问题

问题按严重程度排序（严重 → 高 → 中 → 低 → 细枝末节）。

🔴 严重（必须修复）

[会导致错误、安全漏洞或数据丢失的问题]

[问题标题]

• 文件：path/to/file.ts:L123
• 问题：[清晰描述]
• 影响：[可能出现的问题]
• 建议：[修复方法]

🟠 高（应当修复）

[可能引发问题或违反重要模式的问题]

🟡 中（考虑修复）

[代码质量问题、轻微错误或违反模式的问题]

🟢 低（锦上添花）

[风格问题、轻微改进]

💭 细枝末节

[纯风格方面的建议，可选改进]

---

🧪 测试覆盖分析

此 PR 中的测试更改

测试文件	类型	覆盖范围
[文件]	[unit/integration/e2e]	[测试内容]

覆盖评估

• 新代码已测试：[是/否/部分] - [说明]
• 边界情况已覆盖：[是/否/部分] - [说明]
• 回归测试：[是/否/不适用] - [说明]

建议补充的测试

1. [应添加的具体测试用例]
2. [另一个测试用例]

---

❓ 问题与不确定之处

以下是我不确定、希望得到澄清的事项：

1. [关于设计决策的问题]

   • 上下文：[提问原因]
   • 我的假设：[我认为答案可能是什么]

2. [关于边界情况的问题]

   • 上下文：[此事的重要性]
   • 潜在问题：[可能出现的问题]

---

✅ 审查结论

方面	状态	备注
代码质量	🟢/🟡/🔴	[简要说明]
安全性	🟢/🟡/🔴	[简要说明]
性能	🟢/🟡/🔴	[简要说明]
测试覆盖率	🟢/🟡/🔴	[简要说明]
文档	🟢/🟡/🔴	[简要说明]

总体结论：[批准 / 请求修改 / 需要讨论]

---

审查清单（内部使用 - 用于分析）

代码质量

• 没有重复代码
• 函数职责明确且简短
• 变量名和函数名清晰
• 没有无用代码或被注释掉的代码
• 错误处理恰当
• 没有本应可配置却被硬编码的值

安全性

• 代码中没有机密信息或凭据
• 在需要的地方进行了输入验证
• 没有 SQL 注入漏洞
• 没有 XSS 漏洞
• 已进行身份验证和授权检查
• 已妥善处理敏感数据

性能

• 没有 N+1 查询模式
• 没有不必要的重新渲染（React）
• 没有内存泄漏
• 使用了高效算法
• 异步上下文中没有阻塞操作

破坏性变更

• 保留了 API 契约（如有变更，则已记录）
• 数据库迁移可逆
• 对高风险变更使用了功能标志
• 保持了向后兼容性

文档

• 已记录公开 API
• 复杂逻辑已添加注释
• 根据需要更新了 README
• 面向用户的变更已添加 CHANGELOG 条目

重要说明

1. 具体明确：始终注明确切的文件路径和行号
2. 提供建设性意见：建议修复方法，不要只指出问题
3. 确定优先级：先处理关键问题，最后处理细枝末节
4. 结合上下文：考虑代码库中现有的模式
5. 提出问题：不确定时，应先询问，而不是自行假设