LLM Wiki Complete Guide: Build a Cumulative AI Knowledge Base with Claude Code

What This Document Is

If you often upload articles, papers, or meeting notes to ChatGPT or NotebookLM, you have probably run into the same thing: you come back to the same material a few days later, and it reads everything from the beginning again. The questions you asked and the conclusions it drew disappear when the conversation ends.

Andrej Karpathy published a gist on GitHub titled LLM Wiki, which proposes a different approach: have an LLM organize the material you collect into a continuously updated markdown wiki. You find the sources and ask the questions; the LLM handles the chores of organizing, cross-referencing, and recording.

This guide breaks that gist into steps you can actually follow, and demonstrates them with Claude Code.

How to read this document

On your first read, we suggest going from the beginning through “Build Your First Wiki in 15 Minutes.” Once you finish that, you can start using it. You can come back to the later chapters to look things up as you go.

What comes from the original and what is this guide’s design

Karpathy’s gist explains itself as an idea file. It only describes concepts. The concrete directory structure, page formats, and tools are for you and your own LLM Agent to decide.

So this guide covers two kinds of content:

• Concepts from the original: the three-layer architecture, the three actions Ingest, Query, and Lint, and the two special files index.md and log.md. Each chapter marks what comes from the gist.
• Designs from this implementation: folder naming, the Schema template, and the prompts. These are one approach I put together. You can use them as they are, or adjust them for your own field.

Example environment

• Use Claude Code as the LLM Agent, running inside the wiki folder.
• Use Obsidian as the reading tool, keeping it open to see which pages the LLM just changed.
• The wiki itself is a git repository that holds markdown files.

I use both Obsidian and Notion myself. The workflow in this guide is not tied to any specific software. As long as the LLM can read and write those markdown files, it works.

Next step

You don’t need to install anything yet. Pick a topic you have been collecting for a while but that is scattered across different places, such as articles on a framework, a book you are reading, or meeting notes from a client. The next chapter uses it to compare RAG and LLM Wiki.

Sources: Andrej Karpathy’s LLM Wiki gist (queried 2026-11-05).

Why RAG Does Not Accumulate Knowledge

You upload ten documents to NotebookLM or ChatGPT’s file upload and ask a question that can only be answered by synthesizing five of them. It finds the relevant fragments from the files and assembles an answer.

The next day you ask a similar question, and it searches again from scratch and assembles the answer again from scratch. The conclusion it assembled last time is not kept anywhere.

How RAG works

The RAG (Retrieval-Augmented Generation) flow is:

1. Split the documents into fragments and build an index.
2. When you ask a question, the system finds the most relevant fragments.
3. The fragments and the question are passed to the LLM together to produce an answer.

Karpathy’s gist points out that NotebookLM, ChatGPT’s file upload, and most RAG systems work this way. Each time you ask a question, the LLM rediscovers the knowledge from the original documents. Nothing is accumulated.

How LLM Wiki works

LLM Wiki moves the point in time earlier. Each time you add a new source, the LLM reads it first, extracts the key points, and then integrates them into the wiki that already exists: it updates the related pages, corrects the summaries, and flags where the new source contradicts older claims.

The knowledge is organized once and then kept up to date, instead of being re-derived every time you ask a question. The gist sums up the difference in one sentence: the wiki is a continuously accumulating artifact, with cross-references already in place, contradictions already flagged, and synthesized conclusions that reflect every source you have read.

Comparison table

When to still use RAG

LLM Wiki is not meant to replace RAG. RAG is a better fit in two situations:

• A very large amount of data, where you only need to look up specific fragments: for example, a customer service bot that needs to find one particular rule among thousands of documents does not need to integrate those documents into one overall understanding.
• The data is not something you are accumulating yourself: for example, a public document library where you only need to query it and do not need to maintain your own organized version.

The gist mentions that an index-style approach such as index.md works well at a scale of roughly 100 sources and several hundred pages, without building a separate embedding retrieval. Beyond that scale, adding a search tool helps; later chapters cover that.

I have written before about building a customer service bot with n8n, Google Drive, and Pinecone. That is a typical RAG scenario, and you can read it alongside this guide: How to Build a Company-Owned Line Customer Service AI Bot with N8N, Google Drive + RAG (Traditional Chinese).

