Die Karpathy CLAUDE.md erklärt: Eine Datei hinter einer Skills-Suche

Bei Google Trends erscheint weltweit in den vergangenen sieben Tagen, abgerufen am 23. Oktober 2026, „karpathy skills“ als steigende Suchanfrage unter dem Ausgangsbegriff „claude skills“. Wer dieser Suche folgt, landet an derselben Stelle: github.com/multica-ai/andrej-karpathy-skills, ein Repository, das am 23. Oktober 2026 auf GitHub 222.612 Sterne verzeichnete. Die Beschreibung des Repositories enthält das Wort „Skill“ überhaupt nicht. Dort heißt es: „Eine einzige CLAUDE.md-Datei zur Verbesserung des Verhaltens von Claude Code, abgeleitet aus Andrej Karpathys Beobachtungen zu Fallstricken beim Coding mit LLMs.“

Die Kluft zwischen der Abfrage und dem Objekt ist keine kleine technische Spitzfindigkeit. Ein Skill und eine Datei CLAUDE.md sind unterschiedliche Mechanismen, die unterschiedliche Arbeit leisten, und fast jede Aussage, die Menschen über dieses Repository treffen, hängt entweder davon ab, zu wissen, um welchen der beiden es sich handelt, oder sie setzt stillschweigend den falschen voraus. Die Anleitung darin ist eine einzige Datei. Das Repository um diese Datei herum enthält außerdem ein Plugin-Manifest und einen Ordner unter skills, was wahrscheinlich der Ursprung des Wortes in der Suchleiste ist. Die Verpackung vom Inhalt zu trennen, ist hier der erste sinnvolle Schritt.

Die Zahlen, alle von GitHub und gelesen am 23. Oktober 2026: 222.612 Sterne, 22.321 Forks, erstellt am 27. Januar 2026, zuletzt gepusht am 20. April 2026, MIT-Lizenz. Das letzte Paar ist das Interessante. Das Repository hat seit etwa sechs Monaten keinen Push mehr erhalten, und die Zahl der Sterne ist trotzdem weiter gestiegen.

Die Datei erledigt die Arbeit; die Verpackung erklärt den Suchbegriff.

Öffnet man das Repository, ist die Diskrepanz an der Dateiliste leicht zu erkennen. Im Wurzelverzeichnis liegt CLAUDE.md, daneben CURSOR.md, EXAMPLES.md, ein Ordner .cursor/rules mit denselben Richtlinien als Cursor-Projektregel, ein Ordner .claude-plugin und ein Verzeichnis skills/karpathy-guidelines. Die im README empfohlene Installationsroute ist der Plugin-Marketplace, und dort wird das Ergebnis so beschrieben, dass „der Skill in allen Ihren Projekten verfügbar“ gemacht wird.

Der Suchbegriff ist nicht so sehr falsch als vielmehr unpräzise. Es gibt einen Skills-Ordner. Es gibt ein Plugin. Was es nicht gibt, ist eine Reihe separater Skills, die jeweils eine andere Aufgabe erledigen, was der Form entspricht, die Leute üblicherweise mit einem Skill-Pack meinen: ein Ordner mit einer SKILL.md und den unterstützenden Dateien, die diese Fähigkeit benötigt, aufgerufen für eine Aufgabe. Hier besteht die gesamte Anleitung aus einem einzigen Dokument mit dauerhaften Anweisungen, und das Plugin dient dazu, dieses Dokument in ein Projekt zu bringen.

Ob diese Unterscheidung für dich eine Rolle spielt, hängt davon ab, was du von der Suche erwartet hast. Wenn du einen Werkzeugkasten gesucht hast, ist das hier keiner. Wenn du ein kurzes Regelwerk wolltest, das das Verhalten eines Coding-Agents über ein Projekt hinweg verändert, dann ist es genau das, und es lohnt sich zu verstehen, warum jemand es als Datei statt als Skills schreiben würde.

