You open the repo for the first time in two weeks: a branch called feat/queue-retry with four commits on it, a half-written test file, and a // revisit this comment you wrote yourself and no longer understand. The fastest way to resume an AI coding project at that point is not to re-read the code, and it is not to open a session and prompt until something clicks.
What you lost is not the code. You can still read the code. What went missing is the reasoning around it: which approach you already rejected, what the last session was in the middle of, why that retry loop looks wrong on purpose. Your assistant has none of it either, since its conversation context expired days ago.
Rebuild that layer in a fixed order before you write a single prompt: instructions, then decisions and memory, then the last session you kept. Fifteen minutes, usually less.
The gap between reading the code and understanding it
Two weeks away produces a specific kind of confusion. You recognise every file. You can follow every function. But you cannot tell which parts are settled and which parts are halfway through an idea.
The commit log does not close that gap. fix: handle empty batch tells you what changed. It does not tell you that you spent an afternoon finding out the queue delivers empty batches during a redeploy, and decided to swallow them rather than alert on them. That distinction is the entire decision. In the log it is seven words.
So the catch-up problem is not "what is in this project". It is "what did past-me already work out, and where did past-me stop".
Two memories reset at once
Your own recall fades gradually. The assistant's is binary: either the conversation is still open or it is gone. Every new session starts from the files, plus whatever instruction file loads automatically, plus whatever you paste in.
The AI assistant memory reset is usually the one you notice first. It re-suggests the library you removed. It offers to clean up the odd-looking code that exists for a reason. It asks something you answered at length in a conversation that no longer exists. With sharp recall you would catch all of that in seconds, but your recall is not sharp either, so you half-agree with one suggestion and lose an hour to it.
Treating these as one problem rather than two saves the time. The same three artifacts that get you oriented are the ones that orient the assistant, and the order is the same.
A fixed order to resume an AI coding project
1. Instructions, first and fast
Open CLAUDE.md or AGENTS.md and read it top to bottom. Two minutes, and it is the cheapest orientation available: commands, conventions, boundaries. It also surfaces drift. A line like "use the local container for the queue while staging is down" may have been true a month ago and is now a trap. Delete it while you are looking at it, rather than letting the assistant obey it for another week.
Note anything you remember re-explaining by hand in your last few sessions. That is a candidate for the instruction file instead of your prompts.
2. Decisions and memory, newest first
Read your memory or decision notes in reverse chronological order and stop when you hit entries you clearly remember. You are after three things: what was decided, what was tried and dropped, and what was left open.
### 2026-09-18 — Retry at the consumer, not the publisher
Decision: Retries live in the queue consumer with a 3-attempt cap.
Why: Publisher-side retries duplicated messages during redeploys.
Rejected: exponential backoff in the SDK wrapper (hid real failures).
Open: no dead-letter handling yet.
Five lines, and they rebuild more usable context than twenty minutes spent reading queue/consumer.ts. The "rejected" line earns its place most often, because it names exactly what a fresh assistant will propose within its first two messages. If your notes are not in this shape yet, lightweight decision records for AI-assisted projects covers a format that survives being skimmed months later, and project memory for AI coding covers what else belongs there.
3. The last saved session, last
Only now open the most recent conversation you kept. By this point you know the rules and the decisions, which means you can read the transcript for the one thing it is uniquely good for: where you stopped, and what you were in the middle of thinking when you did.
What a transcript carries that nothing else does
A kept session shows work in progress rather than conclusions. The option you were still weighing. The error message you were chasing. The thing you said you would check tomorrow and then did not. It also shows the assistant's reasoning at the time, which matters when you are deciding whether to continue its approach or throw that piece away and start over.
Which is also why most sessions are not worth saving. Routine refactors, bug hunts that ended in a typo, long exploratory rambles: skip them. Keep the ones where a design got argued out or a non-obvious constraint turned up. Which AI coding sessions are worth keeping goes into the selection in more detail.
If you are coming back on a different laptop as well, the same three reads apply, with the extra problem that the transcripts may be sitting on the old machine. Continuing an AI coding project on another machine covers that variant.
Briefing the assistant without re-pasting your history
Resist pasting the old transcript into a fresh session. It burns context, and the assistant tends to read the whole thing as current, including the parts you abandoned halfway down.
Write a short brief instead, four or five lines, assembled from what you just read:
We're on feat/queue-retry. Retries live in the consumer, 3-attempt cap;
publisher-side retries were tried and dropped (duplicates on redeploy).
No dead-letter handling yet. Last session stopped while writing the
test for the empty-batch case in queue/consumer.test.ts.
Start there; don't touch the publisher.
Worth writing even on a day you are not using an assistant, because it doubles as the note that orients you next time. A handoff note to yourself written at the end of a work block is the cheap version, since you still have all the context when you write it.
Keeping the three reads in one place
What makes this order hard to follow is that the three artifacts usually live apart. Instructions in the repo, decisions in a notes app or nowhere, sessions in a chat client that may or may not still hold them. So you go to pick up a coding project again and the catch-up becomes a scavenger hunt across tools, which is most of what lost context in AI coding actually feels like.
We built PrjLab so those three sit beside the code as one versioned repository: .prjcontext/instructions/, .prjcontext/memory/ and .prjcontext/sessions/. You push with prj push, and each push becomes an immutable version you can open in the browser with a line diff against the one before it. After two weeks away that diff is often the fastest read available, because it shows precisely what moved in your instructions and memory since you last looked. On another machine, prj clone brings the whole picture down in one command.
If that is how you want a project to wait for you, the getting-started guide walks through the first push.
