用途
review 是一个代码质量技能，用于进行系统化代码评审、发现问题、提出重构建议并推行最佳实践，相当于一个自动代码审查者，在问题进入生产环境前将其拦截。
主要能力
该技能围绕一份 25 点清单展开，分为五个方面：
1. 代码结构（5 项）
- 单一职责原则（SRP）：检查每个函数/类是否只有一个明确目的，拆分职责混杂的函数。
- DRY（不要重复自己）：检查是否存在重复逻辑，提取共享函数或工具。
- 函数长度：检查函数是否在 50 行以内（最好 30 行以内），拆分过长函数。
- 命名清晰度：检查命名是否清楚表达用途，避免 data、info、temp、x、y 等模糊名称。
- 魔法数字：检查常量是否被命名，将无法解释的数字提取为具名常量。
2. 错误处理（5 项）
- 所有错误是否被捕获：在风险操作周围添加错误处理。
- 无静默失败：错误应被记录或暴露，避免空 catch 块。
- 用户友好的错误信息：错误应说明出了什么问题以及该怎么做。
- 便于调试的日志：在关键点添加带上下文的结构化日志。
- 覆盖边界情况：处理 null、空值、零值等边界条件，增加防御性检查与校验。
3. 安全（5 项）
- 输入校验：校验并净化所有用户输入，可使用 schema 校验库。
- SQL 注入防护：使用参数化查询或 ORM，避免字符串拼接 SQL。
- XSS 防护：转义 HTML 输出、设置 CSP 头，安全渲染或净化后再输出。
- 敏感数据处理：密码哈希（bcrypt/argon2）、PII 加密、安全传输、净化日志。
- 密钥使用环境变量：API key、凭据放在环境变量或密钥管理器中，避免硬编码。
4. 性能（5 项）
- 避免 N+1 查询：批量查询、预加载，避免循环内查询。
- 适当的缓存：缓存昂贵操作，避免重复相同 API 调用或计算。
- 数据库索引：在 WHERE/JOIN 使用的列上建索引，避免大表全表扫描。
- 避免不必要的计算：使用提前返回、惰性求值，将昂贵操作放在校验之后。
- 防止内存泄漏：清理资源、关闭连接，使用 finally 块或资源管理模式。
5. 测试（5 项）
- 存在测试：为新功能编写测试，覆盖所有新函数/组件。
- 测试边界情况：不仅测试 happy path，还要测试边界与错误条件。
- 测试 happy path：验证正常行为。
- 测试错误条件：验证无效输入与失败情况。
- 测试可维护：测试名称清晰、减少重复，提取测试辅助函数，使用明确断言。
使用方式
激活触发条件
当用户说“review this code”、问“can this be improved?”、提到“refactoring”“optimization”或“code smell”、在 git 提交前（pre-commit review）、完成一个功能后，或说“is this code good?”时，该技能会被激活。
评审流程
- 确定范围：询问用户要评审什么，包括当前暂存改动（
git diff --cached）、当前未暂存改动（git diff）、指定文件或目录、整个功能、近期提交。 - 分析代码：运行相应的 git diff 或读取文件，例如暂存改动用
git diff --cached，未暂存用git diff，指定文件用 Read file_path，整个功能用git diff main...HEAD。 - 应用清单：依次检查代码结构（5 项）、错误处理（5 项）、安全（5 项）、性能（5 项）、测试（5 项）。
- 生成评审报告。
UltraThink 架构问题
如果评审发现根本性架构问题，会激活深度思考，例如当代码违反多个原则（SRP、DRY、YAGNI）、紧耦合导致难以测试、相似逻辑在多个文件中重复、错误处理分散且不一致、性能问题暗示数据结构或算法选择错误时。会深入追问：这是否是错误架构的症状？重构能否解决根因还是只是转移复杂度？如果从零设计会是什么样？阻碍关注点清晰分离的原因是什么？领域模型是否正确？之后会给出战术性修复（重构）或战略性重新设计的建议并说明理由。
评审输出格式
报告包含：优点（具体且鼓励性）、按优先级分级的问题（高优先级/合并前必须修复、中优先级/应当处理、低优先级/可考虑改进，每项含位置、问题、风险或影响、修复或建议）、重构建议（含当前代码、重构后代码、收益）、代码度量（复杂度、测试覆盖率、可维护性、代码行数、重复代码比例）、行动项清单，以及总体评估和建议（Approve/Request Changes/Reject）与置信度。
适用场景
- 提交前评审暂存改动。
- 完成功能后检查新代码质量与测试覆盖。
- 请求对某个模块提出改进建议。
- 识别代码坏味道并规划重构。
集成点
- 执行阶段与 spec-driven-implementation 技能协同。
- 提交前评审与 git-workflow 技能协同。
- 验证测试质量时与 systematic-testing 技能协同。
- 若集成，可在提交前自动触发。
限制与说明
资料未提供该技能的具体运行平台、收费方式、价格、实现细节或安装命令。评审时应保持彻底但建设性，按优先级排列问题，始终提供具体代码示例，解释问题原因而不仅是现象，给出具体解决方案而非单纯批评，在完美主义与务实之间取得平衡，聚焦高影响改进。