用途
Session Handoff 用于在当前作业告一段落时，生成一段可粘贴的交接留言，使新会话能够首先认识当前状态，再恢复工作。产出物是「下一个 agent 最先应阅读的最小上下文」，既不是完整工作日志，也不是立即执行指令。
何时使用
- 用户要求：关闭会话 / 建立引き継ぎ（交接）/ 生成传话 / 创建 handoff / resume later，即请求生成下一个会话用的消息。
- 长作业中途上下文变重，只想把下一会话所需的状态传过去。
- 需要留下未完成任务、作业中文件、验证状况、下次要执行的命令。
不适用场景
- 用户只是粘贴了一段类似 handoff 的正文，或想让当前 agent 执行以「次のセッションでは...」开头的作业指令。这属于消费/恢复指令，而不是创建 handoff。
- 仅需普通进度报告或完成报告的小请求。
- 保存持久化的运用规则（若需规则化，应考虑 instruction / skill / repo docs）。
- 将秘密信息、令牌、个人信息、已认证 URL 原样传给下一会话。
工作流要点
- 确认用户是要「创建交接便签」，而不是要当前 agent 消费已有交接式指令并立即继续；若有歧义，先做一句简短澄清。
- 确定目标与恢复对象。最多携带两个目标：最初请求时的原始目标，以及方向改变后的当前目标。两者都应从开启本会话的 handoff 继承，不得换成本次会话偶然所做的工作，因为这种替换正是交接链跑偏的原因。没有 handoff 时，从最初请求重建原始目标。定稿前用一句话与用户确认当前大目标，即便你有把握也要确认；若同时需要澄清，可并入第 1 步。在收到答复前不要输出 handoff；用户的更正优先。
- 只记录继续所需状态：涉及的文件、已运行的命令、验证结果、阻塞项、假设、待定决策。未发送的交付物（回复草稿、评论正文、邮件草稿）应写入文件，并在便签中引用相对路径；仅存在于聊天中的文本会因上下文压缩而丢失。
- 若仓库存在多于一个来源的未提交改动，要说明哪些脏路径属于你、哪些不应被 staged，否则下一会话可能提交他人未完成的编辑。
- 区分事实与猜测：不确定项标记为 未確認 或 仮説。
- 保留仍然重要的用户约束，包括措辞、范围限制、禁止动作。
- 若存在相关的直入式工作流，将其调用作为经明确批准后选定的首要候选；不要复述其阶段、生命周期、验收标准或运行契约，只纳入其不负责的恢复状态与需求。
- 使用 references/handoff-template.md 编写可粘贴的 handoff。
- 定稿前复核：移除秘密、私人账号标识、敏感 URL、不必要的个人绝对路径、重复日志、过期 TODO。
- 若用户要求橡皮鸭复核，或交接非平凡，按下方清单做第二遍复核。
恢复瘦交接
当粘贴的便签指向一份从未保存到文件的草稿时，文本可能仍在本地会话存储中。应查询它，而不是凭记忆重写草稿：
- 先读 schema（SELECT sql FROM sqlite_master），使用真实列名，猜测列名会浪费一次失败往返。
- 用便签中的原始会话 ID 过滤，再用有辨识度的短语收窄；返回整轮对话会淹没上下文。
- 把恢复内容当作起始草稿而非已批准文本；重用前须对照当前工作树重新核实每个声明。
橡皮鸭复核清单
- 第一行是否说明这是从另一会话粘贴来的交接便签，当前 agent 应先确认并概述状态、给出 A/B 选项，然后才行动？
- 新 agent 不读旧会话能否知道目标？
- 原始目标与当前目标是否都保留，并与本次会话目标分开陈述，而非被上一次会话的工作取代？
- A/B 候选与选定后的动作是否无歧义？
- 已完成、待定、阻塞、未知项是否分开？
- 文件路径尽可能为工作区相对路径？
- 验证结果是否写明命令名与结果？
- 秘密、凭据、无关转录细节是否已省略？
- 消息是否足够简洁，可作为新会话提示粘贴？
- 建议的会话名与模型是否以建议形式呈现，无法验证模型时写 unspecified？
- 下一会话能否定位根会话、其直接前驱，以及本便签描述的确切仓库版本？
输出规则
- 可粘贴的 handoff 本身放在一个围栏 markdown 块中，便于用户无需周围评论即可复制。
- 块首为自识别行：这是来自另一会话的交接便签，当前 agent 应先确认并概述状态，并给出 A/B 下一步动作选项。
- 不要指示下一 agent 立即开始工作；告知其在编辑文件、运行命令或操作外部服务前等待用户明确批准。
- 避免听起来像要求再创建一个 handoff 的措辞，例如仅以「次のセッションでは...」开头。
- 优先用项目符号而非叙述性历史。
- 仅在安全且可能被重跑时包含确切命令。
- 在顶部附近记录会话谱系、日期与仓库状态。没有它们，当摘要过薄时下一会话无法拉取原始日志，也无法判断所述状态属于哪个版本。标识符是日志键而非凭据，可安全携带；日志路径不是，须排除。
- 谱系构建方式：从开启本会话的 handoff 继承并追加当前标识符；根保存着后续摘要会丢失的原始请求。写作 root: <id> → … → this session: <id>，保留根加最近两条非根条目。不要记录省略号隐藏了多少条——继承来的计数无法重算，要求它会迫使下一会话猜测。
- 在顶部附近建议下一会话名称，便于用户一步重命名。已知时使用原始会话标题；标题可能缺失，即便会话元数据带有摘要，此时回退到由目标衍生的简短名称，而不是去寻找标题。
- 仅将末尾的 Re 或 Re<数字> 视为交接后缀。把 Re 替换为 Re2，对 Re<数字> 递增，否则追加 Re。将结果作为建议而非唯一标识符呈现。
- 建议一个在当前环境已验证的模型显示名，并附一行理由。标注为建议性：下一会话选择前会重新检查可用性。无法验证时写 unspecified。
- 不要仅凭会话历史推断模型可用性；某模型未出现只说明未被观察到，不等于被证明不可用。
- 最多包含一个 Next Candidates 节。
- 当涉及用户安全或外部系统时，在顶部附近包含禁止动作与停止条件。
- 以预期的停止条件或完成标准结束。
参考资料
- handoff-template.md：下一会话消息的可粘贴结构。
限制
具体模板字段规则、完整示例与更多细节暂未提供。