A self-maintaining personal knowledge base. Markdown files in folders. No plugins, no vector DB, no Obsidian.
The pattern is from Andrej Karpathy's gist (April 2026). His own wiki on a single topic is now 100+ articles, 400K words, all maintained by an LLM.
This guide walks you through building one in 10 minutes using Claude Code.
What you need
- Claude Code installed (or any agent that can read/write files in a folder)
- A folder you can dedicate to this
- That's it
Step 1 — Create the folder structure
mkdir my-wiki && cd my-wiki
mkdir raw wiki outputs
touch wiki/index.md wiki/log.md CLAUDE.md
You should have:
my-wiki/
├── CLAUDE.md # the rules — what conventions the LLM follows
├── raw/ # original source material (you drop things here)
├── wiki/ # LLM-generated pages (the actual knowledge base)
│ ├── index.md # catalog of every page
│ └── log.md # append-only ingest log
└── outputs/ # query results — the LLM writes answers here
That's the whole architecture. Three folders, one schema file, two special files.
Step 2 — Write CLAUDE.md (the rules)
This is the most important file. It tells the LLM how to think about your wiki — what page format to use, when to create new pages vs update existing ones, how to cite sources, what operations exist.
Open CLAUDE.md and paste in your conventions. Mine looks like this (adapt to your domain):
# Knowledge Base — Schema & Conventions
This is a Karpathy-style LLM wiki. Markdown files in folders. No plugins.
## Folder Layout
- raw/ — immutable source material I drop in
- wiki/ — LLM-generated pages, the knowledge base itself
- wiki/index.md — catalog of every page
- wiki/log.md — append-only ingest log
- outputs/ — query results
## Page Format
Every wiki page follows this structure:
---
title: <Page Title>
type: <topic | entity | observation>
created: <YYYY-MM-DD>
updated: <YYYY-MM-DD>
sources: [raw/<filename>]
---
# <Title>
## Summary
One paragraph.
## Key Claims
- Claim 1 (source: raw/<filename>)
- Claim 2 (source: raw/<filename>)
## Related
- [[other-page]]
- Filenames are kebab-case
- Use [[wiki-link]] for cross-references
- Always cite the raw source for every claim
## Operations
**Ingest** — when I say "ingest raw/<file>":
1. Read the raw file fully
2. Identify topics, entities, and observations
3. Create new pages OR update existing ones (check index.md first)
4. Update index.md with new entries
5. Append an entry to log.md
**Query** — when I ask a question:
1. Read index.md first
2. Drill into relevant pages
3. Synthesize an answer with [[wiki-link]] citations
4. Write the result to outputs/YYYY-MM-DD-<slug>.md
**Lint** — when I say "lint the wiki":
1. Check for orphan pages (not in index)
2. Check for broken [[links]]
3. Flag stale claims and contradictions
4. Write findings to outputs/YYYY-MM-DD-lint.md
## Principles
- Markdown only
- Cite everything
- Update over duplicate
- One concept per page
- The index is the brain — read it first
Adapt the page format and operations to your domain. The point is to write down YOUR conventions clearly enough that the LLM can follow them every time.
Step 3 — Drop a source into raw/
The "source" is anything you want the wiki to know about. The format is just a markdown file. Save it with a date prefix so the log makes sense:
raw/2026-04-07-claude-code-skills.md
raw/2026-04-07-team-runbook.md
Five practical ways to add a source
1. Drag and drop
Open your raw/ folder in Finder or VS Code. Drag any markdown file in. Done.
2. Paste it manually
Open a new file in raw/ (e.g., 2026-04-07-notes.md), paste your content, save. Works for anything you can copy: a Notion page in markdown view, a Slack message, a transcript, your own brain dump.
3. Save it from a web page
Most documentation sites have a "view as markdown" or you can use a browser extension like "MarkDownload" to grab a clean markdown version. Save the file into raw/.
4. Tell Claude Code to fetch and save it
You can skip the manual step entirely:
Fetch https://docs.example.com/something and save it as raw/2026-04-07-something.md
Claude reads the page and writes the markdown directly into raw/.
5. Pipe from a tool
For research reports (e.g., from a deep-research skill), pipe the output:
my-research-tool "topic" > raw/2026-04-07-topic.md
What makes a good source
- Self-contained — the file should make sense on its own
- One topic per file — don't dump 10 unrelated docs into one file
- Date-prefixed filename — keeps the log readable and lets you re-ingest specific sources
- Real content, not links — the wiki ingests text, not URLs. Fetch the actual content first.
- No need for special structure — the LLM extracts what matters during ingest. Plain markdown works.
Step 4 — Ingest
Open Claude Code in the wiki directory and say:
Ingest raw/2026-04-07-claude-code-skills.md. Follow CLAUDE.md.
The LLM will:
- Read the source
- Pull out the distinct topics, entities, and observations
- Generate one page per concept (or update existing pages)
- Update
wiki/index.mdwith the new pages - Append a line to
wiki/log.md
You'll watch ~5-15 pages get created. You can ingest more sources anytime — the wiki grows over time.
Step 5 — Ask questions (THE PAYOFF)
This is the part that makes the whole thing worth it.
Just ask Claude Code a question. Anything the wiki content could answer. Examples from my Claude Code wiki:
Should I build a code reviewer as a skill or a subagent?
When should I scope an MCP server to a single subagent?
What's the difference between disable-model-invocation and user-invocable on a skill?
Can I have a hook that runs only after a specific subagent finishes?
Walk me through building a skill that runs in a forked subagent and returns a summary.
The LLM will:
- Read
wiki/index.mdfirst to know what exists - Drill into the relevant pages
- Synthesize an answer using ONLY the wiki contents
- Cite the pages it used with
[[wiki-link]]references - Write the answer to
outputs/YYYY-MM-DD-<question-slug>.md
The cited answer is the magic. It's not hallucinating from training data. It's reasoning over your actual notes and saying here's where I got this from. You can click through to verify.
Step 6 — Lint (every couple weeks)
Just say:
Lint the wiki.
Claude reads the whole wiki and flags:
- Orphan pages (created but not in the index)
- Broken
[[links]] - Stale claims (e.g. "as of March 2026" that are now outdated)
- Contradictions between pages
It writes findings to outputs/. Then you fix or re-ingest as needed.
Why this beats RAG / vector DBs
- Inspectable. It's just markdown files. You can read them, edit them, version them in git.
- No infrastructure. No vector DB, no embedding pipeline, no plugins.
- Citations are real. The
[[wiki-link]]points to a file you can open. - The schema is your schema. You decide what a "page" is and how it's structured.
- It compounds. Every ingest adds to a growing brain. The index keeps it navigable.
Karpathy says it best in his gist: "All you do is put markdown files in a folder."
Tips from running mine
- Start narrow. One topic, a few sources. Don't try to ingest your whole digital life on day one.
- Re-read your CLAUDE.md. If pages aren't coming out the way you want, the rules need updating, not the LLM.
- The query is the test. A wiki you can't query usefully is a folder of notes. Always test by asking it something real.
- Lint regularly. Wikis decay. Lint catches it.
- Don't manually edit wiki pages. Re-ingest the raw source. Manual edits get overwritten and the LLM loses trust in its own pages.
What I built mine for
I built this wiki to give Claude Code a brain about itself. The sources I dropped in:
- The official Claude Code Skills documentation
- The official MCP documentation
- The official Subagents documentation
- The official Hooks documentation
Now when I ask "should I build a code reviewer as a skill or a subagent?", I get an answer that reasons across all four docs and cites the exact pages it pulled from.
The same pattern works for anything you wish AI actually knew about. Your project's design decisions. Your favorite library's docs. Your company's runbooks. Your own notes.
That's the whole point.
