NEXT.md and the session handoff
Claude Code sessions don’t carry memory from one conversation to the next. Whatever a session knows about where a long-running project stands, it has to get from files, because nothing else survives between one terminal session and the next one, days or weeks later, possibly run by a different instance of the model entirely. For a project the size of a novel-in-progress, with a moving canon, a shifting scene count, and a publishing schedule already partly live, “read everything” isn’t a workable recovery strategy. Autoroad’s answer is a single living document, plans/NEXT.md, whose whole job is to be the first thing a fresh session reads.
What the file actually contains
The same handful of sections come back every time it’s updated. A note on current state as of the date it was last touched. A section headed explicitly to orient a session that’s lost all context. A record of what’s been settled as binding fact or ruling since the last update. Then a numbered queue of what to do next, with enough context that a session can start on item one directly, and a section for work that’s owed but not next: cascade fixes and follow-ups a completed task revealed but didn’t itself require.
On the day the draft reached its end, the queue read, in order: get David’s read on the two most recently drafted acts, run the consistency-backfill skill over every “new facts” list the editing lenses had produced but not yet folded into canon, and run a mechanical pass thinning overused “because” constructions and write-verb tics in the newest chapters, keeping every reason intact. Then write author’s notes for the newly finished chapters, and update the chapter-grouping file that controls how scenes get bundled for Royal Road. Each item names the file or skill it depends on, so a session can go straight to the work rather than reconstructing the plan from scratch.
Why the queue is numbered and dated, not a wiki page
A queue with owed items, not just next items, exists because completing a task in this project routinely surfaces more work than it resolves. Redrafting an act flags several deliberate departures from an earlier planning document that need reconciling later, and a chapter amendment applied under delegated authority during a backfill needs a note left for whoever reads the affected chapter next. Rather than resolving these immediately and risking a rushed fix, they get logged as owed, with enough detail that a later session, possibly weeks removed, can act on them without rediscovering why they matter.
The file is edited in place, every session, and nothing about it is append-only: closed queue items get removed, not marked done and left cluttering the top of the document, because the point is to be read quickly by a session that has nothing else to go on. Canon files work differently: they keep dated rulings as a permanent record woven through the file rather than deleting them once acted on, because canon needs an audit trail and NEXT.md needs to be short.
The session that took the draft from a partial state to a finished one shows the pattern in use: it read the old queue, worked through most of it, and left a new one behind. 2026-09-02, drafting to the end of book one.