Cross-session continuity is not a memory feature. It is a project-state design problem. When an AI coding session ends, the next session needs more than old chat history: it needs the decisions already made, the current state of the work, the next useful action and the risks that should not be rediscovered.
A short HANDOFF.md file can carry that state across sessions without turning a general instruction file into a progress log or expecting the model to remember an entire project.
The problem is continuity, not memory
My side projects are usually split across short sessions. On the Gwarket website work, one session included a long architecture discussion about using Next.js static generation instead of continuing with WordPress Elementor. The decision was tied to later interactive features and the compatibility limits of a page builder.
The next session did not inherit that reasoning and proposed Elementor again. The same failure mode appeared in content work: editorial decisions and failed approaches were easy to repeat when only the conversation held the state.
Resuming a conversation can recover history, but history is not the same as a current project brief. A useful handoff should tell the next session what is settled, what remains open and where work should resume.
Why built-in memory features leave a gap
CLAUDE.md stores operating rules
CLAUDE.md is useful for durable instructions: commands, code conventions and project-specific rules. It should not become a running status report. Mixing temporary progress with persistent rules makes both harder to maintain.
Memory stores reusable fragments
Auto-memory can retain build instructions, debugging techniques or user preferences. Those fragments answer “how should this be done?” They do not reliably answer “where is this project now?”
Resume restores a conversation
claude --continue and claude --resume can reopen earlier sessions. That helps when the correct session is easy to find and its important decisions remain visible. It is less reliable when several projects are active, sessions have been compressed or the relevant reasoning is buried in a long transcript.
Skills preserve task knowledge
Skills can hold a writing method, output contract or repeatable workflow. They are intentionally reusable and relatively static. They are not the right place for a project’s changing state.
Together, these mechanisms cover rules, reusable knowledge, conversation history and task methods. The missing layer is a concise, structured record of current project state.
A handoff file turns state into an artifact
The pattern borrows from operational shift handovers: leave enough information for the next person—or the next AI session—to continue safely.
# HANDOFF — 2026-03-20
## Completed
- Four pages implemented and reviewed
## Decisions still open
- Final information architecture
## Next actions
- Design the WordPress API integration
## Known issues
- Do not reopen the Next.js versus Elementor decision
unless the interactive-feature requirement changesEach section has one job:
- Completed prevents the next session from rebuilding finished work.
- Decisions still open separates unresolved questions from settled choices.
- Next actions gives the session a useful starting point.
- Known issues prevents repeated failures and unnecessary detours.
What changed in practice
After the Gwarket architecture work, the handoff recorded four completed pages, an information-architecture decision still in review and a WordPress API integration that still needed design. The next session could begin from those facts instead of reconstructing the project from chat history.
The handoff itself was kept to roughly 20–40 lines, or about 200–400 tokens. That is intentionally small. An external practitioner has described a monorepo session using roughly 20,000 tokens for basic loading; that comparison is source-reported rather than a measurement of this project, but it illustrates the cost difference between loading broad context and reading a bounded state artifact.
The same pattern can support other continuity problems:
article-log.mdcan record what was published, the central idea and metaphors already used.- A writing Skill can hold approved examples so style does not depend on session memory.
- A decision log can preserve why an option was rejected, not only what was selected.
Design rules that keep handoffs useful
Keep the artifact short. A handoff records conclusions, current state, next steps and known issues. Detailed history belongs in a work log.
Automate the update, review the result. An AI can update HANDOFF.md after meaningful work, but a person should check that implicit decisions and unresolved risks were not omitted.
Use it with memory, not instead of memory. Memory stores reusable knowledge. A handoff stores the state of one stream of work. The two solve different problems.
The broader lesson
Reliable AI collaboration does not require the model to remember everything. It requires a system that externalizes the information the next session must know. A handoff file is a small mechanism, but it changes continuity from a hope into a reviewable operating practice.
Sources