القائمة
对已有模块发起业务变更，产出 spec Delta + 技术方案 + TODO 的单一载体。触发：新增 / 加功能 / 增强 / 重构 / change / /eo-change。 NOT FOR: bug 修复（走 /eo-implement，不开新 change）。
التثبيت باستخدام 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 内的回归审查。
根据 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 |
| description | 对已有模块发起业务变更，产出 spec Delta + 技术方案 + TODO 的单一载体。触发：新增 / 加功能 / 增强 / 重构 / change / /eo-change。 NOT FOR: bug 修复（走 /eo-implement，不开新 change）。 |
对某个模块发起一次变更。change 文档是单一真相载体：既是需求澄清（Delta），又是实施方案（TODO）。归档时 Delta 自动合并回模块 spec。
eo-doc/dev/<module-name>/changes/ 下eo-doc/dev/<module-name>/changes/<NNN-change-id>/change.md启动时读 eo-doc/templates/project-profile.md 和 plan-layers.md（兼容 change-layers.md；存在则启用层级 Part 模式，否则用默认 S/C/G 三分类）。
.eo-project.json。找不到 → 报错退出，提示运行 /eo-project-init。eo-doc/ 路径通过 doc_root 字段解析eo-doc/dev/<module-name>/ 必须存在且含 spec.md（status: confirmed）/eo-module-init <module-name> 完成模块初始化status: draft → 提示用户先完成 spec-revieweo-doc/dev/ 下所有模块的 spec.md frontmatter（title / module_name / tags / summary）/eo-module-init 创建新模块，暂停本流程depends_on 关联depends_on 顺序依次产出读目标模块的 spec.md（了解"当前能力基线"）——先读 frontmatter + 用 Grep 取章节地图（^#{1,3} ），再 Read（offset/limit）变更涉及的章节（通常 §3 功能需求 / §5 边界 / §6 AC）；spec 较大时不要整篇读
阅读该模块 changes/ 下最近的 3 个历史 change（了解演化方向，避免重复/冲突）
识别变更类型，按以下矩阵判断：
| 问题 | change_type | 说明 |
|---|---|---|
| spec 有，代码无 → 首次把 spec 实现出来 | bootstrap | module-init 后首批落地，或空能力首次实现 |
| spec 无，代码无 → 加一个 spec 里不存在的新能力 | feature | 真正的"加 spec"（Delta ADDED） |
| spec 有，代码有 → 调整现有能力 | enhance | Delta MODIFIED 为主 |
| spec 有，代码有 → 内部重构、对外能力不变 | refactor | Delta 以内部章节的 MODIFIED 为主，对外能力表不动 |
bootstrap 的核心区别：不改 spec，只把 spec 已声明的章节落成代码。§3 不写 Delta，改写"实现范围"（见 §3 模板的 bootstrap 分支）fix 作为类型：若用户描述是"修 bug"——属于对某个已归档 change 的实施缺陷修复，不是新 change：
/eo-implement 继续修enhance，按 enhance 处理执行模板发现（见上方）
逐项列出模糊点，向用户澄清：
反复澄清直到 95% 确信。宁可多问一轮，不要用"可能"、"应该"这类词。
cd eo-doc/dev/<module-name>/changes/ 扫描现有子目录001 / 002 / 037）<NNN>-<kebab-name>001-add-queue、002-enhance-overflow-handling、015-refactor-cache-layerfix- 开头的 change-id——bug 修复不应产生新 change创建目录 eo-doc/dev/<module-name>/changes/<NNN-change-id>/，按下方模板写入 change.md。
交付用户确认。根据反馈修订到用户满意后，保持 status: draft（暂不改 approved）。
eo-doc/dev/<module-name>/changes/INDEX.md（模块内 change 时间线），若不存在则创建spec.md——合并动作由 eo-archive 在归档时执行关键分派：先判断"这是首次产出还是返工修订"，两种场景提示完全不同。
根据规模和风险判断是否建议走 change-review：
/eo-change-review统一提示模板：
change 文档已就绪（
status: draft）。后续流程：🟡 （可选，建议）
/eo-change-review <change-path>— 方案级审查（§3 合规、TODO 完整、AC 覆盖），通过后再 approve
- 将 change.md
status改为approved/eo-implement <change-path>— 按 TODO 实施代码/eo-test <change-path>— 测试与验证/eo-review <change-path>— 实施后代码审查（仅当 implement 已跑过）/eo-archive <module-name> <change-id>— 代码审查通过后归档
⚠️ 关键：此时代码尚未实施，必须走 /eo-change-review 复审，不要走 /eo-review。
/eo-review 是实施后的代码审查，需要代码已经写出来；此时根本没代码，路径走错会让 reviewer 空审。
统一提示模板（场景 B）：
change 重写完成（
status: draft）。既然前一轮 change-review 发现了问题，修订后请再跑一次/eo-change-review <change-path>确认问题已收敛。🔁
/eo-change-review <change-path>— 复审方案（不是 /eo-review；代码还没写，没东西给 /eo-review 审） 🔁 直到 change-review 无 P0/P1 → 用户改status: approved→ 进入/eo-implement禁止此时直接改
status: approved跳过复审，也禁止跳到/eo-implement或/eo-review。
change-review.md 且含未解决的 P0/P1 → 场景 B见 references/change-template.md。
# <module-name> 变更时间线
| 编号 | 标题 | 类型 | 状态 | 日期 | 摘要 |
|------|------|------|------|------|------|
| [001-xxx](001-xxx/change.md) | ... | feature | archived | YYYY-MM-DD | ... |
| 信号 | 走 eo-change | 走 eo-module-init |
|---|---|---|
| 目标模块已存在 spec | ✅ | ❌ |
| 目标模块完全不存在 | ❌（先 init） | ✅ |
| 是对已有能力的修改 | ✅ | ❌ |
| 是全新模块的首次落地 | ❌ | ✅ |
当模块 spec 需要大规模结构性重写（Delta 占 spec 80% 以上）时，不要跳回 eo-module-init，而是用 change_type: refactor 发一个 change，逐步演化。
核心准则：以"是否要动别人的 spec"为界。
一个 change 结构上只能归属一个模块，Delta 只能合并到一份 spec.md。跨模块需求按下表处理：
| 场景 | 归属 | 做法 |
|---|---|---|
| A. 只调用不改契约 — 新 change 只是调用对方模块已有的接口/能力，对方 spec 不动 | 单 change，归主模块 | §2.3 或 §4.2 列出"依赖的外部模块"；对方 spec 不产生 Delta |
| B. 多模块 spec 都要动 — 新功能需要在多个模块的 spec 同时 ADDED/MODIFIED/REMOVED | 拆多个 change，每模块一个 | 用 depends_on frontmatter 和共享命名关联 |
| C. 只动 Proto/Config，不改业务模块 spec | 归调用方模块 | Proto/Config 不是一等模块，归属消费侧 |
dev/inventory/changes/007-crafting-system/dev/building/changes/012-crafting-system/depends_on / related：
depends_on:
- inventory/007-crafting-system
related:
- building/012-crafting-system
/eo-workflow implement 一次只跑一个 change，天然强制顺序dev/cross/ 虚拟模块把跨模块需求塞进去 — 破坏"模块一等公民"，archive 无法定位目标 spec/eo-archive 会拒绝（它只认单一目标 spec，见 eo-archive 的"拒绝跨模块 Delta"规则）:::new / :::changed / :::extern 高亮本次动了的节点；删除节点不画，在图下方用 > 移除：... 文字补注:::new/:::changed 后并入 spec.md §3.5NNN-kebab-name，NNN 按模块内现有 change 最大编号 +1，3 位补零feature / enhance / refactor → 必须写至少一条 Delta（ADDED/MODIFIED/REMOVED 任一）；产生不了 Delta 大概率是 bug fix，归 implement 循环bootstrap → 必须写"实现范围"（认领的 spec 章节列表）；不允许写 ADDED/MODIFIED/REMOVEDspec.md，合并由 eo-archive 负责