LLM Wiki: Karpathy's Pattern, How to Build One, and the Graph Layer

An LLM wiki is a folder of interlinked markdown pages that can help an LLM produce better responses from a knowledge base. In an LLM Wiki, a large language model writes and keeps current from your raw sources — papers, notes, transcripts, data. Andrej Karpathy proposed the pattern in April 2026 as an alternative to retrieval-augmented generation (RAG): rather than re-deriving knowledge from your documents on every query, the model extracts it once, writes it down, and reads its own pages afterwards. The knowledge and memory accumulates in your local folder instead of being recomputed.

It is one of two ways to build the semantic layer of an AI knowledge base, and the pattern works. What it lacks is a view of its own structure. A model reading a wiki page by page has no measure of which concepts hold the material together, which topics have formed, or where the wiki is thin. InfraNodus knowledge graph adds that layer: it represents the wiki as a knowledge graph and analyzes its structure using network science, so the system can tell you not only what it knows but where it is not yet connected and what the main elements and clusters in the graph are.

This page covers what the pattern is, how to build an LLM wiki in Claude Code, Cursor or Obsidian, the open-source implementations on GitHub, and the graph layer. The LLM Wiki skill sets all of it up in one pass, and LLM wiki vs RAG compares the pattern with retrieval.

Set It Up

https://mcp.infranodus.com

https://mcp.infranodus.com

claude mcp add infranodus -s user --transport http https://mcp.infranodus.com/mcp

{
  "mcpServers": {
    "infranodus": {
      "url": "https://mcp.infranodus.com"
    }
  }
}

codex mcp add infranodus --url https://mcp.infranodus.com
codex mcp login infranodus

{
  "mcpServers": {
    "infranodus": {
      "command": "npx",
      "args": ["-y", "infranodus-mcp-server"],
      "env": {
        "INFRANODUS_API_KEY": "your-api-key"
      }
    }
  }
}

/plugin marketplace add infranodus/skills
/plugin install llm-wiki@infranodus-skills

npx skills add infranodus/skills --skill llm-wiki -g -a claude-code -y

$skill-installer install the llm-wiki skill from https://github.com/infranodus/skills

npx skills add infranodus/skills --skill llm-wiki -g -a codex -y

npx skills add infranodus/skills --skill llm-wiki -g

Use the llm-wiki skill to set up an LLM wiki for my research on [topic]. Ask me what sources I have, scaffold the folders and the schema file, ingest the first source, and show me the ontology it produced.

Add Graph View to Your Knowledge Base

What an LLM Wiki Is

The structure is deliberately plain. Three folders and a linking convention:

New material lands in raw/. The model reads it, extracts concepts, relations, and sources, and writes each of them as its own page in wiki/, connected with [[wikilinks]]. Ideas generated from those pages go to output/. When new sources arrive, the wiki is updated rather than rebuilt.

Because the linking convention is the Obsidian one, an Obsidian vault and an LLM wiki are the same folder. You can open it, navigate it, and edit it by hand — but you rarely need to. The model owns the markdown layer; you curate what goes into raw/ and decide what to ask.

This is the difference from a RAG pipeline. RAG embeds chunks, retrieves the closest ones, generates an answer, and discards everything. Cross-references made in one session are gone by the next, and as a chat grows longer its context becomes less relevant, so the results drift towards the generic. A wiki writes its conclusions down. They stay. The full comparison, including where a knowledge graph fits, is in RAG vs. LLM wiki vs. knowledge graph.

How to Build an LLM Wiki Step by Step

The pattern needs no software beyond a coding agent that can read and write files: Claude Code, Cursor, Codex, or OpenClaw. Six steps, in the order they matter.

1 Choose one corpus

Start with one subject, not your whole vault: the thirty PDFs behind a paper, a client's documents, a product's release notes. A wiki that compiles everything you own converges on the generic. One that compiles a focused corpus produces pages you can argue with. Keep the originals where they are and copy them in.

2 Create the folders and the schema file

Make raw/, wiki/ and output/, plus infranodus/ if you want the graph layer. Then write a schema file at the root: CLAUDE.md for Claude Code, AGENTS.md for Codex and Cursor. It tells the agent what each folder holds, how pages are named, which frontmatter they carry, and what to do when a new source arrives. Karpathy's gist is this file in abstract form. The LLM Wiki skill writes a concrete one after asking about your corpus.

3 Ingest

Drop a source into raw/ and ask the agent to process it. It reads the file, creates or updates one page per concept, entity or source in wiki/, links them with [[wikilinks]], and appends to index.md and a log. Ask it to record where the new source contradicts an existing page instead of overwriting the page.

4 Query, then file the answers

Ask questions. The model opens index.md, follows the links to the pages that matter, and answers from them. When an answer is worth keeping, have it written back as a new page or into output/. This is the step that makes the wiki compound: every good answer becomes a source for the next one.

5 Lint

Every few ingests, ask the agent to check the wiki: orphan pages with no inbound links, the same concept under two names, summaries made stale by later sources, claims that two pages state differently. Karpathy's pattern calls this the lint pass. Without it the wiki drifts, and the drift is invisible from inside any single page.

