Handoff
目标：下一个代理，即使没有任何关于本次对话的记忆，也能直接继续工作，无需向任何人提问，也无需重新推导任何内容。
在开始时
- 完整阅读
docs/HANDOFF.md，然后阅读docs/handoff/LOG.md最新的 3 条记录。 - 用实际仓库状态验证它：
git status、git log --oneline -10、git branch -a，以及打开中的 PR（gh api repos/al0olo/agents-village/pulls --jq '.[].title'）。 - 如果交接文档与实际状态不一致，以实际为准，然后在开始新工作前先修复交接文档，并在日志中说明。
- 用一两句话向用户说明下一步操作，然后执行它。
在工作期间
当以下任何情况发生时，立即更新 docs/HANDOFF.md：一个工作单元完成、做出一个决策、一种方法失败、发现环境特性、打开或合并了一个 PR。
在结束时（或被中断时）
- 使用下方的模板重写
docs/HANDOFF.md。它是当前状态，不是历史记录： 替换过时的行，不要堆叠。 - 在
docs/handoff/LOG.md最前面插入一条带日期的记录（最新的在最前）：你做了什么、为什么、什么失败了、相关链接。历史记录放在那里。 - 运行
scripts/check-handoff.sh，并将交接文档与工作一起提交。 - 给用户的最后一条消息：已完成的内容、下一步做什么、任何需要他们决策的事项。
docs/HANDOFF.md 的模板
# Handoff
更新日期：YYYY-MM-DD 由 <agent/model> · 分支：<name> · 最后提交：<sha>
## 目标
一段话：该项目当前正在努力实现的目标。
## 状态
- 已完成：事项（PR #n）
- 进行中：事项，精确描述停在了哪里，未提交的文件（如果有）
- 未开始：事项
## 下一步
单个后续行动，具体到可以立即开始，并附带命令。
## 队列
下一步之后的有序列表。
## 待定决策（需要负责人决定）
问题、选项、我的建议。
## 注意事项
环境特性、失败的方法及原因、看起来不对但实际上是预期的内容。
## 如何验证
用于证明当前状态健康的命令。
## 参考信息
需要深入阅读的文件和文档。
质量标准
- 明确写出文件名、分支名、PR 编号、命令。不要使用“如上所述”、“我们讨论过的那个东西”。
- 记录失败的方法及原因，以便后来者不会重复。
- 将已验证的内容和假设的内容分开，并说明哪部分是哪种。
- 保持
docs/HANDOFF.md大约在 150 行以内；将历史记录移至日志文件中。