karpathy-llm-wiki: a skill that compiles sources into a markdown wiki instead of re-searching them
Agent Skills-compatible LLM wiki for Claude Code, Cursor, and Codex. Build a Karpathy-style knowledge base from raw sources, citations, and linting.
At a glance
- What is it?
- This repository packages Karpathy's LLM Wiki idea as an Agent Skills-compatible skill for Claude Code, Cursor and Codex. It is a workflow, not a search engine: the agent writes and maintains markdown pages, and retrieval stays on grep.
- Who is it for?
- Adopt it if you already keep a personal knowledge base and want an agent to do the cross-linking and summarising, and if your corpus is small enough that grep over a curated wiki still returns what you need. Do not adopt it if you need retrieval over a large unstructured corpus, or if you want scheduled background maintenance, since the author explicitly assigns that to the agent harness rather than the skill.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 54 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: synthesis happens at query time and is thrown away
Retrieval-augmented generation answers a question by pulling raw chunks and assembling an answer on the spot. The README frames the alternative sharply: in an LLM wiki, knowledge lives in curated markdown pages and synthesis happens during ingest and maintenance, not at query time. The stated payoff is compounding knowledge, summaries and durable cross-links, as opposed to re-deriving relationships on every question.
The repository is aimed at people who already keep notes and want the model to maintain them. The README's FAQ draws the line against a normal personal wiki: an LLM wiki is maintained by the model, which updates summaries, cross-links, index entries and contradictions as new material arrives, while a personal wiki depends on manual editing. If you are happy being the one who decides where a new fact belongs and which old page it contradicts, this skill has little to offer you.
Three operations and the directory layout they act on
The skill exposes exactly three operations. Ingest collects a source into raw/, triages it, then creates or updates wiki articles, or just logs it when nothing is new. Query searches the wiki and answers with citations linking back to markdown pages. Lint checks index integrity, links and wiki health, and produces auto-fixes plus a reported list of issues.
The layout is the load-bearing part. raw/ holds immutable source material, filed by topic with dated filenames such as 2026-04-03-source-article.md. wiki/ holds the compiled pages, again by topic, plus a global index.md table of contents and an append-only log.md operation log. The README's claim about compounding rests on a specific behaviour: each new source can update multiple pages, strengthen cross-references, and record contradictions.
That is a different data flow from a vector store. There is no embedding step and no chunk table. The durable artifact is the markdown file, and the index and log are the only global state. Lint is what keeps that state honest, which is why it is a first-class operation rather than a maintenance afterthought.
Installation and the commands the README actually gives
The primary install path is a single command, npx add-skill Astro-Han/karpathy-llm-wiki. The compatibility table lists that same command for Claude Code, Cursor and OpenCode. Codex CLI is the exception: the README says to copy the skill to .agents/skills/karpathy-llm-wiki/. For tools that are not in the table, the instruction is to copy SKILL.md, references/ and scripts/ into the tool's skill directory.
There is no configuration file documented, no environment variable and no server to start. The interface is natural language. The README's quick start gives three example prompts: "Ingest this article: https://example.com/attention-is-all-you-need", "What do I know about attention mechanisms?", and "Lint my wiki".
That means setup is mostly a decision about where the raw/ and wiki/ directories live, not about tuning parameters. It also means the skill's behaviour is only as reproducible as the agent running it. Two different tools implementing the Agent Skills standard may follow the same SKILL.md and still produce pages that read differently, because nothing in the layout enforces phrasing.
The design boundaries are the most opinionated part of the repo
The README's Design Boundaries section lists what the author deliberately did not build, and it is unusually specific. Source-hash freshness tracking is out because raw/ is immutable, so hashes would guard against events that cannot happen. Persisted line-number citations are out because, in the author's account, every observed fidelity error was a value absent from the source, which a whole-file grep catches; the annotation friction made agents skip the rule. Numeric confidence scores are rejected as false precision with no calibration behind them. Per-article review dates are out because nobody can predict at compile time how fast a domain moves, so maintenance is driven by whole-wiki lint instead. Access-based decay is rejected on the grounds that frequently asked is not the same as true.
Two omissions matter more than the rest for anyone evaluating fit. Vector or graph search is deliberately absent: the README states that at 50K to 100K tokens of curated wiki, grep and read are more reliable, and that search tooling should be added only when recall measurably degrades. Automatic hooks and scheduled runs are also absent, on the argument that they belong to the agent harness rather than a tool-agnostic skill. Retract and bad-source machinery is deferred until it is needed.
You can disagree with these calls and still find the list useful. It tells you which failure modes the author has and has not seen, and it tells you what you are expected to supply yourself.
Where this is the wrong tool
The retrieval argument cuts both ways. The README says grep and read are more reliable at 50K to 100K tokens of curated wiki and that search tooling should be added only when recall measurably degrades. That is a stated ceiling, not a marketing hedge. If your corpus is a document dump you intend to query broadly, the RAG column in the README's own comparison table is the better fit, and the skill's ingest step becomes a bottleneck because every source has to be compiled into pages rather than indexed.
Compilation is also a write. Ingest can create or update multiple wiki pages per source, and the log is append-only. On a large import, that is a lot of agent-generated prose landing in your repository at once, and the README documents no bulk mode, no dry run and no diff preview. The lint operation reports and fixes problems, but it is described as checking index integrity, links and wiki health, which is not the same as reviewing whether a page states something the source does not.
The third boundary is maintenance. Because automatic hooks and scheduled runs are explicitly out of scope, the wiki only stays current when someone asks for an ingest or a lint. A repository that depends on a nightly job to stay accurate will not get one from this skill.
Compared with RAG, and with the neighbouring projects the author surveyed
The README's own table is the cleanest statement of the difference. RAG keeps knowledge in raw chunks and embeddings and synthesises at query time, and is good for broad retrieval across large corpora. The LLM wiki keeps knowledge in curated markdown pages and synthesises during ingest and maintenance, and is good for compounding knowledge, summaries and durable cross-links. The practical consequence is that a wiki answer can be wrong in a way you can edit: you open the cited page and fix the sentence. A RAG answer is assembled fresh each time, so a correction has nowhere to live unless you change the underlying chunk.
The Design Boundaries section also names the ecosystem the author surveyed before deciding what to omit: LLM Wiki v2, llm-wiki-compiler, OKF, and the agent-memory literature. OKF conformance is described as a v0.1 draft with a minimal tooling ecosystem, tracked but not adopted. That is a concrete difference in approach rather than a vague preference: the author looked at a specification, judged the tooling too thin, and left it out. If OKF conformance matters to your organisation, this skill does not provide it today.
Maintenance cost, licence and what the usage numbers do and do not say
The licence is MIT, stated in the README badge and in the repository metadata. That permits reuse and modification with the usual attribution and warranty terms; it is not legal advice, and if you plan to redistribute the skill inside a commercial product, read the LICENSE file rather than the badge.
The README reports usage stats from what it calls a production knowledge base maintained daily since April 2026: 94 wiki articles across 13 topic directories, 99 source materials ingested, and 87 operation log entries in the last seven days. Those numbers describe one person's wiki. They are not a benchmark, they say nothing about answer accuracy, and the 87 log entries in a week are as much a measure of how often the agent was invoked as of anything else. Treat them as an existence proof that the workflow has been run for months, which is what the README claims them to be.
Upgrade cost is low in the sense that there is no service to migrate and no schema to version. The repository has no retrieved releases, so updates arrive through the main branch and through re-running npx add-skill. The real cost is editorial: the wiki accumulates, lint is the only automated check on it, and the append-only log means the history of what the agent changed is preserved but not summarised for you.
Editorial conclusion
Adopt it if you already keep a personal knowledge base and want an agent to do the cross-linking and summarising, and if your corpus is small enough that grep over a curated wiki still returns what you need. Do not adopt it if you need retrieval over a large unstructured corpus, or if you want scheduled background maintenance, since the author explicitly assigns that to the agent harness rather than the skill. Before committing, open examples/ and confirm the page template and log format match how you actually write, and read the Design Boundaries list in the README to check that the omitted features are ones you can live without.
Community notes