handoff

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（详见下方「收集纪律」）；这是严格模式的交接工作流，证据优先于回忆。

证据优先级从高到低（即收集顺序）：

1. 同会话历史：检查当前 chat 的同会话历史，包括更早轮次与 compact / summarized / pre-compaction 历史（如果当前环境可读）
2. 当前可见对话：检查当前可见对话
3. 当前 todo：检查当前 todo 状态（如果可用）
4. 只读 git：需要时用终端做只读仓库检查（git diff --stat HEAD~10..HEAD / git status --porcelain / rg / ls / pwd）
5. 直接读取必要文件：只读取足以确认关键事实的最少文件（计划、规格、测试输出、说明文档）；只有在项目级指令确实影响当前工作时，才读取它们

如果当前环境没有 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 或“第一个具体动作”。 不要改写被引用的用户请求或显式约束。