# An LLM wiki CLAUDE.md template: the schema, an annotated example, and a copy-paste file Andrej Karpathy's LLM wiki gist describes a folder of Markdown pages that an LLM agent keeps up to date for you. The schema that makes it work lives in a `CLAUDE.md`: where pages go, how to write them, and the loop the agent runs when new information arrives. Below is a copy-paste `CLAUDE.md`, an annotated example page, and how to run the same pattern hosted over MCP with Hjarni. Most write-ups argue about whether the pattern is right. It is. [I wrote that argument already](/blog/karpathys-llm-wiki-is-right). This post is the part people actually search for: the file you paste in. ## What a CLAUDE.md actually does here A `CLAUDE.md` is not content. It is the instruction sheet your agent reads before it touches the wiki. It answers three questions: 1. **Where do pages live, and how are they named?** So the agent files things in the right place instead of inventing a new folder every session. 2. **What gets written, and what does not?** So the wiki stays a brain, not a transcript dump. 3. **What is the maintenance loop?** So when a new source arrives, the agent updates the right pages, links them, and flags anything that now contradicts what was already there. Get those three right and the agent does the bookkeeping. You do the thinking. That is the whole pattern. ## The folder schema The wiki is a folder of Markdown files. A schema that holds up past month three has four kinds of page: - **`index.md`**: the home page. A short map of the wiki: the main topics, with links. The agent reads this first to orient. - **`topics/`**: one page per durable topic. This is where knowledge accumulates. Each page is a living summary, not a log. - **`sources/`**: one page per source you fed in: an article, a meeting, a conversation. Raw-ish capture. Topic pages cite these. - **`log.md`**: an append-only changelog. Every session the agent notes what it changed and why. This is your audit trail and your "what did I learn this week" view. The split matters. Topic pages are *synthesized and overwritten* as understanding improves. Source pages are *appended and kept*. Mixing the two is how wikis rot: you either lose the raw record or you never consolidate it. ## The copy-paste CLAUDE.md Drop this in the root of the wiki folder. Edit the bracketed parts. It is deliberately short, because an agent ignores the bottom of a long instruction file. ```markdown # LLM wiki: agent instructions This folder is a personal knowledge wiki. You maintain it. I think with it. When I give you new information, your job is to fold it into the right pages and keep the whole thing consistent. Do the bookkeeping so I don't have to. ## Where things go - `index.md`: the map of the wiki. Topics with one-line descriptions and links. - `topics/.md`: one page per durable topic. Living summaries. - `sources/-.md`: one page per source (article, meeting, chat). - `log.md`: append-only. One dated line per session: what changed, why. ## How to write a topic page - Lead with a 2-3 sentence summary that stands on its own. - Write the current understanding, not a history of edits. Overwrite freely. - Link related topics with [[wiki-links]]. Cite the sources that back a claim. - Keep one page per topic. If a page covers two things, split it. - Short sentences. No filler. This is for fast reading, by me and by you. ## What to capture - Decisions and the reasoning behind them. - Stable facts, preferences, conventions, and "how we do X here". - Open questions, with what would resolve them. ## What NOT to capture - Full transcripts or raw dumps. Summarize into a topic, link the source. - Anything that will be stale in a week. Put time-bound things in the source page. - Secrets, credentials, anything I would not want in plain Markdown. ## The maintenance loop (run this when I give you something new) 1. Read `index.md` to orient. 2. Decide which topic page(s) this touches. Open them. 3. Update the topic page(s). Add new ones if needed and link them from index. 4. If the new information contradicts what's there, do NOT silently overwrite. Flag it: note both versions and ask me which holds. 5. If it came from a source, write/append a `sources/` page and cite it. 6. Append one line to `log.md`: date, what changed, why. 7. Tell me, in one short paragraph, what you changed and what you flagged. ``` That last rule, the contradiction flag, is the one people leave out and regret. An agent that silently overwrites will quietly erase a correct note with a wrong one from a bad source. Make it surface the conflict instead. ## An annotated example topic page Here is what one good `topics/` page looks like. The pattern is summary first, then the substance, then links and sources. ```markdown # Postgres connection pooling We run PgBouncer in transaction mode in front of Postgres. App pools are small on purpose; PgBouncer owns the real connection count. This page is the current setup and the reasoning, not the history. ## Current setup - PgBouncer, transaction pooling mode. - App pool size: 5 per process. Web has 8 processes, so 40 app-side max. - PgBouncer default_pool_size: 20. Hard ceiling regardless of app processes. ## Why transaction mode Session mode pinned a server connection for the whole client session, which defeated the point under our request pattern. Transaction mode returns the connection at COMMIT. See [[prepared-statements]] for the one gotcha. ## Open questions - Do we need a separate pool for the analytics jobs? Unresolved. Would be settled by measuring connection wait time during the nightly batch. Sources: [[2026-06-02-pgbouncer-incident]], [[2026-05-18-db-review]] ``` Notice what it is *not*: there is no "on June 2nd we tried X, then on June 5th we changed to Y". That history lives in `log.md` and the source pages. The topic page is only ever the current best answer. That is what makes it cheap for an agent to read and safe to act on. ## Running it in Claude Code Put the `CLAUDE.md` and the folders in a git repo. Open Claude Code in that directory. It reads `CLAUDE.md` automatically, so every session already knows the schema and the loop. Paste in a new article or paste your notes from a meeting and say "fold this in". It does steps one through seven. This is the original Karpathy setup: a vault, Claude Code in a terminal, a schema file, a log. It works well, and if you live in a terminal and want git history, it is genuinely the right choice. ## LLM wiki without Claude Code You do not need Claude Code. The `CLAUDE.md` above is just instructions for an agent that can read and write Markdown. Three ways to run the same pattern without it: - **Claude or ChatGPT projects.** Paste the schema and the loop into the project's custom instructions. Keep the pages as files you upload, or as notes the assistant maintains. - **Any MCP client.** Store the rules as instructions and let the assistant read and write the pages through MCP. More on this below. - **By hand, with any model.** The loop is model-agnostic. Anything that can read and write text can run it. It is just slower without an agent that already knows the rules. The pattern is the folder plus the rules. The client is interchangeable. ## With Obsidian or Logseq An Obsidian vault or a Logseq graph *is* a folder of Markdown files, so the schema drops straight in. Put `CLAUDE.md` at the vault root, point Claude Code at the folder, and the `[[wiki-links]]` in the template render natively in both tools. You get the graph view for free. The limit is not the schema, it is reach. A local vault is readable by the one client wired into it. ChatGPT cannot see it. Your phone cannot see it. If that does not bother you, stay local. If it does, read [LLM wiki with Obsidian vs. a hosted wiki](/blog/llm-wiki-obsidian-vs-hjarni) for the tradeoff in full. ## The hosted version: same schema, every client The local vault has one structural limit: one machine, one client. The fix is to host the wiki and expose it over MCP, so any client reads and writes the same pages. [Hjarni](https://hjarni.com) is that. A knowledge base of Markdown notes, folders, tags, and links, with a built-in MCP server. The `CLAUDE.md` schema maps onto it directly: folders are your `topics/` and `sources/`, links are `[[wiki-links]]`, and the maintenance loop becomes per-folder LLM instructions the assistant follows automatically. The difference is that Claude, ChatGPT, Codex, and Cursor all reach the same wiki, from any device, with no syncing. If you want the schema without assembling it by hand, the [Knowledge Wiki template](/templates/knowledge-wiki) ships it ready-made: topics, sources, open questions, a changelog, and the AI instructions already wired in. Paste the link into Claude or ChatGPT and it builds the structure for you. ## Where to go next - The why behind the pattern: [Karpathy's LLM wiki is right](/blog/karpathys-llm-wiki-is-right). - The hosted, no-terminal setup, step by step: [How to build an LLM wiki with Claude or ChatGPT and MCP](/blog/how-to-build-an-llm-wiki-with-claude-mcp). - When a single Markdown file is still enough: [LLM wiki vs. plain Markdown](/blog/llm-wiki-vs-plain-markdown). --- Start with the file. When you want the same wiki in every AI client instead of just one, [set up Hjarni in five minutes](/docs/getting-started).