code-review

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

审查原则

1. 报告问题，不重写代码。 除非用户明确要求，代码审查不应直接修改代码。
2. 精确引用。 每条发现必须包含文件路径和行号（src/app.ts:42）。
3. 给出修复方向，不给出完整实现。 指出问题和修复思路即可，避免过度干涉。
4. 根据 diff 规模调整深度。 小改动快速扫，大 PR 逐文件过。
5. 不粉饰问题。 有阻断级问题必须明确报告，不因「这是个小改动」而降低标准。