Generated banner for @micuintus/llm-wiki
Generated logo for @micuintus/llm-wiki

@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.
— the description by micuintus

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.

Folders
FolderRoleFiles
llm-wikifolder8

Requirements

Runtimes: Node.js

Databases: SQLite

Set it up

  1. 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
  2. cd llm-wiki && claude

  3. AutoGineer scanned these files at commit e03cd38.

  4. 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-wiki

Pi (GitHub):

pi install git:github.com/micuintus/llm-wiki

Everyone 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-wiki

That 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.

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.

RepoStarsContributorsLicenseLanguageShapeNotes
Astro-Han/karpathy-llm-wiki6511MITMarkdownSkillAgent Skills-compatible. Single-file SKILL.md, no session recipes. Closest to a vanilla skill.
toolboxmd/karpathy-wiki661—ShellSkillTwo Claude Code skills: setup + maintenance. Hooks-driven.
balukosuri/llm-wiki-karpathy1251——SkillArticle + implementation walkthrough.
lewislulu/llm-wiki-skill4472MITTypeScriptSkill + ecosystemSkill + Obsidian audit plugin + local web viewer + shared TypeScript audit library. For users who want IDE-like tooling.
lucasastorian/llmwiki808—Apache-2.0Python + TypeScriptCLI toolUpload documents, connect Claude via MCP, agent writes the wiki. MCP-native.
Pratiyush/llm-wiki2291MITPythonCLI toolllmwiki 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-wiki91MITTypeScriptPi-nativePi package with bundled skill + Pi extension. Enforces guardrails via code rather than convention.
yologdev/karpathy-llm-wiki432—TypeScriptSelf-growing"Yoyo" AI agent grows the wiki from Karpathy's founding prompt. Commits are the agent's work. Includes web viewer.
hsuanguo/llm-wiki112MITPythonSelf-growingWiki 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 pages

SCHEMA.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.

  1. Register. List the source in raw-sources/index.md with a stable identifier. If the source is mutable or auth-walled (e.g. Google Doc, Confluence), copy it into raw-sources/<bucket>/YYYY-MM-DD-slug.md (see references/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.md format: one section per bucket. Each entry is a table row with path | 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.

  2. Compile. Distill the source into pages in <topic>/. Merge with targeted edits (don't rewrite); append to sources:; bump updated:. 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.

  3. Log. Update index.md; append to log.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.md is 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: see references/agent-session-recipe.md. Lazy-load.

  • Web LLM chats — now the separate @micuintus/ingest-web-chat package (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 -layout or 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 as dir/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: stub pages 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|unverified whose 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

Advantages

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
GitHub avatar of micuintusmicuintus
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