Skill first：skills/writing/handoff。
长会话最危险的地方，不是上下文变长。
危险在于交接时大家以为“总结一下”就够了。总结给人看，handoff 给下一位 agent 执行。这两件事完全不同。
所以我把 handoff 做成一个固定 skill。它只做一件事：把当前任务、已确认事实、未完成事项、风险和最值得立刻做的下一步，写进一个 dated markdown 文件。路径默认是 ./handoff/YYMMDD-handoff.md。
这不是漂亮话。
这是协作接口。
接力路径
1. 先把长会话里的状态压成可验证事实。
2. 再写入 handoff/YYMMDD-handoff.md。
3. 最后给下一位 agent 一个最具体的第一步。
第一步：路径要稳定
一个交接文件如果每次都放在不同地方，它就不是交接文件。它只是又一个附件。
handoff 的默认路径是 ./handoff/YYMMDD-handoff.md。如果用户给了自定义路径，就用自定义路径，并创建父目录。dated 文件已经存在时，默认替换，而不是追加。
这个选择很小，但很硬。下一位 agent 不应该猜“上一轮到底写到哪里了”。
第二步：先重建状态，再动笔
handoff 最容易写坏的方式，是一边回忆一边润色。这样会把确定事实、合理推断和未验证假设揉在一起。
这个 skill 强制先重建状态：当前 thread、repo state、修改过的文件、最近跑过的检查、产出的 artifact。关键路径、命令、模块名和决策点要先验证，再写进文档。
- Confirmed facts：精确文件、命令、输出、页面、接口结果。
- Reasonable inferences：为什么这件事大概率成立。
- Unresolved assumptions：下一位 agent 必须先确认什么。
事实是事实。推断是推断。假设是债务。
第三步：写给下一位 agent，不是写给用户
这条规则是整个 skill 的中心。
用户更新可以温柔，可以概括，可以把噪音折叠掉。handoff 不行。handoff 要保留下一位 agent 接手所需的操作性细节：文件路径、命令、API、route、class、module、table、env var、已知死路、风险和建议第一步。
它不需要漂亮。它需要可继续。
第四步：七段结构就是协议
我不想让每次交接都重新发明格式，所以 handoff 固定了七个编号 section：
1. 当前任务目标
2. 当前进展
3. 关键上下文
4. 关键发现
5. 未完成事项
6. 建议接手路径
7. 风险与注意事项
最后还必须有一句 下一位 Agent 的第一步建议。这句话很重要。它把“你可以继续看看”变成“第一步先做这个”。
第五步：验证不是形式主义
这个 skill 的最后一步要求确认四件事：文件存在、七个 numbered sections 都在、最后的第一步建议存在、整篇读起来像内部 baton pass 而不是用户更新。
这看起来像格式检查。其实是在防止一种更隐蔽的失败：文档写了，但下一位 agent 仍然不知道怎么开始。
能接上，才算写完。
这次发布的真实边界
这次我把本地 /Users/minxian/.codex/skills/handoff/SKILL.md 放进 GitHub-backed skill repo 的 skills/writing/handoff/SKILL.md，并补了 repo 需要的 metadata、常见坑表和 verification checklist。
这里有一个边界要说清楚：skill 是主 artifact，blog 是解释层。以后真正复用时，不应该回来看这篇文章照着猜，而应该直接用 GitHub 上的 skill。
文章负责讲为什么。skill 负责让下一次少踩坑。
如果你在长任务结束时只想做一件事，就做 handoff。不要等上下文已经糊成一团才开始抢救。
Skill 源码：https://github.com/XJM034/SKILL/tree/main/skills/writing/handoff