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. 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.

# 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/<kebab-title>.md`: one page per durable topic. Living summaries.
- `sources/<yyyy-mm-dd>-<slug>.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.

# 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 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 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 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.
• The hosted, no-terminal setup, step by step: How to build an LLM wiki with Claude or ChatGPT and MCP.
• When a single Markdown file is still enough: 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.