nvk/llm-wiki: Wissensbasen, die ein LLM aus Quellen zusammenbaut

Welches Problem hier gelöst wird

Recherche mit einem LLM endet meist in einem Chatverlauf. Die Quellen liegen verstreut, die Zusammenfassung steht in einem Fenster, das beim nächsten Start leer ist. llm-wiki setzt an dieser Stelle an und beschreibt sich selbst als LLM-kompilierte Wissensbasen für jeden AI-Agenten. Der Gegenstand ist also nicht das Modell, sondern der Speicher: ein Verzeichnis mit Markdown-Dateien, das aus eingelesenen Quellen aufgebaut und danach abgefragt wird. Die Zielgruppe sind Nutzer von Claude Code, OpenAI Codex und OpenCode, die ihre Recherche als Dateien im eigenen Dateisystem behalten wollen. Das README nennt zusätzlich Obsidian-Kompatibilität, was bedeutet, dass die Ablage ohne Zwischenschicht in einem gängigen Editor lesbar sein soll. Wer bisher Notizen, Zitate und Belege manuell in ein Wiki übertragen hat, bekommt hier einen Ablauf, der diese Übertragung als eigenen Kompilierungsschritt behandelt.

Ideen, Projekte und die Promotion als eigener Schritt

Auffällig ist die Trennung zwischen Ideen und Projekten. Das README beschreibt den Ablauf so: grobe Ideen festhalten, recherchieren und ausarbeiten, dann genehmigte Briefs ausdrücklich zu Delivery-Projekten befördern. Diese Beförderung ist ein expliziter Vorgang, kein Nebeneffekt der Recherche. Die Portfolio-Ansicht aus v0.18.0 liest über aktive Topic-Wikis hinweg, listet kanonische Ideen und aktive Projekte getrennt auf und unterscheidet ausdrücklich beförderte von direkt angelegten Projekten. Concepts bleiben als unterstützendes Wissen erhalten. Das ist eine Datenmodellentscheidung mit Folgen: Wer viele lose Notizen sammelt, bekommt sie nicht automatisch als Projekt angezeigt. Der Preis dafür ist ein zusätzlicher manueller Schritt, der Nutzen ist, dass die Projektliste nicht mit Halbfertigem vollläuft. Nachvollziehbar ist das aus der Beschreibung des Portfolio-Befehls, der laut Changelog keine abgeleitete Abstammung und keine veralteten Caches verwendet.

Der Weg von der Quelle zum Eintrag

Die Kette besteht aus mehreren benannten Stufen. Über @wiki ingest wird eine URL eingelesen, über @wiki research ein Thema bearbeitet, über @wiki collect ein Collector-Katalog gefüllt, und die Kompilierung erzeugt daraus den Wiki-Bestand. Das README nennt daneben Audits, Abfragen und Artefakterzeugung als eigene Schritte. Für die Recherche gibt es mehrere Modi, darunter den im README hervorgehobenen thesis-driven Ansatz, bei dem eine These die Untersuchung strukturiert, sowie parallele Multi-Agent-Recherche. Wie die einzelnen Stufen intern implementiert sind, lässt sich aus dem vorliegenden Material nicht belegen; das README beschreibt die Befehle und ihre Reihenfolge, nicht die Datenstrukturen dazwischen. Wer die Architektur bewerten will, muss den Quellcode lesen. Ein Punkt ist dagegen klar dokumentiert: Die Abfrage kennt unterschiedliche Tiefen, und die explizite Variante $wiki-query ist laut README klein, lesend und verändert keine Wiki-Dateien. Sie aktiviert sich nie implizit. Das ist eine bewusste Einschränkung, die verhindert, dass eine beiläufige Frage den Bestand anfasst.

Installation in den drei Laufzeitumgebungen

