Claude Skill

eo-handoff

在 /clear 之前生成最小可恢复快照到 tmp/eo/handoff/<topic>.md,让下一个会话载入这一个文件就能从当前节点继续。优先记录任务状态、关键口径、下一步分叉,主动丢弃探索过程。触发:handoff / 存一下进度 / 我要 clear / /eo-handoff。 NOT FOR: 机械压缩对话流(用内置 /compact)。

LLM Mart · 0 points · 6 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download simpleeve-eo-skills-eo-handoff-e6f1112.zip · 4 KB
Part of simpleeve/eo-skills — 16 skills

Install

skills CLI npx skills add https://github.com/SimpleEve/eo-skills/tree/main/eo-handoff
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install simpleeve-eo-skills@llmmart
Git git clone https://github.com/SimpleEve/eo-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole simpleeve/eo-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

eo-handoff — 跨会话状态交接

定位

clear 前的最后一步:把"下次会话要立刻接着干"所需的最少信息写到 <repo>/tmp/eo/handoff/<topic>.md。

和容易混淆的两个东西的边界:

名称 对端 性质
内置 /compact 同一会话续命 机械压缩对话流,保留所有信息
/eo-handoff clear 之后的下一个会话("未来的自己") 定向提取当前状态 + 决策口径,主动丢弃探索过程

核心区别:eo-handoff 不是总结,是"开机指令"。读者是新会话的自己,目标是 5 分钟内回到当前节点。

不依赖 .eo-project.json

tmp/eo/handoff/ 是工作区机制(eo 临时工件命名空间的一个域,见 ../eo-shared/conventions.md),任何 git 仓库都能用,不归 eo-doc/ 体系管。即使没跑过 /eo-project-init 也能用本 skill。

输入

  • topic 名:从最近上下文推断(最近聊的 module / change-id / 任务名)。推不出再问用户一次。
    • 文件名:tmp/eo/handoff/<topic>.md,<topic> 用 kebab-case
  • 可选口头加权:用户说"重点记 X / 别记 Y / 把这段对话原文带上" → 写入时按指示偏置
  • tmp/eo/handoff/ 目录:不存在则建。已存在的同名文件直接覆盖(默认行为;老的 handoff 已经过期没价值)。如果用户希望保留历史,自行加日期后缀。

文件骨架(6 段固定)

每段没有内容就写 _无_,不要省略段落——固定结构便于下一个会话按位置取信息。

# <topic> — 会话交接快照

> <YYYY-MM-DD HH:MM> 由 /eo-handoff 生成。
> 用途:`/clear` 后载入本文件即可从「<一句话节点描述>」继续。

## 1. 当前状态

- 在做什么、卡在哪个节点
- 关键产物路径 + status(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 / 当前代码重复)
- …

执行步骤

1. 推断 topic

扫最近 ~20 轮对话,找最高频出现的具体名词(module 名 / change-id / 文件路径根)。例:用户在拆 residence 模块的 bootstrap change → topic = residence-next-steps 或 residence。

推不出(话题分散) → 一次性问用户:"这次 handoff 的主题是什么?我建议 <topic-A> 或 <topic-B>"。

2. 询问加权(可选)

如果用户的初次触发已经带了指示("重点记口径"/"把方案 B 的细节带上"),跳过;否则一句话问:"有什么必须记 / 必须丢的吗?没有就按默认骨架走。"

3. 拉基线

  • git rev-parse --short HEAD + git branch --show-current
  • git status --short(dirty 状态进 §2)
  • 不跑 git log 长输出——历史在 git 里,不要复制到 handoff

4. 起草 6 段

按上面骨架逐段填。判断标准:

  • §1 当前状态:写到下一个会话能立刻回答"我现在在哪"。不写"我们之前讨论了 X、Y、Z"。
  • §2 基线:只写路径和状态,不复制文件内容(新会话自己去读)。
  • §3 下一步分叉:每个候选限 2-3 行说明,长篇论证压到 §4 关键口径里。
  • §4 关键口径:密度第一。每条一行结论 + 一行「为什么」。决策、不变量、硬约束、踩过的坑都进这里。
    • 密度判据见关键约束表「§4 密度第一」行——扫对话找"我们决定…"/"不能…"/"必须…"的点。
  • §5 开机动作:可执行的,有序。不写"先理解一下背景"这种虚的。
  • §6 明确不写的:列 3-5 条最大头的丢弃项,让用户能一眼看出有没有漏。

5. 落盘 + 提示

写到 <repo>/tmp/eo/handoff/<topic>.md。tmp/ 不存在先建。

完成后告知用户三件事:

  1. 文件路径
  2. 关键口径条数(密度自检)
  3. clear 后的开机指令模板,例如:
    读 tmp/eo/handoff/<topic>.md,按 §5 开机动作序列执行
    

