Handoff
通过将工作会话的进度写入磁盘上的一个文件，后续会话读取该文件以精确恢复之前的工作状态。此技能替代 /compact 使用，绝不同时混用。
为什么不用 /compact
/compact 为了写入摘要会重新读取整个对话，然后替换整个历史记录为该摘要。结果，前缀发生变化，已构建的缓存失效，之后每一轮都重新在该摘要（约四十轮）之上重建缓存。这种做法并不节省成本，而是购买了连续性，却付出了高昂代价。
而 Handoff 文件在三个方面恰好相反：
- 成本更低。 文件本身只有几百个 token 的写入和读取，新会话从一个干净的小前缀开始。
- 由用户选择保留什么。
/compact自行决定，通常会抛弃最有价值的东西——即那些已被证明无效的尝试路径。没有任何自动摘要能保留它们。 - 持久保存在磁盘上。 同一个工作的第三次会话能知道第一次和第二次做了什么。而 compact 在其会话内生灭、无法传递。
操作步骤
1. 自己重建，不要问你能看得到的信息。 哪些文件被修改过、尝试过什么、哪些失败及原因、做出了哪些决策、停在了哪里——这些都在对话中。对于 Git 仓库，可补充 git status --short 和 git log --oneline -5。
2. 只问两个你无法推断的空白点。 它们是：目标（正在构建什么以及为什么，而非今天做了什么）和下一步期望（不总是显而易见的下一步）。如果缺失，一次性提问，并在问题中附带你的假设，这样用户只需回答“是”。其余所有都不需要问：如果某个部分为空，直接写 无 并继续，不要捏造不存在的已解决问题。
3. 决定文件存放位置。 在代码仓库中：docs/handoff/{YYYY-MM-DD}-{slug}.md。在笔记库或文件夹中（例如本项目 il-tuo-os）：一个 handoffs/ 文件夹，位于工作所属的项目内。{slug} 是关于工作的两三个词，而非日期。如果已存在相同 slug 的 handoff 文件，不要覆盖：新文件增加一个 seq 字段，并将前一个文件标记为 prev，从而形成可回溯的链式结构。
4. 写入文件，包含以下 Frontmatter——type: handoff, date, status, seq, prev, tags——以及以下固定顺序的章节：
- 目标：正在构建什么以及为什么，两到三行，包含原因。
- 当前状态：当前真实状态。哪些功能正常、哪些进行中、哪些未开始。
- 已尝试但失败的方法：文件中最重要的部分。每条被放弃的路径及原因。防止后续会话重新尝试。
- 遇到的问题及解决方法：仅列出会重现的问题。症状、原因、修复。
- 已做的决策：选了什么以及舍弃了什么，并附上一行原因。没有附上被舍弃替代方案的决策，一周后会被重新质疑。
- 涉及的文件：文件路径，并附一行关于每个文件所做变更的说明。
- 下一步方向：下一步的指令式描述。如果已清晰，也可包含再下一步。
- 动手前需知：陷阱、需以特定方式运行的命令、看似损坏实则正常的情况。如果没有，写
无。
5. 关闭会话时，在聊天中打印恢复命令：读取 {路径} 并从“下一步方向”处恢复。 另加一行说明此时可以执行 /clear，恢复仅需读取该文件。
何时不使用
一个一直使用的技能是随意使用的技能。
- 任务切换无连续性 →
/clear，无需 handoff。 - 最后几轮走错了方向 →
/rewind，回到缓存已知的某个点。 - 很快恢复且中间无更新 →
/rename加/resume。 - 工作持续到另一天或另一周 → 使用此 skill。
此 skill 不会代替用户执行 /clear：它仅进行建议。