handoff

移交

将此对话整理成一份文档，让新的 Agent 可以从此处继续工作。将其写入操作系统临时目录（$TMPDIR；若不存在则使用 /tmp；Windows 上使用 %TEMP%），绝不要写入工作区——移交文档是会话临时文件，不是项目产物。将文件命名为 handoff-<topic>-<timestamp>.md，并告知用户其绝对路径。

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

内容

• 目标 — 用用户自己的表述说明这项工作的最终目的。
• 当前状态 — 已完成和进行中的工作、确切的分支／工作树，以及工作树是否有未提交改动。
• 已尝试并放弃 — 列出所有尝试过或考虑过但最终放弃的方法，并说明原因。本节能让接手者避免重走弯路，通常是最有价值的部分。
• 已知／未知（如有） — 最新已知项清单的路径，并用一句话概述其中明确了什么、仍有哪些未决事项，以及尚未解决的盲点；如果存在 .skills/*-knowns.md 或 .skills/*-scan.md 文件中的 Blindspot，请引用它们。
• 偏离项（如有） — .skills/implementation-notes.md 的路径，以及每条已记录偏离项的一句话摘要；接手者不应仅凭聊天记忆重新发现这些内容。
• 下一步操作 — 具体且有序，从紧接着要执行的命令或编辑开始。
• 建议使用的技能 — 指明接手者应调用本技能集中的哪些技能，以及在哪一步调用（例如“从任务 4 继续执行 execute-plan”“在宣告任务 3 完成前运行 verify”）。如果多任务分支已准备好让作者在合并前自行检查，请为用户提及 /comprehend-change；如果大型或影响架构的改动需要一份供团队评审者使用、放在 docs/explainers/ 下的说明和导览，请提及 /explain-change（由用户自行调用——不要自动调用其中任何一个）。
• 团队背景（如有） — 如果 docs/agents/project.md 中的 ## Team 有非空的 roster 或 band 覆盖设置，用一行说明 band 及打包方式；Small／Multi：如果 roster 或所有权说明中指定了此项工作的负责人，请说明由谁负责后续操作；如果未指定负责人，则省略负责人这一行。缺少 Team → 整节省略（不要臆造团队信息）。

规则

• 引用，不要重复。 规格、计划、ADR、问题单、提交、差异——请通过路径、URL 或哈希引用。复制其内容会让移交文档臃肿，并造成信息源分叉；磁盘上的产物才是权威信息源。
• 脱敏秘密信息。 API 密钥、令牌、密码、个人数据——用占位符替代，并说明实际值存放位置。此文档可能成为另一位 Agent 的提示词。
• 记录用户已做出的决定，并视为定论，同时说明其理由——接手者不得重新讨论这些决定或再次询问用户。

可选：启动接手者

仅当用户提出要求时：启动一个后台 Agent，将移交文档作为其提示词，并设置一个描述性显示名称，在当前工作目录中运行。承诺启动前，请确认你的执行环境提供了什么机制；如果没有，提供上述路径就是全部移交内容。

完成标准

以审慎的态度阅读完成后的文档：如果新的 Agent 只能看到此文档及其引用的产物，能否无需询问用户任何本次对话中已有答案的问题，就继续工作？如果还有任何问题，这些答案都应写入文档——补充后再结束。