不要在终端里把整个 md 内容贴出来——文件已经写进去了,贴一遍是噪音。

关键约束

约束 说明
不是对话总结 探索过程主动丢;只留收敛后的状态、决策、动作
6 段固定不省略 没内容就写 _无_,结构稳定便于新会话按位置取信息
每条口径带「为什么」 没有原因的口径就是规则,规则在边界情况会被滥用
§4 密度第一 口径太少(<5 条)多半是漏了,重新扫对话
不复制文件内容到 handoff 只写路径,新会话自己读;handoff 是地图不是百科
tmp/eo/ 用户管 默认覆盖同名文件;不自动清理历史;tmp/eo/ 由 /eo-project-init 写入 .gitignore(未跑过 init 的仓库由项目自决)
不依赖 eo-doc/ 工作区级机制,任何项目能用,不读 .eo-project.json
不替代 /compact 看「定位」表格,职责互不重叠

示例(最小完整版)

用户:"我快 clear 了,存一下 residence 拆 change 的进度。"

Claude:

  1. 推断 topic = residence
  2. 不问加权(用户没给特殊指示)
  3. 拉 HEAD = 243ebcf on main,clean
  4. 起草 6 段,§4 收敛 13 条口径(候补池存储 / 合批硬约束 / IsActive 过滤 / Proto 锁死方案 …)
  5. 写到 tmp/eo/handoff/residence.md
  6. 告知用户:
    已写 tmp/eo/handoff/residence.md(§4 关键口径 13 条)。
    clear 后第一句话发:读 tmp/eo/handoff/residence.md,按 §5 开机动作序列执行。
    

与其它 skill 的关系

  • 内置 /compact:续命当前会话,保留全量;本 skill 是清空当前会话前的状态导出
  • /eo-project-record:项目级长期记录(决策 / 经验),活在 <project_root>/;本 skill 是工作区临时快照,活在 tmp/eo/
  • 任何 eo-* 流程节点(brainstorming/change/implement/test/review/archive)都可以在中途调用本 skill 做 clear 前快照
