code-review

name	code-review
description	代码审查技能。当用户要求进行代码审查、Review 代码变更、检查 PR/提交时使用。支持审查未提交的变更、指定提交、分支对比和 PR 审查。

代码审查

根据用户消息确定审查范围，收集足够上下文后，按审查重点逐项检查，最终按输出模板提交报告。

所有回复内容必须使用中文。

审查流程

进度跟踪：

• 确定审查范围（见下方分支判断规则）
• 获取 diff 并识别涉及的文件
• 读取每个被修改文件的完整内容，理解上下文
• 按审查重点逐项检查
• 按输出模板提交报告

---

确定审查范围

从用户消息中提取输入，按以下优先级匹配：

1. 包含 PR 编号或 github.com/pull 链接 → 审查 Pull Request

   gh pr view <pr_number>
   gh pr diff <pr_number>
   

2. 包含 40 位 SHA 或短 hash → 审查该提交

   git show <commit_hash>
   

3. 包含分支名 → 对比当前分支与指定分支

   git diff <branch_name>...HEAD
   

4. 无明确输入（默认） → 审查所有未提交的变更

   git diff           # 未暂存的变更
   git diff --cached  # 已暂存的变更
   git status --short # 未跟踪的新文件
   

---

收集上下文

仅看 diff 不够。需要读取被修改文件的完整内容——孤立看起来有问题的代码，在完整逻辑中可能正确，反之亦然。

使用 Explore agent 查找项目中类似问题的现有处理方式，在声称某处"不合适"之前先确认项目既有模式。

---

审查重点

按以下优先级检查，缺陷（Bugs）是首要关注点：

优先级	类别	检查项
P0	缺陷	逻辑错误、差一错误、条件判断错误、缺少 guard、不可达代码
P0	缺陷	边界情况：null/空/undefined、错误条件、竞态条件
P0	安全	注入攻击、权限绕过、数据泄露
P0	缺陷	错误处理：吞掉异常、意外抛出、返回未捕获的错误类型
P1	结构	是否遵循项目现有模式；是否遗漏已有抽象可用的场景
P1	结构	过深嵌套是否可通过提前返回或提取函数简化
P1	行为	行为变更（尤其可能非预期的变更）
P2	性能	仅在明显有问题时指出（O(n²)、N+1、阻塞热路径 I/O）

---

陷阱（Gotchas）

审查时需要特别注意以下常见陷阱：

• 只审查变更的代码 — 不要审查未被修改的已有代码，除非变更使既有代码的行为产生了变化。
• 不确定就不标记为 bug — 先调查，不要凭空假设问题。如果边界情况确实重要，需说明在什么现实场景下会出问题。
• 风格问题需谨慎 — 除非明确违反了项目既定规范（如 CONVENTIONS.md、.editorconfig），否则不要把风格偏好当作问题提出。验证代码是否真正违规。
• 行为变更需明确标注 — 即使变更不是 bug，只要改变了既有行为（尤其是可能非预期的），都应提出。

---

输出模板

使用以下模板提交审查报告（中文）：

# 代码审查报告

## 变更概述
[一句话总结这次变更做了什么]

## 审查结果

### 🔴 严重问题（必须修复）
- [文件名:行号] 问题描述 — 影响说明
  建议：修复方式

### 🟡 建议改进（可以改进）
- [文件名:行号] 问题描述
  建议：改进方式

### 🟢 观察（仅供参考）
- 观察内容

## 总结
[整体评价，问题数量统计]

输出要求：

• 语气客观、就事论事，不要指责或过度正面
• 每个问题需明确传达产生 bug 所需的场景、环境或输入条件
• 读者无需仔细阅读全文就能快速理解问题
• 不要使用"做得好"、"感谢"等无实际信息的措辞