6 Add the graph layer

Generate an ontology of each folder's relations into infranodus/, build the graph, and read the topical clusters and the gaps between them. Then ask across a gap instead of asking in general. The rest of this page explains why that step changes what the wiki can do for you.

What It Cannot See

A wiki is still a pile of pages. The model can scan concepts and follow links, but it has no measure of the shape they form: which concepts are central, which clusters dominate, which parts of the material are barely connected to the rest. Every query starts from a local view.

This has a consequence that gets worse as the wiki grows. Each new page is written in the vocabulary of the pages already there, so the dominant topics keep being reinforced. The knowledge base becomes more coherent and more confident — and progressively less able to surprise you. Without a structural measure there is no way to tell a wiki that is maturing from one that is closing in on itself.

A knowledge base that only accumulates pages converges. What makes it generative is knowing where it is not yet connected.

You could ask the model to assess this. It will produce something plausible and different every time you ask. That is not a diagnosis, it's a guess about a structure the model cannot observe.

The Graph Layer

Represented as a network, the wiki becomes measurable. Concepts (or [[wikilinks]]) are the nodes, their relations are the edges, and the groups they fall into are topical clusters. Graph metrics then describe the structure directly: betweenness centrality identifies the concepts that hold the discourse together, community detection identifies the topics, and the sparse regions between communities are the gaps.

These come from a peer-reviewed text network analysis algorithm applied widely in network science, not from the model's impression of its own notes. Run it twice on the same wiki and you get the same answer — which is what makes it usable as a control signal rather than another opinion.

1 Topics and Central Concepts

The graph shows the dominant themes, their relative weight, and the concepts that act as conceptual gateways between them — nodes with high inter-topical influence relative to their number of connections. Those are the terms worth developing, because a small addition there propagates across the whole structure. It also shows which clusters carry only a few percent of the material: the underdeveloped areas and the patterns just beginning to form.

2 Content Gaps

A content gap is a pair of clusters that both exist in your wiki and are not connected to each other. The material contains both topics; nothing in it relates them. These are the blind spots — and they are the most productive place to work, because a question that bridges two established clusters produces something the material implies but does not yet state.

3 Ontology as Living Memory

Each folder of the wiki also gets an ontology file in infranodus/ — a flat list of relations in [[wikilinks]] syntax describing how its concepts connect. These files are appended to as new sources arrive, never regenerated from scratch, so they hold a current snapshot of the project's structure that is small enough to sit in context. The model reads the ontology to know where it is before it reads any page. This is the bridge between the markdown layer and the network view, and it is what turns a static folder into a memory the system can navigate. Give those relations explicit types and constraints and the ontology stops describing the wiki and starts steering the reasoning over it — see AI reasoning graph.

GraphRAG: Graph Traversal

The graph does more than diagnose the wiki. It changes how the model retrieves from it. Standard retrieval embeds your question, finds the chunks closest to it in vector space, and reads those. That works for lookup and fails in two predictable ways. A general question such as "what is this wiki about?" matches nothing useful, because similarity to the words "what" and "about" is noise. A relational question such as "which approaches does this framework depend on?" returns the chunks that mention "framework" and "approaches", not the things they are connected to. Similarity is not relevance.

With the graph in place, retrieval follows relations instead. The model locates the query concepts as nodes, walks one or two hops along their edges, and collects the statements behind every node it reached, as in the figure above. Some of those statements share no vocabulary with the question. That is the point: the structure of the wiki decided what counts as context, not the wording of the query. Asked about prompt caching, a vector search returns the caching page. A traversal also returns the page on statelessness, because the graph knows that caching exists to compensate for it, and the answer explains the mechanism instead of restating the definition. The LLM wiki vs RAG page shows the three answers side by side.

Three uses follow from this, and they combine. Prompt augmentation: before the model opens any page, it reads the main clusters and rewrites a vague question into a specific one in the wiki's own terms. Relational context: the relations and statements around the query concepts are added to the context, so the model works with how your material connects things, not only with what it says. Topical overview: the clusters, their relative weight and the gateway concepts between them give the model a summary of the whole wiki that no sequence of page reads produces, because index.md lists pages and the graph ranks them. The fourth capability is the one only a graph has: the walk reports which clusters it could not enter, so a retrieval also tells you what the wiki is missing on this question.

In practice this runs over the InfraNodus MCP server. The model calls retrieve_from_knowledge_base with the graph summary enabled for a traversal, generate_contextual_hint for the lightweight overview before a longer task, and the LLM Wiki skill wires both into its query phase. The GraphRAG documentation describes each operation and the API exposes the same retrieval for your own pipeline.

The Workflow

Build the wiki. Sources into raw/, the model extracts concepts and connections into wiki/, ontologies into infranodus/.

Read the structure. Map the concepts into a graph, identify the clusters and the conceptual gateways, and see which topics dominate and which are thin.

Run gap analysis. Surface the clusters that exist but are not linked, and the relations the material implies but never makes.

Ask across the gap. Instead of a general question, give the model the structure and a specific gap, and ask it to connect the two sides. The answer is targeted because the question was.

