Andrej Karpathy published an LLM Wiki gist last week. 5,000+ stars. Nearly 3,000 forks. The idea: instead of retrieving documents every time you ask a question, have an LLM compile and maintain a persistent knowledge base.
I took the pattern and built it as a reusable Claude Code skill.
Four commands:
→ /wiki-init to bootstrap
→ /wiki-ingest to process sources
→ /wiki-query to synthesize answers
→ /wiki-lint to health-check
Two use cases where I have seen it work:
CTO Decision Wiki — architecture decisions, meeting notes, and post-mortems compiled into a queryable knowledge base. No more reconstructing context from Slack threads.
Content Research Wiki — every source for every article accumulates. Cross-references build automatically. Contradictions get flagged.
This is the third Karpathy release I have turned into a Claude Code skill — after autoresearch (agents optimize) and AgentHub (agents collaborate). LLM Wiki completes the trilogy: agents remember.
Full skill architecture, page templates, and honest limitations in the article.
Read the Full Article on Medium
Top comments (1)
This is a great pattern — Karpathy's wiki idea is elegant, and turning it into a Claude Code skill makes it actually reusable.
One challenge I keep running into with this approach: as the wiki grows, the ingestion overhead becomes noticeable. If you're processing thousands of documents on every /wiki-ingest run, latency starts to matter — especially for real-time coding assistance.
For embedded AI scenarios (robotics, drones, edge devices), you also face a different constraint: no persistent filesystem orObsidian. That's where an embedded database that can store vectors, time-series, and structured data locally becomes critical — you get the persistence benefits without the file system overhead.
Have you measured ingestion latency at scale, or considered incremental updates instead of full re-indexing?