Skill first：skills/writing/handoff。
The most dangerous part of a long session is not that context gets long.
The danger is that during handoff everyone thinks "just summarize it" is enough. A summary is for people to read; a handoff is for the next agent to execute. These are completely different.
所以我把 handoff 做成一个固定 skill。它只做一件事：把当前任务、已确认事实、未完成事项、风险和最值得立刻做的下一步，写进一个 dated markdown 文件。路径默认是 ./handoff/YYMMDD-handoff.md。
This is not polished language.
This is a collaboration interface.
Relay Path
1. 先把长会话里的状态压成可验证事实。
2. 再写入 handoff/YYMMDD-handoff.md。
3. 最后给下一位 agent 一个最具体的第一步。
Step One: Keep the Path Stable
If a handoff file lands in a different place every time, it is not a handoff file. It is just another attachment.
handoff 的默认路径是 ./handoff/YYMMDD-handoff.md。如果用户给了自定义路径，就用自定义路径，并创建父目录。dated 文件已经存在时，默认替换，而不是追加。
This choice is small but firm. The next agent should not have to guess "where did the previous round write this?"
Step Two: Rebuild State Before Writing
The easiest way to ruin a handoff is to polish while remembering. That blends confirmed facts, reasonable inferences, and unverified assumptions together.
This skill forces state reconstruction first: current thread, repo state, changed files, recently run checks, and produced artifacts. Critical paths, commands, module names, and decision points should be verified before entering the document.
- Confirmed facts: exact files, commands, output, pages, and API results.
- Reasonable inferences: why something is probably true.
- Unresolved assumptions: what the next agent must verify first.
Facts are facts. Inferences are inferences. Assumptions are debt.
Step Three: Write for the Next Agent, Not the User
This rule is the center of the whole skill.
User updates can be warm, summarized, and hide the noise. A handoff cannot. It must preserve the operational detail the next agent needs: file paths, commands, APIs, routes, classes, modules, tables, env vars, known dead ends, risks, and the recommended first step.
It does not need to be pretty. It needs to be continuable.
Step Four: Seven Sections Are the Protocol
我不想让每次交接都重新发明格式，所以 handoff 固定了七个编号 section：
1. 当前任务目标
2. 当前进展
3. 关键上下文
4. 关键发现
5. 未完成事项
6. 建议接手路径
7. 风险与注意事项
最后还必须有一句 下一位 Agent 的第一步建议。这句话很重要。它把“你可以继续看看”变成“第一步先做这个”。
Step Five: Verification Is Not Formalism
The final step of this skill asks it to confirm four things: the file exists, all seven numbered sections are present, the final first-step suggestion exists, and the whole piece reads like an internal baton pass rather than a user update.
This looks like a formatting check. It is really preventing a more hidden failure: the document exists, but the next agent still does not know how to start.
It is done only when the next person can pick it up.
The Real Boundary of This Release
这次我把本地 /Users/minxian/.codex/skills/handoff/SKILL.md 放进 GitHub-backed skill repo 的 skills/writing/handoff/SKILL.md，并补了 repo 需要的 metadata、常见坑表和 verification checklist。
One boundary is worth making explicit here: the skill is the main artifact, the blog is the explanation layer. When it is actually reused later, the agent should not come back to this post and guess; it should use the skill on GitHub directly.
The article explains why. The skill makes the next run less painful.
If you only do one thing at the end of a long task, do the handoff. Do not wait until the context has already turned into mush before rescuing it.
Skill 源码：https://github.com/XJM034/SKILL/tree/main/skills/writing/handoff