How to hand off agent context, memory, and project state to the next person, so the work survives a transition without a knowledge tax.
The whole retreat builds a system that runs on your taste, your judgment, and your eight agents. The question this protocol answers is the one that haunts every founder by month six: what happens when I am not the one running it?
Three reasons it matters: you will hire someone (they need to ramp without reading your mind), you will take a break (the work does not stop, you do), you will pivot (a project paused for six months loses all context, even from your own head).
The whole retreat builds a system that runs on your taste, your judgment, and your eight agents. The question this protocol answers is: what happens when I am not the one running it?
Three reasons it matters. You will hire someone, and they need to ramp without reading your mind. You will take a break, and the work does not stop. You will pivot, and a project paused for six months loses all context, even from your own head.
Every handoff has these three layers. Most teams only do the first one. That is why most handoffs fail at the boundary.
One file, docs/handoff.md, kept current as you go. Not written at the end (when the urgency to leave kills the quality of the doc), but maintained throughout.
Three rules. The third is the one that catches teams off-guard.
Pick a real project of yours. Pretend you are leaving tomorrow. You will write the four-section handoff doc, then open a fresh Claude session and ask it to operate the project.
Summary, Active decisions, Known landmines, Next-person-should. Skeleton first, content second.
Three paragraphs as described in the teaching. The hardest part is the second paragraph (where it is now). Be honest.
List your five biggest in-flight decisions. For each: what we chose, why, what we considered, what we rejected. A paragraph each.
List at least three. The deploy that almost killed you. The dependency that breaks under load. The customer who needs a human reply, not an automated one. Be specific.
Open a new Claude Code session in the project. Ask: "Read docs/handoff.md and tell me what to do tomorrow." If it can answer, your handoff works. If it cannot, the gap is your next edit.
A real docs/handoff.md committed to your project, tested against a fresh reader, and the habit set to update it weekly. Future-you and future-them inherit the full picture, not just the code.
You pretend you are leaving tomorrow and write the handoff. Then a fresh Claude session reads it and tells you exactly what you forgot. The gaps become the discipline.