Build a personal knowledge base wiki that a coding agent maintains from your notes
Follow the "LLM wiki" pattern Andrej Karpathy described in April 2026. Keep raw sources in one folder the agent never edits, let a coding agent write and update linked markdown pages in a wiki folder, and give it a schema file (CLAUDE.md or AGENTS.md) with your conventions. You add a source, the agent ingests it across the pages it touches, and you review the diff in git. People who ran it for months report drift between pages, duplicate entities and dead links, so add a regular lint pass and keep everything under version control.
You have a folder of interlinked markdown pages with an index and a change log, built from your sources, that you can read in Obsidian and query through the agent, with every change reviewable in git.
- Difficulty
- Intermediate
- Time
- 1-2 hours to set up, then a few minutes per source
- Sources
- 5 · 5 independent
- Updated
- 2026-10-13
- Cost:
- Included in a Claude, ChatGPT or Gemini plan that includes the coding agent. Obsidian is free for personal use.
The prompt
Fill the blanks here, or leave them for your agent to ask. Pick the tab for your agent. The hand-off button gives any agent this page as markdown.
You maintain my personal wiki in this folder. Read SCHEMA.md [or CLAUDE.md / AGENTS.md] first, every time. Layout: - raw/ holds my sources (articles, notes, transcripts, PDFs). Never edit, move or delete anything in raw/. - wiki/ holds pages you write. One page per entity or concept, named by its title. Link pages with [[wikilinks]]. - wiki/index.md lists every page with a one-line description. - wiki/log.md is append-only. Add one dated line per change. Task: ingest [raw/2026-10-13-article-name.md]. 1. Read the source. List the entities and concepts it mentions. 2. For each one, search wiki/ for an existing page first, including other spellings and names. Update that page instead of creating a duplicate. 3. Add new facts with a link back to the source file. If the source contradicts a page, keep both claims, mark the conflict, and add it to the "Conflicts" section of wiki/index.md. 4. When a fact changes, update the reference sections of the page, not just a changelog line. 5. Create pages only for things that matter to [my interests: topic A, topic B]. 6. Update wiki/index.md and append to wiki/log.md. 7. Show me the list of changed files and the diff summary. Do not commit. Do not delete, merge or rename pages without asking.
Human checkpoints: the agent stops and asks you
- Approve the schema file before the first ingest.
- Review the diff of every ingest before you commit it.
- Approve any page deletion, merge or rename.
The agent rewrites files in bulk. Keep the vault in git, keep raw sources read-only, and review diffs, or a bad ingest can quietly change many pages.
What you need
- A notes folder under gitdata
Git lets you review and undo every ingest.
- A coding agent that can read and write local filesapp
For reading the wiki and its links. Any markdown viewer works.
- A schema filedata
CLAUDE.md, AGENTS.md or GEMINI.md with your conventions.
Steps
Put the folder under git and split raw from wiki
Create raw/ and wiki/, add wiki/index.md and wiki/log.md, and commit. Make raw/ read-only in the schema rules.
Check: git status is clean and the two folders exist.
Write the schema with the agent
Ask the agent to propose the schema: page types, naming, links, source citations, conflicts, and the ingest, query and lint steps. Edit it until it matches how you think.
Check: The schema is short, and you agree with every rule in it.
Ingest one source and review the diff
Run the ingest prompt on one source. Read every changed page in the diff before you commit.
Check: Each new fact links to its source, and no page was duplicated.
Ingest in small batches
Add sources one at a time or a few at a time, committing after each. Large batches make diffs hard to review.
Check: Each commit holds one ingest and its log line.
Query the wiki, and file good answers back
Ask questions against the wiki. When an answer is useful, ask the agent to save it as a page with links to the pages it used.
Check: Answers cite wiki pages, and those pages cite raw sources.
Lint on a schedule
Run a lint pass weekly or after every ten sources: orphan pages, dead links, duplicate entities and stale reference sections. Approve fixes one by one.
Check: The lint report shrinks over time and you approved each fix.
Add search when the wiki outgrows the index
When the index and pages no longer fit the agent's context, add per-folder indexes or a local search tool, and keep the wiki as the main record.
Check: The agent still finds the right pages for your questions.
What goes wrong
Changelog entries say one thing while the page's main text still describes the old state.
Fix: Make the schema require updating reference sections, not just logs, and lint for retired terms. One user's linter found nine files still describing an old publishing setup.
Two pages describe the same entity under different names, so counts and answers double up.
Fix: Require a search for existing pages and other names before creating one, and keep one file per entity named by its link text.
Orphan pages and dead links pile up as the wiki grows.
Fix: Lint weekly, not occasionally. One user found occasional linting was not enough at about 300 pages.
The agent reads the wiki at the start but forgets to check it while working.
Fix: Add rules for when to look things up, for example before diagnosing a known problem.
A bulk ingest or reorganisation deletes or overwrites files.
Fix: Keep the folder in git, forbid deletes in the schema, and review the diff before every commit.
Read the lesson →You stop thinking about the material because the agent writes everything.
Fix: Discuss a source with the agent until you understand it, then ingest. One writer keeps every card human-verified for this reason.
Evidence
Two or more public accounts from different people or sites describe the same job. We summarise each source in our own words. Open the original before you rely on it.
- GitHub2026-04-04llm-wiki (idea file)
Karpathy describes raw sources, an agent-maintained wiki and a schema file, with ingest, query and lint operations. He says the index-based approach works at moderate scale, around a hundred sources.
Andrej Karpathy · gist.github.com - Blog2026-08-13· Claude CodeKarpathy's LLM wiki works. Here's what broke when I ran it at real scale
After about six months and several hundred pages maintained by Claude, he reports drift between change logs and reference text, duplicate entities that double-counted, and orphan pages. Linters, a one-file-per-entity rule and a weekly lint fixed most of it.
Michael Tuszynski · mpt.solutions - Blog2026-04-10· Claude CodeKarpathy's LLM wiki compared with a Zettelkasten
The author ran the ingest method on seven sources next to his own Obsidian system built with Claude Code. He kept his system but plans to adopt the contradiction checks and lint, and verifies every card himself.
WenHao Yu · yu-wenhao.com - Blog2026-04-11· Claude CodeHow Karpathy's LLM wiki and Obsidian changed my Claude Code workflow
The author built a layered setup with a code graph, CLAUDE.md rules and Obsidian, and reports far fewer tokens per session. He does not describe how he measured it, and a commenter warns the wiki is one more thing to maintain.
Ketan Chavan · ketanchavan.substack.com - GitHub2026-09-21· Claude CodeComment on the llm-wiki gist about a small agent-written wiki
The commenter audited nine sessions on a 15-page wiki written by Claude and Codex. The agent read the wiki at session start but not mid-task, and twice re-diagnosed a problem that already had a written lesson.
orcosto-lab · gist.github.com
- How Claude remembers your project (CLAUDE.md and AGENTS.md)checked 2026-10-13
- Gemini CLI commands (/init and GEMINI.md)checked 2026-10-13
Report how it went
Every report makes this page better for the next person and the next agent. Reports are reviewed before they count. Agents can report with the report_run tool.
Loading reports…