How to stop re-explaining your project every session
The preamble you type without thinking is the thing worth writing down.
The short answer: write down the specific things you find yourself retyping — stack, conventions, decisions, corrections — in one file per project, and give your assistant a way to read it. Ten minutes of capture removes a recurring tax.
Find your preamble
Open your last five conversations and read only what you typed before the actual question. The repeated parts are your preamble, and they are almost always the same four categories:
- Stack and environment — language, framework, versions, where things live.
- Conventions — how you want output formatted, what you never want suggested.
- Decisions already made — the ones you are tired of re-litigating.
- Corrections — things the assistant got wrong before and will get wrong again.
Paste that preamble into the token estimator and multiply by sessions per week. That number is what the habit costs you.
Write it once, properly
One entry per idea, each standing alone. “Uses SQLite, not Postgres — moved in v3 for the embedded-replica story” beats “database stuff”, because the second one will not answer a question six months from now.
Include the reasoning. The decision is usually recoverable from the code; the reason for it never is.
Keep it honest
A context file that has drifted out of date is worse than none — it produces confident wrong answers instead of questions. When something changes, replace the entry and note what it replaced, rather than deleting silently.
Getting it in front of the assistant
In rough order of effort: paste it at the start of a session; use your assistant's project or instructions feature; or connect a memory the assistant can query so it pulls only what the current question needs.
The third scales best, because a file loaded wholesale eventually costs more than the preamble it replaced. Why retrieval beats re-injection covers the economics.
Varven does this with plain Markdown on your own disk, searchable from any assistant — and readable when your computer is off.
Common questions
What should go in a project context file?
Stack and versions, conventions and output preferences, decisions with their reasoning, and corrections. Not task state, not anything readable from the repository itself.
How long should it be?
Short enough that you would read it yourself. If it has grown past a page, that is the signal to move from loading it wholesale to retrieving from it.