Für Claude Code genügt ein Befehl: claude plugin install wiki@llm-wiki. Für OpenAI Codex registriert man zuerst den Katalog und installiert dann das Plugin, entweder aus GitHub mit codex plugin marketplace add nvk/llm-wiki und codex plugin add wiki@llm-wiki oder aus einem lokalen Checkout über ./scripts/bootstrap-codex-plugin.sh --scope user --verify. Der Bootstrap-Helfer ist der einzige im README dokumentierte Weg, der die Installation selbst überprüft. Für OpenCode wird kein Plugin installiert, sondern eine Anweisungsdatei eingetragen. In opencode.json steht unter instructions eine URL auf die SKILL.md im Repository, dazu ein permission-Block mit external_directory-Einträgen für ~/.config/llm-wiki/** und den iCloud-Pfad. OpenCode lädt die URL laut README bei jedem Sitzungsstart neu, ein manuelles Aktualisieren entfällt damit. Wer stattdessen eine lokale Kopie bevorzugt, lädt die Datei per curl nach ~/.config/opencode/AGENTS.md. Für einen rein lesenden Aufbau gibt es ein kleineres Preset, das auf die wiki-query-SKILL.md zeigt. Die Konfigurationsschlüssel sind damit real und nicht illustrativ: instructions und permission.external_directory.

Hooks, Vertrauen und die Grenze zu privaten Adaptern

Zwei Stellen verdienen vor dem Einsatz Aufmerksamkeit. Erstens die Hooks: Das README weist darauf hin, dass man über /hooks die mitgelieferten Hooks prüfen und ihnen vertrauen muss, wenn die automatische Sitzungserfassung genutzt werden soll. Der @wiki-Skill funktioniert auch ohne dieses Vertrauen. Wer die Sitzungserfassung abschalten will, kann @wiki session disable setzen. Zweitens die Adapter-Grenze, die sich über mehrere Releases hinweg verschoben hat. In v0.19.0 kam ein ausdrücklich vertrauenswürdiges, maschinenlokales Adapter-Registry mit einem JSON-Vertrag llm-wiki-adapter/v1 hinzu. v0.21.3 nennt den Übergang an der Adaptergrenze, v0.22.0 macht das Routing deklarativ, und das öffentliche Plugin enthält seither laut Changelog keine prozedurspezifischen Anmelde-, Browser- oder Bearbeitungsabläufe mehr. Provider-spezifisches Material liegt nur noch im jeweiligen privaten Adapter. Für Nutzer heißt das: Das öffentliche Repository ist kein vollständiger Client für jede Quelle. Wer eine bestimmte Plattform anbinden will, braucht einen passenden Adapter, und der ist nicht Teil der Veröffentlichung. Diese Grenze ist eine Designentscheidung, keine Lücke, aber sie verschiebt Arbeit in Code, den das Projekt nicht mitliefert.

Schreibzugriffe und was sie absichern

Die Release-Historie zeigt ein wiederkehrendes Muster: Schreibvorgänge werden enger gefasst. v0.20.0 führt genehmigte entfernte Schreibzugriffe ein, mit exakten Allowlists für Ressourcen, deklarierten Lese- und Schreibeigenschaften, einer an einen exakten Plan-Hash gebundenen Freigabe, erwarteten Revisionen, stabilen Idempotenzschlüsseln und inhaltsfreier Terminalausgabe. v0.24.0 ergänzt Projekt-Wissens-Checkpoints unter docs/knowledge/<slug>/ mit Dry-Run als erstem Schritt, lesender Verifikation, begrenztem Import, ausgewiesenen Auslassungen und deterministischer Versiegelung. Im Changelog steht ausdrücklich, dass Checkpoint-Schreibvorgänge niemals Commit, Veröffentlichung oder Import genehmigen. v0.24.3 trägt den Titel Privacy-Sensitive Log Retraction, v0.24.2 befasst sich mit einer Reparatur des Index-Vertrags. Diese Abfolge ist ein Signal: Das Projekt behandelt Protokolle und Indizes als Flächen, auf denen sensible Daten liegen bleiben können. Wer den Bestand versioniert, sollte vor dem ersten Commit prüfen, was in Logs und Indexdateien landet.

Wann ein anderes Werkzeug die bessere Wahl ist

Die naheliegende Alternative ist ein klassisches Notizwerkzeug mit manueller Pflege, etwa ein Obsidian-Vault, in den man Quellen selbst einträgt. Der Unterschied liegt nicht im Dateiformat, denn llm-wiki ist Obsidian-kompatibel, sondern im Kompilierungsschritt. Ein manuell gepflegter Vault enthält genau das, was jemand hineingeschrieben hat, und keine Zusammenfassung, die ein Modell aus mehreren Quellen erzeugt hat. Dafür entfällt jede Abhängigkeit von einem Agenten, von Hooks und von Plugin-Updates. Ein zweiter Vergleichspunkt ist eine Such- oder Vektorindexlösung über die eigenen Dokumente: Dort wird nichts kompiliert, sondern zur Abfragezeit gesucht. llm-wiki materialisiert den Zwischenstand als Markdown, was ihn lesbar und diffbar macht, aber auch bedeutet, dass sich Fehler aus der Kompilierung als Text festsetzen. Wer ausschließlich aktuelle Antworten aus unveränderten Quellen braucht, fährt mit einem reinen Retrieval-Ansatz direkter. Wer dagegen einen prüfbaren, versionierbaren Bestand mit explizit beförderten Projekten will, bekommt hier genau diese Struktur.

Pflegeaufwand, Lizenz und was vor dem Einsatz zu prüfen ist

Das Repository steht unter der MIT-Lizenz. Diese erlaubt Weitergabe und Änderung, solange der Lizenztext und der Urheberrechtshinweis erhalten bleiben; sie enthält keine Patentschutzklausel und keine Gewährleistung. Das ist eine Einordnung, keine Rechtsberatung. Wer das Plugin in einem kommerziellen Produkt weiterverbreitet, sollte die Bedingungen mit eigenen Mitteln prüfen. Zum Pflegeaufwand lässt sich aus dem Material sagen: Die Release-Kadenz ist hoch, zwischen v0.24.2 und v0.24.4 liegen fünf Tage, und die Versionssprünge betreffen teils Verträge und Protokolle, nicht nur Oberfläche. Wer Adapter oder eigene Integrationen auf llm-wiki-adapter/v1 aufsetzt, muss mit Änderungen an diesen Verträgen rechnen; v0.21.3 und v0.22.0 zeigen genau solche Übergänge. Für Codex-Nutzer ist der Upgrade-Pfad dokumentiert: codex plugin marketplace upgrade llm-wiki, gefolgt von codex plugin add wiki@llm-wiki. Beim Entfernen sind beide Einträge zu löschen, Plugin und Marktplatz. Vor dem produktiven Einsatz würde ich drei Dinge prüfen: ob die Hooks vertrauenswürdig sind, ob ein privater Adapter für die anvisierten Quellen existiert, und ob der Audit-Lauf gegen ein kleines Topic die erwarteten Abweichungen zwischen Quellen und kompiliertem Bestand sichtbar macht.

Redaktionelles Fazit

Sinnvoll ist der Einsatz für Teams und Einzelpersonen, die ihre Recherche in einem versionierten Verzeichnis mit Obsidian-kompatiblen Markdown-Dateien halten wollen und bereit sind, die Plugin-Hooks zu prüfen. Wer keinen Agenten mit Dateisystemzugriff betreiben will oder eine fertige Wissensdatenbank ohne Kompilierungsschritt sucht, ist hier falsch. Vor dem ersten produktiven Lauf sollte die Trust-Entscheidung über die Hooks fallen und ein Lauf mit @wiki audit gegen ein kleines Topic geprüft werden, weil der Audit der einzige im README dokumentierte Schritt ist, der den kompilierten Bestand gegen die Quellen abgleicht.

Offizielle Quellen

1. License: MIT
2. nvk/llm-wiki on GitHub
3. Project website
4. README
5. Releases