Our recipe: the pattern made concrete
Karpathy’s note is deliberately abstract. It says so outright: “This document is intentionally abstract. It describes the idea, not a specific implementation… share it with your LLM agent and work together to instantiate a version that fits your needs.” That is the gap our recipe fills. Every group that starts from the raw idea re-derives the same directory layout, conventions, and tooling. The llm-wiki-memory-template makes those decisions once, so you fork it and start filing sources on day one instead of co-designing a wiki first. Here is what it actually pins down.
A schema, not a suggestion. A SCHEMA_<repo>.md file is the authoritative conventions the agent follows: the page type: vocabulary, the required frontmatter (type:, up:), the typed-edge set (extends:, supports:, criticizes:, requires:, related:), naming and cross-reference rules, and the special files, index_<repo>.md (the catalog of every page), log_<repo>.md (an append-only chronological record), and Home_<repo>.md. Karpathy leaves all of this to you; the template ships it and keeps it consistent.
Instance and wiki are separated. The project repo (the instance, where tools install) is distinct from the wiki itself, a nested, separately git-versioned directory that carries a subtype and is what gets published as a bundle. Tools install into the instance; subtype and sharing are properties of the wiki.
A reified knowledge graph, built in. A pipeline under scripts/kg/ extracts the frontmatter and body links into RDF, validates them with SHACL against the la3d/llm-wiki-colab ontology, and produces a SPARQL-queryable graph.ttl with a shipped library of canned queries. One command (build-graph.sh) rebuilds it after edits.
Discipline in the artifact. A verification gate blocks the agent from filing numerical results that are not backed by real script output. Named discipline gates pair each common rationalization (“this is basically what the data would show”) with the check that defeats it. A SessionStart hook reminds every new agent session, before it does anything, that the wiki is project memory. These are hooks and commands the harness runs, not habits a user has to remember.
Four operations as single commands. Ingest a source, query the wiki, lint for staleness, and verify a change before commit, each is one command the agent reaches for when the context calls for it. Karpathy describes these as workflows you develop yourself; the template makes them concrete and repeatable.
Multi-writer collision handling. A push protocol (wiki_push) pushes optimistically, and on a collision it fetches, union-merges the index and log automatically, routes genuine content conflicts to an LLM-assisted resolver, and retries, so two collaborators writing at once both land and neither overwrites the other. Every entry carries a by: <human> via <agent> attribution line, and git keeps the full amendment history.
Model-neutral overlays. Claude Code, Cursor, and whatever comes next each read the same wiki through their own commands and skills while sharing the policy files, gates, and schema. Swapping the model is a new overlay, not a migration; the wiki is the durable part, the model is disposable.
Karpathy gives you the idea and says “your LLM can figure out the rest.” The recipe is the rest, figured out once, tested, and forkable. It is a template, not a platform: you own it, and you take your memory with you.
Sources
- llm-wiki-memory-template (GitHub), the implementation described here.
- Andrej Karpathy, “llm-wiki” (gist), the abstract idea it instantiates.
- Beyond Memory (Saboia Moreira et al., 2026, Zenodo) and the la3d/llm-wiki-colab ontology.