Memory fades faster than a project changes, so a handoff written from recollection is only as good as the recollection. Writing it from live commands, ending in the exact prompt to resume, is what actually survives the gap.
The moment I most reliably lose track of a project is not mid-task, it is the gap between sessions — the point where one working session ends and, hours or days later, a new one has to pick the work back up with none of the context the first session built up along the way. For a long time I handled that gap the way most people do: I trusted my own memory, or a few lines dashed off at the end of a session, to carry the important parts forward. Both failed the same way. Memory fades faster than the actual state of a project changes, and a few rushed lines written from memory are only as accurate as the memory that produced them.
What actually works is writing a handoff document from live state rather than from recollection — running the commands that show what is really true right now, and building the document out of their output rather than out of what I believe is true. Git log for what actually shipped, not what I remember shipping. A status check across whatever worktrees or branches are open, not a mental list of "I think I left something running over there." The difference sounds small until you have been burned by the alternative: a handoff written from memory that confidently states a piece of work as done, when the actual git history shows it stalled halfway through three days earlier and nobody circled back.
A good handoff separates cleanly into what is finished, what is genuinely in flight, and what is an open question nobody has answered yet — and each of those three categories needs different treatment. Finished work gets a pointer to the proof it is finished: the commit, the test run, whatever showed it actually worked, not just a claim that it did. In-flight work gets the specific state it is in — which branch, which file, what the next concrete step is — because "still working on X" is useless to whoever picks it up next; "the migration script is written and tested against staging, the last step is running it against production" is not. Open questions get written down as questions, explicitly, rather than smuggled in as an assumption that whoever reads the document will happen to share.
The part of a handoff document that earns its keep the most, in my experience, is the exact resumption instruction at the end — not a summary of the situation, but the literal thing you would type to pick the work back up with zero re-derivation needed. A handoff that ends in a paragraph of context makes the next session start by re-reading and re-inferring what to do next. A handoff that ends in a copy-pasteable prompt, referencing the specific files and the specific next step, means the next session starts working instead of starting by figuring out where it left off. That difference compounds every time a project gets picked back up, because re-deriving the same context repeatedly is pure waste — work that produces no new output, just re-establishes what was already known before.
Writing the handoff from live commands rather than memory also catches something memory cannot: the gap between what I intended to leave in a working state and what the repository actually shows. More than once, running the actual status check while writing a handoff has surfaced a worktree I had forgotten was open, or a branch that never got merged, that my own recollection of the session would have skipped entirely. The document is not just a courtesy to whoever reads it next. Writing it honestly is often the first moment a session’s real state gets checked against what I assumed it was.