PR Review Skill#

完整的 Pull Request 审查工作流，涵盖安全分析、测试覆盖、性能评估、代码质量检查。

When to Use#

✅ USE this skill when:

• 审查 Pull Request 的代码变更
• 检查 PR 的安全漏洞和风险
• 分析测试覆盖情况
• 评估代码变更的性能影响
• 生成审查报告并通知到飞书

❌ DON'T use this skill when:

• 本地 git 操作（commit、push、pull）→ 直接用 git
• 非 GitHub 仓库（GitLab、Bitbucket）→ 不同的 CLI
• 简单查看 PR 状态 → 直接用 gh pr view
• 写代码或修复 → 用 coding-agent skill

Prerequisites#

bash

# 确认 gh 已认证
gh auth status

# 如果未认证，执行
gh auth login

审查流程（6 步）#

text

Step 1: 获取 PR 信息
    ↓
Step 2: 分析变更内容
    ↓
Step 3: 安全审查
    ↓
Step 4: 测试覆盖检查
    ↓
Step 5: 性能 & 质量评估
    ↓
Step 6: 生成报告 + 飞书通知

---

Step 1: 获取 PR 信息#

确定 PR 目标#

用户可能提供以下格式之一：

• PR URL: https://github.com/owner/repo/pull/123
• PR 编号: #123（需要在 git 仓库中）
• 分支名: feature/xxx（需查找对应的 PR）

bash

# 从 URL 解析
# owner/repo: 从 URL 提取
# pr_number: 从 URL 提取

# 获取 PR 详情
gh pr view <pr_number> --repo <owner/repo> --json title,body,author,state,additions,deletions,changedFiles,files,reviews,comments,labels,mergeable,headRefName,baseRefName

# 获取 PR 的文件变更列表
gh pr diff <pr_number> --repo <owner/repo> --stat

# 获取完整 diff
gh pr diff <pr_number> --repo <owner/repo>

如果用户只提供了分支名#

bash

# 查找分支对应的 PR
gh pr list --repo <owner/repo> --head <branch_name> --json number,title

如果在 git 仓库内且未指定 PR#

bash

# 获取当前分支的 PR
gh pr view --json number,title,body,state

---

Step 2: 分析变更内容#

获取 diff 后，按以下维度分析：

变更概览#

text

📊 变更概览
- 文件数: X 个文件变更
- 新增: +X 行
- 删除: -X 行
- 涉及模块: [列出模块/目录]

文件分类#

将变更文件分为以下类别：

类别说明关注点🔐 安全相关auth、crypto、permission、config注入、暴露、权限绕过🧪 测试文件test、spec、 tests覆盖率、边界用例📦 依赖变更package.json、requirements.txt版本锁定、已知漏洞🏗️ 核心逻辑业务代码、API、数据库逻辑正确性、性能📝 文档README、docs是否同步更新⚙️ 配置CI/CD、Dockerfile、环境变量安全配置、敏感信息

---

Step 3: 安全审查#

对每个变更文件检查以下安全维度：

安全检查清单#

markdown

🔐 安全审查

**认证/授权 (Auth)**
- [ ] 是否有未授权的端点暴露？
- [ ] 权限检查是否完整？
- [ ] Token/Session 处理是否安全？

**数据暴露 (Data Exposure)**
- [ ] 是否有敏感数据泄露到日志？
- [ ] API 响应是否暴露内部信息？
- [ ] 错误消息是否泄露系统细节？

**注入风险 (Injection)**
- [ ] SQL 注入：是否使用参数化查询？
- [ ] XSS：用户输入是否正确转义？
- [ ] 命令注入：是否有未经验证的 shell 执行？
- [ ] 路径遍历：文件路径是否验证？

**加密与密钥 (Crypto)**
- [ ] 是否使用了弱加密算法？
- [ ] 密钥是否硬编码？
- [ ] 是否使用安全的随机数生成？

**依赖安全 (Dependencies)**
- [ ] 新增依赖是否有已知漏洞？
- [ ] 版本是否锁定？
- [ ] 是否引入了不必要的权限？

安全严重性分级#

级别标记说明处理🔴 CriticalCRITICAL可被远程利用，影响数据安全必须修复 才能合并🟠 HighHIGH潜在安全风险，需要关注建议修复 后合并🟡 MediumMEDIUM最佳实践问题建议改进🟢 LowLOW代码风格/建议可选改进

---

Step 4: 测试覆盖检查#

测试分析清单#

markdown

🧪 测试覆盖分析

**新增代码测试**
- [ ] 新增功能是否有对应测试？
- [ ] 测试是否覆盖正常流程？
- [ ] 测试是否覆盖异常/边界用例？

**测试质量**
- [ ] 断言是否有意义（非 trivial assert）？
- [ ] 测试是否独立（无共享状态）？
- [ ] Mock/Stub 使用是否合理？

**回归测试**
- [ ] 修改的逻辑是否有回归测试？
- [ ] 是否破坏了现有测试？

**覆盖率评估**
- 关键路径覆盖率: __%
- 建议覆盖率目标: 80%+

测试建议模板#

markdown

## 🧪 测试建议

### 缺失测试
1. [文件路径] — [建议添加的测试]
2. ...

### 边界用例
1. [场景描述] — [建议的测试方法]
2. ...