Next step

Look back at the topic you picked in the previous chapter, and write down the three questions you ask an LLM about it most often. If the answers to those three questions each require synthesizing several sources, that topic is a good candidate for an LLM Wiki.

Sources: The “The core idea” and “Indexing and logging” sections of Andrej Karpathy’s LLM Wiki gist (queried 2026-11-05). The “What you do” row of the comparison table is this guide’s own summary.

Three-Layer Architecture

To have an LLM maintain a wiki over the long term, the first thing to settle is who may change what. If the raw sources and the organized pages sit in the same folder, the LLM can easily alter the originals while it is tidying things up. A few weeks later, you can no longer tell which parts are the original text and which are its interpretation.

The gist divides the whole system into three layers.

What each layer is responsible for

Raw sources: immutable original material

This layer is your source of truth. The LLM reads from it but does not modify it. This has two benefits: any claim on a wiki page can be checked against the original source, and if the LLM organizes something incorrectly, the original is still there and you can start over.

Wiki: the layer the LLM owns

The wiki is a folder full of markdown files. The LLM is responsible for creating pages, updating them when new sources come in, maintaining the links between pages, and keeping the content consistent. You are responsible for reading.

The gist uses a software development analogy: Obsidian is the IDE, the LLM is the engineer, and the wiki is the codebase. You browse in Obsidian while the LLM changes the files based on your conversation, and you see the results in real time.

Schema: making the LLM a disciplined maintainer

The Schema is a document that tells the LLM the wiki’s structure, its naming rules, and the procedures to follow when new sources arrive, when questions are answered, and when the wiki is health-checked. Claude Code reads CLAUDE.md, and Codex reads AGENTS.md.

Without a Schema, the LLM is just a general chatbot, organizing things differently in every conversation. With a Schema, every new session starts from the same set of rules. The gist also stresses that this document should be adjusted gradually as you use it, so that it fits your field.

What the folder looks like

The structure this guide demonstrates:

my-wiki/
├── CLAUDE.md          # schema
├── raw/               # sources, read-only
│   └── assets/        # downloaded images
└── wiki/              # owned by the LLM
    ├── index.md       # catalog of all pages
    ├── log.md         # append-only timeline
    ├── sources/       # one summary page per source
    ├── entities/      # people, products, organizations
    └── concepts/      # ideas and topics

The three subfolders sources, entities, and concepts are part of this guide’s design. The gist only mentions that the wiki will contain summaries, entity pages, concept pages, comparisons, and overviews, and it does not prescribe folders. If your field does not divide up this way, use a split that suits it, as long as you write it into the Schema.

Next step

On your computer, create an empty folder named my-wiki, and do not put any files in it yet. The next chapter starts from this empty folder and uses Claude Code to build the whole structure.

Sources: The “Architecture” and “The core idea” sections of Andrej Karpathy’s LLM Wiki gist (queried 2026-11-05). The folder structure is this guide’s design.

Build Your First Wiki in 15 Minutes

If you just want to see what using an LLM Wiki actually feels like, follow these steps in order. When you are done, you will have a working wiki with the first source added.

1. Create the folders

mkdir -p my-wiki/raw/assets my-wiki/wiki/{sources,entities,concepts}  # 1. Folders
cd my-wiki
touch CLAUDE.md wiki/index.md wiki/log.md                             # 2. Empty files
git init                                                              # 3. Version history

git init is intentional. The wiki is a repository of markdown files. Each time the LLM makes changes, you can use git diff to see which pages it touched, and roll back anything you are not happy with.

2. Write a minimal Schema

Open CLAUDE.md and paste in this short section. The full template is in the next chapter. For now, the LLM only needs the most basic rules:

# My Wiki

This is a personal knowledge base maintained by an LLM. The topic is: <your topic>

## Directory

- `raw/`: Raw sources. Read-only. Do not modify.
- `wiki/`: Pages you maintain.
- `wiki/index.md`: Catalog of all pages. Update it on every ingest.
- `wiki/log.md`: Chronological record of actions. Only append to the end.

## Rules

- Write all wiki pages in English.
- Link pages to each other with `[[page name]]`.
- After adding or modifying a page, always update `wiki/index.md` and append one entry to `wiki/log.md`.

