You spent two hours with your assistant chasing a bug that only appeared after a cache warm-up. You found the cause, fixed it, and closed the terminal. Three weeks later the same symptom comes back in another service. The reasoning that cracked it the first time is gone, and a fresh session starts from zero.
Most AI coding sessions deserve to disappear. They rename variables, write tests, fix typos. But a few contain work you will want again: a root cause, a rejected design, a procedure that took an afternoon to get right. The hard part is telling them apart while you still remember what happened.
This article gives you a short test for spotting the sessions worth keeping, a way to trim them into something a person or an assistant can reuse, and a simple place to store them beside your code.
Most sessions are disposable, and that is fine
Keeping everything feels safe. It is not useful. A folder of fifty raw transcripts is a folder nobody opens. When you, a teammate or an assistant needs an answer, it has to wade through setup chatter, failed commands and long code dumps to find three sentences that matter.
So the default should be: let the session go. Keep one only when it passes a clear test. That keeps the saved sessions short, few and worth reading.
A useful mental model is the difference between a chat log and a lab notebook. A chat log records everything that was said. A lab notebook records what you tried, what happened and what you concluded. You want the notebook.
Five kinds of session worth keeping
These are the sessions that tend to pay off later.
1. The debugging hunt that found a root cause
If the fix was one line but finding it took an hour, keep the session. The value is in the path: which hypotheses you ruled out and what evidence settled it. The next time a similar symptom shows up, that path saves the hour.
2. The design discussion with rejected options
You asked the assistant to compare three ways to paginate an API, and you picked cursor-based pagination. The code shows the choice. It does not show why offset pagination was rejected. Without that record, a new session will happily suggest the approach you already turned down.
3. The procedure you had to work out
Upgrading a major dependency, migrating a database column, rotating a signing key, setting up a local environment on a new operating system. If you would need to work it out again next time, keep the session, or better, the steps it produced.
4. The explanation of an unfamiliar area
Sometimes you ask the assistant to walk you through a part of the codebase you did not write. If that explanation was good and accurate, it can help the next person who opens that folder.
5. The session that ended in a decision
Any session where you said "OK, we'll do it this way" and the reason is not obvious from the code. Keep the session, and also turn the conclusion into a short decision record. The article on lightweight decision records for AI-assisted projects shows a format that takes minutes.
A quick test before you save
Run through these questions at the end of a session. If you answer yes to at least one, save it. If you answer no to all, let it go.
- Would I be annoyed to redo this? Hours of investigation, not minutes.
- Does it explain a "why" the code cannot? A trade-off, a constraint, a rejected option.
- Will a new session probably get this wrong? The assistant keeps suggesting the thing you ruled out.
- Would a teammate ask me about this? "Why is the retry limit 3?" "How did you get the local build working?"
- Did it produce steps I will follow again? A procedure, a checklist, a migration plan.
Then one more check that overrides the rest: does the session contain secrets, customer data or anything you would not want a teammate to read? If yes, clean it before saving, or save only your summary. The guide on keeping secrets out of your AI context covers what to look for.
Trim before you save: from transcript to record
A raw transcript is rarely the best thing to keep. Most assistants let you copy or export a conversation. Start from that, then cut it down.
Here is what a raw export often looks like, shortened:
> the /orders endpoint is slow after deploy, can you look
Sure. Let me read src/orders/handler.ts ...
[400 lines of file contents]
> run the tests
[200 lines of test output]
> that's not it, the slowness only happens after the cache warms up
...
> ok so it's the N+1 in loadCustomer, fix it
...
And here is the trimmed version worth keeping:
**2026-09-12 Slow /orders after deploy**
### Symptom
/orders p95 jumped after deploy, only once the cache was warm.
### What we ruled out
- Database indexes: query plans unchanged.
- Cache misses: hit rate was normal.
### Root cause
loadCustomer() ran one query per order when the customer cache
returned partial records (N+1). Introduced when we added the
`tier` field to the cached object.
### Fix
Batch-load customers in loadOrders(). See commit "batch customer
load in orders handler".
### If this comes back
Check whether a cached object gained a field that the loader
does not populate.
The trimmed record keeps the parts that are hard to rebuild: the symptom, the dead ends, the cause and the warning for next time. It drops file dumps and test output, which live in the code and can be regenerated.
Some tips for trimming:
- Keep the questions you asked and the conclusions. Drop the tool output unless one line of it was the evidence.
- Name the dead ends. "We ruled out X because Y" is the part most likely to save time later.
- Write the date and a plain title. You will scan these by filename.
- Keep the raw export only if the path matters. For a long investigation, you might store both: a short summary and the full transcript next to it.
Where to store the sessions you keep
Store kept sessions in the project, in a folder the whole team can see, not in a personal notes app. That way they travel with the code and anyone who clones the project gets them.
A simple layout:
my-service/
├── CLAUDE.md
├── AGENTS.md
├── src/
└── .prjcontext/
├── instructions/
├── memory/
│ └── decisions.md
└── sessions/
├── 2026-08-30-cursor-pagination-design.md
├── 2026-09-12-slow-orders-after-deploy.md
└── 2026-09-18-postgres-16-upgrade-steps.md
A few conventions that help:
- Date first, then a short slug. Files sort by time and the name tells you what is inside.
- One session per file. Easier to link, review and delete.
- Link from memory to sessions. When a decision in
decisions.mdcame from a session, add the filename. The decision stays short, and the full reasoning is one click away. - Point your assistant at them. Add a line to your project instructions, such as "Past investigations and design discussions are in
.prjcontext/sessions/. Check them before proposing an alternative approach." The article on writing CLAUDE.md and AGENTS.md covers how to phrase instructions like this.
Prune now and then. If a session describes code that no longer exists, delete it or move its conclusion into project memory. Old sessions that contradict the current code confuse people and assistants alike.
Make kept sessions useful to the next reader
A saved session is only worth something if the next reader can use it. That reader might be you in three months, a teammate, or a fresh assistant session.
- Add one line at the top saying what the session is for. "Read this before touching the order cache."
- State the outcome clearly. Do not make the reader scroll to the end to learn what you decided.
- Mark what is still true. If part of the session was later reversed, add a note: "Superseded on 2026-10-02, see decisions.md."
- Keep personal and machine details out. Local paths, internal hostnames and account names add noise and can leak more than you intend.
If you work on the same project from more than one computer, keeping sessions in the project folder also means they follow you. The guide on continuing an AI coding project on another machine goes deeper on that.
How PrjLab handles this
We built PrjLab so the sessions you choose to keep live beside the code instead of on one laptop. Put them in .prjcontext/sessions/ and the prj CLI captures them with their own content type, next to your project instructions and .prjcontext/memory/. Nothing is captured automatically: global assistant folders are never scanned, so a session is only stored when you put it in the project. Run prj status to see exactly what would be captured before prj push. Every push creates an immutable version you can open in the browser, with a list of changes and a line diff, so you can see when a session was added or edited. Anyone you share the repository with gets the sessions too when they run prj clone.
Frequently asked questions
Should I keep the raw transcript or only a summary? Keep a summary for most sessions. Keep the raw transcript as well only when the path of the investigation matters, and review it for secrets first.
How many sessions should a project have? There is no right number. If you cannot scan the folder in a minute, you are probably keeping too much, and some conclusions belong in project memory instead.
Can my assistant read the saved sessions? Yes, if they are plain files in the project and you point to them in your project instructions. Keep them short so they fit comfortably in the assistant's context.
Does PrjLab save my sessions automatically?
No. You choose which sessions to keep and place them in .prjcontext/sessions/, and prj push captures them with the rest of the project.
Ready to keep your best sessions with your code? Start with the getting-started guide.