Die Beschwerden, gegen die es verfasst wurde

Die im README angegebene Quelle ist ein Beitrag von Andrej Karpathy auf X, den das README für drei Beschwerden darüber zitiert, wie Modelle Code schreiben. Es lohnt sich, sie vollständig zu lesen, denn die vier Prinzipien lassen sich nahezu eins zu eins auf sie abbilden.

Das erste: Modelle „treffen in Ihrem Namen falsche Annahmen und machen einfach damit weiter, ohne sie zu prüfen“, und „gehen nicht mit ihrer Verwirrung um, suchen keine Klärung, legen keine Widersprüche offen, stellen keine Abwägungen dar und widersprechen nicht, wenn sie es sollten.“ Beachten Sie, was hier beschrieben wird. Dies ist keine Beschwerde über falsche Antworten. Es ist eine Beschwerde über flüssig formulierte falsche Antworten, die ohne Zögern geliefert werden, wobei die Unsicherheit, die eine Frage hätte auslösen müssen, stattdessen selbstsicheren Code hervorbrachte.

Der zweite Punkt: Sie „verkomplizieren wirklich gern Code und APIs, blähen Abstraktionen auf, räumen toten Code nicht auf … implementieren ein aufgeblähtes Konstrukt mit über 1000 Zeilen, obwohl 100 ausreichen würden.“ Das dürfte jedem bekannt vorkommen, der nach einem Feature gefragt und ein Framework bekommen hat.

Der dritte Punkt ist subtiler und für alle, die Diffs prüfen, der teuerste: Sie „ändern/entfernen mitunter immer noch Kommentare und Code, den sie nicht ausreichend verstehen, als Nebenwirkungen, selbst wenn er orthogonal zur Aufgabe ist.“ Eine orthogonale Änderung an einem Kommentar ist für sich genommen klein. Über eine Codebasis hinweg multipliziert, ist es das, wodurch sich eine Review-Warteschlange mit Änderungen füllt, nach denen niemand gefragt hat, und wodurch ein Kommentar, der eine Problemumgehung erklärt, verschwindet, bevor irgendjemand erfährt, warum die Problemumgehung existierte.

Vier Prinzipien – und der Test, den jedes einzelne hinterlässt

Die Datei kodiert vier Prinzipien. Jedem liegt eine kurze Reihe von Regeln bei, und zwei von ihnen formulieren einen einzeiligen Test, den man auf einen Diff anwenden kann, ohne etwas zu installieren. Die Regeln sind der Ort, an dem sich der Charakter der Datei zeigt.

Erst denken, dann programmieren

Die Anweisung in der Überschrift lautet: „Geh nicht von Annahmen aus. Verbirg keine Verwirrung. Mach Zielkonflikte sichtbar.“ Darunter: Annahmen ausdrücklich benennen und fragen statt zu raten; mehrere Interpretationen darlegen, wenn die Anfrage mehrdeutig ist; Widerspruch einlegen, wenn ein einfacherer Ansatz existiert; innehalten, wenn Verwirrung herrscht, benennen, was unklar ist, und um Klärung bitten. Das zielt direkt auf die erste Beschwerde. Der Mechanismus ist nicht „sei vorsichtiger“ – sondern stille Entscheidungen in sichtbare zu verwandeln, sodass ein Reviewer widersprechen kann, bevor Code existiert, statt danach.

Einfachheit zuerst

Die Regel lautet: minimaler Code, der das Problem löst, ohne Spekulatives: keine Funktionen über das Gefragte hinaus, keine Abstraktionen für Einmal-Code, keine Flexibilität oder Konfigurierbarkeit, die niemand verlangt hat, keine Fehlerbehandlung für unmögliche Szenarien, und „wenn 200 Zeilen zu 50 werden könnten, schreib es neu“. Der Test ist eine einzige Frage – würde ein Senior Engineer sagen, das ist überkompliziert? – was eine Ermessensfrage ist, und zwar ganz offen.

