Generated banner for llmwiki
Generated logo for llmwiki

llmwiki

LLM wiki kit

Created by Pratiyush

Published in Pratiyush/llm-wiki. Publisher page

401 GitHub stars

What it is

> **LLM-powered knowledge base from your Claude Code, Codex CLI, Cursor, Gemini CLI, and Obsidian sessions.** > Built on [Andrej Karpathy's LLM Wiki pattern](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f).
— the description by Pratiyush

AutoGineer overview, from the brain’s own files

llmwiki is a tool designed to convert dormant AI agent session transcripts from tools like Claude Code, Codex CLI, Cursor, and Gemini CLI into a structured, Karpathy-style knowledge base. It operates locally without requiring a database or cloud service, organizing data into three layers: raw session transcripts, an LLM-generated wiki, and a static site. The system provides a comprehensive suite of features including activity heatmaps, global search, and AI-consumable exports like JSON-LD graphs and llms.txt, enabling other AI agents to query the wiki directly. It also supports deep integration with Obsidian, allowing users to manage their knowledge base within a familiar vault environment.

How it works

Memory model: LLM wiki

AutoGineer overview, from the brain’s own files

The system ingests session logs from various AI agent directories and converts them into immutable markdown files in a raw folder. These are then processed into a structured wiki containing sources, entities, concepts, and syntheses. Finally, a build command compiles these into a static HTML site with machine-readable metadata, search indexes, and RSS feeds. It uses a command-line interface for syncing, building, and serving the wiki, and provides an MCP server for agents to interact with the knowledge base.

Folders
FolderRoleFiles
.claudeagent-config25
.githubagent-config29
.kiroagent-config3
docsdocs99
examplesexamples18
scriptsscripts11
teststests205
wikiwiki23
.claude-pluginfolder2
homebrewfolder1
integrationsfolder8
llmwikifolder97
specsfolder10

The agent reads

The agent writes

Requirements

Apps: Docker

Runtimes: Node.js, Python >=3.9

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Google Antigravity, Kiro, OpenCode, Amp, Roo Code, Cline, JetBrains Junie, Devin (ex-Windsurf)

Set it up

  1. This brain runs code automatically: 1 script. Review setup.sh before opening the folder in Claude Code. No step below turns a hook on for you.

    • setup.sh: sh setup.sh
  2. Clone the repository at the commit AutoGineer scanned:

    git clone https://github.com/Pratiyush/llm-wiki.git && cd llm-wiki && git checkout b1088890ee0743810a92577aecad946c6b3eb2d2
  3. Claude Code reads CLAUDE.md from this folder automatically.

  4. cd llm-wiki && claude

  5. AutoGineer scanned these files at commit b108889.

  6. Not scanned by AutoGineerThe author’s README also describes installing it with Docker Compose. Read its install section: AutoGineer did not scan that path. https://github.com/Pratiyush/llm-wiki/blob/b1088890ee0743810a92577aecad946c6b3eb2d2/README.md#deployment-targets
  7. Not scanned by AutoGineerThe author’s README also describes installing it from a clone of its repository. Read its install section: AutoGineer did not scan that path. https://github.com/Pratiyush/llm-wiki/blob/b1088890ee0743810a92577aecad946c6b3eb2d2/README.md#install
  8. Not scanned by AutoGineerIts setup steps could not be read from the brain’s own files. https://github.com/Pratiyush/llm-wiki/tree/b1088890ee0743810a92577aecad946c6b3eb2d2
  9. Not scanned by AutoGineerIts dependencies are installed by pip or uv when you run it and were not scanned by AutoGineer (1 declared). https://pypi.org/project/llm-notebook/
  10. Created by Pratiyush. Published in Pratiyush/llm-wiki. Licence: MIT License.

Usage

AutoGineer overview, from the brain’s own files

  • Syncing session history from multiple AI agents into a local wiki
  • Generating AI-consumable knowledge graphs for agent RAG
  • Browsing session history with a searchable, static web interface
  • Integrating session knowledge into an Obsidian vault
  • Running automated linting and quality checks on knowledge base content
“llmwiki sync”
Imports new session transcripts from configured agent directories and updates the raw markdown files.
“llmwiki all --with-synth”
Runs the full pipeline: synthesizes summaries, builds the static site, generates the knowledge graph, and lints the wiki.

Documentation by Pratiyush

llmwiki

LLM-powered knowledge base from your Claude Code, Codex CLI, Cursor, Gemini CLI, and Obsidian sessions. Built on Andrej Karpathy's LLM Wiki pattern.

👉 Live demo: pratiyush.github.io/llm-wiki

Rebuilt on every master push from the synthetic sessions in examples/demo-sessions/. No personal data. Shows every feature of the real tool (activity heatmap, tool charts, token usage, model info cards, vs-comparisons, project topics) running against safe reference data.

Image: License: MIT Image: Python 3.9+ Image: Version Image: Tests Image: CI Image: Link check Image: Wiki checks Image: Docker Image: Works with Claude Code Image: Works with Codex CLI Image: Works with Copilot Image: Works with Cursor Image: Works with Gemini CLI Image: Works with Obsidian


Every Claude Code, Codex CLI, Copilot, Cursor, and Gemini CLI session writes a full transcript to disk. You already have hundreds of them and never look at them again.

llmwiki turns that dormant history into a beautiful, searchable, interlinked knowledge base — locally, in two commands. Plus, it produces AI-consumable exports (llms.txt, llms-full.txt, JSON-LD graph, per-page .txt + .json siblings) so other AI agents can query your wiki directly.

./setup.sh                         # one-time install
./build.sh && ./serve.sh           # build + serve at http://127.0.0.1:8765

Want LLM-enriched wiki pages from the CLI? After ./setup.sh, llmwiki sync only fills raw/. To populate wiki/sources/ (semantic summaries), set synthesis.backend in examples/sessions_config.json (ollama for local Ollama, or keep dummy for stubs), then run llmwiki synthesize or chain it with llmwiki all --with-synth. See docs/modes/api/ and llmwiki sync --status for the current backend hint.

llmwiki sync
llmwiki all --with-synth --graph-engine builtin   # synthesize → build → graph → export → lint

Image: llmwiki — 70-second demo

Contributing in one line: read CONTRIBUTING.md, keep PRs focused (one concern each), use feat: / fix: / docs: / chore: / test: commit prefixes, never commit real session data (raw/ is gitignored), no new runtime deps. CI must be green to merge.

Screenshots

All screenshots below are from the public demo site which is built on every master push from the dummy example sessions. Your own wiki will look identical — just with your real work.

Home — projects overview with activity heatmap

Image: llmwiki home page — LLM Wiki header, activity heatmap, and a grid of three demo projects (demo-blog-engine, demo-ml-pipeline, demo-todo-api)

All sessions — filterable table across every project

Image: llmwiki sessions index — activity timeline above a table of eight demo sessions with project, model, date, message count, and tool-call columns

Session detail — full conversation + tool calls

Image: llmwiki session detail — Rust blog engine scaffolding session showing summary, breadcrumbs, a TOML Cargo.toml block and a Rust main.rs block, both highlighted by highlight.js

Changelog — renders CHANGELOG.md as a first-class page

Image: llmwiki changelog page — keep-a-changelog format with colored headings for Added / Fixed / Changed and auto-linked PR references

Projects index — freshness badges + per-project stats

Image: llmwiki projects index — three demo project cards with green/yellow/red freshness badges showing how recently each project was touched

What you get

Human-readable
  • All your sessions, converted from .jsonl to clean, redacted markdown

  • A Karpathy-style wiki — sources/, entities/, concepts/, syntheses/, comparisons/, questions/ linked with [[wikilinks]]

  • A beautiful static site you can browse locally or deploy to GitHub Pages

    • Global search (Cmd+K command palette with fuzzy match over pre-built index)

    • highlight.js client-side syntax highlighting (light + dark themes)

    • Dark mode (system-aware + manual toggle with data-theme)

    • Keyboard shortcuts: / search · g h/p/s nav · j/k rows · ? help

    • Collapsible tool-result sections (auto-expand > 500 chars)

    • Copy-as-markdown + copy-code buttons

    • Breadcrumbs + reading progress bar

    • Filter bar on sessions table (project/model/date/text)

    • Reading time estimates (X min read)

    • Related pages panel at the bottom of every session

    • Activity heatmap on the home page

    • Model info cards with structured schema (provider, pricing, benchmarks)

    • Auto-generated vs-comparison pages between AI models

    • Append-only changelog timeline with pricing sparkline

    • Project topic chips (GitHub-style tags on project cards)

    • Agent labels (colored badges: Claude/Codex/Copilot/Cursor/Gemini)

    • Recently-updated card on the home page

    • Dataview-style structured queries in the command palette

    • Hover-to-preview wikilinks

    • Deep-link icons next to every heading

    • Mobile-responsive + print-friendly

AI-consumable (v0.4)

Every HTML page has sibling machine-readable files at the same URL:

  • <page>.html — human HTML with schema.org microdata

  • <page>.txt — plain text version (no HTML tags)

  • <page>.json — structured metadata + body

Site-level AI-agent entry points:

FileWhat
/llms.txtShort index per llmstxt.org spec
/llms-full.txtFlattened plain-text dump (~5 MB cap) — paste into any LLM's context
/graph.jsonldSchema.org JSON-LD entity/concept/source graph
/sitemap.xmlStandard sitemap with lastmod
/rss.xmlRSS 2.0 feed of newest sessions
/robots.txtAI-friendly robots with llms.txt reference
/ai-readme.mdAI-specific navigation instructions
/manifest.jsonBuild manifest with SHA-256 hashes + perf budget

Every page also includes an <!-- llmwiki:metadata --> HTML comment that AI agents can parse without fetching the separate .json sibling.

Recipe — query graph.jsonld from your terminal

The JSON-LD graph isn't just for crawlers — you can ask quick questions about your wiki without leaving the shell. Example: print every session as a tree, grouped by project:

python3 examples/scripts/tree_from_graph.py

Output:

📚 8 sessions across 3 projects
   (site/graph.jsonld v1.3.0)

llmwiki/
├── demo-blog-engine/  (4 sessions)
│   ├── 2026-03-12  scaffolding-the-rust-blog-engine
│   ├── 2026-03-18  adding-syntax-highlighting
│   ├── 2026-03-25  rss-feed-and-sitemap
│   └── 2026-04-01  dark-mode-toggle
├── demo-ml-pipeline/  (2 sessions)
│   ├── 2026-01-20  training-data-pipeline
│   └── 2026-02-02  model-training-loop
└── demo-todo-api/  (2 sessions)
    ├── 2026-02-08  fastapi-project-bootstrap
    └── 2026-02-15  adding-oauth-login

The full script is stdlib-only at examples/scripts/tree_from_graph.py. Same recipe pattern works for any aggregation question — count sessions per model, find the largest project by token usage, list every entity that appears in 3+ sessions, etc. The graph is yours to slice.

Quality & governance (v1.0)
  • 4-factor confidence scoring — source count, source quality, recency, cross-references; with Ebbinghaus-inspired decay per content-type

  • 5-state lifecycle machine — draft → reviewed → verified → stale → archived with 90-day auto-stale

  • 16 lint rules — 8 structural (frontmatter, link integrity, orphans, freshness, duplicates, index sync…) + 3 LLM-powered (contradictions, claim verification, summary accuracy) + stale_candidates (#51) + tags_topics_convention (#302) + stale_reference_detection (#303) + frontmatter_count_consistency (#378) + tools_consistency (#378)

  • Auto Dream — MEMORY.md consolidation after 24h + 5 sessions: resolve relative dates, prune outdated, 200-line cap

  • 9 navigation files — CLAUDE.md, AGENTS.md, MEMORY.md, SOUL.md, CRITICAL_FACTS.md, hints.md, hot.md + per-project hot caches

Obsidian-native experience (v1.0)
  • link-obsidian CLI — symlinks the whole project into an Obsidian vault; graph view + backlinks + full-text search just work

  • Dataview dashboard — 10 ready-to-use queries (recently updated, by confidence, by lifecycle, by project, by entity type, open questions, stale pages)

  • Templater templates — 4 templates for source/entity/concept/synthesis pages, seeded with confidence + lifecycle + today's date

  • Category pages — tag-based index pages in both Dataview (Obsidian) and static markdown (HTML) modes

  • Integration guide — docs/obsidian-integration.md covers 6 recommended plugins with per-plugin configs

Automation
  • SessionStart hook — auto-syncs new sessions in the background on every Claude Code launch

  • Auto-build on sync — /wiki-sync triggers /wiki-build (configurable; default on)

  • One-shot pipeline — llmwiki all runs build → graph → export → lint in a single command (--strict for CI)

  • MCP server — 12 production tools (query, search, list, read, lint, sync, export, + confidence, lifecycle, dashboard, entity search, category browse) queryable from any MCP client (Claude Desktop, Cline, Cursor, ChatGPT desktop)

  • Pending ingest queue — SessionStart hook converts + queues; /wiki-sync processes queue

  • No servers, no database, no npm — Python stdlib + markdown. Syntax highlighting loads from a highlight.js CDN at view time.

Tutorial — every command in 90 seconds

A guided tour. Run these in order and you'll have a fully working wiki at http://127.0.0.1:8765/ by the end. Each command is idempotent and prints what it did.

A scripted recording of the same flow ships at docs/videos/cli-tutorial.gif (31 seconds against an 8-session sandbox). The reproducible source is docs/videos/cli-tutorial.tape — re-render anytime with vhs docs/videos/cli-tutorial.tape.

# 1. One-time scaffold (≈1 sec). Creates raw/, wiki/, site/, seed nav files.
llmwiki init

# 2. Pull in your sessions (≈1 sec / 100 sessions). Walks every adapter
#    that's "available" on this machine (Claude Code, Codex CLI, Cursor,
#    Gemini, Obsidian, Copilot Chat / CLI), converts new .jsonl files to
#    raw/sessions/*.md, then runs build + lint by default.
llmwiki sync

# 3. Compile the static HTML site (≈3 sec on a 500-session corpus).
#    Already runs as part of `sync`; call directly when you're iterating
#    on a wiki/ page and don't need a fresh sync.
llmwiki build

# 4. Browse it locally. Cmd+K opens the search palette; / focuses the
#    filter bar on /sessions/. Press Ctrl+C to stop.
llmwiki serve

# 5. (Optional) Generate the knowledge graph + AI-consumable exports.
#    `all` runs build → graph → export → lint in one shot.
llmwiki graph
llmwiki export all
llmwiki all     # one-shot equivalent of build + graph + export + lint

That's the entire happy path. Two more commands you'll reach for occasionally:

# Inspect what's installed + configured. Prints a per-adapter table:
# (available: yes/no, configured: yes/no, session-store path).
llmwiki adapters

# Lint the wiki. 16 rules — broken wikilinks, orphaned pages, stale
# summaries, duplicate detection, freshness, missing entities, etc.
# Runs as part of `sync` by default; call directly for a one-shot check.
llmwiki lint

Three optional flags you'll discover later:

  • --adapter <name> — limit sync to one adapter (e.g. --adapter claude_code)

  • --vault PATH — write into an Obsidian / Logseq vault overlay instead of wiki/ (#54)

  • --synthesize — call out to a local Claude / Ollama backend during build for an LLM-generated overview page

Each subcommand has its own --help with the rest. The CLI reference table below is the full list.

How it works

┌─────────────────────────────────────┐
│  ~/.claude/projects/*/*.jsonl       │  ← Claude Code sessions
│  ~/.codex/sessions/**/*.jsonl       │  ← Codex CLI sessions
│  ~/Library/.../Cursor/workspaceS…   │  ← Cursor
│  ~/Documents/Obsidian Vault/        │  ← Obsidian
│  ~/.gemini/                         │  ← Gemini CLI
└──────────────┬──────────────────────┘
               │
               ▼   python3 -m llmwiki sync
┌─────────────────────────────────────┐
│  raw/sessions/<project>/            │  ← immutable markdown (Karpathy layer 1)
│     2026-04-08-<slug>.md            │
└──────────────┬──────────────────────┘
               │
               ▼   /wiki-ingest  (your coding agent)
┌─────────────────────────────────────┐
│  wiki/sources/<slug>.md             │  ← LLM-generated wiki (Karpathy layer 2)
│  wiki/entities/<Name>.md            │
│  wiki/concepts/<Name>.md            │
│  wiki/syntheses/<Name>.md           │
│  wiki/comparisons/<Name>.md         │
│  wiki/questions/<Name>.md           │
│  wiki/index.md, overview.md, log.md │
└──────────────┬──────────────────────┘
               │
               ▼   python3 -m llmwiki build
┌─────────────────────────────────────┐
│  site/                              │  ← static HTML + AI exports
│  ├── index.html, style.css, ...     │
│  ├── sessions/<project>/<slug>.html │
│  ├── sessions/<project>/<slug>.txt  │  (AI sibling)
│  ├── sessions/<project>/<slug>.json │  (AI sibling)
│  ├── llms.txt, llms-full.txt        │
│  ├── graph.jsonld                   │
│  ├── sitemap.xml, rss.xml           │
│  ├── robots.txt, ai-readme.md       │
│  ├── manifest.json                  │
│  └── search-index.json              │
└─────────────────────────────────────┘

See docs/architecture.md for the full 3-layer Karpathy + 8-layer build breakdown.

Documentation

Full production documentation lives under docs/. The editorial hub is docs/index.md — tutorials, per-agent guides, reference, and deployment, all in one place.

Start here:

GoalRead
Install and build your first site in 10 minutesTutorial 01 → 02
Use llmwiki with Claude CodeTutorial 03
Use llmwiki with Codex CLITutorial 04
Query / lint / review your wiki dailyTutorial 05
Point llmwiki at an existing Obsidian / Logseq vaultTutorial 06
See four real end-to-end workflowsTutorial 07

Contributing to docs? See the style guide.

Install

macOS / Linux
git clone https://github.com/Pratiyush/llm-wiki.git
cd llm-wiki
./setup.sh
Windows
git clone https://github.com/Pratiyush/llm-wiki.git
cd llm-wiki
setup.bat
With pip (v0.3+)
pip install -e .                # basic — everything you need
pip install -e '.[graph]'       # + graphifyy AI-powered graph engine
pip install -e '.[dev]'         # + pytest + ruff
pip install -e '.[e2e]'         # + Playwright + pytest-bdd + pytest-html (E2E)
pip install -e '.[all]'         # graph + everything

Syntax highlighting is now powered by highlight.js, loaded from a CDN at view time — no optional deps required.

What setup does
  1. Creates raw/, wiki/, site/ data directories

  2. Installs the llmwiki Python package in-place

  3. Detects your coding agents and enables matching adapters

  4. Optionally offers to install the SessionStart hook into ~/.claude/settings.json for auto-sync

  5. Runs a first sync so you see output immediately

For maintainers

Running the project? The governance scaffold lives under docs/maintainers/ and is loaded by a dedicated skill:

FileWhat it's for
CONTRIBUTING.mdShort rules for contributors — read this first
CODE_OF_CONDUCT.mdContributor Covenant 2.1
SECURITY.mdDisclosure process for redaction bugs, XSS, data leaks
docs/maintainers/ARCHITECTURE.mdOne-page system diagram + layer boundaries + what NOT to add
docs/maintainers/REVIEW_CHECKLIST.mdCanonical code-review criteria
docs/maintainers/RELEASE_PROCESS.mdVersion bump → CHANGELOG → tag → build → publish
docs/maintainers/TRIAGE.mdLabel taxonomy + stale-issue policy
docs/maintainers/ROADMAP.mdNear-term plan + release themes
docs/maintainers/DECLINED.mdGraveyard of declined ideas with reasons

Four Claude Code slash commands automate the common ops:

  • /review-pr <N> — apply the REVIEW_CHECKLIST to a PR and post findings

  • /triage-issue <N> — label + milestone + priority a new issue

  • /release <version> — walk the release process step by step

  • /maintainer — meta-skill that loads every governance doc as context

Running E2E tests

The unit suite (pytest tests/ — 2,651 tests) runs in seconds and covers every module. The end-to-end suite under tests/e2e/ is separate: it builds a minimal demo site, serves it on a random port, drives a real browser via Playwright, and runs scenarios written in Gherkin via pytest-bdd.

Why both? Unit tests lock the contract at the module boundary; E2E locks the contract at the user's browser. A diff that passes unit tests but breaks the Cmd+K palette will fail E2E.

Install the extras (one-time, several hundred MB for the Chromium binary):

pip install -e '.[e2e]'
python -m playwright install chromium

Run the suite:

pytest tests/e2e/ --browser=chromium

Run a single feature:

pytest tests/e2e/test_command_palette.py --browser=chromium -v

The E2E suite is excluded from the default pytest tests/ run (see the --ignore=tests/e2e addopt in pyproject.toml) so you can iterate on the unit suite without waiting for browser installs. CI runs the E2E job as a separate workflow (.github/workflows/e2e.yml) that only fires on PRs touching build.py, the viz modules, or tests/e2e/**.

Feature files live under tests/e2e/features/ — one per UI area (homepage, session page, command palette, keyboard nav, mobile nav, theme toggle, copy-as-markdown, responsive breakpoints, edge cases, accessibility, visual regression). Step definitions are all in tests/e2e/steps/ui_steps.py. Adding a new scenario is usually a 2-line change to a .feature file plus maybe one new step.

Run locally with an HTML report:

pytest tests/e2e/ --browser=chromium \
  --html=e2e-report/index.html --self-contained-html
open e2e-report/index.html     # macOS — opens the browseable report

Where to see test reports:

WhatWhere
Unit test resultsGitHub Actions → ci.yml → latest run → lint-and-test job logs
E2E HTML reportGitHub Actions → e2e.yml → latest run → Artifacts → e2e-html-report (14-day retention)
Visual regression screenshotsSame run → Artifacts → e2e-screenshots
Playwright traces (failed runs only)Same run → Artifacts → playwright-traces (open with playwright show-trace <zip>)
Demo site deploy statusGitHub Actions → pages.yml → latest run

Locally, the HTML report is one file (e2e-report/index.html) that you can open in any browser — pass/fail per scenario, duration, stdout/stderr, screenshot on failure.

Scheduled sync

For a daily / weekly cron-style sync, schedule llmwiki sync directly via your OS's native job runner (launchd on macOS, systemd on Linux, Task Scheduler on Windows). Paths and adapter selection come from examples/sessions_config.json.

CLI reference

llmwiki init                    # scaffold raw/ wiki/ site/ + seed nav files
llmwiki sync                    # convert .jsonl → markdown (auto-build + auto-lint if configured)
llmwiki build                   # compile static HTML + AI exports
llmwiki serve                   # local HTTP server on 127.0.0.1:8765
llmwiki adapters                # list available adapters + configured state (v1.0)
llmwiki graph                   # build knowledge graph (v0.2)
llmwiki lint                    # 16-rule wiki lint (v1.2)
llmwiki export <format>         # AI-consumable exports (v0.4)
llmwiki synthesize              # auto-ingest synthesis pipeline (v0.5)
llmwiki all                     # build → graph → export → lint in one shot (v1.2)
llmwiki version

Each subcommand has its own --help. All commands are also wrapped in one-click shell/batch scripts: sync.sh/.bat, build.sh/.bat, serve.sh/.bat, upgrade.sh/.bat.

Works with

AgentAdapterStatusAdded in
Claude Codellmwiki.adapters.claude_code✅ Productionv0.1
Obsidian (input)llmwiki.adapters.obsidian✅ Productionv0.1
Obsidian (output)llmwiki.obsidian_output✅ Productionv0.2
Codex CLIllmwiki.adapters.codex_cli✅ Productionv0.3
Cursorllmwiki.adapters.cursor🧪 Beta — needs verification against current Cursor session formatv0.5
Gemini CLIllmwiki.adapters.gemini_cli🧪 Beta — layout TBCv0.5
Copilot Chatllmwiki.adapters.copilot_chat🧪 Betav0.9
Copilot CLIllmwiki.adapters.copilot_cli🧪 Betav0.9
OpenCode / OpenClaw—⏸ Deferred—

Adding a new agent is one small file — subclass BaseAdapter, declare SUPPORTED_SCHEMA_VERSIONS, ship a fixture + snapshot test.

MCP server

llmwiki ships its own MCP server (stdio transport, no SDK dependency) so any MCP client can query your wiki directly.

python3 -m llmwiki.mcp   # runs on stdin/stdout

Twelve production tools (7 core + 5 added in v1.0 #159):

ToolWhat
wiki_query(question, max_pages)Keyword search + page content (no LLM synthesis)
wiki_search(term, include_raw)Raw grep over wiki/ (+ optional raw/)
wiki_list_sources(project)List raw source files with metadata
wiki_read_page(path)Read one page (path-traversal guarded)
wiki_lint()Orphans + broken-wikilinks report
wiki_sync(dry_run)Trigger the converter
wiki_export(format)Return any AI-consumable export (llms.txt, jsonld, sitemap, rss, manifest)
wiki_confidence(min, max)Pages by confidence range (v1.0)
wiki_lifecycle(state)Pages by draft/reviewed/verified/stale/archived (v1.0)
wiki_dashboard()Health summary: counts by type, lifecycle, confidence (v1.0)
wiki_entity_search(name, entity_type)Search entities by name substring or type (v1.0)
wiki_category_browse(tag)Browse tags with counts, drill into specific tag (v1.0)

Register in your MCP client's config — e.g. for Claude Desktop, add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "llmwiki": {
      "command": "python3",
      "args": ["-m", "llmwiki.mcp"]
    }
  }
}

Configuration

Single JSON config at examples/sessions_config.json. Copy to config.json and edit:

{
  "filters": {
    "live_session_minutes": 60,
    "exclude_projects": []
  },
  "redaction": {
    "real_username": "YOUR_USERNAME",
    "replacement_username": "USER",
    "extra_patterns": [
      "(?i)(api[_-]?key|secret|token|bearer|password)...",
      "sk-[A-Za-z0-9]{20,}"
    ]
  },
  "truncation": {
    "tool_result_chars": 500,
    "bash_stdout_lines": 5
  },
  "adapters": {
    "obsidian": {
      "vault_paths": ["~/Documents/Obsidian Vault"]
    }
  }
}

All paths, regexes, truncation limits, and per-adapter settings are tunable. See docs/configuration.md.

.llmwikiignore

Gitignore-style pattern file at the repo root. Skip entire projects, dates, or specific sessions without touching config:

# Skip a whole project
confidential-client/
# Skip anything before a date
*2025-*
# Keep exception
!confidential-client/public-*

Karpathy's LLM Wiki pattern

This project follows the three-layer structure described in Karpathy's gist:

  1. Raw sources (raw/) — immutable. Session transcripts converted from .jsonl.

  2. The wiki (wiki/) — LLM-generated. One page per entity, concept, source. Interlinked via [[wikilinks]].

  3. The schema (CLAUDE.md, AGENTS.md) — tells your agent how to ingest and query.

See docs/architecture.md for the full breakdown and how it maps to the file tree.

Design principles

  • Stdlib first — only mandatory runtime dep is markdown. Optional extras (graph, dev, e2e) layer in graph engines, lint/test tooling, and Playwright on top.

  • Works offline — no Google fonts, no external CSS. Syntax highlighting loads from a highlight.js CDN but degrades gracefully without it.

  • Redact by default — username, API keys, tokens, emails all get redacted before entering the wiki.

  • Idempotent everything — re-running any command is safe and cheap.

  • Agent-agnostic core — the converter doesn't know which agent produced the .jsonl; adapters translate.

  • Privacy by default — localhost-only binding, no telemetry, no cloud calls.

  • Dual-format output (v0.4) — every page ships both for humans (HTML) and AI agents (TXT + JSON + JSON-LD + sitemap + llms.txt).

Docs

Per-adapter docs:

Releases

VersionFocusTag
v0.1.0Core release — Claude Code adapter, god-level HTML UI, schema, CI, plugin scaffoldingv0.1.0
v0.2.0Extensions — 3 new slash commands, 3 new adapters, Obsidian bidirectional, full MCP serverv0.2.0
v0.3.0PyPI packaging, eval framework, i18n scaffoldv0.3.0
v0.4.0AI + human dual format — per-page .txt/.json siblings, llms.txt, JSON-LD graph, sitemap, RSS, schema.org microdata, reading time, related pages, activity heatmap, deep-link anchors, build manifest, link checker, wiki_export MCP toolv0.4.0
v0.5.0 – v0.9.0Internal sprint milestones — features (_context.md, auto-ingest, qmd export, model-profile schema, activity heatmap, Copilot adapters, etc.) shipped consolidated under the v0.9.x line. No standalone tags were published.—
v0.9.1Sprint 1 & 2 foundation — link-obsidian CLI, 4-factor confidence scoring, 5-state lifecycle machine, llmbook-reference skill, 7 entity types, flat raw/ naming, pending ingest queue, _context.md stubs, meeting + Jira adapters, configurable Web Clipper intake, rich log formatv0.9.1
v0.9.2Sprint 3 quality — 11 lint rules (8 basic + 3 LLM-powered), Auto Dream MEMORY.md consolidation, Dataview dashboard template, category pages (Dataview + static), auto-build on sync + configurable lint schedulev0.9.2
v0.9.3Sprint 3 polish — Obsidian Templater templates, integration guide, two-way editing tests, MCP server 7→12 tools, adapter config validation, pipeline fix (sigstore, PyPI gate)v0.9.3
v0.9.4Session C1 (Sprint 4) — multi-agent skill installer, enhanced search with facets, configurable scheduled sync (launchd/systemd/Task Scheduler), CI wiki-checks workflowv0.9.4
v0.9.5Docs polish + consistency audit before v1.0.0v0.9.5
v1.0.0Production-ready Obsidian integration — full v1.0 scopev1.0.0
v1.1.0-rc1Solo quick-win sprint — candidates workflow, Ollama scaffold, prompt-cache scaffoldv1.1.0-rc1
v1.1.0-rc2Session E — interactive graph viewer + remaining code-only v1.1 workv1.1.0-rc2
v1.1.0-rc3Gap-sweep bundle — state portability, quarantine, sync --status, log CLI, synthesize --estimate breakdown, tag family, stale references, graph context menu, raw immutability, AI-sessions defaultv1.1.0-rc3
v1.1.0-rc4Navigation + quality — graph site_url resolver (99.7% → 0% dead clicks), llmwiki backlinks CLI (95% → 0% orphan pages), source-code → GitHub link rewriter (471 → 100 broken), verify-before-fixing contribution rulev1.1.0-rc4
v1.1.0-rc5Site audit + 5 closed batches — session-local ref stripping (351 → 247 broken), cheatsheet, README/CONTRIBUTING compile, expanded E2E, slash-CLI parity test, 4 adapter docs, Ollama tutorial, dual-mode docs skeleton, /wiki-synthesize slashv1.1.0-rc5
v1.1.0-rc6rc6 batch — fixed adapter tag hardcoded to claude-code for every adapter (#346), tutorial UX polish with in-page TOC + prev/next + edit-on-GitHub (#282), command palette now indexes 107 doc pages + 17 slash commands (#277), content-hash cache for md_to_html (#283)v1.1.0-rc6
v1.1.0-rc7rc7 batch — automatic AI-suggested tags during synthesis (#351), link-checker config fix (#348, #350, #353)v1.1.0-rc7
v1.1.0-rc8rc8 batch — complete Mode B agent-delegate backend (#316): new llmwiki synthesize --list-pending + --complete <uuid> CLI subcommands, /wiki-sync step 6 auto-detects pending prompts, Mode B ships end-to-end without an API keyv1.1.0-rc8
v1.2.0First stable on the 1.x line — llmwiki all one-shot pipeline runner, Playwright + axe-core E2E suite (#384), project-stub auto-seeding, 2 new lint rules, critical export-fidelity + sync-collision fixes, 10 UX-critique items (#387). PyPI distribution name: llm-notebook.v1.2.0

Roadmap

Shipped milestones:

  • v0.5.0 — Folder-level _context.md, auto-ingest, adapter graduations, lazy search index, scheduled sync, WCAG, E2E tests (milestone)

  • v0.6.0 — qmd export, GitLab Pages CI, PyPI release automation, maintainer governance scaffold (milestone)

  • v0.7.0 — Structured model-profile schema, vs-comparison pages, append-only changelog timeline (milestone)

  • v0.8.0 — 365-day activity heatmap, tool-calling bar chart, token usage card, session metrics frontmatter (milestone)

  • v0.9.0 — Project topics, agent labels, Copilot adapters, image pipeline, highlight.js, public demo deployment

  • v0.9.x — Sprint 1-4 foundation for v1.0.0 Obsidian integration: confidence scoring, lifecycle state machine, 9 navigation files, 11 lint rules, Auto Dream, Dataview dashboard, multi-agent skills, 12-tool MCP server, meeting + Jira adapters

Active milestones:

MilestoneFocusTracking
v1.0.0Final docs polish + PyPI trusted publisher + releaseMilestone
v1.1.0Ollama backend, prompt caching, interactive graph viewer, Homebrew tapMilestone
v1.2.0ChatGPT + OpenCode adapters, vault-overlay mode, tree-aware search, cache tiersMilestone
Deployment targets

Acknowledgements

License

MIT © Pratiyush

docs/framework.md

llmwiki Framework — Building an Agent-Native Dev Tool

Adapted from the maintainer's "Open Source Project Framework v4.0" (local reference — kept outside the public repo).

Extensions specific to llmwiki and any tool in this class (dev tools that ingest from AI coding agents):

  1. Agent-Aware pipeline (Phase 1.75)

  2. Adapter Contribution flow (Phase 5.25)

  3. Self-Demo pattern (Phase 6.5)

  4. Living-Knowledge loop (Phase 7.5)

  5. Schema-Versioning rules (cross-cutting)

  6. Privacy-First rules (cross-cutting)

  7. Performance Budget (cross-cutting)

  8. Dogfooding Meta-Loop (cross-cutting)

This document is both the spec for how llmwiki is built and the contribution guide for anyone extending it. It is the source of truth for what "done" means at each phase.


The Pipeline (extended)

0 CAPTURE  →  1 VALIDATE  →  1.25 RESEARCH  →  1.5 STEERING  →  1.75 AGENT SURVEY
  →  2 BRAND  →  3 STRUCTURE  →  4 CONTENT  →  5 CONTRIBUTION  →  5.25 ADAPTER FLOW
  →  5.5 PRE-LAUNCH QA  →  6 LAUNCH  →  6.5 SELF-DEMO  →  7 GROW
  →  7.5 LIVING KNOWLEDGE  →  8 MAINTAIN

Five new phases slot into the parent pipeline. Kiro-style spec-driven overlay applies to every phase (see .kiro/steering/ for always-loaded rules).

The new phases are:

PhaseNew?Why it existsDeliverable
1.75 Agent SurveyNEWAgent-native tools need to know the .jsonl / session store schema for every agent they claim to supportPer-agent compatibility matrix + test fixtures
5.25 Adapter FlowNEWExtensible agent tools need a contract for community-contributed adaptersdocs/adapter-contract.md + PR template
6.5 Self-DemoNEWDev tools that produce browsable HTML have a killer demo surface — the tool's own dev historyPublic GitHub Pages site built from the repo's own sessions
7.5 Living KnowledgeNEWThe wiki built during development IS a growth engine — publish it and it sells the tool for youPublic wiki updating on every release

Phase 0 — Capture

Same as parent framework. See idea-brief.md at the repo root for llmwiki's capture.

Gate to Phase 1: idea-brief.md exists and names the target users + the one non-obvious mechanism that makes this 10x.


Phase 1 — Validate

Same scoring (/25). llmwiki scored 22/25 on 2026-04-08 (see _progress.md).

DimensionScoreNote
Gap5/5No existing tool bridges .jsonl → Karpathy wiki
Quality gap5/5Existing implementations require Node + Postgres + MCP; we require only stdlib + one pip install
Audience4/5Every Claude Code user is a potential user; niche but growing fast
Effort4/5v0.1 ships in a day; v1.0 in a week
Personal fit4/5Author already has 278+ session transcripts; uses the tool daily

Kill threshold: < 13/25 → kill. 13–19 → research further. 20+ → build.


Phase 1.5 — Project Steering

llmwiki steering decisions (locked on 2026-04-08):

DecisionChoiceRationale
Runtime dep floorPython 3.9+ stdlib + markdownMatches oldest common macOS system Python
Optional depsgraphifyy (advanced graph layout)Detected, not required. PDF ingestion was removed in the simplification sweep.
No-network by defaultTruePrivacy + offline-first
Binding default127.0.0.1 onlyPrivacy-first — user must opt-in to LAN
Redaction defaultONUsername, API keys, tokens, emails — all redacted
Config fileJSON, single fileTOML excluded because tomllib is 3.11+ only
DistributionGit-native (clone + ./setup.sh)v0.1. pip-installable from git in v0.2
Branch namemasterMatches author's other projects
LicenseMITPermissive, widely understood
TelemetryNone, everTrust the user's machine
GPL/AGPL depsForbiddenKeep the tool MIT-compatible end-to-end

Phase 1.75 — Agent Survey (NEW)

Before Phase 2 Brand, any tool targeting AI coding agents must complete this survey:

Agent compatibility matrix
AgentSession storeFile patternRecord types seenTested versionAdapter status
Claude Code~/.claude/projects/<proj>/<uuid>.jsonl + <uuid>/subagents/agent-*.jsonluser, assistant, tool_use, tool_result, queue-operation, file-history-snapshot, progress2.1.87✅ Production
Codex CLI~/.codex/sessions/ (TBC)TBCTBCTBC🚧 Stub
Gemini CLITBCTBCTBCTBC⏳ Planned
OpenCode~/.opencode/ (TBC)TBCTBCTBC⏳ Planned
Test fixture requirements

Every claimed agent must ship:

  1. At least one fixture .jsonl under tests/fixtures/<agent>/ (synthetic or heavily redacted).

  2. A snapshot test that converts the fixture and asserts the output matches tests/snapshots/<agent>/*.md.

  3. A schema version constant pinned in the adapter: SUPPORTED_SCHEMA_VERSIONS = ["..."].

Without all three, the adapter ships as a stub (imports cleanly, logs "not yet tested", does not convert).

Graceful degradation rule

When an adapter encounters a record type it doesn't know:

  • Skip it silently — don't crash the build

  • Log at DEBUG level, not WARN or ERROR

  • Never drop user-visible content — user prompts and assistant text are always rendered even if the wrapping record is unknown

Gate to Phase 2

1.75 closes when:

  • [x] Matrix row exists for every agent the README claims to support

  • [x] Test fixtures exist for every "Production" adapter

  • [x] Stub adapters are clearly marked in the README and CHANGELOG


Phase 2 — Brand

Same as parent. llmwiki brand artifacts:

  • Name: llmwiki (lowercase, one word)

  • Tagline: "LLM-powered knowledge base from your Claude Code and Codex CLI sessions"

  • README header: License + Python + Claude Code badge + Codex badge

  • LICENSE: MIT


Phase 3 — Structure

Same as parent. llmwiki layout is defined in docs/architecture.md. Key invariants:

llmwiki/                      # Python package (renamed from tools/)
├── __init__.py
├── __main__.py               # enables `python3 -m llmwiki`
├── cli.py                    # argparse entry
├── convert.py                # .jsonl → markdown
├── build.py                  # markdown → HTML
├── serve.py                  # HTTP server
├── adapters/
│   ├── __init__.py           # registry
│   ├── base.py               # BaseAdapter
│   ├── claude_code.py
│   └── codex_cli.py
└── templates/
    ├── style.css             # embedded as Python string for single-file rendering
    └── script.js             # embedded as Python string

raw/, wiki/, site/            # [gitignored] data layers
bin/, docs/, examples/        # user-facing
.claude/commands/             # Claude Code slash commands (committed)
.github/workflows/            # CI (committed)
Hard rule — no dual Python package

There is exactly ONE llmwiki/ directory that is a Python package. Tools live inside it, not alongside it in a tools/ sibling. (This is a lesson from the earlier llm-wiki workspace which had both.)


Phase 4 — Content

Same as parent. For llmwiki specifically:

  • CSS/JS are Python string constants inside build.py — single-file rendering, no template loader, no file watching complexity.

  • No templates directory as separate files (the templates/ subdirectory is a stub for future split when the files grow beyond 2000 lines).

  • Syntax highlighting uses highlight.js loaded from a CDN at view time. No build-time syntax parsing required.

Performance Budget (cross-cutting rule)
MetricTargetMeasured 2026-04-08
Cold build time (300 sessions)< 15s9s
Incremental build time (no changes)< 1s0.4s
Total static-site size (300 sessions)< 50 MB24 MB
Per-session HTML page< 500 KBavg 50 KB
CSS + JS bundle< 100 KB12 KB

If any metric exceeds its budget, the offending change is blocked or must be preceded by a measurement + optimisation PR.

Privacy-First rules (cross-cutting)
  1. Redaction is on by default. Username, API keys, tokens, and emails are redacted at the converter layer, before anything hits raw/.

  2. No telemetry, ever. Not even anonymised "which adapter is used". The tool never calls home.

  3. Binding default is 127.0.0.1. LAN or public binding requires an explicit --host 0.0.0.0.

  4. No cloud features. No auth, no accounts, no sync. Everything is local.

  5. Config never stores secrets. The config file only stores regex patterns and truncation limits.

  6. CI must pass grep -r "pratiyush1" site/ with zero hits on any build produced from fixtures.

Schema-Versioning rules (cross-cutting)
  1. Every adapter declares SUPPORTED_SCHEMA_VERSIONS: list[str].

  2. When an adapter sees a session from an unlisted version, it logs DEBUG and continues (graceful degradation).

  3. Test fixtures are committed per-version — tests/fixtures/claude_code/v2.1/*.jsonl.

  4. Major agent version bumps get their own adapter file (never a monolithic if/elif chain).


Phase 5 — Contribution Setup

Same as parent plus one addition: adapter contribution flow (Phase 5.25).

PR rules (reiterated from parent)
  • git config user.name: Pratiyush

  • git config user.email: [e-mail address on the upstream page](https://github.com/Pratiyush/llm-wiki/blob/b1088890ee0743810a92577aecad946c6b3eb2d2/docs/framework.md)

  • No AI co-authored-by lines

  • One PR per concern

  • Small commits (one file group per commit)

Library-style two-workflow CI

From parent framework. For llmwiki:

  • ci.yml — lint + build smoke test on push + PR to master. Never publishes.

  • pages.yml — deploys the self-demo site (see Phase 6.5) on tag push.


Phase 5.25 — Adapter Contribution Flow (NEW)

An extensible agent tool needs a predictable way for community contributors to add support for a new agent.

Contract

To add a new agent adapter, a PR must include:

  1. One file under llmwiki/adapters/<agent>.py that:

    • Subclasses BaseAdapter

    • Registers itself via @register("<agent>")

    • Sets session_store_path to the agent's default location(s)

    • Declares SUPPORTED_SCHEMA_VERSIONS

    • Overrides derive_project_slug() if needed

  2. At least one fixture under tests/fixtures/<agent>/minimal.jsonl (synthetic or heavily redacted).

  3. One snapshot test under tests/snapshots/<agent>/minimal.md.

  4. One test under tests/test_<agent>_adapter.py that loads the fixture, runs the converter, and diffs against the snapshot.

  5. One documentation page at docs/adapters/<agent>.md explaining:

    • What session store path the adapter reads

    • How to verify the adapter sees sessions (python3 -m llmwiki adapters)

    • Known format quirks

  6. A CHANGELOG entry under ## [Unreleased].

  7. One line in README.md under "Works with".

Review checklist
  • [ ] Adapter declares SUPPORTED_SCHEMA_VERSIONS

  • [ ] Fixture file is under 50 KB and contains no real PII

  • [ ] Snapshot test passes locally

  • [ ] docs/adapters/<agent>.md exists and is linked from README

  • [ ] Graceful degradation: unknown record types are skipped, not crashed on

  • [ ] No new runtime deps introduced

Gate to Phase 5.5

Adapter-flow is met when the checklist above is automatable (a GitHub Actions workflow enforces it on every PR touching llmwiki/adapters/**).


Phase 5.5 — Pre-Launch QA

Same as parent. For llmwiki specifically:

  • [ ] Run ./setup.sh on a pristine git clone

  • [ ] Run ./sync.sh && ./build.sh && ./serve.sh

  • [ ] Visit http://127.0.0.1:8765/ and click through 5 random session pages

  • [ ] Cmd+K opens the command palette

  • [ ] / focuses the search bar

  • [ ] Dark mode toggle works and persists

  • [ ] Copy-code button works on a code block

  • [ ] Copy-as-markdown button works on a session page

  • [ ] grep -r pratiyush1 site/ returns zero hits (privacy check)

  • [ ] All links in README return HTTP 200

  • [ ] python3 -m llmwiki --version prints the version

  • [ ] python3 -m llmwiki adapters lists claude_code as available


Phase 6 — Launch

Same as parent:

  1. git init

  2. Atomic commits per file group (README separate from code, tests separate from adapters, etc.)

  3. gh repo create Pratiyush/llmwiki --public

  4. git push -u origin master

  5. git tag v0.1.0 && git push origin v0.1.0

  6. Create GitHub Release (mark as pre-release for 0.x)


Phase 6.5 — Self-Demo (NEW)

llmwiki's killer demo is its own repo.

Every dev tool that produces browsable output should publish its own dev history as the demo. The pattern:

  1. On tag push, CI: a. Runs the tool against the author's own session transcripts (stored as an encrypted test corpus OR synthetic fixtures) b. Builds the HTML site to site/ c. Publishes to GitHub Pages

  2. The GitHub Pages URL becomes the README's demo link.

  3. Every release updates the demo automatically.

  4. Visitors SEE the exact output they'd get. No screenshots, no "look here's what it looks like on my machine".

For privacy reasons, llmwiki's self-demo uses a synthetic corpus under tests/fixtures/demo/, not the author's real session history. The fixtures are hand-curated, cover all UI states (short sessions, long sessions, sub-agents, code blocks, tool calls, errors), and are committed to the repo.

Gate to Phase 7

Self-demo is closed when:

  • [x] tests/fixtures/demo/ has 10+ representative sessions

  • [ ] .github/workflows/pages.yml builds and publishes on tag push

  • [ ] The README's demo link is a working URL


Phase 7 — Grow

Same as parent. Platform strategies for a dev tool:

PlatformAngle
Reddit r/ClaudeAI"I built a local tool that turns all your Claude Code sessions into a Karpathy-style wiki"
Reddit r/programming"Self-hosted knowledge base from your AI coding sessions, no servers needed"
Hacker News"Show HN: llmwiki — Turn your coding agent session history into a searchable wiki"
X/TwitterThread: screenshot → demo URL → install command → link
Dev.toLong-form: "I have 278 Claude Code sessions. I built this to browse them."
LinkedIn"Learning from your own work" framing

Phase 7.5 — Living Knowledge (NEW)

The wiki built during development IS a growth engine. Publish it.

  • The author's own wiki/ (synthetic or hand-curated) becomes a public knowledge base at https://pratiyush.github.io/llmwiki/wiki/.

  • Every release refreshes the public wiki with new insights, decisions, and patterns extracted from dev sessions.

  • Visitors who land on the demo can also browse the living documentation of how the tool is built — a form of meta-transparency that doubles as SEO.

Operational rules
  1. No real PII. Use the same synthetic corpus as Phase 6.5 Self-Demo.

  2. Opt-in. The pages.yml workflow only publishes to Pages when a tag is pushed, not on every commit.

  3. The public wiki and the release notes cross-link. Every release's changelog links to the relevant wiki page.

  4. Feedback loop. Community feedback on wiki pages (via GitHub Issues) feeds back into the framework.


Phase 8 — Maintain

Same as parent plus agent-specific additions:

Monthly checklist
  • [ ] Check Claude Code / Codex CLI release notes for schema changes

  • [ ] Re-run test fixtures against latest CLI version

  • [ ] Update SUPPORTED_SCHEMA_VERSIONS if compatibility confirmed

  • [ ] Bump CHANGELOG

  • [ ] Re-run pre-launch QA checklist

  • [ ] Review open issues labelled adapter:*

Schema-change response playbook

When an agent ships a new .jsonl schema:

  1. Create a fresh fixture from a real (redacted) session

  2. Run the converter; note any crashes or data-loss

  3. If graceful degradation works: add the version to SUPPORTED_SCHEMA_VERSIONS, commit the fixture, done

  4. If not: open an issue, tag adapter:<agent>, block the release until fixed

  5. If the change is breaking: ship a new adapter file (claude_code_v3.py) alongside the old one, route by version


Dogfooding Meta-Loop (cross-cutting)

llmwiki tracks its own development with llmwiki.

  • Every dev session on llmwiki is already being captured by Claude Code.

  • ./sync.sh pulls those sessions into raw/sessions/llmwiki/.

  • The author runs ./build.sh and reads the output to validate the tool on its own dev history.

  • Insights (bugs, UX issues, missing features) get extracted into tasks.md.

  • The loop closes: the tool's own output drives the tool's own backlog.

This is only possible because the tool is self-referential by design — it's a dev tool that browses dev sessions, built during dev sessions.


Summary of extensions over the parent framework

Phase / RuleAddedWhat it gives you
1.75 Agent Survey✅Predictable adapter compatibility tracking
5.25 Adapter Flow✅Community can extend the tool without the author's intervention
6.5 Self-Demo✅Zero-effort landing-page demo from CI
7.5 Living Knowledge✅The dev wiki doubles as marketing + meta-documentation
Schema-Versioning rules✅Graceful degradation when upstream agents change format
Privacy-First rules✅No telemetry, no network, no PII by default
Performance Budget✅Budget-enforced build pipeline
Dogfooding Meta-Loop✅Tool improves itself from its own output

None of these violate the parent framework; they extend it with patterns specific to agent-native dev tools — a category that the parent framework's Curated Lists / Libraries / Marketplaces / Dev Tools typology didn't cover.

Future projects in this category (a Cursor wiki, a Cline session browser, a multi-agent unified viewer) should inherit this document and extend it further.

512 files · 468 not served here

Advantages

  • Supports multiple AI agent session formats including Claude Code, Codex CLI, Cursor, and Gemini CLI. evidence: README.md
  • Produces machine-readable exports like JSON-LD and llms.txt for direct AI agent consumption. evidence: README.md

Limitations

  • Requires manual setup and maintenance of the local Python environment. evidence: README.md
  • Relies on local file system access, which may be restricted in some cloud-based development environments. evidence: README.md

Security

Risk level: Medium risk

This brain runs

MCP servers (2)

  • .claude-plugin/plugin.json (llmwiki): python3 -m llmwiki.mcp
  • README.md (llmwiki): python3 -m llmwiki.mcp

Agent instructions that run or fetch something (101)

  • .claude/commands/maintainer.md: Run this once at the start of a maintainer session.
  • .claude/commands/maintainer.md: **Check current state** — run these in parallel so you know what the queue looks like:
  • .claude/commands/maintainer.md: gh run list --branch master --limit 5
  • .claude/commands/maintainer.md: Run `/review-pr <N>` to review a specific PR against the canonical checklist
  • .claude/commands/maintainer.md: Run `/triage-issue <N>` to apply the label taxonomy to an untriaged issue
  • .claude/commands/maintainer.md: Run `/release <version>` to walk the release process for a new version bump
  • .claude/commands/release.md: **Run the pre-flight** — confirm all of:
  • .claude/commands/release.md: Master is green (`gh run list --branch master --limit 5`)
  • .claude/commands/release.md: `python3 -m pytest tests/ -q` passes on a clean checkout
  • .claude/commands/release.md: `python3 -m llmwiki build` completes without new warnings
  • .claude/commands/release.md: `README.md` → version badge (`Version-v<NEW>-7C3AED.svg`) Run `python3 -m llmwiki --version` to confirm.
  • .claude/commands/release.md: Run `gh pr list --state merged --limit 30` and cross-reference.
  • .claude/commands/release.md: git add llmwiki/__init__.py pyproject.toml README.md CHANGELOG.md
  • .claude/commands/release.md: git commit -m "release(v<NEW>): bump version + CHANGELOG"
  • .claude/commands/release.md: git tag v<NEW>
  • .claude/commands/release.md: git push origin master v<NEW> · uses the network
  • .claude/commands/release.md: gh run list --workflow=pages.yml --limit=3
  • .claude/commands/release.md: Visit `https://pratiyush.github.io/llm-wiki/` and confirm the new version badge is visible. · uses the network
  • .claude/commands/review-pr.md: Run the canonical llmwiki code review against a pull request and post findings.
  • .claude/commands/review-pr.md: **Run the checklist** — apply every section of `REVIEW_CHECKLIST.md` to the diff:
  • .claude/commands/review-pr.md: Tests (happy + edge, descriptive names, regression, tmp_path, run locally)
  • .claude/commands/triage-issue.md: **Check for duplicates** — before labeling, run:
  • .claude/commands/wiki-all.md: Run the full llmwiki pipeline end-to-end: build → graph → export all → lint.
  • .claude/commands/wiki-all.md: `$ARGUMENTS` is forwarded verbatim to `python3 -m llmwiki all`.
  • .claude/commands/wiki-all.md: `--graph-engine builtin` — skip optional Graphify (use when `pip install llm-notebook[graph]` has not been run)
  • .claude/commands/wiki-all.md: `--with-synth` — run `synthesize` before build (fills `wiki/sources/` from `raw/`;
  • .claude/commands/wiki-all.md: Run:
  • .claude/commands/wiki-all.md: python3 -m llmwiki all $ARGUMENTS
  • .claude/commands/wiki-all.md: **lint** — run every registered lint rule against the wiki
  • .claude/commands/wiki-all.md: It is the canonical one-shot "CI-ready site" command to run after `/wiki-sync`.
  • .claude/commands/wiki-build.md: Run:
  • .claude/commands/wiki-build.md: python3 -m llmwiki build $ARGUMENTS
  • .claude/commands/wiki-candidates.md: python3 -m llmwiki candidates list
  • .claude/commands/wiki-candidates.md: python3 -m llmwiki candidates list --stale
  • .claude/commands/wiki-candidates.md: python3 -m llmwiki candidates promote --slug MyEntity
  • .claude/commands/wiki-candidates.md: python3 -m llmwiki candidates merge --slug DuplicateFoo --into Foo
  • .claude/commands/wiki-candidates.md: python3 -m llmwiki candidates discard --slug BogusEntity \
  • .claude/commands/wiki-candidates.md: After any promote/merge, run `/wiki-lint` to catch broken wikilinks from pages that used to point at the candidate location.
  • .claude/commands/wiki-export-marp.md: Run: `python3 -m llmwiki export-marp --topic "$ARGUMENTS"`
  • .claude/commands/wiki-graph.md: Run:
  • .claude/commands/wiki-graph.md: python3 -m llmwiki graph $ARGUMENTS
  • .claude/commands/wiki-graph.md: If the user asked for `html` or `both`, offer to open `graph/graph.html` locally with `python3 -m llmwiki serve --dir graph --port 8766`.
  • .claude/commands/wiki-init.md: Run:
  • .claude/commands/wiki-init.md: python3 -m llmwiki init
  • .claude/commands/wiki-reflect.md: Run a self-reflection pass over the whole wiki — look for patterns, gaps, and improvement opportunities.
  • .claude/commands/wiki-serve.md: Run:
  • .claude/commands/wiki-serve.md: python3 -m llmwiki serve --port ${ARGUMENTS:-8765}
  • .claude/commands/wiki-sync.md: Steps (run in this order, report progress to the user):
  • .claude/commands/wiki-sync.md: python3 -m llmwiki sync $ARGUMENTS
  • .claude/commands/wiki-sync.md: Run:
  • .claude/commands/wiki-sync.md: python3 -m llmwiki synthesize --list-pending
  • .claude/commands/wiki-sync.md: python3 -m llmwiki synthesize --complete <uuid> --page wiki/sources/<project>/<date>-<slug>.md --body /tmp/synth-<uuid>.md
  • .claude/commands/wiki-sync.md: **Done.** Run `/wiki-build` if the caller asked for fresh HTML.
  • .claude/commands/wiki-synthesize.md: Wraps: `python3 -m llmwiki synthesize`
  • .claude/commands/wiki-synthesize.md: | You say | Runs | |---|---| | "just show me what it would cost" | `python3 -m llmwiki synthesize --estimate` | | "preview without writing" | `python3 -m llmwiki synthesize --dry-run` | | "check the backend is reachable" | `python3 -m llmwiki synthesize --check` | | "force re-synthesiz …[+391 chars]
  • .claude/commands/wiki-synthesize.md: First run on a fresh corpus (dummy backend):
  • .claude/commands/wiki-synthesize.md: Re-run on unchanged tree:
  • .claude/skills/llmwiki-query/SKILL.md: **Locate the llmwiki install** (see `llmwiki-sync` skill for the fallback search order).
  • .claude/skills/llmwiki-sync/SKILL.md: Asks a knowledge question that would benefit from the latest sessions ("what have I been working on this week?") — run sync first, then `/wiki-query`
  • .claude/skills/llmwiki-sync/SKILL.md: **Locate the llmwiki install.** Check the current working directory and common locations:
  • .claude/skills/llmwiki-sync/SKILL.md: **Run the converter** (idempotent — safe to re-run):
  • .claude/skills/llmwiki-sync/SKILL.md: python3 -m llmwiki sync
  • .claude/skills/llmwiki-sync/SKILL.md: python3 -m llmwiki sync --project <substring> # only one project
  • .claude/skills/llmwiki-sync/SKILL.md: python3 -m llmwiki sync --since 2026-04-01 # only recent
  • .claude/skills/llmwiki-sync/SKILL.md: python3 -m llmwiki sync --include-current # include <60min live
  • .claude/skills/llmwiki-sync/SKILL.md: python3 -m llmwiki sync --force # ignore state, reconvert all
  • .claude/skills/llmwiki-sync/SKILL.md: python3 -m llmwiki sync --dry-run # preview without writing
  • .claude/skills/llmwiki-sync/SKILL.md: If the user wants the converter to run automatically on every Claude Code session start, offer to add this to `~/.claude/settings.json`:
  • .claude/skills/project-maintainer/SKILL.md: | Phase | The Maintainer's job in this phase | |---|---| | **0 Capture** | Verify `idea-brief.md` exists and names target users + the 10x mechanism | | **1 Validate** | Verify scorecard /25 is in `_progress.md` and ≥20 | | **1.25 Research** | Verify `.temp/` has at least 10 cloned ref …[+1141 chars]
  • .claude/skills/project-maintainer/SKILL.md: **Run stale checks:**
  • .claude/skills/project-maintainer/SKILL.md: **Run CI gates locally** (if configured):
  • .claude/skills/project-maintainer/SKILL.md: Link check: `python3 -m llmwiki lint-docs` (when implemented)
  • .claude/skills/self-learn/SKILL.md: Added **"no AI co-authored-by"** rule to `.kiro/steering/contributing-rules.md` after a first-run slip.
  • .claude/skills/wiki-all/SKILL.md: **lint** — run 14 quality rules, report issues
  • .claude/skills/wiki-all/SKILL.md: Run each step in order.
  • .claude/skills/wiki-all/SKILL.md: python3 -m llmwiki init
  • .claude/skills/wiki-all/SKILL.md: python3 -m llmwiki sync --no-auto-build --no-auto-lint
  • .claude/skills/wiki-all/SKILL.md: python3 -m llmwiki graph
  • .claude/skills/wiki-all/SKILL.md: python3 -c "
  • .claude/skills/wiki-all/SKILL.md: python3 -m llmwiki build
  • .claude/skills/wiki-all/SKILL.md: python3 -m llmwiki lint
  • .claude/skills/wiki-all/SKILL.md: python3 -m llmwiki serve --open
  • .claude/skills/wiki-all/SKILL.md: | Step | Result | |------|--------| | init | N dirs, M seed files | | sync | N converted, M unchanged | | graph | N nodes, M edges, K communities | | build | N HTML files, M MB | | lint | N issues (E errors, W warnings) | | serve | http://127.0.0.1:8765 | · uses the network
  • .kiro/steering/contributing-rules.md: `git config user.name` = `Pratiyush`
  • .kiro/steering/contributing-rules.md: `git config user.email` = `[e-mail address: https://github.com/Pratiyush/llm-wiki]`
  • .kiro/steering/contributing-rules.md: **Run privacy grep before committing**: `grep -r "<your_username>" .` should return zero hits outside `.gitignore`d paths.
  • .kiro/steering/verification-rules.md: [ ] `python3 -m llmwiki --version` prints the version
  • .kiro/steering/verification-rules.md: [ ] `python3 -m llmwiki adapters` lists the expected adapters
  • .kiro/steering/verification-rules.md: [ ] All tests pass: `python3 -m pytest tests/ -q`
  • .kiro/steering/verification-rules.md: [ ] Every internal link resolves (`python3 -m llmwiki lint-docs` or grep)
  • .kiro/steering/verification-rules.md: [ ] `setup.sh` runs clean on a fresh `git clone` · uses the network
  • .kiro/steering/verification-rules.md: [ ] `git tag v<version>` is signed (optional for 0.x)
  • .kiro/steering/verification-rules.md: If the underlying agent schema changed (Claude Code version bump, Codex CLI release), re-run the fixture snapshot tests and update `SUPPORTED_SCHEMA_VERSIONS`.
  • AGENTS.md: The CLI auto-detects which adapter(s) to run.
  • AGENTS.md: Run from inside the repo:
  • AGENTS.md: python3 -m llmwiki sync # convert new .jsonl → raw/sessions/*.md
  • AGENTS.md: python3 -m llmwiki build # compile site/ from raw/ + wiki/
  • AGENTS.md: python3 -m llmwiki serve # local HTTP server on 127.0.0.1:8765
  • AGENTS.md: python3 -m llmwiki init # scaffold raw/, wiki/, site/ directories
  • CLAUDE.md: | Command | Intent | Workflow | |---|---|---| | `/wiki-sync` | Convert new `.jsonl` sessions into `raw/sessions/` AND ingest them into `wiki/` | Runs `python3 -m llmwiki sync`, then executes the Ingest Workflow below for each new file | | `/wiki-ingest <path>` | Ingest one source or fo …[+756 chars]
  • CLAUDE.md: Use `python3 -c "from llmwiki.context_md import find_uncontexted_folders;

Install scripts (1)

  • setup.sh: sh setup.sh
  • Medium risk: runs-instruction-instruction-network (.claude/commands/release.md:48)
  • Medium risk: runs-instruction-instruction-network (.claude/commands/release.md:63)
  • Medium risk: runs-instruction-instruction-network (.kiro/steering/verification-rules.md:63)
  • Low risk: network-instructions (.claude/commands/wiki-all.md:7)
  • Low risk: network-instructions (pyproject.toml:55)
  • Low risk: scripts-present (setup.sh)

Attribution and licence

Created by
Pratiyush
Declared authors
  • Pratiyush (declared in .claude-plugin/plugin.json)
  • Pratiyush (declared in pyproject.toml)
Publisher
Pratiyush Kumar Singh (Community)
Source
Pratiyush/llm-wiki · commit b108889
Licence
MIT License (files served here)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Pratiyush.

Install from source

468 of its files are not served here, so there is no ZIP. Pratiyush/llm-wiki at b108889