Eine Wis­sens­basis aufbauen

Eine Wissensbasis nach Andrej Karpathy ist eine Sammlung von Notizen, die ein Agent aus Rohquellen schreibt und pflegt. Der Mensch legt Quellen hinein und stellt Fragen. Das Muster selbst, seine drei Schichten und seine drei Abläufe erklärt Vibe-Coding / Agentic Engineering, Kapitel 06 ausführlich. Dieses Kapitel fragt enger: Mit welchen Teilen von Claude Code baut man so eine Sammlung, und was davon lässt sich festschreiben?

Karpathy hat seine Beschreibung im April 2026 als Gist (externe Seite, gist.github.com) veröffentlicht. Er nennt sie eine Ideendatei, die man dem eigenen Agenten übergibt. Claude Code nennt er dabei als eines von mehreren Beispielen. Die Einzelheiten soll der Agent gemeinsam mit dem Menschen ausarbeiten. Was folgt, ist also eine mögliche Umsetzung, gebaut aus dem, was die Dokumentation von Claude Code hergibt.

Das Muster in einem Absatz

Rohquellen liegen in einem eigenen Ordner, und der Agent ändert sie nie. Aus ihnen schreibt er ein Wiki aus verlinkten Markdown-Dateien. Eine Schemadatei sagt ihm, wie beides aufgebaut ist. Auf dieser Sammlung laufen drei Abläufe: eine Quelle aufnehmen, eine Frage beantworten, das Wiki durchsehen. Wie sich das von einer Suche über Dokumente unterscheidet, steht in Vibe-Coding / Agentic Engineering, Kapitel 06. Für Notizen und Dokumentation, die ohne dieses Muster in einem Ordner liegen, gilt Kapitel 10.

Wo jedes Teil in Claude Code steckt

Die Schemadatei. Karpathy nennt sie selbst beim Namen: für Claude Code die CLAUDE.md (externe Seite, gist.github.com), für Codex die AGENTS.md. Claude Code lädt sie zu Beginn jeder Sitzung, und Claude liest sie als Kontext (Doku zum Gedächtnis (externe Seite, code.claude.com)). Ein Satz wie „Ändere nie etwas in den Rohquellen“ bleibt dort deshalb eine Bitte an das Modell.

Die drei Abläufe. Die Doku rät zu einem Skill, sobald ein Abschnitt der CLAUDE.md zu einem Ablauf geworden ist (Doku zu Skills (externe Seite, code.claude.com)). Genau das sind Aufnehmen, Fragen und Durchsehen. Die CLAUDE.md behält den Aufbau der Sammlung, jeder Ablauf bekommt seinen Skill. Der Rumpf eines Skills lädt erst, wenn er gebraucht wird.

