Andrej Karpathy hat in einem Beitrag beschrieben, wie sich Coding-Modelle verhalten. Sie treffen Annahmen, ohne nachzufragen, und laufen damit weiter. Sie suchen keine Klärung, benennen keine Widersprüche und zeigen keine Alternativen auf.
Ein Repository namens andrej-karpathy-skills übersetzt diese Beobachtungen in eine einzelne Datei namens CLAUDE.md. Die Datei soll das Verhalten von Claude Code verbessern. Sie enthält vier Prinzipien, die genau diese Muster adressieren.
Wichtig für die Einordnung: Das Repository beschreibt die Regeln als Sammlung von Leitlinien, nicht als gemessenes Ergebnis.
Die vier Prinzipien im Detail
Think Before Coding verlangt explizites Nachdenken. Annahmen sollen ausgesprochen werden, bei Unklarheit wird gefragt statt geraten. Bei Mehrdeutigkeit sollen mehrere Lesarten genannt werden, und bei Verwirrung soll das Modell stoppen und nachfragen.
Simplicity First setzt auf minimalen Code. Keine Features über die Anfrage hinaus, keine Abstraktionen für Einmal-Code, keine erfundene Konfigurierbarkeit. Der Test lautet: Würde ein erfahrener Entwickler das als überkompliziert bezeichnen?
Surgical Changes heißt: nur anfassen, was nötig ist. Benachbarten Code nicht „verbessern“, bestehenden Stil übernehmen, fremden toten Code melden statt löschen. Jede geänderte Zeile soll sich direkt auf die Anfrage zurückführen lassen.
Goal-Driven Execution dreht Aufgaben in prüfbare Ziele um. Statt „Bug beheben“ heißt es: einen Test schreiben, der ihn reproduziert, dann zum Laufen bringen.
So bindest du die Regeln ein
Es gibt zwei Wege. Als Claude-Code-Plugin fügst du zuerst den Marketplace hinzu und installierst dann das Plugin. Danach steht die Skill in allen deinen Projekten zur Verfügung.
Alternativ legst du die Datei pro Projekt an. In einem neuen Projekt lädst du sie per curl herunter, in einem bestehenden hängst du sie an die vorhandene CLAUDE.md an.
Für Cursor liegt im Repository eine Projektregel bei, damit dieselben Leitlinien auch dort greifen. Die Anleitung dazu steht in einer eigenen Datei.
Woran du merkst, dass es wirkt
Das Repository nennt konkrete Anzeichen. In Diffs tauchen weniger unnötige Änderungen auf, nur die angeforderten. Es gibt weniger Umschreibungen wegen Überkomplizierung, weil der Code gleich einfach sitzt.
Rückfragen kommen vor der Umsetzung, nicht erst nach Fehlern. Pull Requests bleiben klein, ohne Refactoring nebenbei. Das sind Erwartungen an das Verhalten, keine Messwerte aus einem Test.
Ein ehrlicher Hinweis steht ebenfalls drin: Die Leitlinien neigen zur Vorsicht statt zum Tempo. Bei Kleinigkeiten wie einem Tippfehler brauchst du nicht die volle Strenge.
Anpassen und was offen bleibt
Die Regeln sind zum Zusammenführen gedacht. Du kannst sie mit projektspezifischen Abschnitten ergänzen, etwa strenger TypeScript-Modus oder Tests für alle API-Endpunkte. So bleibt die allgemeine Basis, dein Projekt bekommt seine eigenen Vorgaben.
Das Repository liefert Prinzipien und Installationswege, keine Vergleichsmessung. Wenn du sie ausprobierst, achte auf die Diffs nach ein paar Aufgaben.
Affiliate links: we may earn a commission from qualifying purchases, and it never changes our data or rankings. They open Amazon's search results: prices and availability are shown there.
