메뉴
在 /clear 之前生成最小可恢复快照到 tmp/<topic>-handoff.md，让下一个会话载入这一个文件就能从当前节点继续。优先记录任务状态、关键口径、下一步分叉，主动丢弃探索过程。触发：handoff / 存一下进度 / 我要 clear / /eo-handoff。 NOT FOR: 跨 agent 任务派发（用 /eo-flow）；机械压缩对话流（用内置 /compact）。
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，代码还没写时用）。
对模块 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。
| name | eo-handoff |
| description | 在 /clear 之前生成最小可恢复快照到 tmp/<topic>-handoff.md，让下一个会话载入这一个文件就能从当前节点继续。优先记录任务状态、关键口径、下一步分叉，主动丢弃探索过程。触发：handoff / 存一下进度 / 我要 clear / /eo-handoff。 NOT FOR: 跨 agent 任务派发（用 /eo-flow）；机械压缩对话流（用内置 /compact）。 |
clear 前的最后一步：把"下次会话要立刻接着干"所需的最少信息写到 <repo>/tmp/<topic>-handoff.md。
和容易混淆的两个东西的边界：
| 名称 | 对端 | 性质 |
|---|---|---|
内置 /compact | 同一会话续命 | 机械压缩对话流，保留所有信息 |
/eo-flow | 同时存在的另一个 agent (codex pane) | 跨 agent 任务派发 |
/eo-handoff | clear 之后的下一个会话（"未来的自己"） | 定向提取当前状态 + 决策口径，主动丢弃探索过程 |
核心区别：eo-handoff 不是总结，是"开机指令"。读者是新会话的自己，目标是 5 分钟内回到当前节点。
tmp/ 是工作区机制，任何 git 仓库都能用，不归 eo-doc/ 体系管。即使没跑过 /eo-project-init 也能用本 skill。
tmp/<topic>-handoff.md，<topic> 用 kebab-case每段没有内容就写 _无_，不要省略段落——固定结构便于下一个会话按位置取信息。
# <topic> — 会话交接快照
> <YYYY-MM-DD HH:MM> 由 /eo-handoff 生成。
> 用途：`/clear` 后载入本文件即可从「<一句话节点描述>」继续。
## 1. 当前状态
- 在做什么、卡在哪个节点
- 关键产物路径 + status（spec / change / review 等的 frontmatter status）
- 上下游依赖是否就绪
## 2. 基线
- 仓库 HEAD：`<git rev-parse --short HEAD>` on `<branch>`
- 关键文件清单（路径 + 一句话作用），区分「已存在」「待新增」
- 工作目录 dirty / clean 状态
## 3. 下一步分叉
等用户决策的点，列出候选：
- **A) <方案>**：…（适用场景 / 取舍）
- **B) <方案>**：…
- **C) 待定**：还没成型的方向
如果没有分叉、就一条路走到黑，写「无分叉，下一步：<动作>」。
## 4. 关键口径清单 ⭐ 最重要
跨 clear 必须保持一致的决策与不变量。每条带「**为什么**」一行，便于新会话判断边界情况。
- [ ] <口径 1>：<内容>。为什么：<原因>
- [ ] <口径 2>：…
- …
这一段是 handoff 的核心价值——探索过程可以丢，但收敛出来的决策不能丢。
## 5. 开机动作序列
clear 后新会话该做的第一组动作（有序）：
1. 读 <文件路径>（拿到 <信息>）
2. 跑 `<命令>` 验证 <状态>
3. 问用户 <具体问题> 后再动手
4. …
## 6. 明确不写的
主动丢弃了哪些内容，让用户最后检查一遍：
- <丢弃 1>（理由：探索过程，已收敛到 §4）
- <丢弃 2>（理由：与 git log / 当前代码重复）
- …
扫最近 ~20 轮对话，找最高频出现的具体名词（module 名 / change-id / 文件路径根）。例：用户在拆 residence 模块的 bootstrap change → topic = residence-next-steps 或 residence。
推不出（话题分散） → 一次性问用户："这次 handoff 的主题是什么？我建议 <topic-A> 或 <topic-B>"。
如果用户的初次触发已经带了指示（"重点记口径"/"把方案 B 的细节带上"），跳过；否则一句话问："有什么必须记 / 必须丢的吗？没有就按默认骨架走。"
git rev-parse --short HEAD + git branch --show-currentgit status --short（dirty 状态进 §2）git log 长输出——历史在 git 里，不要复制到 handoff按上面骨架逐段填。判断标准：
写到 <repo>/tmp/<topic>-handoff.md。tmp/ 不存在先建。
完成后告知用户三件事：
读 tmp/<topic>-handoff.md，按 §5 开机动作序列执行
不要在终端里把整个 md 内容贴出来——文件已经写进去了，贴一遍是噪音。
| 约束 | 说明 |
|---|---|
| 不是对话总结 | 探索过程主动丢；只留收敛后的状态、决策、动作 |
| 6 段固定不省略 | 没内容就写 _无_，结构稳定便于新会话按位置取信息 |
| 每条口径带「为什么」 | 没有原因的口径就是规则，规则在边界情况会被滥用 |
| §4 密度第一 | 口径太少（<5 条）多半是漏了，重新扫对话 |
| 不复制文件内容到 handoff | 只写路径，新会话自己读；handoff 是地图不是百科 |
| tmp/ 用户管 | 默认覆盖同名文件；不自动清理历史；不进 .gitignore（由项目自决） |
| 不依赖 eo-doc/ | 工作区级机制，任何项目能用，不读 .eo-project.json |
| 不替代 /compact 或 /eo-flow | 看「定位」表格，三者职责互不重叠 |
用户："我快 clear 了，存一下 residence 拆 change 的进度。"
Claude:
residence243ebcf on main，cleantmp/residence-handoff.md已写 tmp/residence-handoff.md（§4 关键口径 13 条）。
clear 后第一句话发：读 tmp/residence-handoff.md，按 §5 开机动作序列执行。
/compact：续命当前会话，保留全量；本 skill 是清空当前会话前的状态导出/eo-flow：跨 agent 任务派发；本 skill 是跨会话状态交接，不涉及第二个 agent/eo-project-update / /eo-project-lesson：项目级长期记录（roadmap / 经验），活在 eo-doc/ 或 vault；本 skill 是工作区临时快照，活在 tmp/