### 测试改进
1. [现有测试] — [改进建议]

---

Step 5: 性能 & 质量评估#

性能检查#

markdown

⚡ 性能评估

**算法复杂度**
- [ ] 是否有 O(n²) 或更高复杂度的操作在热点路径？
- [ ] 是否有不必要的嵌套循环？

**数据库/IO**
- [ ] 是否有 N+1 查询问题？
- [ ] 是否有不必要的全表扫描？
- [ ] 文件操作是否有适当的缓冲？

**内存使用**
- [ ] 是否有内存泄漏风险？
- [ ] 大数据集是否分页/流式处理？

**缓存**
- [ ] 是否应该缓存的结果未缓存？
- [ ] 缓存失效策略是否正确？

代码质量#

markdown

📝 代码质量

**可读性**
- [ ] 命名是否清晰、一致？
- [ ] 函数/方法是否职责单一？
- [ ] 是否有过度复杂的条件逻辑？

**可维护性**
- [ ] 是否遵循项目的代码规范？
- [ ] 是否有重复代码可以提取？
- [ ] 错误处理是否完整？

**架构**
- [ ] 变更是否符合项目架构模式？
- [ ] 是否引入了不当的耦合？
- [ ] 是否有向后兼容性问题？

---

Step 6: 生成报告 + 飞书通知#

审查报告模板#

markdown

# 🔍 PR 审查报告

**PR**: #<number> — <title>
**作者**: @<author>
**分支**: <head> → <base>
**变更**: +<additions> -<deletions> (<changedFiles> 文件)

---

## 📊 总体评估: [✅ 通过 / ⚠️ 需修改 / ❌ 不建议合并]

### 🔐 安全: [✅/⚠️/❌]
- [发现摘要]

### 🧪 测试: [✅/⚠️/❌]
- 覆盖率: __%
- [发现摘要]

### ⚡ 性能: [✅/⚠️/❌]
- [发现摘要]

### 📝 代码质量: [✅/⚠️/❌]
- [发现摘要]

---

## 📋 详细发现

### 🔴 必须修复 (X)
1. [文件:行号] — [问题描述]

### 🟠 建议修复 (X)
1. [文件:行号] — [问题描述]

### 🟡 改进建议 (X)
1. [文件:行号] — [问题描述]

---

## ✅ 亮点
- [值得肯定的地方]

飞书通知#

如果用户要求通知到飞书，使用 message 工具发送审查摘要：

text

发送对象: 用户指定的飞书群/个人
消息格式: 使用卡片或富文本格式
内容: 审查报告的精简版（总体评估 + 关键发现）

飞书消息模板

text

🔍 PR 审查完成

PR: #<number> — <title>
作者: @<author>
总体评估: [✅/⚠️/❌]

🔐 安全: [✅/⚠️/❌]
🧪 测试: [✅/⚠️/❌] (覆盖率: __%)
⚡ 性能: [✅/⚠️/❌]
📝 质量: [✅/⚠️/❌]

关键发现:
• [发现1]
• [发现2]

详细报告: [链接或完整内容]

在 PR 中提交审查（可选）#

bash

# 提交审查评论
gh pr review <pr_number> --repo <owner/repo> --body "审查报告内容" --approve
# 或
gh pr review <pr_number> --repo <owner/repo> --body "审查报告内容" --request-changes
# 或
gh pr review <pr_number> --repo <owner/repo> --body "审查报告内容" --comment

# 对特定文件添加行级评论
gh api repos/<owner/repo/pulls/<pr_number>/comments \
  -f body="这里有个问题" \
  -f commit_id="<commit_sha>" \
  -f path="<file_path>" \
  -f line=<line_number>

---

快速审查模式#

对于简单的 PR，可以跳过某些步骤：

快速安全审查#

只执行 Step 1 → Step 3 → Step 6（跳过测试和性能分析）

快速测试审查#

只执行 Step 1 → Step 4 → Step 6（跳过安全和性能分析）

---

使用示例#

完整审查#

text

用户: 帮我审查这个 PR https://github.com/myorg/myrepo/pull/42

Agent 执行:
1. gh pr view 42 --repo myorg/myrepo --json ...
2. gh pr diff 42 --repo myorg/myrepo
3. 分析变更 → 安全检查 → 测试检查 → 性能评估
4. 生成审查报告
5. (可选) 发送到飞书通知

安全审查#

text

用户: 检查这个 PR 有没有安全问题 #15

Agent 执行:
1. gh pr view 15 --json ...
2. gh pr diff 15
3. 只做安全审查（跳过测试和性能）
4. 生成安全审查报告

飞书通知#

text

用户: 审查完 PR 后把结果发到 "技术评审" 群

Agent 执行:
1. 执行完整审查流程
2. 使用 message 工具发送到指定飞书群

---

常见问题#

Q: gh 未认证怎么办？#

bash

gh auth login
# 或设置 token
export GITHUB_TOKEN="your_token"

Q: 私有仓库无权限？#

bash

# 确认 gh 有仓库权限
gh auth status
# 重新授权
gh auth refresh -s repo

Q: PR diff 太大怎么办？#

• 使用 --stat 先看概览
• 分文件审查，重点关注安全和核心逻辑文件
• 跳过 lock 文件、生成代码等