docs/STATUS.md (accomplishments, exact current state, precise next step, open questions), update TODO checkboxes, log notable decisions, and commit or stash anything uncommitted — a two-minute handoff to future-you.
These two templates are halves of one system. The End-of-Session prompt writes docs/STATUS.md; the Re-Entry prompt reads it. Run the first one
faithfully and the second one feels like magic. Skip the first and the second has nothing
to work with — that's the whole deal.
The End-of-Session prompt — run it last, every time
We're ending this session. Close it out properly: 1. Overwrite docs/STATUS.md with: date; what we accomplished today (3-6 bullets); exact current state (what works, what's half-done); the precise next step with enough detail that a fresh session could start it cold; any open questions/decisions pending. 2. Update checkboxes in docs/TODO.md. If we made a notable technical choice today, append one line to docs/DECISIONS.md (choice + why). 3. git status — if anything is uncommitted, either commit it with a clear message or stash it and NOTE THAT in STATUS.md. 4. Show me STATUS.md so I can confirm it's accurate.
Two minutes, and it pays for itself tenfold. The details that matter:
- "Overwrite" — STATUS.md is a snapshot, not a diary. The old status is obsolete the moment there's a new one; history lives in Git, not in the file.
- "…enough detail that a fresh session could start it cold" — the quality bar for the next-step line. "Continue search feature" fails it; "wire the search input in Header.astro to the /api/search endpoint; the endpoint works, the input is still static" passes.
- The commit-or-stash step kills the #1 returning-developer confusion: mystery uncommitted changes. Future-you either finds clean state, or finds a note explaining exactly what was left dangling and why.
The Grand Re-Entry prompt — after days or weeks away
I'm returning to this project after time away. Rebuild context EFFICIENTLY — do not read the whole codebase. 1. Read CLAUDE.md, docs/STATUS.md, and docs/TODO.md. 2. Run: git log --oneline -15 and git status — note any uncommitted work or surprise branches. 3. Run the build ([npm run build]) to confirm the project is healthy; if it fails, report the error but don't fix yet. 4. Then brief me in under 20 lines: • What this project is (1-2 lines) • Where we left off + what the last 5 commits did • Anything unfinished/uncommitted right now • The top 3 next actions from TODO.md • Any risk or open question I should decide on 5. STOP after the briefing. Wait for me to pick the next task.
Why it works: STATUS + TODO + the git log are the project's state — the source code is just the implementation of that state. Reading three small files and fifteen commit messages costs about 2% of reading the source and gives you (and Claude) 98% of the orientation.
- The build check answers "is anything broken?" before you plan anything — but "report, don't fix yet" keeps the session from wandering off.
- The hard STOP matters. Re-entry sessions that immediately start coding tend to code the wrong thing. First the briefing, then you pick the task.
- Older project without STATUS.md? Say so, and add a step 6: "Since docs/STATUS.md doesn't exist, create the docs/ memory system now based on what you learned, then give the briefing." The system bootstraps itself onto any existing repo.
The moment it clicks: the first time Claude briefs you on your own project — what it is, where you left off, what's next — in twenty seconds, you'll understand why this handbook keeps insisting that files are memory. Run the End-of-Session prompt today; tomorrow-you gets the demo.
Up next: two prompts that make you better, not just faster — Teacher mode for understanding what got built, and the review prompt that finds what a senior dev would flag.