用途 会话结束通常有三种原因：上下文填满、人离开、工作转交他人。三者都会丢失同一样东西——从未写入文件的推理过程。该技能的核心作用就是在这些推理消失前把它写下来。
主要能力
- 写文件而非聊天摘要：聊天会滚动消失，而文件能经受 /clear、崩溃，以及明天另一个人打开仓库等情况。
- 默认路径与追加策略：默认写入仓库根目录的 HANDOFF.md；若仓库已有 docs 约定，则写入 docs/handoff/<yyyy-mm-dd>-<topic>.md。若交接文件已存在，追加新的带日期章节，而不是覆盖——尝试过的历史本身具有一半价值。
- 按固定顺序组织内容：Goal（用用户自己的话一句话说明目标）、State（已完成、半完成、未开始，半完成要具体）、Files touched（路径加一行说明改了什么和为什么，包括读过但决定不改的文件）、Decisions and why（合理的人会质疑的选择：选了什么、拒了什么、原因）、Dead ends（试过但没成功的，指出失败模式）、Next step（一个具体到可立即动手的下一步）、Open questions（等待人的问题，指明是谁）。真正为空的章节可跳过。
使用方式 收集信息时优先依据证据而非记忆：用 git status 和 git diff --stat 查看磁盘上实际改动，用 git log --oneline -15 查看已落地提交，参考最近一次测试/构建输出，目标用用户原话引用而非改写成公司语言。若对话记录与仓库不一致，以仓库为准，并在交接中说明。
规则 不做状态汇报式填充，不写“我们取得了很大进展”；交接是现场笔记，不是利益相关者更新。包含回到工作状态的命令：开发服务器命令、测试命令、需要设置的环境变量。绝不声称自己没亲眼看到能工作的东西可用，要在旁边写“untested”。若工作在分支上，写明分支名及其分叉基点。未提交改动需在顶部明确说明并列出，这是工作丢失最常见的方式。
输出格式 按给定模板输出：标题含主题和日期，随后是 Goal、Branch（含 base 与 Uncommitted 状态）、State（Done / In progress / Not started）、Files、Decisions、Dead ends、Next step、Open questions，以及“Getting back to work”代码块中的命令。
适用场景 工作会话结束、上下文窗口接近占满、需要把工作交给队友或新会话、用户说“hand this off”等情形。
限制与特别说明 若因上下文快满而写交接，应先写文件再做其他任何工作，然后告知用户开启新会话并打开该文件；不要试图再塞进一个修复——被截断的交接比提前写的更糟。资料未提供其他平台、收费或效果信息。