3. Add the first source

Find an article you want to organize, save it as markdown, and put it in raw/. If the article is on a web page, you can use a browser extension (for example, Obsidian Web Clipper) to convert it to markdown, or you can simply copy and paste it:

cat > raw/first-article.md   # Paste the article, then Ctrl+D

4. Start Claude Code and run the first Ingest

claude   # Start in the my-wiki folder

Then enter:

Read raw/first-article.md, and integrate it into the wiki following the rules in CLAUDE.md.
First tell me the three key points you read, then start writing pages.

Claude Code will first discuss the key points with you. After you confirm, it creates a summary page and any related concept pages, updates index.md, and appends one entry to log.md.

5. Check the results

git status --short   # Which files changed
git diff             # What exactly changed
cat wiki/log.md      # The new log entry

Focus on three things: whether there is a new summary page under wiki/sources/, whether wiki/index.md has gained the matching entry, and whether the last line of log.md follows the format ## [date] ingest | article title.

If you are satisfied, run git add -A && git commit -m "ingest: first-article". If you are not, tell Claude Code what needs to change, and check the diff again after it has made the changes.

Common issues

Next step

We suggest doing just one thing: add a second source on the same topic, and repeat step 4. Compare the first and second git diff. In the second one, you should see the LLM modify existing pages, not only add new ones. This is what makes an LLM Wiki different from a simple summarization tool.

Sources: The “Operations” and “Indexing and logging” sections of Andrej Karpathy’s LLM Wiki gist (queried 2026-11-05). The commands and Schema content are this guide’s design.

Writing a Good Schema

The Schema is the most important file in the whole system. The LLM has no memory of its own, and every new session starts from zero. To know what this wiki looks like and which procedures to follow this time, it relies on CLAUDE.md.

The gist calls the Schema the key configuration file: it turns the LLM into a disciplined wiki maintainer rather than a general chatbot. It also stresses that this document is something you and the LLM refine together as you use it.

What the Schema should cover

Full template

The template below can be copied directly into CLAUDE.md. Replace the “topic” and “page types” with your own field:

# My Wiki

This is a knowledge base maintained by an LLM. The topic is: <your topic>.
You are responsible for organizing and maintaining the wiki. I am responsible for selecting sources and asking questions.

## Directory structure

- `raw/`: Raw sources. Read-only. Never modify or delete.
- `raw/assets/`: Images from the raw sources.
- `wiki/`: Pages you own. All organized content goes here.
- `wiki/index.md`: Catalog of all pages.
- `wiki/log.md`: Chronological record. Only append to the end.
- `wiki/sources/`: One summary page per raw source.
- `wiki/entities/`: People, products, and organizations. One object per page.
- `wiki/concepts/`: Concepts and topics. One concept per page.

## Page format

Every page must have frontmatter:

```yaml
---
type: source | entity | concept
tags: []
sources: [] # raw/ files this page is based on
updated: YYYY-MM-DD
---
```

- File names use lowercase English letters and hyphens, for example `retrieval-augmented-generation.md`.
- Link pages to each other with `[[filename]]`, without the file extension.
- Every claim must state which `sources/` page it comes from.
- Summary pages always end with a section titled "Relationship to existing content" that states which pages this source adds to, corrects, or contradicts.

## Ingest: when new material arrives

1. Read the file specified in `raw/`.
2. First tell me three to five key points, and wait for my response before continuing.
3. Create a summary page in `wiki/sources/`.
4. Update the related entities and concepts pages. For important concepts that have no matching page, create a new page.
5. When new material contradicts existing claims, keep both, and mark the contradiction clearly on the page.
6. Update `wiki/index.md`.
7. Append one entry to `wiki/log.md`.

## Query: answering questions

1. Read `wiki/index.md` first, find the relevant pages, and then read those pages.
2. When answering, state which pages the answer is sourced from.
3. If the answer is a new synthesis, comparison, or conclusion, ask me whether to save it as a wiki page.

## Lint: health check

Check and report. Ask me before making any changes:

- Claims on different pages that contradict each other
- Outdated claims that have been replaced by new material
- Orphan pages that no other page links to
- Concepts that are mentioned many times but have no page of their own
- Missing cross-links
- Gaps in the material that can be filled with a web search