Die gesperrten Rohquellen. Was die CLAUDE.md erbittet, erzwingt eine Regel in den Einstellungen. Rechteregeln setzt Claude Code selbst durch, gleich was das Modell vorhat (Doku zu Rechten (externe Seite, code.claude.com)). Eine Regel Edit(/raw/**) unter deny sperrt den Ordner raw/ für alle eingebauten Werkzeuge, die Dateien ändern.

Für die Shell gilt die Sperre nur teilweise. Ein Python-Skript, das Dateien selbst öffnet, erreicht sie nicht. Für eine Grenze, die jeden Prozess trifft, verweist die Doku auf die Sandbox.

seitlich verschiebbar

eigene Darstellung nach Karpathy, LLM Wiki (04.04.2026), und der Herstellerdokumentation zu Gedächtnis, Skills und Rechten, Stand 13.10.2026

Das Durchsehen im Takt. Im Gist ist es ein Auftrag, den man von Zeit zu Zeit erteilt. Claude Code kann ihn nach Zeitplan stellen, auf drei Wegen (Doku zu geplanten Aufgaben (externe Seite, code.claude.com)):

• Die geplante Aufgabe der Desktop-App passt, wenn die Sammlung auf dem eigenen Rechner liegt.
• /loop passt für schnelles Nachsehen während einer offenen Sitzung.
• Die Cloud passt für Arbeit, die ohne den eigenen Rechner zuverlässig laufen soll.

Startet /loop einen Skill nach Zeitplan, muss Claude ihn von sich aus aufrufen dürfen. Die Bedingungen der drei Wege vergleicht Kapitel 28.

Der Verlauf. Eine einzige Quelle kann nach Karpathy zehn bis fünfzehn Seiten des Wikis berühren. Ein Commit je Aufnahme macht so einen Durchgang als Ganzes rückgängig. Die Checkpoints von Claude Code sind für schnelle Korrekturen innerhalb einer Sitzung gebaut (Doku zu Checkpoints (externe Seite, code.claude.com)). Eine Datei, die nur ein Befehl in der Shell geändert hat, erfassen sie gar nicht.

Was beim Menschen bleibt

Karpathy teilt die Arbeit klar auf. Der Mensch wählt die Quellen aus, lenkt die Auswertung, findet gute Fragen und überlegt, was das alles bedeutet. Den Rest übernimmt das Modell (Gist (externe Seite, gist.github.com)). Für das Wiki fasst Karpathy die Rollen in einen Satz: Der Mensch liest es, das Modell schreibt es.

In Claude Code bleiben damit drei Aufgaben beim Menschen:

• Quellen auswählen. Was im Rohordner liegt, bestimmt alles Weitere. Karpathy selbst nimmt Quellen am liebsten einzeln auf und bleibt dabei. Er liest die Zusammenfassungen, prüft die Änderungen und sagt dem Modell, was es hervorheben soll.
• Widersprüche entscheiden. Das Modell findet und markiert sie, beim Aufnehmen wie beim Durchsehen. Wer einen Widerspruch auflöst, legt der Gist nicht ausdrücklich fest. Nach Karpathy hält das Modell das Wiki stimmig. Dieses Kapitel legt die Entscheidung trotzdem zum Menschen. Welche von zwei Quellen gilt, gehört zum Nachdenken darüber, was das alles bedeutet.
• Das Wiki lesen. Ein Skill, der anspringt, ist nur gefunden worden. Ob er getan hat, was gemeint war, zeigt erst das Ergebnis (Doku zu Skills (externe Seite, code.claude.com)). Für einen Prüflauf im Takt gilt dasselbe, denn niemand sieht ihm zu.

Dazu kommt die Schemadatei. Karpathy beschreibt sie als etwas, das Mensch und Modell über die Zeit gemeinsam weiterentwickeln. Wie die Skills, die Regel und der Prüflauf im Einzelnen aussehen, zeigt die zweite Ebene. Wo der Gist und die Doku auseinandergehen und was eine solche Sammlung belegt, steht auf der dritten.

Die erste Ebene hat jedem Teil des Musters seinen Ort in Claude Code zugewiesen. Hier steht, wie man die Teile einrichtet. Die Ordnernamen raw/ und wiki/ sind Beispiele, jeder andere Name geht genauso.

Die Sammlung ist ein gewöhnlicher Ordner, und Claude Code arbeitet darin wie in einem Projekt. Wie das mit einem Editor wie Obsidian daneben zusammengeht, steht in Kapitel 10.

Der erste Auftrag

Karpathys Gist ist dafür geschrieben, dem Agenten vorgelegt zu werden. Ein leerer Ordner mit git init, der Text des Gists als Datei und ein Auftrag genügen für den Anfang:

Lies gist.md. Lege nach diesem Muster die
Ordner raw/ und wiki/ an, dazu index.md, log.md
und eine CLAUDE.md für diese Sammlung.
Zeig mir die CLAUDE.md, bevor du sie schreibst.
Skills legen wir danach an.

Die CLAUDE.md ist damit ein Entwurf. Karpathy sieht vor, dass Mensch und Modell die Schemadatei über die Zeit gemeinsam weiterentwickeln.

Was in die CLAUDE.md gehört

In die Datei gehört, was in jeder Sitzung gelten soll:

• welche Ordner es gibt,
• welche Seitenarten das Wiki kennt,
• wie eine Seite ihre Quelle nennt,
• in welcher Form index.md und log.md geführt werden.

Was die beiden Hilfsdateien leisten, erklärt Vibe-Coding / Agentic Engineering, Kapitel 06 auf der zweiten Ebene.

# Wissensbasis

- raw/: Rohquellen. Nur lesen.
- wiki/: Seiten, die Claude schreibt.
- index.md: jede Seite mit Link und einer Zeile.
- log.md: Einträge der Form
  ## [JJJJ-MM-TT] ingest | Titel

Jede Aussage im Wiki nennt ihre Quelle in raw/.
Widersprüche markieren und mir vorlegen.

Die Doku empfiehlt, je CLAUDE.md unter 200 Zeilen zu bleiben. Längere Dateien kosten mehr Kontext und werden schlechter befolgt (Doku zum Gedächtnis (externe Seite, code.claude.com)). Die Abläufe stehen deshalb in Skills.

Drei Skills

Jeder Ablauf bekommt einen Ordner unter .claude/skills/ mit einer Datei SKILL.md. Wie ein Skill aufgebaut ist, steht in Kapitel 17. Für die Sammlung zählt vor allem, wer ihn auslösen darf. Ab Werk dürfen das der Mensch und Claude (Doku zu Skills (externe Seite, code.claude.com)).

Aufnehmen startet der Mensch. Das Feld disable-model-invocation: true hält Claude davon ab, den Skill selbst zu laden, er läuft dann nur über /aufnehmen. In Karpathys Beispielablauf liest das Modell die Quelle, bespricht die Kernpunkte mit dem Menschen und schreibt danach.

---
description: Arbeitet eine neue Quelle aus raw/ ein.
disable-model-invocation: true
---

Für diese Besprechung läuft der Skill im Gespräch, also ohne das Feld context: fork. Mit ihm liefe er in einem eigenen Subagent, der den Verlauf des Gesprächs nicht sieht.

Fragen darf Claude selbst aufrufen, sobald eine Frage die Sammlung betrifft. Der Skill sagt, dass zuerst index.md gelesen wird und dass jede Antwort ihre Seiten nennt. Eine gute Antwort kann als neue Seite ins Wiki zurück (Gist (externe Seite, gist.github.com)).

Durchsehen muss Claude ebenfalls selbst aufrufen dürfen, wenn /loop oder eine andere geplante Aufgabe in der Sitzung ihn als Auftrag starten soll. Mit disable-model-invocation: true liefe er dann nicht. Was er prüft, zählt Karpathy auf: Widersprüche zwischen Seiten, überholte Aussagen, Seiten ohne eingehenden Verweis und anderes mehr. Soll er nur berichten, nimmt ihm das Feld disallowed-tools die Werkzeuge zum Schreiben, solange er aktiv ist. Das Feld gibt es laut Changelog (externe Seite, code.claude.com) seit Version 2.1.152 vom 27.05.2026.

---
description: Prüft das Wiki und meldet Befunde.
disallowed-tools: Edit Write Bash
---

Die Sperre endet mit der nächsten Nachricht des Menschen. Die Shell steht mit in der Liste, weil sie sonst einen Weg zum Schreiben offen ließe.

Die Regel für die Rohquellen

Die Regel steht in .claude/settings.json im Ordner der Sammlung:

{
  "permissions": {
    "deny": [
      "Edit(/raw/**)"
    ]
  }
}

Ein einzelner Schrägstrich am Anfang verankert den Pfad an einem Ordner, der von der Datei mit der Regel abhängt (Doku zu Rechten (externe Seite, code.claude.com)). Für die Projektdatei .claude/settings.json ist das der Ordner, in dem die Sitzung startet. Die Regel trifft also den Ordner raw/ der Sammlung, wenn Claude Code in der Sammlung gestartet wird. Lesen bleibt erlaubt.

Ein Verbot gilt in jedem Rechtemodus, auch in bypassPermissions (Doku zu den Rechtemodi (externe Seite, code.claude.com)). Eine Erlaubnis kann keine Ausnahme aus einem Verbot schneiden. Neue Quellen legt deshalb der Mensch in den Ordner. Karpathy nennt dafür eine Brow­ser­er­wei­te­rung, die Webartikel in Markdown umwandelt.

Die Datei gehört in die Ver­si­ons­ver­wal­tung. Eine Cloud-Sitzung mit genau einem Repository außerhalb eines Projects liest sie aus dem Klon (Doku zu Einstellungen (externe Seite, code.claude.com)). In den Threads eines Projects gelten ihre Rechteregeln nie. Bei mehreren Repositorys in einer Sitzung bei Anthropic gelten die Rechteregeln daraus nicht. Eine .claude/settings.local.json liegt nur auf dem eigenen Rechner und erreicht die Cloud nie.

In der Shell greift die Regel bei Befehlen, die Claude Code als Dateibefehle erkennt, etwa cat, und bei Umleitungen in eine Datei. Ein Skript, das Dateien selbst öffnet, umgeht sie. Mit eingeschalteter Sandbox fließen die Pfade aus den Regeln in deren Grenze ein, und die trifft jeden Prozess der Shell. Ab Werk ist die Sandbox aus (Doku zur Sandbox (externe Seite, code.claude.com)). Scheitert ein Befehl in ihr, kann Claude ihn außerhalb wiederholen. Wer das freigibt, hängt vom Rechtemodus ab. Wie man das abstellt, steht in Vibe-Coding / Agentic Engineering, Kapitel 09 auf der zweiten Ebene.

Durchsehen nach Zeitplan

Die drei Wege aus der ersten Ebene haben je eine Bedingung, die für eine Sammlung zählt. Die Einrichtung beschreibt Kapitel 28.

• /loop in der offenen Sitzung. Der Befehl nimmt einen Skill als Auftrag und wiederholt ihn in jedem Durchgang, etwa als /loop 1d /pruefen. Die Sitzung muss dafür offen bleiben. Eine wiederkehrende Aufgabe löscht sich nach sieben Tagen selbst (Doku zu geplanten Aufgaben (externe Seite, code.claude.com)).
• Geplante Aufgabe der Desktop-App. Sie erreicht die lokalen Dateien und startet nur, solange die App offen und der Rechner wach ist (Doku zur Desktop-App (externe Seite, code.claude.com)). Ab Werk arbeitet sie auf dem Stand des Ordners, auch mit nicht committeten Änderungen. Läuft sie im Modus Manual und braucht ein Werkzeug ohne Erlaubnis, wartet sie, bis jemand zustimmt.
• Routine in der Cloud. Die Sammlung muss dafür als Repository auf GitHub liegen. Die Routine klont es zu Beginn jedes Laufs (Doku zu Routines (externe Seite, code.claude.com)). Läuft sie außerhalb der Threads eines Projects, nimmt sie die Skills aus dem Repository mit. Eine Routine läuft als volle Cloud-Sitzung. Mit der Doku zu Einstellungen lässt sich daraus schließen: Klont sie nur das Repository der Sammlung, gilt dort auch die Regel für raw/. Ausdrücklich steht das in der Doku zu Routines nicht. Darf der Durchgang Seiten nachziehen, schiebt die Routine ihre Änderungen auf einen Zweig mit dem Präfix claude/, wenn der Auftrag nichts anderes sagt. Der Mensch sieht den Zweig durch, bevor er ihn übernimmt. Routines sind eine Research Preview und stehen in den Tarifen Pro, Max, Team und Enterprise bereit.

Aufnehmen ohne Zuschauer

Wer neue Quellen nachts einarbeiten lässt, startet Claude Code über claude -p, wie in Kapitel 29 beschrieben. Vier Schalter machen den Lauf eng:

claude -p "Arbeite die neuen Quellen in raw/ ein." \
  --tools "Read,Write,Edit,Glob,Grep" \
  --permission-mode dontAsk \
  --allowedTools \
  "Edit(/wiki/**),Edit(/index.md),Edit(/log.md)" \
  --max-budget-usd 2

--tools legt fest, welche eingebauten Werkzeuge es überhaupt gibt (CLI-Referenz (externe Seite, code.claude.com)). Ohne Shell entfällt damit die Lücke der Regel aus dem vorigen Abschnitt. Glob und Grep stehen ausdrücklich darin. Auf macOS und Linux lässt Claude Code sie sonst weg und sucht über die Shell (Werkzeugreferenz (externe Seite, code.claude.com)). Das gilt seit Version 2.1.162 vom 03.06.2026, vorher überging --tools die beiden Namen.

Im Modus dontAsk lehnt Claude Code jeden Aufruf ab, der sonst eine Rückfrage auslösen würde (Doku zum Lauf ohne Oberfläche (externe Seite, code.claude.com)). Einen Teil davon kann ein installierter Mod trotzdem freigeben. Schreiben darf der Lauf so nur, wo --allowedTools oder eine Erlaubnisregel aus den Einstellungen es freigibt. Ein installierter Mod kann darüber hinaus einzelne Aufrufe freigeben. Die Pfade in --allowedTools verankert Claude Code ebenfalls am Ordner, in dem die Sitzung startet.

--max-budget-usd misst gegen eine Schätzung der Kosten, und ein Lauf kann die Grenze überschreiten.

Ohne Shell kann der Lauf selbst nicht committen. Den Commit macht deshalb das Skript, das ihn gestartet hat. Mit einem Commit je Lauf lässt sich jede Aufnahme einzeln zurücknehmen. Eine Rohquelle ist dabei Text von außen. Warum ein Lauf ohne Zuschauer solchen Text als Daten behandelt, steht in Kapitel 28 auf der dritten Ebene.

Dieses Kapitel stützt sich vor allem auf zwei Arten von Quellen. Das Muster stammt aus einem Text eines einzelnen Autors. Die Umsetzung stammt aus der Doku des Herstellers, und die beschreibt, was die Funktionen tun. Diese Ebene ordnet beide ein, beschreibt die Wissensbasis hinter dieser Seite und nennt, was offen bleibt.

Was der Gist belegt

Karpathy hat den Gist (externe Seite, gist.github.com) am 04.04.2026 angelegt. Am 13.10.2026 zeigt die Seite eine einzige Fassung. Der Text sagt selbst, dass er abstrakt bleibt und eine Idee beschreibt. Jeder Baustein darin ist ausdrücklich freigestellt.

Zwei Zahlen im Gist betreffen den Umfang. Eine Quelle kann zehn bis fünfzehn Seiten berühren, und ein Inhalts­ver­zeichnis funktioniert bei etwa hundert Quellen und einigen hundert Seiten überraschend gut. Woher die Zahlen stammen, sagt der Gist nicht.

Unter dem Text stehen viele Kommentare. Die am 13.10.2026 sichtbaren stammen von anderen Nutzern, die oft eigene Werkzeuge vorstellen. Über Karpathys Muster belegen sie nichts.

Welche Schwäche sich aus dem Aufbau ergibt, zeigt Vibe-Coding / Agentic Engineering, Kapitel 06 auf der dritten Ebene an einem eigenen Fall.

Wo Gist und Doku auseinandergehen

Wohin die Abläufe gehören. Im Gist beschreibt die Schemadatei auch die Abläufe für Aufnehmen, Fragen und Durchsehen. Die Doku von Claude Code rät, einen Ablauf in einen Skill zu legen (Doku zu Skills (externe Seite, code.claude.com)). Die Trennung hat eine Folge. Ein Skill lädt erst beim Gebrauch, die CLAUDE.md dagegen in jeder Sitzung (Doku zum Gedächtnis (externe Seite, code.claude.com)). Eine Regel, die auch beim freien Fragen gelten soll, etwa die Pflicht zur Quellenangabe, gehört deshalb in die CLAUDE.md.

Was unveränderlich heißt. Für Karpathy ist es eine Eigenschaft der Schicht: Das Modell liest die Rohquellen und ändert sie nie. In Claude Code ist das ohne Regel eine Bitte in der CLAUDE.md. Mit Regel hält es für die Dateiwerkzeuge, für die Shell nur teilweise (Doku zu Rechten (externe Seite, code.claude.com)).

Wie viel der Mensch dabeibleibt. Karpathy bleibt beim Aufnehmen lieber dabei, hält das Gegenteil aber ausdrücklich offen: Man kann viele Quellen auf einmal mit weniger Aufsicht einlesen. Den passenden Ablauf soll jeder selbst finden und im Schema festhalten. Ein Zeitplan in Claude Code entscheidet diese Wahl für die Automatik. Das Durchsehen ist im Gist ein Auftrag, den jemand erteilt. Für ein Wiki im Team erwähnt Karpathy Menschen, die Änderungen prüfen, und auch das nur als Möglichkeit.

Wer Widersprüche auflöst. Der Gist lässt das Modell sie finden und markieren. Wer entscheidet, welche Quelle gilt, sagt er nicht ausdrücklich. Diese Lücke füllt jede Umsetzung selbst, in Claude Code am einfachsten mit einem Satz in der CLAUDE.md und einem Prüf-Skill, der nur berichtet.

Die Wissensbasis hinter dieser Seite

Hinter ki.herwig.de liegt eine Wissensbasis nach diesem Muster. Beschrieben ist hier die Mechanik, die Inhalte bleiben außen vor.

• Ordner für Rohquellen, Wiki, Ausgaben und Vorlagen, dazu ein Inhalts­ver­zeichnis und ein Protokoll.
• Vier Skills im Projektordner, der die Sammlung enthält: aufnehmen, fragen, recherchieren und durchsehen. Alle vier laufen in einem eigenen Subagent.
• Ein Statusfeld im Kopf jeder Rohquelle. Der Aufnahme-Skill nimmt nur Quellen, die als neu markiert sind, und setzt sie danach auf verarbeitet.
• Ein Lauf am frühen Morgen, der nur startet, wenn neue Quellen da sind und seit zwei Tagen keine Aufnahme lief. Er läuft über claude -p ohne Shell und ohne Web, mit Schreibrecht nur in der Wissensbasis und mit Grenzen für Zeit und Kosten. Den Commit macht das Skript danach.
• Eine Linkprüfung als Skript im Prüf-Skill. Sie kennt drei Ergebnisse: in Ordnung, kaputte Verweise, nicht messbar.

Am 13.10.2026 enthielt die Sammlung 16 Rohquellen und 43 Wiki-Seiten. Das Protokoll verzeichnet seit dem 28.07.2026 fünf Durchgänge zur Aufnahme (eigene Zählung). Die Sammlung liegt damit weit unter dem Umfang, bei dem nach Karpathy ein Inhalts­ver­zeichnis noch überraschend gut funktioniert.

Drei Stellen weichen von dem ab, was die zweite Ebene empfiehlt. Erstens schreibt der Aufnahme-Skill in die Rohquellen, nämlich in ihr Statusfeld. Eine Regel Edit(/raw/**) würde genau das sperren. Wer die Rohquellen ganz sperren will, führt den Status deshalb im Protokoll.

Zweitens läuft auch das Aufnehmen in einem Subagent. Der sieht das Gespräch nicht (Doku zu Skills (externe Seite, code.claude.com)). Die Besprechung der Kernpunkte aus Karpathys Beispielablauf entfällt damit. Dafür lässt sich derselbe Skill ohne Zuschauer verwenden.

Drittens braucht der Skill für einige Schritte eine Shell, und der Lauf am Morgen hat keine. Der Lauf liest den Skill deshalb als Regelwerk. Die Schritte mit Shell übernimmt das Skript davor und danach.

Für die Texte dieser Seite gilt eine feste Regel: Die Wissensbasis zeigt, wo nachzusehen ist. Jede Aussage auf der Seite stützt sich auf das Original, das vor der Übernahme abgerufen wird.

Was offen bleibt

• Ob eine Sammlung mit der Zeit besser oder schlechter stimmt. Keine Quelle dieses Kapitels misst das. Für Skills einer Datenauswertung beschreibt Anthropics Datenteam in einem Bericht (externe Seite, claude.com) über das eigene Werkzeug, wie stark die Treffsicherheit auf den eigenen Evals ohne Pflege sank. Die Zahlen stehen in Kapitel 13.
• Wie viel Aufsicht ein Zeitplan verträgt. Karpathy bleibt lieber dabei und lässt das Gegenteil offen. Ein Prüflauf, der nur berichtet, hält den Menschen in der Entscheidung. Ob er die Berichte auch liest, misst kein Werkzeug.
• Wann eine Suche nötig wird. Karpathy nennt dafür nur eine ungefähre Größe. Die Abwägung steht in Vibe-Coding / Agentic Engineering, Kapitel 06 auf der zweiten Ebene.