菜单
对模块 spec.md 做系统性质量审查。必需场景：module-init 阶段（由 /eo-module-init 触发一次）。可选场景：archive 后含大量 MODIFIED/REMOVED 时复检。触发：审查 spec / review spec / 检查需求 / /eo-spec-review。 NOT FOR: 审代码（/eo-review）或 change 方案（/eo-change-review）。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
对 change.md 做方案级审查（Delta 正确性、TODO 完整性、AC 覆盖）。触发：审查 change / change 审查 / 审方案 / /eo-change-review。 NOT FOR: 代码审查（/eo-review）、spec 审查（/eo-spec-review）、implement 内的回归审查。
对已有模块发起业务变更，产出 spec Delta + 技术方案 + TODO 的单一载体。触发：新增 / 加功能 / 增强 / 重构 / change / /eo-change。 NOT FOR: bug 修复（走 /eo-implement，不开新 change）。
根据 change.md 的 TODO 落地代码；也负责 change 生命周期内所有 bug 修复（fix 是 implement 的职责，不开新 change）。触发：实现 / 写代码 / implement / fix / 修 bug / /eo-implement。
对已实施的代码做审查，产出 P0/P1/P2 分级报告（前提：代码已实现）。触发：review / 代码审查 / /eo-review。 NOT FOR: spec 审查（/eo-spec-review）、change 方案审查（/eo-change-review，代码还没写时用）。
将已审查通过的 change 的 Spec Delta 合并回模块 spec.md，完成变更闭环。触发：归档 change / archive / 合并 delta / /eo-archive。
为全新模块建立 spec 活文档并完成首次 spec-review，打好后续所有 change 的基线。触发：新建模块 / module init / 新模块 / /eo-module-init。 NOT FOR: 修改已有模块（走 /eo-change）。
| name | eo-spec-review |
| description | 对模块 spec.md 做系统性质量审查。必需场景：module-init 阶段（由 /eo-module-init 触发一次）。可选场景：archive 后含大量 MODIFIED/REMOVED 时复检。触发：审查 spec / review spec / 检查需求 / /eo-spec-review。 NOT FOR: 审代码（/eo-review）或 change 方案（/eo-change-review）。 |
对模块 spec.md 做系统性质量审查，确保模块基线完整、无歧义、可执行。
适用阶段：
- 强制一次：模块初始化时（由 /eo-module-init 自动触发）
- 可选复检：archive 后 spec 被 Delta 大改、或发生结构性 refactor 后，用户主动触发
日常业务变更不需要跑 spec-review（走 /eo-change 写 Delta + /eo-change-review 即可）。
/eo-spec 执行eo-doc/dev/<module-name>/spec-review.md启动时检查 eo-doc/templates/：
eo-doc/templates/project-profile.md 存在 → 读取，了解项目类型和层级结构eo-doc/templates/spec-layers.md 存在 → 读取，作为维度 7 "多层协作完整性"的审查依据（知道模板要求了什么，才能判断 spec 是否完整）.eo-project.json。找不到 → 报错退出，提示运行 /eo-project-init。eo-doc/ 路径通过 doc_root 字段解析eo-doc/dev/<module-name>/spec.md 必须已存在/eo-module-init <module-name>（或独立 /eo-spec）eo-doc/dev/<module-name>/spec.md（需通读全文做完整性审查）——若文件较大、单次 Read 超限，先用 Grep 取章节地图（^#{1,3} ）再按 offset/limit 分段读全，不可因超限而漏读章节eo-doc/dev/ 下其他 spec 的 frontmatter，检查跨功能一致性按以下维度逐一审查：
基础设施引用验证原则：
条件维度：仅当
eo-doc/templates/spec-layers.md存在时启用。 审查依据：以 spec-layers.md 模板定义的结构为标准，逐项检查 spec 的"多层协作需求"章节。
按照下方固定模板撰写，写入 eo-doc/dev/<module-name>/spec-review.md。
更新 eo-doc/dev/INDEX.md。
---
title: <功能名称> Spec 审查报告
spec_name: <spec-name>
tags: [标签1, 标签2]
created: YYYY-MM-DD
updated: YYYY-MM-DD
status: active
summary: >
一句话概述审查结论。
---
# <功能名称> Spec 审查报告
> 关联 Spec：[spec.md](spec.md)
> 审查日期：YYYY-MM-DD
> Spec 状态：草稿 | 已确认
## 审查总结
一段话概述 spec 整体质量，是否达到可进入 plan 阶段的标准。
给出明确结论：✅ 模块基线通过 / ⚠️ 需小幅修订后通过 / ❌ 需大幅修订
## P0 - 必须修订（阻塞模块基线确认）
### [P0-1] <问题标题>
- **类型**：歧义 / 遗漏 / 矛盾 / 不可行
- **位置**：spec.md 中的章节
- **描述**：问题的具体描述
- **影响**：如果不解决，plan/implement 阶段会产生什么问题
- **建议**：需要补充或修订的方向
## P1 - 建议修订（不阻塞但影响质量）
### [P1-1] <问题标题>
- **类型**：模糊描述 / 边界不清 / AC 不足 / 一致性问题
- **位置**：spec.md 中的章节
- **描述**：问题的具体描述
- **建议**：改进方向
## P2 - 可选优化（锦上添花）
### [P2-1] <问题标题>
- **类型**：措辞优化 / 场景补充 / 格式调整
- **描述**：建议内容
## 结构完整性检查
| 章节 | 状态 | 备注 |
|------|------|------|
| 1.1 功能简述 | ✅ / ❌ / ⚠️ | ... |
| 1.2 所属模块 | ✅ / ❌ / ⚠️ | ... |
| 1.3 关联文档 | ✅ / ❌ / ⚠️ | ... |
| 2.1 目标用户 | ✅ / ❌ / ⚠️ | ... |
| 2.2 用户故事 | ✅ / ❌ / ⚠️ | ... |
| 2.3 使用场景 | ✅ / ❌ / ⚠️ | ... |
| 3.1 输入 | ✅ / ❌ / ⚠️ | ... |
| 3.2 输出 | ✅ / ❌ / ⚠️ | ... |
| 3.3 核心行为描述 | ✅ / ❌ / ⚠️ | ... |
| 3.4 业务规则与约束 | ✅ / ❌ / ⚠️ | ... |
| 4.1 性能要求 | ✅ / ❌ / ⚠️ | ... |
| 4.2 安全要求 | ✅ / ❌ / ⚠️ | ... |
| 4.3 兼容性要求 | ✅ / ❌ / ⚠️ | ... |
| 5.1 In Scope | ✅ / ❌ / ⚠️ | ... |
| 5.2 Out of Scope | ✅ / ❌ / ⚠️ | ... |
| 5.3 已知约束 | ✅ / ❌ / ⚠️ | ... |
| 6. 验收标准 | ✅ / ❌ / ⚠️ | ... |
| 7. 多层协作需求 | ✅ / ❌ / ⚠️ / N/A | 仅多层项目需要 |
| 8. 开放问题 | ✅ / ❌ / ⚠️ | ... |
| spec-history.md | ✅ / ❌ / ⚠️ | 已生成、含初始记录行 |
## 验收标准覆盖分析
| 功能需求 | 对应 AC | 覆盖情况 |
|----------|---------|----------|
| 需求描述 | AC-N | ✅ 已覆盖 / ❌ 缺失 / ⚠️ 不完整 |