## log.md format

Each entry starts with a fixed prefix:

```text
## [YYYY-MM-DD] ingest | source title
## [YYYY-MM-DD] query | query summary
## [YYYY-MM-DD] lint | lint scope
```

Below that, add one to three lines describing which pages were changed.

When to revise the Schema

The template is a starting point. In practice, these situations are signals that you should come back and revise the Schema:

• You keep having to verbally correct the LLM on the same thing. Write it into the Schema.
• You notice that a certain type of page needs fixed fields, such as the author and publication year for a book. Add them to the page format.
• A certain kind of source only needs simple handling. Write a separate “lightweight ingest” workflow for it.

The gist suggests that you decide whether to process one source at a time and stay involved throughout, or to process many sources in a batch with less intervention. Once you have chosen a workflow, write it into the Schema so that the next session follows it.

Next step

Copy the template above and change only two things: the topic and the page types. Then enter /memory in Claude Code to confirm that CLAUDE.md is loaded. For how loading and path rules work, see the CLAUDE.md and memory system in the Claude Code guide.

Sources: The “The schema” and “Operations” sections of Andrej Karpathy’s LLM Wiki gist (queried 2026-11-05). The template content is this guide’s design.

Ingest: Add One Source

Ingest is the action you perform every day in an LLM Wiki: you hand a new source to the LLM and have it integrated into the wiki. How well this step is done determines whether the wiki becomes more valuable the longer you use it.

What Ingest actually does

The flow described in the gist is:

1. The LLM reads the source and discusses the key points with you.
2. It writes a summary page in the wiki.
3. It updates index.md.
4. It updates the related entity and concept pages across the wiki.
5. It appends one entry to log.md.

A single source may touch 10 to 15 pages. This is also why it is hard for people to maintain a wiki over the long term: the difficulty is not reading everything, but updating that many places every time.

One at a time, or many at once

The gist’s author personally prefers processing one source at a time and staying fully involved. When you are starting out, we suggest doing the same. Once the Schema is stable, use batch processing to catch up on large amounts of older material.

Prompt examples

Processing one source at a time:

Read raw/rag-survey.md, and integrate it into the wiki following the Ingest workflow in CLAUDE.md.
First tell me the key points you read, and wait for my confirmation before you start changing pages.
For this one, I want to emphasize: the comparison of retrieval strategies.

Batch processing:

There are 12 new sources under raw/inbox/.
Process them one by one following the Ingest workflow in CLAUDE.md, and append one entry to log.md after each one is done.
When everything is finished, list the pages you changed and any places where there are contradictions.

How to check whether the LLM did it right

Do not just check whether it says “done.” Look at the actual changes with git:

git diff --stat      # Files touched and line counts
git diff wiki/       # Full content of the changes
git log --oneline -5 # Recent commits

Check four things:

• Whether raw/ was touched: git diff --stat raw/ should produce no output.
• Whether the summary page includes “Relationship to existing content”: this shows whether it compared the source against the older pages.
• Whether index.md has a matching new entry.
• The format of the last log.md entry: for example, ## [2026-11-05] ingest | RAG research survey.

Keep contradictions, do not let them be silently overwritten

When new material says something different from an older page, the most dangerous outcome is for the LLM to simply replace the old claim with the new one. You do not know which one is right, and you lose the record that the view was once overturned.

The Schema template already covers this: keep both, and mark the contradiction clearly. When you review the diff after an Ingest, look specifically for this kind of marking and decide which side to adopt.

Next step

Pick the longest source you have on hand, and run an Ingest on it using the “one at a time” approach. When you are done, count how many pages were touched using git diff --stat. If only the summary page changed, go back and check whether step 4 of the Ingest workflow in CLAUDE.md is spelled out clearly.

Sources: The Ingest paragraph of the “Operations” section of Andrej Karpathy’s LLM Wiki gist (queried 2026-11-05). The prompts and checklist are this guide’s design.

Query: Ask Questions and Save the Answers Back

Once the wiki is built, you can ask it questions directly. The biggest difference from ordinary chat is this: a good answer should not stay only in the conversation history. It should be saved back to the wiki as a page you can cite next time.

How the LLM finds answers

