| name | review |
| description | 代码审查技能。当用户要求做代码审查、检查代码质量、检查 bug 和风险时使用。触发词包括"review"、"代码审查"、"代码检查"、"review 代码"、"/review"。 |
Review - 代码审查技能
根据 spec 和 plan 文档对代码进行全面审查，产出结构化的审查报告。
核心原则
- 对照文档审查：严格依据 spec 和 plan 检查功能完整性与正确性
- 最佳实践审查：检查代码质量、命名规范、架构合理性
- 结构化产出：按 P0/P1/P2 分级，明确区分问题类型
- 固定产出：输出到项目既有的需求目录；若无统一约定，建议使用
spec/<spec-name>/review.md
前置条件
- 对应功能的
spec.md 和 plan.md 必须已存在
- 相关代码已实现（至少部分实现）
工作流程
第一步：阅读上下文
- 阅读对应功能的
spec.md，理解需求规格
- 阅读对应功能的
plan.md，理解技术方案和 TODO 清单
- 阅读项目级背景文档（如 PRD、roadmap、架构说明；如果存在），理解整体方向
第二步：代码审查
按以下维度逐一审查：
维度 1：功能完整性
- Plan 中每个 TODO 的验收标准是否已满足
- Spec 中每条验收标准（AC）是否已覆盖
- 是否有遗漏的边界场景
维度 2：逻辑正确性
- 核心业务逻辑是否正确
- 异常处理是否完整
- 边界条件是否考虑
- 是否存在竞态条件、死锁、资源泄漏或生命周期问题
维度 3：架构合规性
- 是否遵循项目既有的分层、模块边界和依赖方向
- 核心逻辑是否与 UI、CLI、Editor 工具、平台层实现保持合理隔离
- 是否通过合理的抽象保持模块解耦
- 模块职责是否单一，是否存在不合理的耦合
- 是否遵循项目约定的设计模式或扩展机制
维度 4：代码规范
- 命名是否清晰、一致（变量、函数、类、文件）
- 类型使用是否严格（有无不必要的
any、object、弱类型绕过等）
- 是否有重复代码可提取
- 公共 API 是否有必要的文档注释
维度 5：安全与性能
- 是否存在常见安全漏洞（如注入、越权、敏感信息暴露）
- 是否存在明显的性能瓶颈
- 依赖项是否安全可靠
第三步：撰写报告
按照下方固定模板撰写，写入对应功能的 review.md。
固定模板
# <功能名称> 代码审查报告
> 关联 Spec：<spec 文档路径>
> 关联 Plan：<plan 文档路径>
> 审查日期：YYYY-MM-DD
> 审查范围：列出审查涉及的文件或模块
## 审查总结
一段话概述代码整体质量，是否达到可合入标准。
## P0 - 必须修复（阻塞性问题）
影响核心功能、数据安全或导致崩溃的问题。
### [P0-1] <问题标题>
- **类型**：Bug / 安全漏洞 / 逻辑错误 / 功能缺失
- **位置**：`文件路径:行号`
- **描述**：问题的具体描述
- **影响**：该问题会导致什么后果
- **建议**：修复方向（不写代码）
## P1 - 建议修复（重要但不阻塞）
影响代码质量、可维护性或存在潜在风险的问题。
### [P1-1] <问题标题>
- **类型**：架构问题 / 规范违反 / 潜在 Bug / 性能问题
- **位置**：`文件路径:行号`
- **描述**：问题的具体描述
- **建议**：改进方向
## P2 - 可选优化（锦上添花）
代码风格、命名优化、文档补充等非功能性建议。
### [P2-1] <问题标题>
- **类型**：命名优化 / 风格建议 / 文档补充
- **位置**：`文件路径:行号`
- **描述**：建议内容
## 验收标准覆盖检查
| AC 编号 | 描述 | 状态 |
|---------|------|------|
| AC-1 | ... | ✅ 通过 / ❌ 未通过 / ⚠️ 部分通过 |
## TODO 完成度检查
| TODO | 描述 | 状态 |
|------|------|------|
| TODO-S1 | ... | ✅ 完成 / ❌ 未完成 / ⚠️ 部分完成 |
关键约束
- 客观公正：基于文档和最佳实践审查，不做主观偏好评判
- 问题定位精确：必须给出具体的文件路径和行号
- 不直接改代码：Review 只产出报告，修复工作由
/implement 执行
- 分级清晰：P0 仅限阻塞性问题，不要把小问题升级为 P0
