| name | code-review |
| description | 多维度代码审查——对 diff、分支或 PR 进行正确性、安全性、可维护性、性能、风格五维评分。触发词：「代码审查」「review」「审查代码」「帮我看看这段代码」。 |
| allowed-tools | ["Read","Grep","Glob","Bash(git *)"] |
代码审查
对提交、分支或 PR 执行结构化的多维度代码审查。
审查维度
每次审查必须覆盖以下五个维度，每个维度独立评分：
1. 正确性（Correctness）
- 逻辑是否正确？边界条件是否覆盖？
- 空值 / undefined / null 是否妥善处理？
- 异步操作的错误路径是否覆盖？
- 类型使用是否正确？是否有隐式
any？
- 是否存在竞态条件或时序依赖？
2. 安全性（Security）
- 是否有注入风险（SQL、XSS、命令注入、路径遍历）？
- 用户输入是否经过校验和净化？
- 是否暴露了敏感信息（密钥、Token、内部 IP、调试信息）？
- 认证 / 授权逻辑是否正确？
- 依赖是否有已知漏洞？
3. 可维护性（Maintainability）
- 命名是否清晰、自解释？
- 函数是否职责单一、长度合理？
- 是否有过深的嵌套（>3 层）？
- 是否有重复代码？
- 抽象层次是否一致？
4. 性能（Performance）
- 是否有不必要的重复计算或 I/O？
- 循环中是否有可提取的不变表达式？
- 大数据量操作是否考虑分页 / 分批？
- 是否存在内存泄漏风险（事件监听未清理、闭包持有大对象）？
- 关键路径是否避免了同步阻塞？
5. 风格（Style）
- 是否遵守
.claude/rules/code-style.md 中的约定？
- 是否使用
const 优先、提前返回、函数式数组方法？
- 是否有违反反模式清单的行为？
- 注释是否解释了 WHY 而非 WHAT？
严重度分级
| 级别 | 含义 | 处理要求 |
|---|
| 阻断（Critical） | 安全漏洞、数据损坏风险、确定会崩溃的错误 | 必须修复后才能合并 |
| 警告（Warning） | 逻辑缺陷、明显的性能问题、可维护性严重问题 | 应修复，除非有明确理由 |
| 建议（Suggestion） | 风格问题、轻微可读性改进、替代方案 | 可选择采纳 |
审查输出格式
## 代码审查报告
**审查范围**：[文件列表 或 diff 范围]
**审查日期**：[日期]
### 阻断（必须修复）
- `file.ts:42` — [问题描述] — [修复建议]
### 警告（应修复）
- `file.ts:58` — [问题描述] — [修复建议]
### 建议（可选）
- `file.ts:102` — [问题描述] — [替代方案]
### 评分
- 正确性：X/10
- 安全性：X/10
- 可维护性：X/10
- 性能：X/10
- 风格：X/10
审查原则
- 报告问题，不重写代码。 除非用户明确要求，代码审查不应直接修改代码。
- 精确引用。 每条发现必须包含文件路径和行号（
src/app.ts:42）。
- 给出修复方向，不给出完整实现。 指出问题和修复思路即可，避免过度干涉。
- 根据 diff 规模调整深度。 小改动快速扫，大 PR 逐文件过。
- 不粉饰问题。 有阻断级问题必须明确报告，不因「这是个小改动」而降低标准。
