The LLM Wiki — built on camera with INGEST / QUERY / LINT

84% of the edges in my vault exist thanks to a single writing habit: putting a file name inside double square brackets. This piece walks through the entire system that produces that habit.

In the first two parts of this series I covered the problem and Claude Code's own memory. Auto memory knows me: who I am, how I work. But it cannot follow a topic. An API key runs out of credit, I hand it a new one; a while later it drifts back to the old key. My morning routine runs flawlessly for a month; then one day I wake up to find it has forgotten the format I explained a dozen times.

The thing that fills this gap has a big name: the LLM wiki. The thing itself is small. There is no tool and no product here — just a file format and a handful of prompts.

Below are four things: what the format actually does, the vault file structure, the loop the agent uses to update the wiki, and the measured results of all of it in my own vault.

The LLM wiki is not a tool, it is a format

The idea belongs to Andrej Karpathy. In early April he shared a wiki design together with its prompt. I translated that prompt into Turkish, re-split it to fit my own way of working, and I have been building both my memory system and the vault you see in Obsidian with it ever since. The idea is his; my share is the adaptation.

What the format does fits in one sentence: it turns markdown files into a structure with nodes and edges. The rule from the first part was clear: without an edge, the agent cannot know it should go from file A to file B. The LLM wiki is precisely the format that produces those edges.

Setup is a single prompt too: "Set this folder up as an LLM wiki. Write a CLAUDE.md, build an index, keep a log, and never touch the raw files I give you." The agent builds the rest. You do not write the wiki pages; the agent writes them, you only read them.

So who actually needs this format?

When you need it, and who does not

Auto memory keeps short facts about you, and it does that well. The limit shows up once topics multiply: a decision discussed months ago, notes spread across three projects, two pieces of information that contradict each other. For the agent to find these, there have to be paths between files — and in the default system those paths do not exist.

The rule is this: if your notes span more than one project and you return to the same topic weeks later, the wiki works for you. Anyone who accumulates research files, produces content, or runs long-lived projects fits that description. The reverse holds too: if the data is too big for an agent to read file by file, this format is not enough — you cross into the RAG territory from the first part. And for a small notes folder you open once a week, the effort is not worth it.

Once you have settled the boundary, it is time for the format itself.

The vault: three layers, two special files

The vault consists of three layers.

• Raw data. Your sources — downloaded articles, comment exports, notes. The agent reads them but never modifies them.
• Wiki. The pages the agent writes from those sources — summaries, topic pages, comparisons.
• Schema. The rules file — in Claude Code that is CLAUDE.md. How the wiki is read, how it is updated, and what is forbidden all live here.

And there are two special files.

• index.md is the map: which topic lives in which file, one sentence per line, and it is the first file the agent reads. It is also that giant node sitting at the center of the graph.
• log.md is the date file: what was processed on which day, kept as one-line records; the agent answers "what did we do two weeks ago" from here.

The notation that produces the edges is the wikilink (a double-bracketed link): when a page mentions another page by name, it wraps the name in double square brackets. Every pair of brackets is an edge between two files in the graph. With this structure my vault holds 74 files and 952 wikilinks.

The page format is fixed as well. Every wiki page carries the same skeleton: a one-sentence summary at the top, the content below, and links and sources sections at the bottom. The links show which pages this page shares an edge with; the sources show which raw file it rests on. When the agent opens a new page it applies this skeleton on its own, because the format is written into the rules file.

Once the structure is in place, all the work comes down to three commands.

The loop: ingest, query, and building on top

Ingest is the write path: you hand over a new source; the agent reads it, synthesizes it, opens or updates topic pages, wires the cross-links between pages, and finally updates the index and the log. I ran every comment from my first two videos through it this way.

Query is the read path: you ask a question; the agent starts from the index, finds the right pages, and produces the answer. The real difference is a small extra rule: you have it write the answer back into the wiki as a synthesis page and add it to the index. I asked "what did my viewers ask most, and which question did I leave unanswered" — the answer became a new page called the viewer question map.

That addition closes the loop. When the same topic comes up again, the agent does not start from zero; it opens that page and builds on what has accumulated. That is the entire mechanism behind the image of the self-improving agent.

The same path works outside code too. My example in the video comes from design: say you liked three different site designs, and a blue fish appears in all three. You tell the agent to merge the three into a taste file; with every next design, what you liked gets added on top of that file. Your taste becomes a file.

The third command is the system's insurance.

Lint: the weekly health check

Lint is the wiki's health check. It looks for four things: an orphan page with no edges, contradictory claims between pages, a concept that appears in the text but has no page of its own, and a file that never made it onto the map.

The most important rule is on the reporting side. The agent presents what it found as a list first; it does not fix things on its own judgment. My last check surfaced four contradictions, and the agent laid out which ones were waiting for approval. The decision stayed with me — a contradiction silently overwritten is misinformation that goes unnoticed.

The second rule is about frequency: lint is weekly, not daily. Running it every day means re-reading the same files over and over — burning tokens for nothing. If something snags in between, do not wait for the week; be specific — "the link between these two files is broken" — and it fixes it on the spot.

So does this effort actually pay off? I measured it.

Who carries the edges — two measurements

The first part had a single experiment: deleting the brackets dropped the number of files the agent could reach from 68 to 19. For this piece I went two steps further.

First measurement: of the 673 unique edges in my vault, 562 — that is 84% — exist only because of the brackets. The target file's name does not appear in the plain text of the sentence; the moment I skip the brackets, there is no trace left for the agent to find even with grep. The vast majority of edges do not form on their own — they are produced one by one through that writing habit.

The second measurement is more surprising: the links of index.md alone reach 54 of the 74 files. The other 620 edges between pages contribute just 14 more files of reach.

The lesson fits in two sentences. The index does most of the work of reach; without the map, half the graph stays in the dark. The links between pages serve precision: the agent hops to the right page from its neighbor in a single jump, instead of trying three files and burning tokens.

For anyone who wants to build this from scratch, I published everything.

Build it yourself — the ready-made kit

The setup I use, example rules files, and all of the prompts are on GitHub: claude-obsidian-kit. The clean version of the prompts lives in a single file: PROMPTS.md.

Getting started is three steps:

• Paste the setup prompt into your own folder.
• Ingest your first source.
• Run your first lint a week later.

You will get far more out of it if you adapt the prompts to your own work; that is the nice thing about a format — you are not locked into anyone's product.

So: the agent's memory is carried by the format, not the model. The agent writes the wiki; your job is to bring sources and to decide when there is a contradiction.

At this point the most common question is always the same: "But what about Obsidian? How did you connect Claude Code to it?" I did not. Whether Obsidian is open or closed changes nothing for the agent. The next part is entirely the answer to that question: do you actually need Obsidian, or does it just make things look good?