LLM Wiki

This note has two halves. The first is the idea: a pattern for building a personal knowledge base that an LLM writes and maintains for you, inspired by Andrej Karpathy. The second is the build: how I turned that idea into a working wiki skill that scans folders across my machine, ingests any file type, and keeps a cross-linked markdown wiki current, mostly while I sleep. Paths below are repo-relative; I have genericised absolute locations.

The core idea

Most people's experience with LLMs and documents is RAG: upload files, the model retrieves relevant chunks at query time, generates an answer. It works, but the LLM rediscovers knowledge from scratch on every question. Nothing accumulates. Ask something that needs synthesizing five documents and it has to find and piece together the fragments every single time.

The idea here is different. Instead of retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki: a structured, interlinked set of markdown files that sits between you and the raw sources. When you add a source, the LLM reads it, extracts the key information, and integrates it into the existing wiki, updating entity pages, revising summaries, flagging where new data contradicts old claims. The knowledge is compiled once and then kept current, not re-derived on every query.

That is the whole point: the wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. You rarely write any of it yourself. You curate sources, explore, and ask good questions; the LLM does the summarizing, cross-referencing, filing, and bookkeeping that makes a knowledge base actually useful over time.

The pattern fits many contexts: tracking your own health and goals, going deep on a research topic over months, building a companion wiki as you read a book (think fan wikis like Tolkien Gateway, but personal), or a team wiki fed by call transcripts and project docs that stays current because the LLM does the maintenance nobody wants to do.

The three layers

Raw sources. Your curated source documents. Immutable. The LLM reads them, never modifies them. Your source of truth.

The wiki. A directory of LLM-generated markdown: summaries, entity pages, concept pages, comparisons, an index. The LLM owns this layer entirely, creating and updating pages and maintaining cross-references. You read it; the LLM writes it.

The schema. A rulebook document telling the LLM how the wiki is structured, the conventions, and the workflows for ingesting, answering, and maintaining. This is what turns the model from a generic chatbot into a disciplined wiki maintainer. You co-evolve it over time.

How I built it

The idea above is intentionally abstract. Here is my concrete instantiation: a Claude Code skill that maintains a B2B sales knowledge base for my day job. It has grown to 331 wiki pages built from 247 tracked source files.

Where it lives and how I trigger it

The wiki content sits at kb/wiki/; the skill and its machinery at .claude/skills/wiki/. A SCHEMA.md is the law (hard rules, taxonomy, frontmatter spec), a SKILL.md is the operator's guide. I drive it with plain phrases:

• wiki update scans the watched folders and ingests anything new or changed.
• /wiki {information} integrates a fact I give it directly (sources: nic-direct-input).
• wiki lint health-checks the wiki for contradictions, stale claims, and orphan pages.
• what does the wiki say about X queries it: read the index, drill into pages, answer with citations.

Watched folders and the scanner

watched-folders.json is a hand-edited list of folders to scan (a competitive-intel folder, a processed-email output folder, a master-decks folder), each with optional include/exclude globs and an enabled flag to park one without deleting it. A small scan.py walks them, hashes every supported file with SHA-256, diffs against a processed.json manifest, and writes a pending.json queue of what is new or changed. Because dedup is by content hash, re-running is cheap and nothing gets processed twice. Sources are read strictly read-only; files are never moved or touched.

Routing by file type

Each pending file is routed to the right extractor, which is the "if/then by file type" logic that makes it handle anything:

Integration and the rules that keep it honest

Extracted knowledge runs through one integrate() routine (same for files and direct text): scope-filter it, classify which entities and domains it touches, read the existing pages via the index, then update every page it affects, adding facts, appending the source, refreshing the updated date, and flagging contradictions. New pages are created only when nothing fits. A single source can touch 10-15 pages.

The schema's hard rules are what stop it drifting into a generic chatbot:

• Provenance only. Every fact traces to an ingested source in the page's sources: frontmatter. No world knowledge, no completing from model memory. Inferences are labelled as such.
• Never overwrite silently. When new info contradicts an existing claim, both are kept: the page is updated, the superseded claim marked, the conflict recorded. A recent run refreshed a competitor battlecard from two vendor doc links and flagged two contradictions between old and new capacity figures, keeping the newer as primary.
• Scope filter. The wiki holds domain knowledge (products, platform, competitors, market, selling plays). Account-specific or client-internal intel is explicitly excluded and sent elsewhere.
• Vision via subagents, never a raw API. Every page carries mandatory frontmatter (type, domain, tags, summary, status, confidence, created, updated, sources, related), and pages are one of six types: entity, concept, comparison, playbook, reference, or source-note.

Index, changelogs, and no silent edits

After every content change, build_wiki_index.py rebuilds _index.md, a catalog with one line per page (path, type, tags, one-line summary). At query time the LLM reads the index first, then drills in, which works well into the hundreds of pages with no embedding/RAG infrastructure. Every run also writes a timestamped changelog to updates/ recording files ingested, pages created and updated, contradictions flagged, and anything quarantined. No update is silent.

Nightly automation

A macOS LaunchAgent runs the whole thing at 02:30. A wrapper script scans first and only invokes Claude Code headless if the queue is non-empty. The unattended wiki update --auto mode adds guardrails: integrate high-confidence extractions only, send medium/low to a quarantine folder for my review, cap each run at 10 files and ~200k extraction tokens, never auto-transcribe media longer than ~45 minutes, and never ask a question, when in doubt, quarantine. New pages land before the morning, reviewed at my pace.

By the numbers

Of 247 tracked files, 148 were integrated and 99 skipped as out of scope, exactly the scope filter doing its job. Eight logged runs so far, each with its own changelog. I browse the result in an editor like Obsidian (graph view is the best way to see the wiki's shape), but unlike the hands-on-in-Obsidian version of the idea, my maintenance is automated: the LLM is the maintainer, the nightly job is the clock.

Why this works

The tedious part of a knowledge base is not the reading or the thinking, it is the bookkeeping: updating cross-references, keeping summaries current, noting when new data contradicts old claims, staying consistent across hundreds of pages. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs do not get bored, do not forget a cross-reference, and can touch 15 files in one pass. The wiki stays maintained because the cost of maintenance is near zero.

The idea is Vannevar Bush's Memex (1945) with the missing piece supplied: a private, actively curated knowledge store with associative trails between documents. Bush could not solve who does the maintenance. The LLM does.

Caveats

This is one instantiation, not the only one. The directory structure, schema conventions, page formats, and tooling all depend on your domain and your LLM of choice. Everything is modular: text-only sources need no image handling; a small wiki needs no search engine beyond the index; you may want different output formats entirely. As the wiki grows past the point where the index is enough, a local markdown search engine like qmd (hybrid BM25 + vector, on-device, with a CLI and MCP server) is the obvious next tool. The right way to use the pattern is to hand it to your agent and build the version that fits you.

Further reading

qmd

Local markdown search engine (BM25 + vector, CLI + MCP) for scaling the wiki

https://github.com/tobi/qmd

Obsidian

Markdown editor with graph view, good for browsing an LLM-built wiki

https://obsidian.md

ntr