Each cycle adds pages, which changes the graph, which produces different gaps. The structure of the wiki becomes a feedback loop rather than an archive — the same dynamic described in cognitive variability and used deliberately in thought acupuncture.

From a Gap to a Question

Say the graph of a research wiki shows two well-developed clusters — financial flows and regression analysis — with almost nothing between them. The generic prompt would be:

Explain financial systems.

You already know what that returns. The structural prompt is:

The model now works on a specific conceptual bridge inside material it already has, which is why it produces a research direction rather than a summary. The gap did the hard part: it identified which question was worth asking. Repeated across the graph, this shifts the wiki from information retrieval to insight generation.

Visual or Programmatic

There are two ways to work with the graph layer, and they use the same data.

Visually, through the Obsidian graph view plugin or the VSCode / Cursor extension: explore clusters, click into nodes, see the gaps as you write. Useful when you want to develop a sense of the material's shape.

Programmatically, through the InfraNodus MCP server: the LLM runs the network analysis itself, reads the gaps, and acts on them without you looking at a graph at all. Useful when the wiki updates on a schedule and you want the research questions waiting for you.

Both work. Seeing the structure yourself gives you more control over which gaps are worth bridging — not every gap in a knowledge base should be closed, and some are worth widening.

LLM Wiki in Obsidian

An LLM wiki is already an Obsidian vault: markdown files in a folder, linked with [[wikilinks]]. For the ways to connect Claude to that vault over MCP, and what each lets Claude see, read the Obsidian MCP guide. Open the folder in Obsidian and every page the model wrote appears in the file tree, the backlinks pane and the native graph view. Nothing has to be converted.

Two decisions matter. First, keep the wiki in its own vault or a dedicated folder rather than inside your main notes. The model writes many pages, and the line between what you wrote and what it inferred blurs fast. Second, decide how the model gets in. Claude Code opened in the vault folder is the simplest route: it reads and writes the files directly, and the schema file at the root gives it the rules. Connect the InfraNodus MCP server and it can also request the clusters and gaps of any folder as a tool call, without you opening a graph.

Obsidian's own graph view shows which pages link to which. It does not show which concepts dominate, where the clusters are, or which clusters never touch. The InfraNodus graph view plugin adds that inside Obsidian, and knowledge graphs for personal knowledge management covers the same workflow for a vault you already have.

LLM Wiki Implementations on GitHub

Karpathy's gist describes a pattern, not a program, so every implementation is an interpretation. These are the ones in use as of October 2026. Read each README before installing: the pattern is young and the repositories move fast.

• Karpathy's original gist: the one-page pattern. The folders, the schema file, the ingest, query and lint routines, and the argument for compiling once instead of retrieving on every query.
• infranodus/skills, skill-llm-wiki: the skill documented on this site. It runs in Claude Code, Claude Desktop, Cursor, Codex and OpenClaw, asks about your corpus, writes the schema, scaffolds the folders, and wires ontology generation and gap detection into the ingest and query phases. Documentation and install steps.
• Astro-Han/karpathy-llm-wiki: the pattern packaged as a single agent skill for Claude Code, Cursor, Codex and other skill-aware tools.
• ignromanov/llm-obsidian-wiki: a Claude Code plugin that captures URLs, PDFs, GitHub repositories and YouTube transcripts and compiles them into an Obsidian vault.
• green-dalii/obsidian-llm-wiki: an Obsidian plugin with a model provider setting (Anthropic, OpenAI, Gemini, DeepSeek, Ollama), so the wiki is built from inside Obsidian.
• Ar9av/obsidian-wiki: a framework whose setup script installs the same skills into several coding agents and tracks which sources changed since the last compile.
• lewislulu/llm-wiki-skill: an OpenClaw and Codex skill with an Obsidian audit plugin and a local web preview of the wiki.
• atomicmemory/llm-wiki-compiler: a TypeScript compiler that treats the wiki build as a deterministic step rather than a conversation.

They differ in packaging. What they share is the output: pages and links. None of them, going by their READMEs, measures the structure of what was compiled, which is what the graph layer above adds.

Set It Up

The LLM Wiki skill scaffolds the whole structure for you, following Karpathy's specification with the graph layer wired in. It runs in Claude Code, Cursor, or any other client with skills enabled, and it is open source on GitHub if you prefer to adapt the template to your own conventions.

• LLM Wiki skill — sets up the folder structure, schema, and workflows, with ontology generation and gap detection at each stage.
• InfraNodus MCP server — gives your LLM real-time network analysis of the connections in your wiki.
• VSCode / Cursor extension — topics and gaps for any page or folder, inside the IDE.
• Obsidian graph view plugin — network analysis on top of an existing vault.
• API and GraphRAG endpoints — for building the analysis into your own pipeline.

If you already keep notes in Obsidian, Roam, or Logseq, you can start from the graph side instead — see knowledge graphs for personal knowledge management. If you are starting from nothing, building a personal knowledge base covers the files, folders, and viewer first, and the AI second brain assembles the whole workflow.

FAQ

Build Your Own LLM Wiki

Connect your notes, papers, and data to a knowledge graph that shows you the topics, the central concepts, and the gaps between them: