The deeper version
How it works, in engineering terms
The landing page can say this three ways. This page says it one way, the technical one, all of it at once. Nothing here is behind the other levels: it is the same method with the detail left in. Back to the page and its picker.
The repository is the memory
Committed markdown under version control, fronted by a context map that works as an index. A cold session reads the map first and pages in only the notes it needs, so what you spend on context stays flat while the project grows.
Where the memory actually lives
Four surfaces, and nothing else is required. An always-loaded operating manual (CLAUDE.md, or AGENTS.md if that is what your agent reads) holding only load-bearing rules. A context map listing every other surface with a one-line note on when to read it. Topic notes and decision records, opened only when the map points at them. And a small capture file for facts that do not have a home yet.
The map is the part people skip, and it is the part that pays. Front-loading every document into every session is what makes context expensive. Loading an index and then one document is what makes it cheap, and the gap widens the more you write down.
None of it is a format you have to adopt. It is markdown in a folder, so a different agent, a different editor, or a person reading it on GitHub in two years all get the same thing.
Depth is retrieval depth
You are paging through your own repository, and depth here is retrieval depth: the map, then the topic note, then the decision record that says why. Nothing is fetched from anywhere else, because there is nowhere else.
The prompt
Paste it into any agent with file access, at the root of the repo. Step one is a read-only pass over the README, the manifest, the tree and the last twenty commits; it never invents a fact and never overwrites an existing CLAUDE.md or AGENTS.md. What you get is a short operating manual plus docs/now.md, docs/decisions.md and docs/notes.md, with the capture habit wired into the manual so the writes keep happening without you remembering to ask.
What the prompt does, step by step
It reads before it writes: the README, whatever manifest the project has, the folder layout, and the last twenty commits. If the repo is empty it says so rather than inventing a project to describe.
It picks one main file and never creates a second source of truth. If CLAUDE.md exists that is the main file; otherwise AGENTS.md; otherwise it creates CLAUDE.md and leaves the other as a two-line pointer, so an agent that only looks for one of them still finds the content.
It adds to files, never over them. An existing memory file is read and extended, so running this on a project that already has notes is safe.
Then it wires the habit into the manual itself: read the now file at the start of a session, write a decision the same session it happens, write a gotcha the same way. The habit lives in the file the agent already loads, which is the only reason it survives.
The wizard
The prompt gives one repo a memory. The wizard gives you one: a personal operating file your agent reads every session, a memory folder it writes to as you work, and three one-word habits that make a session resumable. It runs entirely in the browser with its state in localStorage, so no answer you type leaves the page. What it produces is a prompt, not a program, and that is deliberate: only something running on your machine knows your OS, which agent you use, and what you already have, so a packaged folder of finished files would either overwrite your setup or land in the wrong place.
Why the payoff is a prompt and not a zip
The seven sessions end in a download, and what you download is a prompt built out of your own answers, packaged with two starter files. You hand it to your agent and it does the installing.
Shipping finished files instead was the obvious alternative and it is the wrong one. Only something running on your machine knows your operating system, which agent you use, where your config already lives, and what you would be clobbering. A folder of ready-made files either overwrites a setup you liked or lands somewhere nothing reads it.
The download exists for a softer reason too, and it is worth being honest about: download your setup feels like a gift, and copy this prompt feels like homework, even when the bytes are identical.
The fourteen pillars
The prompt is the short version. These fourteen are what I run across every repo I own. Read 01 to see where memory lives, then 07, the decision cache, which is the one that changes the economics: a settled call is written down once, so review stops re-litigating it and the cost of a session falls as the project grows instead of climbing with it.
The decision cache, which is the one that pays
Pillar 07 is the reason the rest is worth the typing. Every settled decision gets written once, with the date and the reason, in a file the agent reads before it starts.
The effect is not tidiness, it is cost. Without it, every review re-argues the same call, and the argument gets longer as the project gets bigger, so your worst session is always your most recent one. With it, a settled call is a lookup, and review gets cheaper per unit of code as the record grows.
The failure mode to watch for is a decision file that is really a diary. If an entry does not say what was decided and why, it will not stop the next argument, and you will keep paying for it.
No hosted memory
If a tool keeps your project's memory on its servers behind an API, your memory is part of its product. Here it is plain text under version control, so it diffs, it reviews, and it travels in the same clone as the code it describes. There is no runtime to depend on: no daemon, no service, no key, nothing that can be deprecated out from under you, and no vendor whose pricing page is a fact about your project.
What this deliberately does not have
No server, no account, no API key, no daemon left running, and no telemetry from your repo. There is nothing here that can go down, get acquired, or change its pricing.
The trade is real and worth naming: you get no hosted search across projects, no team dashboard, and no sync that you did not set up yourself, because that is what your version control already is.
The optional local tools (an index, a search, a graph) run on your machine, over your files, and you can delete them without losing anything, because the files were never inside them.
Read the source
Every pillar above is a file, and the files are the method. There is no version of this that is truer than the repo.