write-handoff

交接

将这段对话整理成一份文档，供新的 Agent 接手工作。将文档写入操作系统临时目录（$TMPDIR；若不可用则使用 /tmp；Windows 使用 %TEMP%），绝不要写入工作区——交接文件属于会话临时产物，不是项目文件。将其命名为 handoff-<topic>-<timestamp>.md，并告知用户绝对路径。

如果用户向此技能传入了参数，则将其视为下一次会话的关注重点，并围绕该重点组织整份文档——删除与该重点无关的内容。

内容

• 目标——用用户自己的说法说明这项工作的最终目的。
• 当前状态——已完成的内容、正在进行的工作、准确的分支/工作树，以及工作树是否有未提交改动。
• 尝试过但已放弃的方案——列出所有尝试过或考虑过但最终放弃的方法，并说明原因。本节可避免接手者重走弯路，通常最有价值。
• 已知 / 未知（如有）——最新已知事项清单的路径，以及一句话总结：其中确定了哪些内容、留下了哪些待解问题、仍有哪些盲点未解决；若存在 .skills/*-knowns.md 或 .skills/*-scan.md Blindspot 文件，请指向它们。
• 偏离项（如有）——指向 .skills/<CODE>/implementation-notes.md；用一句话总结每条已记录的偏离项，并注明 Map impact 不为 none 的条目数（如果为零，则注明零项）。接手者不得依靠聊天记忆重新发现这些偏离项。
• 后续操作——按顺序列出具体步骤，从接下来要执行的命令或编辑开始。
• 建议使用的技能——说明接手者应使用本套技能中的哪些技能，以及在哪一步使用（例如“从任务 4 继续执行 build-in-waves”“在宣布任务 3 完成之前运行 prove-claim”）。当包含多个任务的分支已准备好由作者在合并前自行检查时，告知用户使用 /understand <range>（不要自行运行）。
• 团队背景（如有）——如果 docs/agents/project.md 中的 ## Team 下存在非空的 roster 或 band 覆盖，则用一句话说明 band 及其打包规则；Small/Multi：如果 roster 或所有权说明中指定了本项工作的负责人，则注明谁负责后续操作；如果未指定负责人，则省略负责人信息。缺少 Team → 省略整个章节（不要凭空编造团队信息）。

规则

• 只引用，不复述。 规格说明、计划、ADR、议题、提交记录、差异——通过路径、URL 或哈希引用。复制其中内容会使交接文档臃肿，并造成信息源分叉；磁盘上的文档才是权威版本。
• 隐去机密信息。 API 密钥、令牌、密码、个人数据——替换为说明真实值存放位置的占位符。该文档可能会成为另一个 Agent 的提示词。
• 将用户已作出的决定记录为定论，并写明理由——接手者不得重新讨论这些决定，也不得再次询问用户。

可选：启动接手者

仅当用户提出要求时：以交接文档为提示词，在当前工作目录中启动一个后台 Agent，并为其设置清晰的显示名称。承诺此操作之前，请先确认你的运行环境提供了何种机制；如果没有，已告知用户的路径就是完整交接内容。

完成标准

以审慎的态度通读最终文档：一个新的 Agent 仅凭此文件及其引用的材料，能否在不向用户重复询问本次对话中已有答案的情况下继续工作？如果仍有任何问题，答案就应写入文档——补充后再完成。