Chirurgische Änderungen

Hier teilt die Datei die Anweisung in zwei Teile, was das Nützlichste daran ist. Beim Bearbeiten von vorhandenem Code: Verbessern Sie angrenzenden Code, Kommentare oder Formatierung nicht; refaktorisieren Sie nicht, was nicht kaputt ist; passen Sie sich dem vorhandenen Stil an, auch wenn Sie es anders machen würden; erwähnen Sie nicht zusammenhängenden toten Code, anstatt ihn zu löschen. Wenn Ihre eigenen Änderungen verwaiste Elemente erzeugen: Entfernen Sie die Importe, Variablen und Funktionen, die durch Ihre Änderungen ungenutzt geworden sind, aber lassen Sie bereits vorhandenen toten Code in Ruhe, sofern nicht anders verlangt. Der Test ist, dass jede geänderte Zeile direkt auf die Anfrage zurückführbar ist.

Zielorientierte Ausführung

Definiere Erfolgskriterien und iteriere, bis sie verifiziert sind. Das README zeigt die Transformation als Paare. Statt „Validierung hinzufügen“ schreibe Tests für ungültige Eingaben und sorge dafür, dass sie bestehen. Statt „den Fehler beheben“ schreibe einen Test, der ihn reproduziert, und sorge dafür, dass er besteht. Statt „X refaktorisieren“ stelle sicher, dass die Tests vorher und nachher bestehen. Bei mehrstufiger Arbeit wird ein kurzer Plan verlangt, in dem jeder Schritt seine eigene Verifikation angibt. Das README zitiert Karpathy hier erneut: „LLMs sind außergewöhnlich gut darin, in Schleifen zu arbeiten, bis sie bestimmte Ziele erreichen… Sag ihm nicht, was es tun soll, gib ihm Erfolgskriterien und sieh zu, wie es loslegt.“

Eine Datei, ein Skill und ein Plugin sind drei verschiedene Dinge.

Es lohnt sich, bei der Mechanik präzise zu sein, denn das praktische Verhalten unterscheidet sich. CLAUDE.md ist eine Projektanweisungsdatei: Text, den Claude Code als dauerhaften Kontext für ein Repository liest und der vorhanden ist, unabhängig davon, ob jemand ihn in diesem Turn angefordert hat. Ein Skill ist ein Ordner mit einer SKILL.md, die beschreibt, wann die Fähigkeit verwendet werden sollte; geladen wird er, wenn eine Aufgabe es erfordert, und nicht vorher. Ein Plugin ist ein Distributionspaket, das über einen Marktplatz installiert wird und Skills, Befehle und andere Komponenten enthalten kann. Die Unterscheidungen betreffen, wann Anweisungen in den Kontext gelangen und wer entscheidet, nicht die Qualität.

Eine CLAUDE.md ist in diesem Sinne die am wenigsten subtile der drei. Sie ist in diesem Projekt immer aktiv, sie gilt für jede Aufgabe darin, und sie belegt bei jedem Turn Kontext, egal ob es sich um die Korrektur eines Tippfehlers in einer Zeile oder um eine Migration handelt. Die README der Datei selbst räumt die Kosten in einem Abschnitt namens Tradeoff Note ein: Die Richtlinien neigen eher zur Vorsicht als zur Geschwindigkeit, und bei trivialen Aufgaben — einfache Tippfehlerkorrekturen, offensichtliche Einzeiler — sollten Sie nach eigenem Ermessen entscheiden. Darin heißt es, das Ziel sei, kostspielige Fehler bei nicht trivialen Arbeiten zu reduzieren, nicht, einfache Aufgaben zu verlangsamen.

Das ist eine zutreffende Darstellung dessen, was eine dauerhafte Anweisungsdatei leisten kann. Sie kann keine Fähigkeit hinzufügen, über die das Modell nicht verfügt. Sie kann nur die Wahrscheinlichkeit dafür erhöhen oder verringern, dass das Modell sein vorhandenes Verhalten zeigt. Deshalb ist die Datei als Einschränkung formuliert – dies nicht tun, vor jenem erst fragen – statt als Ermutigung, besser zu sein.

