| name | eo-review |
| description | 对已实施的代码做审查，产出 P0/P1/P2 分级报告（前提：代码已实现）。触发：review / 代码审查 / /eo-review。
NOT FOR: spec 审查（/eo-spec-review）、change 方案审查（/eo-change-review，代码还没写时用）。
|
eo-review — 代码审查
根据模块 spec 和 change 文档对已实施的代码进行审查，产出结构化的审查报告。
定位：eo-review 只审代码。审查范围前移（审 spec / 审 change 方案）请用 /eo-spec-review / /eo-change-review。三种 review 关注点、上下文、产出物都不同，不要混用。
| Skill | 审查对象 | 产出 |
|---|
/eo-spec-review | 模块 spec.md | spec-review.md |
/eo-change-review | change.md（implement 前） | change-review.md |
/eo-review（本技能） | change 实施后的代码 | review.md |
核心原则
- 对照文档审查：严格依据模块 spec 和 change 文档检查功能完整性与正确性
- 最佳实践审查：检查代码质量、命名规范、架构合理性
- 结构化产出：按 P0/P1/P2 分级，明确区分问题类型
- 固定产出：输出到
eo-doc/dev/<module-name>/changes/<change-id>/review.md
模板发现
启动时读 eo-doc/templates/project-profile.md 和 plan-layers.md（存在则启用维度 6「跨层一致性」，否则跳过）。
前置条件
- 必须能找到
.eo-project.json。找不到 → 报错退出，提示运行 /eo-project-init。eo-doc/ 路径通过 doc_root 字段解析
- 模块活文档
eo-doc/dev/<module-name>/spec.md 和 change 文档 eo-doc/dev/<module-name>/changes/<change-id>/change.md 必须已存在
- 相关代码已实现（即
/eo-implement 已经跑过至少一轮，change.md 的 TODO 至少部分被勾选）
- change.md
status 应为 implementing 或 done（不应是 draft / approved）
前置拦截（硬性）
若启动时发现以下任一信号，立即停止并纠偏，不要开始审查：
| 信号 | 含义 | 正确路径 |
|---|
change.md status: draft | change 还没 approve，更没 implement | 走 /eo-change-review |
change.md status: approved 但所有 TODO 未勾选 | 代码还没开工 | 走 /eo-implement 先实施 |
| 用户描述是"审查 change 方案" / "审方案" / "implement 之前再看看" | 用户想要的是方案审查 | 走 /eo-change-review（不是本 skill） |
| 用户描述是"change 重写后再看看有没有新问题" | 代码未变，只是 change.md 改了 | 走 /eo-change-review |
纠偏反馈模板：
⚠️ /eo-review 是实施后的代码审查，需要代码已经写出来。
你当前的情况是 <信号描述>——这一步应该走 /eo-change-review（方案审查）。
两者区别：
/eo-change-review 审 change.md 本身（Delta / TODO / AC 是否合规） — implement 之前/eo-review（本 skill）审代码 — implement / test 之后
工作流程
第一步：阅读上下文
- 阅读
eo-doc/dev/<module-name>/spec.md（模块活文档基线）——先读 frontmatter + 用 Grep 取章节地图（^#{1,3} ），再 Read（offset/limit）本次 change 涉及的章节（通常 §3 功能需求 / §6 AC）；spec 较大时不要整篇读
- 阅读
eo-doc/dev/<module-name>/changes/<change-id>/change.md（本次变更的 §3、实施方案、TODO、AC）
- 从 frontmatter 读取
change_type：
bootstrap → §3 是认领的 spec 章节，审查时对照 spec 这些章节定义的能力检查代码实现feature / enhance / refactor → §3 是 Delta，审查时对照 Delta 声明检查代码改动
- 阅读项目级背景文档（如果存在）
第二步：模板发现与维度确定
- 执行模板发现（见上方），确定是否启用跨层审查维度
- 检查 change 的 TODO 结构：
- 若 change 采用层级 Part 结构且模板存在 → 在标准 5 个维度之外，增加维度 6：跨层一致性
- 若 change 为默认 S/C/G 结构或无模板 → 保持标准 5 个维度
第三步：代码审查
按以下维度逐一审查：
维度 1：功能完整性
- change 中每个 TODO 的验收标准是否已满足
- Spec 中每条验收标准（AC）是否已覆盖
- 是否有遗漏的边界场景
维度 2：逻辑正确性
- 核心业务逻辑是否正确
- 异常处理是否完整
- 边界条件是否考虑
- 是否存在竞态条件、死锁、资源泄漏或生命周期问题
维度 3：架构合规性
- 是否遵循项目既有的分层、模块边界和依赖方向
- 核心逻辑是否与 UI、CLI、Editor 工具、平台层实现保持合理隔离
- 模块职责是否单一，是否存在不合理的耦合
维度 4：代码规范
- 命名是否清晰、一致
- 类型使用是否严格（有无不必要的
any、弱类型绕过等）
- 是否有重复代码可提取
- 公共 API 是否有必要的文档注释
维度 5：安全与性能
- 是否存在常见安全漏洞（注入、越权、敏感信息暴露）
- 是否存在明显的性能瓶颈
维度 6：跨层一致性（仅多层 Part 模式）
条件维度：仅当 eo-doc/templates/plan-layers.md 存在且 change 采用层级 Part 结构时启用。
审查依据：以 plan-layers.md 模板定义的层边界和 project-profile.md 的层间约束为标准。
- 各层之间的接口定义是否匹配（如 Proto 消息字段与 Server/Client 使用是否一致）
- 跨层数据流是否完整（请求→处理→响应→通知 链路无断裂）
- 各层状态同步是否可靠（如登录/重连时各层数据能否正确恢复）
- 是否存在层间假设不一致（一层假设另一层有某行为，但另一层未实现）
- 各层代码是否在模板定义的目录范围内（未越界修改其他层的代码）
第四步：撰写报告
按照下方固定模板撰写，写入 eo-doc/dev/<module-name>/changes/<change-id>/review.md。
固定模板
见 references/review-template.md。
关键约束
- 客观公正：基于文档和最佳实践审查，不做主观偏好评判
- 问题定位精确：必须给出具体的文件路径和行号
- 不直接改代码：Review 只产出报告，修复工作由
/eo-implement 执行
- 分级清晰：P0 仅限阻塞性问题，不要把小问题升级为 P0
