Eo 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 |

核心原则

1. 对照文档审查：严格依据模块 spec 和 change 文档检查功能完整性与正确性
2. 最佳实践审查：检查代码质量、命名规范、架构合理性
3. 结构化产出：按 P0/P1/P2 分级，明确区分问题类型
4. 固定产出：输出到 eo-doc/dev//changes//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//spec.md 和 change 文档 eo-doc/dev//changes//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 之后

工作流程

第一步：阅读上下文

1. 阅读 eo-doc/dev//spec.md（模块活文档基线）——先读 frontmatter + 用 Grep 取章节地图（^#{1,3} ），再 Read（offset/limit）本次 change 涉及的章节（通常 §3 功能需求 / §6 AC）；spec 较大时不要整篇读
2. 阅读 eo-doc/dev//changes//change.md（本次变更的 §3、实施方案、TODO、AC）

• 从 frontmatter 读取 change_type：
• bootstrap → §3 是认领的 spec 章节，审查时对照 spec 这些章节定义的能力检查代码实现
• feature / enhance / refactor → §3 是 Delta，审查时对照 Delta 声明检查代码改动

1. 阅读项目级背景文档（如果存在）

第二步：模板发现与维度确定

1. 执行模板发现（见上方），确定是否启用跨层审查维度
2. 检查 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//changes//review.md。

固定模板

见 [references/review-template.md](references/review-template.md)。

关键约束

• 客观公正：基于文档和最佳实践审查，不做主观偏好评判
• 问题定位精确：必须给出具体的文件路径和行号
• 不直接改代码：Review 只产出报告，修复工作由 /eo-implement 执行
• 分级清晰：P0 仅限阻塞性问题，不要把小问题升级为 P0

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: SimpleEve
• Source: SimpleEve/eo-skills
• License: MIT

Install and usage instructions live in the source repository linked above.