review

name	review
description	代码审查技能。当用户要求做代码审查、检查代码质量、检查 bug 和风险时使用。触发词包括"review"、"代码审查"、"代码检查"、"review 代码"、"/review"。

Review - 代码审查技能

根据 spec 和 plan 文档对代码进行全面审查，产出结构化的审查报告。

核心原则

1. 对照文档审查：严格依据 spec 和 plan 检查功能完整性与正确性
2. 最佳实践审查：检查代码质量、命名规范、架构合理性
3. 结构化产出：按 P0/P1/P2 分级，明确区分问题类型
4. 固定产出：输出到项目既有的需求目录；若无统一约定，建议使用 spec/<spec-name>/review.md

前置条件

• 对应功能的 spec.md 和 plan.md 必须已存在
• 相关代码已实现（至少部分实现）

工作流程

第一步：阅读上下文

1. 阅读对应功能的 spec.md，理解需求规格
2. 阅读对应功能的 plan.md，理解技术方案和 TODO 清单
3. 阅读项目级背景文档（如 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