@micuintus/llm-wiki
LLM wiki kit
First committed by micuintus
Published in micuintus/llm-wiki. Publisher page
32 GitHub stars
What it is
As minimal as Pi. Karpathy's LLM Wiki pattern as a minimal, agent-agnostic skill.
AutoGineer overview, from the brain’s own files
llm-wiki is a lightweight, dependency-free skill designed to implement the Karpathy LLM Wiki pattern. It functions as a persistent memory layer where an AI agent curates, summarizes, and cross-links information from raw sources into a structured knowledge base. By relying on conventions defined within the skill text rather than complex code or external infrastructure, it ensures that data remains portable and readable by any agent. The system consists of a single core skill file and a set of lazy-loaded reference files, keeping the footprint minimal while allowing for complex knowledge compounding.
How it works
Memory model: LLM wiki
AutoGineer overview, from the brain’s own files
The system operates by placing a single SKILL.md file into an agent's skill directory. This file contains the instructions and conventions the agent follows to process information. It uses a references folder containing lazy-loaded recipes for specific tasks, such as handling session transcripts or code repositories. The agent reads these instructions to summarize, link, and maintain the wiki, which is stored as plain markdown files on the user's disk.
| Folder | Role | Files |
|---|---|---|
| llm-wiki | folder | 8 |
Requirements
Runtimes: Node.js
Databases: SQLite
Set it up
- Download the brain as a ZIP and unzip it where you keep your notes or project: https://mp-staging.autogineer.com/agent-brains/micuintus/llm-wiki/download
cd llm-wiki && claude
AutoGineer scanned these files at commit e03cd38.
First committed by micuintus. Published in micuintus/llm-wiki. Licence: MIT License.
Usage
AutoGineer overview, from the brain’s own files
- Curating research papers into a searchable, interlinked knowledge base.
- Documenting project architecture, decisions, and open questions.
- Mapping complex ecosystems or taxonomies through agent-assisted ingestion.
- Synthesizing book chapters into concept pages and theme threads.
- “Summarize the last five research papers I uploaded and link them to the existing 'Quantum Computing' concept page.”
- The agent updates the 'Quantum Computing' markdown file with new summaries and creates cross-references to the specific paper files.
- “Review my project documentation and identify any contradictions between the architecture decisions and the current bug list.”
- The agent scans the wiki files and flags conflicting information, suggesting updates to maintain consistency.
Documentation by micuintus
@micuintus/llm-wiki
As minimal as Pi.
Karpathy's LLM Wiki pattern as a skill. One file. ~6 KB. No dependencies, no CLI, no web server, no Obsidian plugin.
The user curates sources. The LLM does the bookkeeping — summarizing, cross-linking, flagging contradictions. Knowledge compounds instead of being re-derived from raw chunks on every query.
Install
Pi (npm):
pi install npm:@micuintus/llm-wikiPi (GitHub):
pi install git:github.com/micuintus/llm-wikiEveryone else:
# Copy the skill directory (SKILL.md + its lazy-loaded recipes). Start ingesting.
curl -L https://github.com/micuintus/llm-wiki/archive/refs/heads/main.tar.gz \
| tar -xz --strip-components=1 -C ~/your-agent/skills/ llm-wiki-main/llm-wikiThat lands ~/your-agent/skills/llm-wiki/SKILL.md with its
references/ alongside, so the lazy-loaded recipes resolve. (SKILL.md
is the only always-loaded file — the rest is read on demand.)
What you get
One file: SKILL.md. Everything else is lazy-loaded — referenced by
path in the skill text, never loaded until you actually need it.
Agent session recipes (lazy-loaded):
Pi sessions — JSONL trees with fork detection
Claude Code / opencode / Gemini CLI — transcripts, SQLite, JSON
Code-source recipe (lazy-loaded) — grep+cite-by-line conventions for when the source is a repository rather than prose.
Web chat ingestion — Claude.ai, ChatGPT, Gemini via CDP. A
separate package:
ingest-web-chat
(pi install npm:@micuintus/ingest-web-chat).
The lazy-loaded subskills sleep forever until you wake them. (Don't forget to kiss these sleeping beauties.)
Use cases
Reading a book — chapter summaries, character/concept pages, theme threads, all interlinked.
Researching a topic across many papers — concept pages cite multiple sources; contradictions surface instead of getting lost.
Mapping an ecosystem (e.g., the Pi extension landscape) — taxonomies, comparisons, primitive mappings.
Documenting your own project — decisions, architecture, bugs, open questions, all linked through one schema.
Why this exists
Most wiki implementations ship a CLI, a web server, a static site generator, and 2,000 tests. That's fine if you want infrastructure. This is for people who want a pattern — a convention the agent already understands — and nothing else.
Conventions live in the skill text, not in code. The wiki itself is plain markdown on disk — if you ever switch agents or skills, your data travels with you unchanged.
Related work
The Karpathy gist has spawned a diverse ecosystem. Every implementation below shares the same three-layer foundation (raw sources → compiled wiki → schema); they differ in shape (how the agent consumes the pattern) and weight (how much tooling ships alongside the skill).
What makes @micuintus/llm-wiki different: it is a pure skill
— a single SKILL.md (~6 KB) plus lazy-loaded reference files that
any agent (Pi, Claude Code, Codex, Cursor) can read directly. No
runtime dependencies, no generated code, no CLI to install, no web
server to run, no Obsidian plugin to manage. Conventions are enforced
by the skill text itself, not by code. If you want the lightest
possible commitment to the pattern — copy one file, start ingesting —
this is it. Other implementations add value in exchange for weight:
IDE plugins, static-site generators, code-based guardrails, or
self-driving agents. Pick the shape that matches your workflow.
| Repo | Stars | Contributors | License | Language | Shape | Notes |
|---|---|---|---|---|---|---|
| Astro-Han/karpathy-llm-wiki | 651 | 1 | MIT | Markdown | Skill | Agent Skills-compatible. Single-file SKILL.md, no session recipes. Closest to a vanilla skill. |
| toolboxmd/karpathy-wiki | 66 | 1 | — | Shell | Skill | Two Claude Code skills: setup + maintenance. Hooks-driven. |
| balukosuri/llm-wiki-karpathy | 125 | 1 | — | — | Skill | Article + implementation walkthrough. |
| lewislulu/llm-wiki-skill | 447 | 2 | MIT | TypeScript | Skill + ecosystem | Skill + Obsidian audit plugin + local web viewer + shared TypeScript audit library. For users who want IDE-like tooling. |
| lucasastorian/llmwiki | 808 | — | Apache-2.0 | Python + TypeScript | CLI tool | Upload documents, connect Claude via MCP, agent writes the wiki. MCP-native. |
| Pratiyush/llm-wiki | 229 | 1 | MIT | Python | CLI tool | llmwiki CLI: session ingestion, static site generation, 2,651 tests, 16 lint rules, MCP server, Playwright E2E, AI exports. Most feature-rich; heaviest. |
| Kausik-A/pi-llm-wiki | 9 | 1 | MIT | TypeScript | Pi-native | Pi package with bundled skill + Pi extension. Enforces guardrails via code rather than convention. |
| yologdev/karpathy-llm-wiki | 43 | 2 | — | TypeScript | Self-growing | "Yoyo" AI agent grows the wiki from Karpathy's founding prompt. Commits are the agent's work. Includes web viewer. |
| hsuanguo/llm-wiki | 11 | 2 | MIT | Python | Self-growing | Wiki that "evolves with you" + Python scaffolding. |
Changelog
See CHANGELOG.md.
License
MIT
llm-wiki/SKILL.md
name: llm-wiki description: | Karpathy's LLM Wiki: LLM-curated personal knowledge base. Trigger on "add to wiki", "save this", "file this", "remember this", "ingest this paper/article/chat/video", "what do I know about X", "what's in the wiki about X", "lint/audit the wiki", or any mention of "LLM wiki", "Karpathy wiki", or "knowledge base" — i.e., any accumulation of material that should compound rather than scatter.
LLM Wiki
The user curates sources; the LLM does the bookkeeping. Knowledge compounds in markdown rather than being re-derived per query.
Layout
<project>/llm-wiki/
├── SCHEMA.md # per-project conventions — read FIRST
├── index.md # catalog of compiled pages
├── log.md # append-only op log
├── raw-sources/ # immutable; append-only
│ ├── index.md # registry of every source
│ └── <bucket>/ # copies of ad-hoc sources only
└── <topic>/ # compiled pagesSCHEMA.md overrides everything below. If llm-wiki/ doesn't exist,
create the four stubs (using references/SCHEMA.template.md) and
propose schema values before the first ingest.
Ingest
Ingest = register + compile + log. Use these verbs precisely
in log.md so wiki state is transparent.
Register. List the source in
raw-sources/index.mdwith a stable identifier. If the source is mutable or auth-walled (e.g. Google Doc, Confluence), copy it intoraw-sources/<bucket>/YYYY-MM-DD-slug.md(seereferences/source.template.md). If the source is already stable (in-repo path, public URL), reference it by path/URL without copying. New bucket needs user approval + SCHEMA update.raw-sources/index.mdformat: one section per bucket. Each entry is a table row withpath | slug | topics. Keep it terse — this is a registry, not a summary.HTML documentation sites (Sphinx, Doxygen, ReadTheDocs) and auth- walled sources (Confluence, Google Docs) may require extraction or credentials. Redact credentials from any copied material. For proprietary or confidential sources, prefer reference-by-path over copying, and don't reproduce confidential identifiers in any page you may publish.
Compile. Distill the source into pages in
<topic>/. Merge with targeted edits (don't rewrite); append tosources:; bumpupdated:. Cascade to other affected pages. Forward references to pages not yet compiled are acceptable — they self-resolve as the wiki grows. Annotate conflicts inline with attribution. Archive pages (type: synthesis/archive) are never cascade-updated.Log. Update
index.md; append tolog.md:## [YYYY-MM-DD] ingest | <title>+- Updated: <page>per cascade. If only register happened (no compile yet), log as## [YYYY-MM-DD] register | <title>and note "compile pending".log.mdis the wiki's VCS-independent operation log: it works when the wiki isn't a git repo, stays readable without shelling out to git, and in a shared repo isolates wiki ops from surrounding code commits. Keep entries semantic — what knowledge changed and why — not file-level; git already records the diff.
For many independent sources, ingest can run in parallel: dispatch one
subagent per source to compile concurrently. Serialize writes to the
shared files (index.md, log.md, raw-sources/index.md) through one
agent or a final merge pass — concurrent edits to the same file
conflict.
Frontmatter (mandatory): title, type, updated, sources. Types:
concept, decision, bug, open-question, source, reference,
synthesis, stub. Use stub for sources registered but not yet
compiled. Optional: tags: [tag1, tag2] for grep-based discovery on
wikis >20 pages. Depth rules per type — plus concept variants and
the correction pattern — in references/quality.md.
Special sources
Code repositories / source trees — different shape from prose. See
references/code-source-recipe.md.Agent sessions — Pi (JSONL trees with forks): see
references/pi-session-recipe.md. Claude Code, Gemini CLI, opencode: seereferences/agent-session-recipe.md. Lazy-load.Web LLM chats — now the separate
@micuintus/ingest-web-chatpackage (URL → markdown via CDP, enterprise-SSO-safe).Binaries (figures, audio, checkpoints) — bucket per kind, always pair with a companion
.md; cite the.md, not the binary.PDFs — extract to text first (
pdftotext -layoutor equivalent), register the extracted text path, not the PDF.
For sources whose claims are inconsistent or partially fabricated
(common for LLM chat exports), add reliability: high|mixed|unverified
to the source entry's frontmatter and annotate per-claim attribution
in compiled pages. See references/quality.md for the pattern.
Query
Read index.md, follow links, synthesize with citations. Prefer wiki
over training; say so if coverage is missing. If the answer connects
≥2 pages, offer to file as type: synthesis.
When the user explicitly asks to file/save/archive a query answer,
or to document a correction to prior analysis, see
references/synthesis-and-archive.md (also covers the
### Correction: pattern in references/quality.md).
Navigation and discoverability
A wiki that only machines can navigate compounds poorly. Apply these
patterns during compile so humans can use it too. None of this applies
to wikis under ~10 pages — for small wikis a flat index.md is fine.
One canonical browse location
Pick README.md or index.md as the place that lists every
compiled page, not both. Two browse lists drift the moment you add a
page. The other file links to it.
The usual split: README.md is the GitHub landing (goal-oriented,
small, links into the wiki); index.md is the canonical full browse.
Inline table of contents on long pages
Pages >200 lines get a ## Contents block immediately after the h1,
linking to slugified section anchors:
## Contents
- [Section name](#section-name)Line count is the threshold; H2-count alone is not enough (short pages with many short sections scroll fine). GitHub's slug rules are not obvious for headings with em-dashes, parens, or slashes — verify anchors via lint, not by guessing.
Survey page lede
Survey pages (pages comparing ≥3 entries) open with a 2–3 sentence "short answer" naming the top picks before any taxonomy or variant breakdown. Readers who just want a recommendation get one without scrolling.
If you find yourself writing a "What this page is for" or "About this survey" section, that's a smell — write the answer instead. Defensive meta-commentary tells the reader the author was unsure; it doesn't help the reader decide.
Decision tables on survey pages
Survey pages end with a picking table: "If you want X, use Y" with a one-line why. Don't make the reader re-synthesize what the survey already concluded. Topic pages and concept pages don't need this.
## See also on every page
2–4 related links. Reference pages and index.md are not exempt. If a
page genuinely has no relations, write the section with an explanation
— the heading itself is the consistency signal.
Lint
Two categories with different authority levels.
Deterministic (auto-fix)
Index ↔ filesystem sync. File present but missing from
index.md→ add entry with(no summary)placeholder. Index entry pointing to nonexistent file → mark[MISSING]; do not delete.Internal links. For every
](path.md)link in compiled pages, verify the target exists at that relative path. Common errors: same-dir links written as../dir/file.md; sibling links written asdir/file.md(looks for subdir, not sibling). If exactly one file with the same basename exists elsewhere, fix the path; otherwise report.Anchor links. For every
](path.md#anchor)and same-page](#anchor)link, verify the anchor matches a slugified heading in the target. GitHub slugifies by lowercasing, replacing spaces with-, dropping most punctuation but keeping-and_, and collapsing repeated-. Report mismatches.Raw-source references. Every link from a compiled page into
raw-sources/must resolve. Same fix-or-report rule.See Also bidirectionality. If A links to B in See Also, B should link back. Add the missing direction.
Frontmatter type validity. Reject types not in the canonical list.
Stub aging.
type: stubpages older than 30 days → flag in log.
Heuristic (report only)
Contradictions across pages without attribution.
Stale claims superseded by newer sources.
Orphan pages (no inbound links).
Concepts mentioned ≥3× across the wiki but lacking a dedicated page.
Sources with
reliability: mixed|unverifiedwhose claims appear in compiled pages without per-claim attribution.Archive pages whose cited sources have been substantially updated.
Post-lint
Append to log.md:
## [YYYY-MM-DD] lint | <N> issues, <M> auto-fixed
- <issue or fix summary>Schema
LLM proposes; user approves. Triggers: new bucket/topic, type misuse, systemic lint findings, user request.
16 files
- .gitignore
- .npmignore
- ATTRIBUTION.md
- CHANGELOG.md
- LICENSE
- README.md
- llm-wiki/SKILL.md
- llm-wiki/references/SCHEMA.template.md
- llm-wiki/references/agent-session-recipe.md
- llm-wiki/references/code-source-recipe.md
- llm-wiki/references/pi-session-recipe.md
- llm-wiki/references/quality.md
- llm-wiki/references/source.template.md
- llm-wiki/references/synthesis-and-archive.md
- package-lock.json
- package.json
Advantages
- Zero runtime dependencies, CLI tools, or web servers required. evidence: README.md
- Data is stored as plain markdown, ensuring portability across different agents. evidence: README.md
- Lazy-loading of reference files keeps the memory footprint minimal. evidence: README.md
Limitations
- Lacks built-in IDE plugins or graphical interfaces for those preferring visual tooling. evidence: README.md
- Relies on agent-driven convention adherence rather than hard-coded guardrails. evidence: README.md
Security
Risk level: No risk found
This brain runs
Agent instructions that run or fetch something (2)
llm-wiki/SKILL.md:git already records the diff.llm-wiki/SKILL.md:For many independent sources, ingest can run in parallel: dispatch one subagent per source to compile concurrently.
Attribution and licence
- First committed by
micuintus
- Declared authors
- Michael Voigt (micu) (declared in package.json)
- Publisher
- micu (Community)
- Source
- micuintus/llm-wiki · commit e03cd38
- Licence
- MIT License (files served here)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Contributors
- micuintus
AutoGineer is not affiliated with or endorsed by micuintus.
Download
The ZIP holds the files AutoGineer serves, with ATTRIBUTION.md and the licence. Download llm-wiki.zip