القائمة
对 change.md 做方案级审查（Delta 正确性、TODO 完整性、AC 覆盖）。触发：审查 change / change 审查 / 审方案 / /eo-change-review。 NOT FOR: 代码审查（/eo-review）、spec 审查（/eo-spec-review）、implement 内的回归审查。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
对已有模块发起业务变更，产出 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，代码还没写时用）。
对模块 spec.md 做系统性质量审查。必需场景：module-init 阶段（由 /eo-module-init 触发一次）。可选场景：archive 后含大量 MODIFIED/REMOVED 时复检。触发：审查 spec / review spec / 检查需求 / /eo-spec-review。 NOT FOR: 审代码（/eo-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-change-review |
| description | 对 change.md 做方案级审查（Delta 正确性、TODO 完整性、AC 覆盖）。触发：审查 change / change 审查 / 审方案 / /eo-change-review。 NOT FOR: 代码审查（/eo-review）、spec 审查（/eo-spec-review）、implement 内的回归审查。 |
对某个处于 draft 状态的 change 做方案级审查，在 implement 前把牢"方向是否正确、TODO 是否完整、Delta 是否合规"。可选环节——小 change 可跳过，大 change / 高风险 change / 涉及多层协作的 change 建议跑。
| Skill | 审查对象 | 问的问题 |
|---|---|---|
eo-spec-review | 模块 spec.md（活文档基线） | 需求对不对？业务自洽吗？ |
eo-change-review（本技能） | 某个 change 的 change.md | 方案对不对？Delta 和实施方案一致吗？ |
eo-review | change 实施后的代码 | 代码对不对？实现 vs AC？ |
三者关注点、上下文、回退动作完全不同，不要混用。
/eo-changeeo-doc/dev/<module-name>/changes/<change-id>/change-review.md.eo-project.json。找不到 → 报错退出，提示运行 /eo-project-init。eo-doc/ 路径通过 doc_root 字段解析eo-doc/dev/<module-name>/changes/<change-id>/status 为 draft（若已 approved 也允许，但提示用户通常无需再审）eo-doc/dev/<module-name>/spec.md 存在（审查 Delta 需要对照 spec 当前状态）启动时检查 eo-doc/templates/：
project-profile.md 存在 → 读取，了解项目层级结构plan-layers.md 存在且 change 采用层级 Part 结构 → 启用维度 6：层级 Part 合规性eo-doc/dev/<module-name>/changes/<change-id>/change.md（本次审查对象）change_type，确定审查模式：
bootstrap → 实现范围模式（不审 Delta，审"认领范围合规性"）feature / enhance / refactor → Delta 模式（审 ADDED/MODIFIED/REMOVED 合规性）eo-doc/dev/<module-name>/spec.md（模块基线）——先读 frontmatter + 用 Grep 取章节地图（^#{1,3} ），再 Read（offset/limit）定位 change §3 各 Delta 条目指向的章节；spec 较大时不要整篇读doc/<module>.md（玩法层业务文档）→ 读，理解业务背景⚠️ 不要主观追问审查模式：
change_type是确定性字段，必须从 change.md 直接读取并据此分派。禁止向用户提问"这份 change 是在改 spec 还是只是拆实施批次"——若 change.md 没填change_type或填错，应作为 P0 问题报告（"frontmatterchange_type缺失/不匹配"），而不是反向追问。
按以下维度逐一审查：
按模式分派：
Delta 模式（feature / enhance / refactor）：
§X.Y）？bootstrap 类型实现范围模式（bootstrap）：
Delta 模式：
实现范围模式（bootstrap）：
change_type 与实际改动匹配吗？
refactor 但 §3 Delta 大量 ADDED/MODIFIED → 应改为 feature/enhancefeature 但 §3 全是 MODIFIED → 应改为 enhancefeature/enhance 但 Delta 在复述 spec 已有内容 → 应改为 bootstrapbootstrap 但 §3 写了 ADDED/MODIFIED/REMOVED → P0，类型或内容二选一修正条件维度：仅当
eo-doc/templates/plan-layers.md存在且 change 采用层级 Part 结构时启用。
按下方模板写入 eo-doc/dev/<module-name>/changes/<change-id>/change-review.md。
向用户汇报，严格按下面两种终态二选一措辞（避免含糊指向 /eo-review）：
终态 1 — 通过（无 P0/P1）：
✅ change-review 通过（P0=0, P1=0, P2=N）。 下一步：用户将
change.md的status从draft改为approved，然后跑/eo-implement <change-path>。 （注意：/eo-review是代码审查，要在/eo-implement之后跑，现在还不轮到它。）
终态 2 — 需修订（有 P0/P1）：
⚠️ change-review 发现 P0=N / P1=M 个问题，不能进入 implement。 下一步：用户回到
/eo-change <change-path>按本报告 P0/P1 逐条修订，修订完成后再跑一次/eo-change-review <change-path>复审。 🚫 不要直接改status: approved，不要跑/eo-review（代码还没写），不要跑/eo-implement跳过复审。 循环直到本报告 P0=0 且 P1=0。
严禁在终态 2 的措辞里出现"下一步跑 /eo-review" 或"可进入 implement"——这是高频踩坑点，agent 会把 /eo-review（代码审查）和 /eo-change-review（方案审查）串线，导致用户走错路径。
---
title: <变更标题> Change 审查报告
module: <module-name>
change_id: <NNN-change-id>
tags: [标签1, 标签2]
created: YYYY-MM-DD
updated: YYYY-MM-DD
status: active
summary: >
一句话概述审查结论。
---
# <变更标题> Change 审查报告
> 关联 Change：[change.md](change.md)
> 模块 Spec：[spec.md](../../spec.md)
> 审查日期：YYYY-MM-DD
> Change 状态：draft | approved
## 审查总结
一段话概述 change 整体质量，是否达到可进入 implement 阶段的标准。
明确结论：✅ 可进入 implement / ⚠️ 需小幅修订后进入 / ❌ 需大幅修订
## P0 - 必须修订（阻塞 implement）
### [P0-1] <问题标题>
- **类型**：Delta 错误 / Delta-方案不一致 / TODO 缺失 / AC 缺失 / 范围失控
- **位置**：change.md §X.Y
- **描述**：问题具体描述
- **影响**：若不修会导致 implement 阶段什么问题
- **建议**：修订方向
## P1 - 建议修订（不阻塞但影响实施质量）
### [P1-1] <问题标题>
- **类型**：Delta 粒度过粗 / TODO 依赖不清 / 风险评估遗漏 / 层间边界模糊
- **位置**：change.md §X.Y
- **描述**：问题具体描述
- **建议**：改进方向
## P2 - 可选优化（锦上添花）
### [P2-1] <问题标题>
- **类型**：措辞优化 / 分类调整 / 文档链接补充
- **描述**：建议内容
## §3 合规性检查
> 按 `change_type` 选一种表格填写：
**Delta 模式表（feature / enhance / refactor）**
| Delta 条目 | 类型 | spec 定位 | 状态 | 备注 |
|-----------|------|-----------|------|------|
| <能力名1> | ADDED | §X.Y | ✅ / ⚠️ / ❌ | ... |
| <能力名2> | MODIFIED | §X.Y | ✅ / ⚠️ / ❌ | 旧描述在 spec 中是否存在 |
| <能力名3> | REMOVED | §X.Y | ✅ / ⚠️ / ❌ | ... |
**实现范围表（bootstrap）**
| 认领章节 | 认领范围 | 章节是否存在 | 是否被其他 bootstrap 认领 |
|---------|---------|------------|-------------------------|
| spec §3.1 | 完整 / 子集 | ✅ / ❌ | ✅ 无冲突 / ❌ 与 `NNN-xxx` 重叠 |
## §3 ↔ TODO 映射检查
> Delta 模式填"Delta 条目"；bootstrap 模式填"认领章节"。
| §3 条目 | 对应 TODO | 覆盖状态 |
|--------|-----------|---------|
| ADDED-1 / §3.1 | TODO-S1, TODO-C2 | ✅ 完整覆盖 / ⚠️ 部分覆盖 / ❌ 遗漏 |
## AC 覆盖检查
| Delta 条目 | 对应 AC | 覆盖状态 |
|-----------|---------|---------|
| ADDED-1 | AC-1, AC-2 | ✅ 已覆盖 / ❌ 缺失 / ⚠️ 不完整 |
## 结构完整性检查
| 章节 | 状态 | 备注 |
|------|------|------|
| §1 变更意图 | ✅ / ❌ / ⚠️ | ... |
| §2 范围（In/Out Scope） | ✅ / ❌ / ⚠️ | ... |
| §3 Spec Delta | ✅ / ❌ / ⚠️ | ... |
| §4 实施方案 / TODO | ✅ / ❌ / ⚠️ | ... |
| §5 验收标准 | ✅ / ❌ / ⚠️ | ... |
| §6 测试标准 | ✅ / ❌ / ⚠️ | ... |
| §7 影响评估 | ✅ / ❌ / ⚠️ | ... |
| §8 风险与缓解 | ✅ / ❌ / ⚠️ | ... |
/eo-change 执行change_type 是什么就按什么审，不向用户追问模式归属；change_type 缺失/错填 → P0 报告