| name | handoff |
| description | 为新的 chat / 新会话生成面向下一会话目标的 handoff / continuation context。仅在用户明确要把当前工作交接到新 chat 继续时触发；不要用于普通总结、状态同步、代码评审、changelog 或文章摘要。基于只读证据输出可直接粘贴到新 chat 的中文优先接续上下文。 |
| argument-hint | 请说明要交接到新建会话的目标、要求或关注点；可留空 |
Handoff Skill
这个 skill 用于为新的 chat / 新会话生成自包含、基于证据、上下文损失尽可能小的交接摘要。产出的交接块可直接粘贴到下一个 chat，在 GitHub Copilot Chat、Claude Code、Cursor 等 agent runtime 中通用。
固定骨架标题和续接说明默认中英双语；正文、空值占位和动作说明默认中文优先，除非用户明确要求纯英文或双语正文。
何时使用
在以下场景使用这个 skill：
- 用户明确要求生成 handoff、交接总结、continuation summary，或明确要“新开 chat 接着做”
- 用户明确要求把当前工作、当前对话或当前实现状态整理成可直接带到新 chat 的接续上下文
- 当前 chat 已经很长、被 compact 或上下文质量下降，且用户明确仍要把当前工作续接到新 chat
默认按显式交接意图触发——仅因 chat 很长、质量下降或上下文窗口接近上限，不足以单独路由到这里。
不要路由到 handoff
以下请求默认不要路由到这个 skill：
- 普通总结、recap、状态同步，或“你刚刚做了什么”“现在进展怎样”这类回顾请求
- 代码评审、缺陷分析、方案比较、问题排查、实现建议
- PR、commit、release 摘要或 changelog 生成
- 文章摘要、网页总结、会议纪要、读后总结
- 仅讨论 handoff skill、prompt、workflow 或协议本身，而不是要生成真实交接摘要
- 用户只是希望继续在当前 chat 中做事，而不是切到新 chat
硬约束
- 在收集证据阶段保持只读
- 直接证据优先于回忆
- 对
用户请求（保留原话） / USER REQUESTS (AS-IS) 和 显式约束 / EXPLICIT CONSTRAINTS 先按 materiality 过滤，再 verbatim 复制保留下来的项；如果过滤后为空，写 无；已过期、对继续工作不再重要的引用内容要省略
- 如果某个证据源不可用，要明确写出，并使用
未知 或 无，而不是猜测
- 不要包含 secrets、credentials 或 tokens
🔴 PHASE 0: 验证请求（开工前必过的关卡）
开始前先确认（任一项不满足就停下，不要进入收集阶段）：
- 当前 chat 中确实有值得保留的工作或上下文
- 用户现在就是要交接摘要，而不是只是在讨论 handoff 这件事
- 用户要的是给新 chat 使用的 continuation context，而不是普通总结或状态同步
- 如果用户额外说明了下一个 chat 的目标、用途或焦点，把它视为首要筛选条件，只保留对该目标真正有帮助的上下文
🛑 早退：如果当前 chat 几乎没有内容，或者没有任何有价值的上下文要保留，就直接说明没有实质内容可交接，不要强行产出模板。
🛑 遇到近邻场景（普通总结 / recap / 代码评审 / changelog 等）时，按上文“不要路由到 handoff”处理，不要进入 handoff 流程。
PHASE 1: 收集程序化上下文
严格只读收集（三义）：证据优先——只用本会话/chat 内直接证据（同会话历史 / 可见对话 / todo / git / 文件），缺证据标 未知/无，不从跨会话 memory 工具（CLAUDE.md / auto-memory 类外部持久化）补造缺失事实；只读——仅只读动作，不写文件、不改 git、不跑 install/build/test（详见下方「收集纪律」）；这是严格模式的交接工作流，证据优先于回忆。
证据优先级从高到低（即收集顺序）：
- 同会话历史：检查当前 chat 的同会话历史，包括更早轮次与 compact / summarized / pre-compaction 历史（如果当前环境可读）
- 当前可见对话：检查当前可见对话
- 当前 todo：检查当前 todo 状态（如果可用）
- 只读 git：需要时用终端做只读仓库检查（
git diff --stat HEAD~10..HEAD / git status --porcelain / rg / ls / pwd）
- 直接读取必要文件：只读取足以确认关键事实的最少文件（计划、规格、测试输出、说明文档）；只有在项目级指令确实影响当前工作时，才读取它们
如果当前环境没有 same-session history 或 todo 工具，就从当前可见对话开始，并明确记录缺失的证据源。
只有当 git 或文件检查能实质提升交接质量时，才去做这些检查。
收集完证据后，需要回答这些问题：
- 用户原话到底要求了什么
- 已经完成了什么工作
- 还有什么没有完成
- 做过哪些决策
- 哪些文件被修改、检查过，或已确认对续接重要
- 建立了哪些约束、偏好或模式
- 还剩下哪些阻塞、注意事项或未决问题
证据冲突处理规则：
- 如果 chat 已经被 compact，优先信任同会话历史，而不是当前可见对话
- 对于文件事实，优先信任直接文件读取，而不是对话回忆
- 对于文件修改事实，优先信任 git 状态，而不是 memory
- 优先信任用户显式指令，而不是推断出来的偏好
- 如果两个来源冲突且无法解决，不要默默选一个，要把不确定性记录下来
收集纪律：
- 不跑 install、build、format 或 test 来“丰富” handoff——这是针对中模型“跑个测试更彻底”冲动的 hard guardrail（入口「只读」总纲的具体解码守卫，非同义重复）
- 区分 verified facts / inferred context / unknowns：弱推断不包装成强结论，合理但无证据的细节标
未知 或省略
证据收集完成判据：上方 5 源已按可用性逐一检查（不可用的已记 未知/无）；下方提炼问题都能基于证据回答；全程未做写操作。
PHASE 2: 提炼上下文
优先用第一人称视角写交接摘要，例如：
- 我要求...
- 我修改了...
- 我决定...
- 我发现...
如果新 chat 可能误判行为主体，就不要写模糊的“我……”，而要显式写成“用户……”、“智能体……”或“我们……”。
提炼时聚焦这些点：
- 聚焦能力、行为和决策，不要陷入琐碎的逐文件细节
- 只保留对续接真正重要的内容
- 除非关键，否则避免低层实现细节
- 保留用户原话请求和显式约束
- 清楚地区分 verified facts、inferred context 和 unknowns
提炼硬规则：
- 用户请求与显式约束按『硬约束』的 materiality 规则处理（过滤后 verbatim 复制；过滤后为空写
无；过期省略见『硬约束』）；不拼成一句概括、不改写保留下来的原话（此处 inline 守卫）
- 如果关键信息已经稳定存在于 PRD、计划、ADR、issue、commit、diff 或其他工件中，不要在 handoff 中重复展开；只引用其路径或 URL，并说明它为何与续接相关
- 不要杜撰约束、请求、决策、文件职责或测试结果
- 只有在路径会影响续接时才写文件路径
- 如果某个细节看起来合理但没有证据，要么省略，要么标成
未知
提炼时重点考虑这些问题：
- 事实层（用户让 agent 做什么、已完成什么、还剩什么、动过哪些文件、做过哪些决策）直接复用 PHASE 1 已回答的结果，不重复列举
- 哪些决策、取舍和约束必须被带到下一个 chat
- materiality 二次复核：重新审视已引用的用户请求或约束，对继续工作是否仍然真正重要；不再重要的弱化或省略（初次过滤见『硬约束』，这是提炼点的二次复核）
- 下一个 chat 的第一步应该做什么
- 下一个 chat 最便宜、最具体的下一步动作是什么
- 还存在哪些风险、坑点或未知项
提炼完成判据：verified facts / inferred context / unknowns 已区分；用户原话 verbatim 保留（未拼概括、未改写）；无关内容已省略。
PHASE 3: 格式化输出
严格使用 references/handoff-output-template.md 中的固定结构、预算、格式规则和续接说明块。
先做 materiality 三次筛选——按下一个 chat 的目标再筛一次，再填充模板；已有工件已稳定承载的信息只引用，不重复展开。
把从 交接上下文 / HANDOFF CONTEXT 到 正文结束 / END OF HANDOFF CONTEXT 的正文整体放进单个外层代码块中，让聊天界面尽量以可复制文本框展示；说明区放在代码块外。
不要新增模板之外的章节，除非用户明确要求。
格式化完成判据（自检 yes/no）：空段已写 无；未新增模板外章节；单外层代码块 + 说明区在外（复检上方规则已立）。
重要约束
- 不要尝试以编程方式创建新 chat
- 要提供一份不依赖当前 chat 也能使用的自包含摘要
- 要让 handoff 能直接作为新 chat 的第一条消息粘贴使用
立即执行
按上述顺序收集程序化上下文，然后生成 handoff 摘要。
如果用户在调用这个 skill 时额外给了补充要求，优先把它当作下一个 chat 的工作焦点；它只能用来收紧 目标 / GOAL、待办事项 / PENDING TASKS、建议技能 / SUGGESTED SKILLS 或“第一个具体动作”。
不要改写被引用的用户请求或显式约束。
