Idea: LLM Wiki on plotting as a complement to the website

[MarkusNeusinger]

Summary

Build an LLM Wiki on the topic of plots / data visualization as a complementary section to the anyplot website. The wiki would sit alongside the existing per-plot catalog and serve as a self-maintaining, AI-curated knowledge base about visualization concepts, chart-type theory, library trade-offs, design principles, and best practices — exactly the kind of context a user needs around a plot example but that does not belong inside a single specification.md.

The wiki directory doubles as a first-class Obsidian vault so contributors can clone the repo, open wiki/ in Obsidian, and use the full PKM experience (graph view, backlinks, search, plugins) on the same files that power the website.

This is a meta / website-feature idea, not a new plot spec. Please do not apply the spec-request label.

Motivation

Today anyplot is excellent at the "show me a chart" axis:

• Every plot has a spec, implementations across 9 libraries, AI quality review, side-by-side comparison.

But there is a second axis users keep asking for: the "why and when" of plotting.

• When should I use a violin plot vs. a box plot vs. a strip plot?
• What are the perceptual trade-offs of stacked bars vs. grouped bars vs. small multiples?
• Which libraries are good for interactive dashboards vs. publication-quality static figures?
• What does "tidy data" mean for plotnine vs. seaborn?
• Colormap pitfalls, accessibility, log scales, dual axes, etc.

This conceptual knowledge is currently scattered across library docs, blog posts and textbooks. It would be a strong complement to anyplot's example-driven core: examples answer how, the wiki answers what / when / why.

Inspiration: Andrej Karpathy's "LLM Wiki" pattern

The concept is directly inspired by Andrej Karpathy's "LLM Wiki" idea (Apr 2026 X post + Gist) and the wider discussion around using LLMs as autonomous bookkeepers for a personal knowledge base. The metaphor: the repo is the IDE, the LLM is the programmer, the wiki is the codebase.

Key principles to borrow:

• Markdown-first, file-over-app: pages are plain .md files in the repo (similar to how plot specs already live under plots/). Future-proof, diffable, AI-friendly, and natively openable in Obsidian.
• Raw ingestion → distilled wiki: a /raw style inbox where rough notes, references, paper links, library changelog snippets land; an automated pipeline distills them into clean wiki pages.
• Bidirectional linking: wiki pages link to plot specs (plots/<spec-id>/) and plot specs link back to wiki pages ("see also: When to use a box plot").
• Bookkeeping is automated: an LLM job re-links, deduplicates, flags contradictions, updates pages when libraries release new versions, generates MOCs (Maps of Content) per topic.
• But: "Don't delegate understanding" (Steph Ango's counter-position). Edits stay reviewable: the LLM proposes via PR, humans approve. The wiki is AI-maintained, human-governed — same pattern anyplot already uses for plot implementations.

Obsidian vault as a first-class artifact

The wiki/ directory is not only the source for the website — it is a shipped, opinionated Obsidian vault that any contributor (or user) can open directly.

Concretely:

• wiki/.obsidian/ is committed with a shared baseline config: enabled core plugins (Graph, Backlinks, Outline, Templates, Daily Notes), a curated set of community plugins (e.g. Smart Connections, Dataview, Excalidraw if useful, Templater), a default theme, and hotkeys. Per-user state (workspace layout, recent files) goes in .gitignore.
• Obsidian-style [[wikilinks]] are the primary link format inside wiki/. The website renderer must understand both [[wikilinks]] and standard Markdown links and resolve them to the right page. Plot-spec links use a stable convention like [[plots/scatter-basic]] or a plot::scatter-basic Dataview-style inline field.
• Graph view becomes a feature, not a side effect. The Karpathy-style auto-linking pipeline must produce a graph that is meaningful when opened in Obsidian — clusters per chart family, MOCs as hubs, orphan detection runs as a maintenance job and opens an issue when orphans appear.
• Templates (wiki/_templates/) define the canonical frontmatter and structure for: a chart-type page, a concept page, a library comparison, an MOC. The LLM uses these templates when drafting new pages, so human-edited and AI-drafted pages stay visually consistent in Obsidian.
• A CLAUDE.md at the vault root (separate from the repo-level CLAUDE.md) defines the wiki's operational rules for the LLM: tone, frontmatter schema, when to create a new page vs. extend an existing one, when to bump an MOC, link conventions. This is the "schema" Karpathy describes.
• Dataview-compatible frontmatter so power users can build their own queries inside Obsidian (e.g. "all chart-type pages last reviewed > 6 months ago", "all pages tagged #distribution").

This costs us very little — the files are already Markdown — and turns the wiki into something contributors can think in, not just read.

Proposed scope (v1)

1. New top-level directory wiki/ (sibling of plots/) structured as an Obsidian vault, e.g.:

   wiki/
   ├── .obsidian/                  # committed shared config
   ├── _templates/                 # Obsidian + LLM templates
   ├── chart-types/
   │   ├── box-plot.md
   │   └── violin-plot.md
   ├── concepts/
   │   ├── tidy-data.md
   │   └── color-and-accessibility.md
   ├── libraries/
   │   └── matplotlib-vs-seaborn.md
   ├── mocs/
   │   └── distributions.md        # Map of Content
   ├── raw/                        # ingestion inbox (gitignored except .keep)
   └── CLAUDE.md                   # LLM operating rules for the vault
   

2. Frontend tab "Wiki" on anyplot.ai, rendering the Markdown (incl. [[wikilinks]]) with cross-links into the existing plot catalog (and vice versa). Optionally embed a read-only graph visualization mirroring Obsidian's graph view.
3. Automation pipeline modeled on the existing spec-* / impl-* GitHub Actions:
   • wiki-request issue label → AI drafts a wiki page using the right template → PR → human approval → merge.
   • Periodic wiki-maintain job: re-checks [[wikilinks]] between wiki pages and plot specs, proposes updates on library version bumps, flags orphans, regenerates MOCs.
4. Quality review: reuse the Claude review pattern (score threshold, repair attempts) for wiki content.

Non-goals (v1)

• No vector DB / RAG infra yet. Plain Markdown + GitHub search + Obsidian-side Smart Connections is enough to start.
• No live "chat with the wiki" UI on anyplot.ai yet — power users get that via Obsidian locally.
• Not a replacement for plot specs; specs stay the source of truth for runnable examples.

Open questions

• Should wiki pages have a YAML frontmatter schema (similar to specification.yaml) for tags / linked plot ids / last-reviewed date? (Probably yes — also enables Dataview queries in Obsidian.)
• Editorial scope: only visualization topics, or also tooling (Jupyter, Quarto, Streamlit)?
• How aggressively should the automation auto-merge vs. require human review? (Default suggestion: human-in-the-loop on every wiki PR, matching the "downstream KI" / "don't delegate understanding" compromise.)
• Link format: enforce [[wikilinks]] everywhere, or allow mixed [[wikilinks]] + standard [text](path) and normalize at render time?
• Which community plugins are worth shipping in the committed .obsidian/ config? (Suggestion to start: Templater, Dataview, Smart Connections; keep the list small.)
• Naming: "Wiki", "Guide", "Handbook", "Encyclopedia"?

References

• Andrej Karpathy, LLM Wiki (GitHub Gist, 2026)
• Steph Ango (Obsidian CEO), Don't delegate understanding / File over app
• Tobi Lütke, QMD — hybrid local search for Markdown knowledge bases
• Tiago Forte, CODE method (Capture, Organize, Distill, Express)
• Nick Milo, Maps of Content (MOCs) in the LYT framework