karpathy-llm-wiki: ein Agent-Skill, der Markdown-Seiten statt Embeddings pflegt

Das Problem: Wissen, das bei jeder Frage neu zusammengesucht wird

Retrieval-Augmented Generation holt bei jeder Anfrage Textabschnitte aus einem Korpus und lässt das Modell die Beziehung zwischen ihnen neu herstellen. Das funktioniert, solange der Korpus groß und die Frage breit ist. Es skaliert schlecht, wenn dieselben Zusammenhänge immer wieder neu hergeleitet werden müssen. karpathy-llm-wiki setzt an dieser Stelle an: Statt Rohdokumente bei jeder Frage zu durchsuchen, kompiliert der Agent neue Quellen einmalig in dauerhafte Markdown-Seiten und aktualisiert dabei Querverweise. Die Antwort zitiert anschließend die Seite, auf der das Wissen bereits synthetisiert wurde. Zielgruppe sind laut README Nutzer von Claude Code, Cursor, Codex CLI und OpenCode, also Menschen, die ihren Coding-Agenten bereits täglich benutzen und ihm eine zweite Rolle geben wollen: die eines Redakteurs für eine persönliche Wissensbasis.

Drei Operationen, ein Dateibaum

Der Skill kennt genau drei Operationen: Ingest, Query und Lint. Ingest nimmt eine Quelle entgegen, legt sie unter raw/ ab, sortiert sie ein und erzeugt oder aktualisiert Artikel unter wiki/. Query durchsucht die Wiki-Seiten und antwortet mit Verweisen auf die Markdown-Dateien. Lint prüft Indexintegrität und Links und korrigiert einen Teil der Befunde selbst. Die Verzeichnisstruktur ist bewusst flach: raw/ enthält unveränderliches Quellmaterial, nach Themen und Datum benannt, etwa raw/topic/2026-04-03-source-article.md. Darunter liegt wiki/ mit den kompilierten Seiten, einer globalen Inhaltsübersicht in wiki/index.md und einem append-only geführten Protokoll in wiki/log.md. Entscheidend ist die Richtung des Datenflusses: Eine neue Quelle kann mehrere Wiki-Seiten gleichzeitig verändern, Querverweise verstärken und Widersprüche festhalten. Genau dieser Schritt macht die Wissensbasis über die Zeit dichter, und er findet beim Ingest statt, nicht beim Abfragen.

Installation und die Grenze zwischen Skill und Harness

Die Installation ist ein einziger Befehl: npx add-skill Astro-Han/karpathy-llm-wiki. Laut README funktioniert das für Claude Code, Cursor und OpenCode identisch. Für Codex CLI nennt die Dokumentation einen anderen Weg: den Skill nach .agents/skills/karpathy-llm-wiki/ kopieren. Für alle übrigen Werkzeuge, die dem Agent-Skills-Standard folgen, sollen SKILL.md, references/ und scripts/ in das jeweilige Skill-Verzeichnis kopiert werden. Eine Konfigurationsdatei mit Schlüsseln oder Umgebungsvariablen taucht im Material nicht auf; die Steuerung läuft über natürliche Sprache, etwa "Ingest this article: https://example.com/attention-is-all-you-need" oder "Lint my wiki". Daraus folgt eine architektonische Grenze, die das Projekt selbst zieht: Automatische Hooks und geplante Läufe gehören ausdrücklich nicht zum Skill, sondern zum Agent-Harness. Wer nächtliche Re-Ingests erwartet, muss sie selbst im jeweiligen Werkzeug verdrahten.

Warum hier kein Vektorindex und keine Konfidenzwerte stehen

Der interessanteste Teil des Repositories ist die Liste dessen, was bewusst nicht gebaut wurde. Vektor- oder Graphsuche fehlt mit der Begründung, dass grep und Lesen bei 50K bis 100K Token kuratierten Wikis verlässlicher seien und Suchwerkzeuge erst nachrüstbar seien, wenn die Trefferquote messbar sinkt. Numerische Konfidenz- oder Qualitätswerte wurden verworfen, weil sie keine Kalibrierung hätten und Evidenzstärke in die Prosa gehöre. Persistierte Zeilenangaben als Zitate entfielen, weil beobachtete Treuefehler stets fehlende Werte betrafen, die ein Volltext-grep findet. Auch eine Frischeprüfung über Quell-Hashes fehlt, da raw/ unveränderlich ist und neue Information ohnehin als neue Quelle eintrifft. Diese Begründungen sind nachvollziehbar, solange die Wissensbasis klein bleibt. Sie sind zugleich die Bruchstelle: Wer 50.000 Seiten statt 50.000 Token erreicht, bekommt hier keine Antwort auf das Recall-Problem, sondern nur den Hinweis, dann Suchwerkzeuge zu ergänzen.

Der Unterschied zu einem klassischen RAG-Stack

Der Vergleich liegt auf der Hand, weil das Repository selbst mit dem Topic rag-alternative wirbt. Bei RAG liegen Chunks und Embeddings im Speicher, die Synthese passiert zur Abfragezeit, und das System eignet sich für breites Retrieval über große Korpora. Beim LLM-Wiki-Modell liegen kuratierte Markdown-Seiten vor, die Synthese passiert beim Ingest und bei der Pflege, und der Nutzen liegt in verdichteten Zusammenfassungen und dauerhaften Querverweisen. Der praktische Unterschied zeigt sich im Scheitern: Ein RAG-System liefert bei einer schlechten Abfrage irrelevante Chunks, ein Wiki liefert eine veraltete oder fehlende Seite. Der zweite Fehler ist sichtbar und reparierbar, der erste nicht. Dafür zahlt man mit manueller Kuratierung: Der Mensch wählt Quellen aus und stellt Fragen, das Modell schreibt. Wer diese Rollenteilung nicht will, für den ist der Ansatz nichts.

Wartung, Lizenz und was die Zahlen im README nicht belegen

Das README nennt Nutzungszahlen aus einer produktiven Wissensbasis: 94 Wiki-Artikel über 13 Themenverzeichnisse, 99 ingestierte Quellen und 87 Protokolleinträge in den letzten sieben Tagen. Diese Zahlen stammen aus der Dokumentation des Projekts und belegen, dass der Autor den Workflow selbst dauerhaft betreibt; sie sind kein Nachweis für Qualität oder Reife der Software. Release Notes oder Versionsnummern liefert das Material nicht, der letzte Push liegt laut Repository-Metadaten im Juli 2026. Der Wartungsaufwand entsteht weniger am Code als am Bestand: Jede neue Quelle kann mehrere Seiten berühren, und der Skill verlässt sich darauf, dass Lint regelmäßig läuft, weil es keine Review-Termine pro Artikel gibt. Lizenziert ist das Projekt unter MIT, was die Übernahme in eigene Repositories und kommerzielle Nutzung erlaubt; die mitgelieferten Beispielseiten und Quelltexte können eigene Lizenzbedingungen haben, das sollte man vor einer Weitergabe prüfen. Rechtliche Beratung ersetzt das nicht.

Wo der Ansatz an seine Grenzen stößt

Der Skill ist das falsche Werkzeug, wenn die Wissensbasis aus fremden, sich ständig ändernden Quellen besteht. raw/ ist unveränderlich, eine korrigierte Webseite wird also nicht als Korrektur derselben Quelle erfasst, sondern als neue Quelle. Ebenso fehlt jede Mechanik, um eine Quelle nachträglich zurückzuziehen; das README nennt Retract- und Bad-Source-Werkzeuge als bewusst nicht gebaut und verweist auf manuelle Behandlung. Ein weiterer Bruchpunkt ist die Zitatgenauigkeit: Ohne persistierte Zeilenanker kann eine Antwort auf eine ganze Datei verweisen, was bei langen Seiten wenig hilft. Und wer mehrere Agenten parallel auf demselben Wiki arbeiten lässt, findet im Material keinen Hinweis auf Sperren oder Konfliktauflösung. Das append-only geführte wiki/log.md hilft beim Nachvollziehen, verhindert aber keine gleichzeitigen Schreibvorgänge.

Redaktionelles Fazit

Wer eine kleine, kuratierte Wissensbasis aus eigenen Quellen aufbauen will und ohnehin mit Claude Code, Cursor oder Codex arbeitet, findet hier einen schlanken, MIT-lizenzierten Einstieg über npx add-skill Astro-Han/karpathy-llm-wiki. Wer Volltextsuche über große Bestände, Embeddings oder automatische Läufe im Hintergrund braucht, ist hier falsch: Der Skill verweigert sich Vektor- und Graphsuche ausdrücklich und überlässt Scheduling dem Agent-Harness. Vor dem ersten Commit sollte man prüfen, ob der eigene Agent das Agent-Skills-Verzeichnis liest und ob die Struktur raw/, wiki/index.md und wiki/log.md zur eigenen Ablage passt.

Offizielle Quellen

1. Astro-Han/karpathy-llm-wiki on GitHub
2. Issues
3. License: MIT
4. README