Was messen 222.612 Sterne?

Sie messen Aufmerksamkeit. Das ist keine Abwertung und es ist nicht nichts: Ein Repository, das im Januar 2026 erstellt und zuletzt im April gepusht wurde, erreichte bis zum 23. Oktober 2026 auf GitHub 222.612 Sterne und 22.321 Forks – an diesem Tag gelesen, was bedeutet, dass es weit verbreitet und von Leuten geforkt wurde, die eine eigene Kopie haben wollten. Eine Sternanzahl ist ein vernünftiger Näherungswert dafür, wie viele Menschen etwas fanden, das es wert war, als Lesezeichen gespeichert zu werden.

Es ist kein Ersatz für den Wirkungsnachweis, und das Repository gibt auch nicht vor, einer zu sein. Was darin nirgends veröffentlicht wird: kein Benchmark, der Ergebnisse mit und ohne die Datei vergleicht, keine Methodik zur Messung, ob sie funktioniert, und kein Vergleich mit einer Kontrolle. Es gibt kein Vorher-Nachher an einer echten Codebasis, keine Reviewer-Studie, keine Vorfallrate. Eine solche Datei ist eine elegant formulierte Hypothese über Modellverhalten, und niemand hat den Versuch durchgeführt.

Was die README stattdessen bietet, ist ein Abschnitt mit dem Titel „How to Know It's Working“, der vier Dinge auflistet, die man beobachten könnte: weniger unnötige Änderungen in Diffs, weniger Umschreibungen aufgrund von Überkomplizierung, klärende Fragen, die vor der Implementierung statt nach Fehlern kommen, und saubere, minimale Pull Requests. Das sind sinnvolle Signale. Sie sind aber auch genau das, was man schreiben würde, wenn man nichts gemessen hat, und sie werden von der Person selbst berichtet, die die Datei anwendet. Lies sie als Checkliste, an der du die Datei in deinem eigenen Repository messen kannst, nicht als Beleg dafür, dass sie bereits bestanden hat.

Was man tatsächlich eingibt, um es zu installieren

Die README beschreibt zwei Wege. Der empfohlene läuft in Claude Code: den Marketplace hinzufügen, dann das Plugin installieren, wonach die Richtlinien projektübergreifend statt pro Repository vorliegen. Der zweite ist pro Projekt: die rohe CLAUDE.md in ein neues Repository holen oder sie an ein bestehendes anhängen. Außerdem gibt es eine eingecheckte Cursor-Projektregel, sodass dieselben Richtlinien gelten, wenn der Ordner in Cursor geöffnet wird – ein Detail, das zeigt, dass die Datei so geschrieben wurde, dass sie über Tools hinweg portierbar ist, die eine Anweisungsdatei auf Projektebene lesen, und nicht an den Loader eines einzelnen Anbieters gebunden ist.

Eine unschöne Stelle, die es wert ist, erwähnt zu werden, weil du darauf stoßen wirst, wenn du die README genau befolgst. Der Marktplatzbefehl nennt {{1}}forrestchang/andrej-karpathy-skills{{/1}}, während die Repository-URL oben auf der Seite {{2}}multica-ai/andrej-karpathy-skills{{/2}} ist. Beide Zeichenfolgen erscheinen in derselben README, gelesen am 23. Oktober 2026. Ich kann die Diskrepanz sehen und dir nicht sagen, warum sie existiert, daher ist der ehrliche Rat, den anderen Pfad zu versuchen, wenn einer fehlschlägt, und eine der beiden Zeichenfolgen als veraltet zu behandeln.

