session-handoff

会话交接

为新会话创建一份简洁、客观的续接材料。优先确保工作能正确续接，而不是记录所有发生过的事。

先核验证据

1. 确认用户想要续接的项目。如果是代码仓库，请检查当前分支、HEAD、git status --short --branch 以及相关变更路径。不要根据工作区干净或 Agent 的描述推断任务已完成。
2. 阅读权威任务材料和当前对话上下文。区分：
   • 通过命令或文件核实的状态；
   • 用户明确提出的决定和约束；
   • 已报告但未独立核实的工作；
   • 尚未解决的问题、失败项和同根残留问题。
3. 只有在能获取到精确命令和结果时，才记录测试证据。某项针对性测试通过，不代表完整测试套件通过。计划中、已开始或声称完成的工作，不算已完成。
4. 只有当下一会话无法从仓库文件或历史记录中轻易恢复时，才纳入仅存在于对话中的事实。省略已结束的旁支、叙述，以及不会影响下一步的背景信息。

工作区有未提交改动可以证明代码阶段，但工作区干净无法证明设计阶段。应结合任务上下文和当前实际材料判断状态属于设计、代码还是混合阶段。

可执行状态检查

如果没有正在进行的目标、待定决定、阻碍、待办事项或无法恢复的上下文，则不要创建 .handoff/ 或交接文件。请说明没有可交接的待执行事项；如果用户丢失了上下文，请让其在原会话中调用此技能。

编写交接材料

存在可执行状态时，在目标项目内创建且只创建一个文件：.handoff/YYYY-MM-DD-HHMM-session.md。仅使用确实有助于续接的章节：

# Resume

## Current state
- Goal: ...
- Working directory: ...
- Branch / HEAD: ...
- Worktree: ...

## Verified completed
- ...

## In progress and residuals
- ...

## Next action
- ...

## Decisions and constraints
- Selected: ... / Rejected: ... / Because: ...

## Verification
- `<exact command>` — PASS | FAIL | NOT RUN; scope: ...

## Relevant files
- `path` — why it matters

规则：

• 省略空章节。不要写 None 或 N/A。
• 对于纯设计交接，应核实仓库状态，但省略工作目录、分支、HEAD、工作区、变更文件清单、相关文件列表，以及仅说明仓库存在或尚未开始实现的内容。只有当代码材料或 Git 事实会直接限制下一项设计决策时，才将其纳入。
• 如果路径明确，只写一个确切的下一步行动。只有在确实存在尚未解决的决定、导致多个有效路径时，才列出备选方案；不要提供泛泛的选项菜单，也不要再次要求用户选择。
• 保留明确说明的理由。如果未记录决定的理由，请写 未记录理由——依赖此决定前请先核实；不要臆造理由。
• 明确标注未经核实的说法和不完整的证据。
• 文件列表只保留会影响续接的路径。不要倾倒完整差异内容。
• 创建交接材料时，不要提交、推送、修改产品代码或改变任务状态。

写入后，报告交接文件的绝对路径，并用一句话说明记录的下一步行动。