Most Project Folders Are Amnesia Machines
Open a project you haven't touched in three months. What do you actually know about it? There's a folder structure, some files, maybe a few comments in the code if you were feeling generous. But why did you make those choices? What were you about to do next? What didn't work and why? That's gone.
Most project folders are designed to hold files, not knowledge. The work gets saved, but the context that makes the work legible disappears the moment you close your laptop. Six months later, you're an archaeologist in your own project.
A knowledge base fixes this. Not documentation in the formal sense — a running record of where things stand and why, written by you for your future self. One file, in the folder, updated every session.
Why This Matters More When You Work with AI
Every AI session starts from scratch. It doesn't matter that you've been working on this project for six months — the model has no memory of your last conversation, your failed experiments, or the decision you made last Tuesday about why you switched frameworks. You have to re-explain everything.
That re-explaining takes time, introduces errors, and dilutes the quality of what you get back. When you're pasting a wall of context at the start of every session, you're doing manual labor that a good knowledge base handles automatically.
The CJ Gain VST3 plugin project is a real example. There's a file called CLAUDE.md sitting in the project root that describes the plugin architecture, what's been built, what was tried and failed, and what comes next. Every new session loads that file first. The difference in conversation quality — less re-explaining, more actual work getting done — is significant.
What Goes in a Knowledge Base
It doesn't need to be long. The minimum viable version covers four things: what the project is (one or two sentences, written like you're explaining it to someone who's never seen it), current state (what's working, what's in progress, what's broken — not a git log, just plain-English status), key technical decisions (the choices that aren't obvious from the code), and what's next (the two or three most important things to tackle next session).
That last one is the most important. The "what's next" section is what you'll be most grateful for when you come back after a two-week gap. Write it at the end of every session while the context is still fresh.
Update the whole file every time you work on the project. It takes three minutes. It saves three hours when you return.
The Format Doesn't Matter. The Habit Does.
A Markdown file called CLAUDE.md, NOTES.md, or README.md in your project root is all this needs to be. No special software, no separate app, no subscription to a second-brain tool. One file, plain text, sitting inside the folder with your actual work.
The format matters less than the location. Keeping the knowledge base inside the project folder means it travels with the project when you share it, archive it, or open it on a different machine. It also means you'll actually update it — it's right there, not three tabs away in a different app.
Start With the Project You're in Right Now
Don't wait for a new project. Open whatever you're working on right now, create a text file in the root folder, and write three things: what this is, where you left off, and what you're doing next session. That's the whole thing.
If you're using AI tools in your workflow, add a fourth line: what you want the AI to know before you start. Your stack, your constraints, the decisions you've already made. You'll never have to explain your own project from scratch again — and the AI you're working with will be useful from the first message instead of the fifth.
The knowledge base isn't overhead. It's the difference between a project you can pick back up and one you have to reconstruct.