Das andere, was auf der Startseite auffällt: Das Repository wird von multica-ai gepflegt, und das einleitende Blockzitat in der README bewirbt Multica, „eine Open-Source-Plattform zum Ausführen und Verwalten von Coding-Agenten mit wiederverwendbaren Skills“. Das ist eine legitime Offenlegung und zugleich ein Hinweis darauf, warum die Paketierung so aussieht, wie sie aussieht. Ein Projekt, das an wiederverwendbaren Skills interessiert ist, wird seine eigene Anleitung wahrscheinlich als etwas Installierbares ausliefern – und genau das ist das Plugin.

Es nutzen, ohne seine Annahmen zu übernehmen

Der Abschnitt „Anpassung“ ist der Teil, den die meisten Leser überspringen. Die Datei ist dafür gedacht, mit projektspezifischen Anweisungen zusammengeführt zu werden, statt sie zu ersetzen, und die Beispiele, die sie nennt, sind konkret: TypeScript-Strict-Modus verwenden, alle API-Endpunkte müssen Tests haben, die vorhandenen Fehlerbehandlungsmuster in einer bestimmten Datei befolgen. Das ist keine Dekoration. Es ist der Unterschied zwischen einem allgemeinen Regelwerk und einer Anweisungssammlung, die weiß, wo Ihr Code liegt.

Es gibt einen praktischen Grund, zusammenzuführen statt zu stapeln. Wenn Sie die Datei unverändert einfügen und Ihr Projekt eigene Konventionen hat, können die beiden Anweisungssätze miteinander in Konflikt geraten, und ein Modell, das einen solchen Konflikt ausgleicht, ist genau die Verwirrung, die das erste Prinzip beseitigen soll. Wenn Sie Ihre Konventionen in dieselbe Datei und im selben Ton schreiben, bleibt die Anweisungsoberfläche klein genug, um sie prüfen zu können.

Und du solltest es prüfen. Dies ist ein kurzes Dokument mit Verhaltensanweisungen, das für jede Anfrage im Repository gilt. Die richtige Frage ist nicht, ob 222.612 Menschen sich irren können – diese Rahmung klärt nichts –, sondern ob jede Regel einem Fehler entspricht, den du tatsächlich gesehen hast. Wenn deine Diffs noch nie beiläufige Kommentarumschreibungen enthalten haben, kostet dich der Abschnitt „Surgical Changes“ nur Kontext ohne Gegenwert. Lösch ihn. Die Datei steht unter MIT-Lizenz und ist zum Bearbeiten gedacht.

Eine Ebene tiefer ändert all dies nichts daran, welches Modell antwortet. Eine CLAUDE.md-Datei beeinflusst, wie eine Anfrage behandelt wird, sobald sie ein Modell erreicht; sie sagt nichts über das Modell aus, das die Anfrage empfängt. Diese zweite Entscheidung liegt bei dem, was vor dem Modell sitzt. Eine Möglichkeit, dies zu arrangieren, ist ein einzelner OpenAI-kompatibler Endpunkt, der mehr als 200 Modelle unter einem Schlüssel führt, mit automatischem Failover zwischen Anbietern und den Listenpreisen der Anbieter, die mit 0 % Aufschlag weitergegeben werden. Wir hosten Modelle; wir stellen Claude Code nicht her, und nichts in Ihrem Repository ist für uns sichtbar.

Die Suche wird weiterhin von „Skills“ sprechen, weil das das Wort ist, das Menschen für eine Sache haben, die man installiert, damit sich ein Agent anders verhält, und die Verpackung rund um dieses Repository verwendet es ebenfalls. Das Artefakt ist eine Datei: ein Dokument mit dauerhaften Anweisungen, geschrieben mit Blick auf drei konkrete Beschwerden, mit vier Prinzipien und einer Reihe von Tests, die man von Hand anwenden kann. Beurteile es danach, ob diese Beschwerden nach deinem Repository klingen. Das ist eine bessere Frage als die Sternzahl, die stets nur gemessen hat, wie viele Leute genauso reagiert haben wie du gerade.