Following the gist’s approach, when the LLM answers a question it:

1. Reads index.md first to find the pages that may be relevant.
2. Goes into those pages and reads their content.
3. Synthesizes an answer and cites the pages it used.

This approach works well at a scale of roughly 100 sources and several hundred pages, without building a separate embedding retrieval. index.md is its map, so you must keep it well maintained during Ingest.

Answers do not have to be text

The gist notes that answers can take different forms depending on the question:

Prompt examples

Compare the three retrieval strategies mentioned in the wiki. Present them in a table,
and mark the source page for each cell.

Based on the wiki's content, if we were to adopt RAG inside our company, what is the biggest risk?
Please state which pages the answer relies on,
and point out where the wiki's current material is insufficient.

The last part of the second prompt matters a lot. Asking it to point out where the material is insufficient prevents the LLM from filling gaps with its own knowledge, which may look reasonable but is not actually in your wiki.

What answers to save back to the wiki

Not every answer is worth saving. In these three cases, we suggest saving it as a new page:

• A conclusion that synthesizes several pages: you will not need to reassemble it next time.
• An answer you spent time following up on and refining: the process itself is valuable.
• A comparison or analysis you will cite again later.

For a one-off question or a simple fact lookup, there is no need to save.

The command to save it back:

Save the comparison above as wiki/concepts/retrieval-strategies.md,
add frontmatter following the page format, update index.md, and append a query entry to log.md.

Once saved, this page works just like a page produced by Ingest: it has links, it is checked by Lint, and it can be cited by later Queries. Your questions therefore accumulate in the wiki as well.

Next step

Ask a question that requires synthesizing at least three pages of the wiki’s existing content. When you get the answer, check whether it cites the source pages. If the answer is worth keeping, save it as a new page with the command above, and then look at git diff again.

Sources: The Query paragraph of the “Operations” section and the “Indexing and logging” section of Andrej Karpathy’s LLM Wiki gist (queried 2026-11-05). The prompts and the criteria for saving answers are this guide’s summary.

Lint: Regular Health Checks

After the wiki has been in use for a few weeks, you will start running into a few situations: the same concept is explained differently on two pages, a conclusion has been overturned by new material but the page still says the old thing, and some pages have been written and then no one links to them anymore.

Lint means periodically asking the LLM to check the entire wiki and surface these problems.

What to check

The checklist items from the gist:

The LLM is also good at suggesting new questions to research and new sources to look for.

Prompt example

Following the Lint workflow in CLAUDE.md, check the entire wiki.
First list all the problems, sorted by severity, and mark the related pages for each item.
Do not modify any files yet. Wait until I decide which ones to address.

The Schema template says “check and report, and ask me before making changes.” The reason is that the scope of changes from Lint is usually large, so you need to review the list before deciding what to change.

Scan with commands first

Some items do not need the LLM and can be found with simple commands. Below is a way to find orphan pages (when pages are linked with [[filename]]):

for f in $(find wiki -name '*.md' ! -name index.md ! -name log.md); do
  n=$(basename "$f" .md)
  grep -rlF "[[$n]]" wiki >/dev/null || echo "$f"   # No inbound link
done

Each line of output is a file that no other page links to.

Because every log.md entry has a fixed prefix, you can also view the most recent entries directly with a command:

grep "^## \[" wiki/log.md | tail -5   # Last 5 entries

How often to run it

The gist only says “periodically.” You can start with this rhythm and adjust it later based on your situation:

• After every 5 to 10 Ingests, run a full Lint.
• When a page’s content does not match what you remember, run a targeted Lint on that topic.

If you want to schedule it to run automatically, Claude Code’s headless mode can do that. For details, see the automation chapter of the Claude Code guide. For scheduled runs, we suggest keeping them to “report only, no changes,” so that you still decide what to modify after reviewing the list.

Next step

Run a Lint now using the prompt above. When you look at the results, deal with only one type of problem. We suggest starting with contradictions, because that is where the wiki is most likely to make you trust incorrect information. When you are done, append a lint entry to log.md.

Sources: The Lint paragraph of the “Operations” section and the “Indexing and logging” section of Andrej Karpathy’s LLM Wiki gist (queried 2026-11-05). The prompt, commands, and frequency suggestions are this guide’s summary.