Files (eo-skills)
  • SKILL.md 7.5 KB
    ---
    name: eo-handoff
    description: |
      在 /clear 之前生成最小可恢复快照到 tmp/eo/handoff/<topic>.md,让下一个会话载入这一个文件就能从当前节点继续。优先记录任务状态、关键口径、下一步分叉,主动丢弃探索过程。触发:handoff / 存一下进度 / 我要 clear / /eo-handoff。
      NOT FOR: 机械压缩对话流(用内置 /compact)。
    ---
    
    # eo-handoff — 跨会话状态交接
    
    ## 定位
    
    **clear 前的最后一步**:把"下次会话要立刻接着干"所需的最少信息写到 `<repo>/tmp/eo/handoff/<topic>.md`。
    
    和容易混淆的两个东西的边界:
    
    | 名称 | 对端 | 性质 |
    |------|------|------|
    | 内置 `/compact` | 同一会话续命 | 机械压缩对话流,保留所有信息 |
    | **`/eo-handoff`** | **clear 之后的下一个会话("未来的自己")** | **定向提取当前状态 + 决策口径,主动丢弃探索过程** |
    
    核心区别:eo-handoff **不是总结**,是"开机指令"。读者是新会话的自己,目标是 5 分钟内回到当前节点。
    
    ## 不依赖 .eo-project.json
    
    `tmp/eo/handoff/` 是工作区机制(eo 临时工件命名空间的一个域,见 [../eo-shared/conventions.md](../eo-shared/conventions.md)),任何 git 仓库都能用,不归 `eo-doc/` 体系管。即使没跑过 `/eo-project-init` 也能用本 skill。
    
    ## 输入
    
    - **topic 名**:从最近上下文推断(最近聊的 module / change-id / 任务名)。推不出再问用户一次。
      - 文件名:`tmp/eo/handoff/<topic>.md`,`<topic>` 用 kebab-case
    - **可选口头加权**:用户说"重点记 X / 别记 Y / 把这段对话原文带上" → 写入时按指示偏置
    - **tmp/eo/handoff/ 目录**:不存在则建。**已存在的同名文件直接覆盖**(默认行为;老的 handoff 已经过期没价值)。如果用户希望保留历史,自行加日期后缀。
    
    ## 文件骨架(6 段固定)
    
    每段没有内容就写 `_无_`,**不要省略段落**——固定结构便于下一个会话按位置取信息。
    
    ```markdown
    # <topic> — 会话交接快照
    
    > <YYYY-MM-DD HH:MM> 由 /eo-handoff 生成。
    > 用途:`/clear` 后载入本文件即可从「<一句话节点描述>」继续。
    
    ## 1. 当前状态
    
    - 在做什么、卡在哪个节点
    - 关键产物路径 + status(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 / 当前代码重复)
    - …
    ```
    
    ## 执行步骤
    
    ### 1. 推断 topic
    
    扫最近 ~20 轮对话,找最高频出现的具体名词(module 名 / change-id / 文件路径根)。例:用户在拆 `residence` 模块的 bootstrap change → `topic = residence-next-steps` 或 `residence`。
    
    推不出(话题分散) → 一次性问用户:"这次 handoff 的主题是什么?我建议 `<topic-A>` 或 `<topic-B>`"。
    
    ### 2. 询问加权(可选)
    
    如果用户的初次触发已经带了指示("重点记口径"/"把方案 B 的细节带上"),跳过;否则一句话问:"有什么必须记 / 必须丢的吗?没有就按默认骨架走。"
    
    ### 3. 拉基线
    
    - `git rev-parse --short HEAD` + `git branch --show-current`
    - `git status --short`(dirty 状态进 §2)
    - 不跑 `git log` 长输出——历史在 git 里,不要复制到 handoff
    
    ### 4. 起草 6 段
    
    按上面骨架逐段填。判断标准:
    
    - **§1 当前状态**:写到下一个会话能立刻回答"我现在在哪"。不写"我们之前讨论了 X、Y、Z"。
    - **§2 基线**:只写**路径**和**状态**,不复制文件内容(新会话自己去读)。
    - **§3 下一步分叉**:每个候选限 2-3 行说明,长篇论证压到 §4 关键口径里。
    - **§4 关键口径**:**密度第一**。每条一行结论 + 一行「为什么」。决策、不变量、硬约束、踩过的坑都进这里。
      - 密度判据见关键约束表「§4 密度第一」行——扫对话找"我们决定…"/"不能…"/"必须…"的点。
    - **§5 开机动作**:可执行的,有序。不写"先理解一下背景"这种虚的。
    - **§6 明确不写的**:列 3-5 条最大头的丢弃项,让用户能一眼看出有没有漏。
    
    ### 5. 落盘 + 提示
    
    写到 `<repo>/tmp/eo/handoff/<topic>.md`。`tmp/` 不存在先建。
    
    完成后告知用户**三件事**:
    1. 文件路径
    2. 关键口径条数(密度自检)
    3. clear 后的开机指令模板,例如:
       ```
       读 tmp/eo/handoff/<topic>.md,按 §5 开机动作序列执行
       ```
    
    不要在终端里把整个 md 内容贴出来——文件已经写进去了,贴一遍是噪音。
    
    ## 关键约束
    
    | 约束 | 说明 |
    |------|------|
    | 不是对话总结 | 探索过程主动丢;只留收敛后的状态、决策、动作 |
    | 6 段固定不省略 | 没内容就写 `_无_`,结构稳定便于新会话按位置取信息 |
    | 每条口径带「为什么」 | 没有原因的口径就是规则,规则在边界情况会被滥用 |
    | §4 密度第一 | 口径太少(<5 条)多半是漏了,重新扫对话 |
    | 不复制文件内容到 handoff | 只写路径,新会话自己读;handoff 是地图不是百科 |
    | tmp/eo/ 用户管 | 默认覆盖同名文件;不自动清理历史;`tmp/eo/` 由 /eo-project-init 写入 .gitignore(未跑过 init 的仓库由项目自决) |
    | 不依赖 eo-doc/ | 工作区级机制,任何项目能用,不读 .eo-project.json |
    | 不替代 /compact | 看「定位」表格,职责互不重叠 |
    
    ## 示例(最小完整版)
    
    用户:"我快 clear 了,存一下 residence 拆 change 的进度。"
    
    Claude:
    1. 推断 topic = `residence`
    2. 不问加权(用户没给特殊指示)
    3. 拉 HEAD = `243ebcf` on `main`,clean
    4. 起草 6 段,§4 收敛 13 条口径(候补池存储 / 合批硬约束 / IsActive 过滤 / Proto 锁死方案 …)
    5. 写到 `tmp/eo/handoff/residence.md`
    6. 告知用户:
       ```
       已写 tmp/eo/handoff/residence.md(§4 关键口径 13 条)。
       clear 后第一句话发:读 tmp/eo/handoff/residence.md,按 §5 开机动作序列执行。
       ```
    
    ## 与其它 skill 的关系
    
    - 内置 `/compact`:续命当前会话,保留全量;本 skill 是清空当前会话前的状态导出
    - `/eo-project-record`:项目级长期记录(决策 / 经验),活在 `<project_root>/`;本 skill 是工作区临时快照,活在 `tmp/eo/`
    - 任何 eo-* 流程节点(brainstorming/change/implement/test/review/archive)都可以在中途调用本 skill 做 clear 前快照
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related