Andrej Karpathy Skills: Die Komplettanleitung – Wie CLAUDE.md Claude Code mit 4 Regeln einschränkt und willkürliche Codeänderungen verhindert

Claude Code ändert ungefragt Dateien, die gar nicht zum Auftrag gehören.
Schnellste Lösung: Regeln in CLAUDE.md für Umfang, Planung, minimale Änderungen und Verifikation festlegen – und sie als Arbeitsanweisungen behandeln, nicht als technische Zugriffssperre.

Dieser Leitfaden richtet sich an Sie, wenn Sie Claude Code beim Entwickeln nutzen und Änderungen eingrenzen möchten.
Er hilft auch technischen Verantwortlichen, die Projektregeln festlegen, sowie Teams, die Andrej Karpathy Skills als Anstoß für einen kontrollierbaren KI-Workflow prüfen.

Wie weit kann CLAUDE.md Claude Code tatsächlich einschränken?

CLAUDE.md kann Claude Code fortlaufende Projektanweisungen geben. Sie können darin festhalten, welche Dateien zum Auftrag gehören, dass vor größeren Änderungen zunächst ein Plan erwartet wird und wie die Ergebnisse überprüft werden sollen. Das verbessert die Vorhersehbarkeit, verhindert aber nicht zuverlässig jede unerwünschte Aktion. Eine Anweisung ist keine technische Berechtigungssperre.

Die offizielle Dokumentation zur Projekt-Memory-Funktion beschreibt, wie Claude Code Projektanweisungen aus CLAUDE.md verwendet. Entscheidend für Ihre Planung: Solche Inhalte geben Kontext und Vorgaben für die Arbeit. Sie setzen jedoch nicht automatisch die Zugriffsrechte des Prozesses außer Kraft und machen aus einer Bitte keine garantierte Einschränkung.

Unterscheiden Sie daher drei Ebenen:

• Projektanweisungen: Was soll Claude Code tun, vermeiden oder vorab klären? Hierfür ist CLAUDE.md geeignet.
• Berechtigungen: Welche Aktionen dürfen ausgeführt werden, welche erfordern eine Bestätigung und welche sind ausgeschlossen? Dafür sind Berechtigungseinstellungen zuständig; die Dokumentation zu Claude-Code-Berechtigungen beschreibt diese Steuerung.
• Prüfung und Rücknahme: Wie erkennen Sie unerwünschte Änderungen und stellen einen bekannten Stand wieder her? Dafür brauchen Sie einen nachvollziehbaren Diff und Versionskontrolle.

Diese Trennung ist der wichtigste Schutz vor falschen Erwartungen. Wenn ein Verzeichnis keinesfalls verändert werden darf, genügt der Satz „Bitte nicht ändern“ in CLAUDE.md nicht. Prüfen Sie, ob die Berechtigungen und die technische Arbeitsumgebung diese Grenze tatsächlich abbilden.

Was Andrej Karpathy Skills hier bedeutet

Der Titel verbindet zwei Dinge, die Sie nicht gleichsetzen sollten. Der Originalbeitrag von Andrej Karpathy ist eine Quelle für seine eigenen Aussagen. Das verlinkte Skills-Repository ist eine separate Ressource. Aus dem Namen oder der Verbreitung eines Repositorys folgt nicht, dass jede dort enthaltene Regel ein offizieller Claude-Code-Standard oder eine verbindliche Vorgabe von Karpathy ist.

Die vier Regeln dieses Leitfadens sind deshalb eine praktische Arbeitsstruktur, keine wörtliche Wiedergabe eines Beitrags. Auch Claude Skills und CLAUDE.md erfüllen nicht automatisch dieselbe Aufgabe: Die Claude-Dokumentation zu Skills behandelt Skills als eigenes Mechanismus für wiederverwendbare Anweisungen und Abläufe. Ein Skill ersetzt nicht die projektspezifische Entscheidung, welche Dateien zu einem konkreten Auftrag gehören.

Für Sie heißt das: Übernehmen Sie keine allgemeine Vorlage unverändert. Prüfen Sie, welche Verzeichnisse, Konventionen und Prüfwege in Ihrem Repository tatsächlich gelten. Eine gute Projektanweisung beschreibt das vorhandene Projekt, statt eine fremde Arbeitsweise als angebliche Sicherheitsfunktion auszugeben.

Vier Regeln für kontrollierte Änderungen festlegen

Die Tabelle ist ein Entscheidungswerkzeug, aber kein Ersatz für Ihre Repository-Prüfung. Gerade die letzte Spalte macht die Regeln überprüfbar: Sie können nicht nur fragen, ob Claude Code „sorgfältig gearbeitet“ hat, sondern Dateien, Plan und Prüfergebnis miteinander abgleichen.

Regel 1: Den erlaubten Änderungsumfang benennen

Schreiben Sie nicht nur das gewünschte Ergebnis auf. Definieren Sie auch, welche Bereiche zum Auftrag gehören und was ausdrücklich nicht angefasst werden soll. Das ist besonders wichtig, wenn ein Fehler in einer Komponente liegt, aber eine umfassendere Bereinigung verlockend erscheint.

Ein Beispiel, das Sie an Ihr Projekt anpassen können:

Ändere für diese Aufgabe nur die betroffene Komponente und die dazugehörigen Tests. Ändere keine Abhängigkeiten, allgemeinen Konfigurationen oder anderen Module. Wenn die Ursache außerhalb dieses Umfangs liegt oder eine zusätzliche Datei nötig ist, beschreibe den Grund und frage vor der Erweiterung nach.

Die Formulierung setzt eine klare Arbeitsgrenze und definiert, was bei Unsicherheit geschehen soll. Sie sperrt die betreffenden Dateien nicht technisch. Wenn Claude Code dennoch eine zusätzliche Datei ändert, ist das ein Abweichungssignal für Ihre Prüfung – kein Beleg dafür, dass die Anweisung als Schutzmechanismus funktioniert hat.

Achten Sie außerdem darauf, dass die Regeln nicht einander widersprechen. „Nur diese Komponente ändern“ und „alle ähnlichen Stellen im Projekt vereinheitlichen“ können bei derselben Aufgabe in unterschiedliche Richtungen weisen. Legen Sie in CLAUDE.md fest, dass aufgabenspezifische Grenzen Vorrang vor beiläufigen Verbesserungen haben und Unklarheiten vor der Umsetzung geklärt werden.

Regel 2: Erst planen, dann den Code ändern

Verlangen Sie vor der Umsetzung eine kurze Erklärung des Auftragsverständnisses, der betroffenen Stellen und des vorgesehenen Prüfwegs. Bei einem kleinen Fehler muss daraus kein langer Entwurf werden. Der Nutzen liegt darin, einen Missverständnispunkt sichtbar zu machen, bevor daraus ein größerer Diff entsteht.

Ein sinnvoller Ablauf bei einem Fehler in einer Eingabeprüfung sieht so aus:

1. Claude Code beschreibt zunächst, welches Verhalten fehlerhaft ist und welche Datei oder Komponente vermutlich betroffen ist.
2. Claude Code nennt die erwartete Änderung und den passenden projektspezifischen Prüfweg.
3. Sie prüfen, ob der Plan im vereinbarten Umfang bleibt.
4. Erst danach beginnt die Umsetzung.
5. Nach Abschluss vergleichen Sie den tatsächlichen Diff mit dem Plan und prüfen das Ergebnis.

Das ist ein Kontrollpunkt, keine Korrektheitsgarantie. Ein plausibler Plan kann auf einer falschen Annahme beruhen. Ebenso kann sich während der Arbeit eine bislang unbekannte Abhängigkeit zeigen. Legen Sie deshalb fest, dass eine solche Entdeckung nicht automatisch zur Ausweitung des Auftrags führt: Claude Code soll die Abweichung erklären und Ihre Bestätigung abwarten.

Die Claude-Dokumentation zu Best Practices ist eine hilfreiche Referenz für eine strukturierte Zusammenarbeit. Übernehmen Sie daraus keine pauschale Zusicherung, dass Planung Fehler verhindert. Planen dient dazu, Erwartungen früh zu vergleichen; erst Diff, Tests und fachliche Prüfung zeigen, ob die Änderung tatsächlich passt.

Regel 3: Den Diff klein und sachlich halten

„Minimal“ bedeutet: nur die Änderungen umsetzen, die für das gewünschte Verhalten erforderlich sind. Es bedeutet nicht, notwendige Fehlerbehebungen wegzulassen oder Tests zu ignorieren. Es bedeutet, eine einzelne Aufgabe nicht mit einer ungefragten Umstrukturierung, einem Wechsel von Abhängigkeiten oder einer Formatierungsrunde im ganzen Projekt zu verbinden.

Eine passende Anweisung könnte lauten:

Setze nur die zur Aufgabenlösung erforderlichen Änderungen um. Behalte die bestehende Architektur, Abhängigkeiten und Formatierungskonventionen bei. Führe keine unabhängigen Refactorings oder Bereinigungen durch. Wenn eine zusätzliche Änderung für die Lösung notwendig erscheint, erkläre den Zusammenhang und hole vor der Erweiterung eine Bestätigung ein.

Nach der Umsetzung prüfen Sie den Diff in zwei Durchgängen. Zuerst kontrollieren Sie die Dateiliste: Gehört jede geänderte Datei zum Auftrag? Danach prüfen Sie die einzelnen Änderungen: Ist jede Zeile nötig, um das gewünschte Verhalten herzustellen oder es abzusichern? Ein kleiner Diff ist nicht automatisch richtig, aber ein unerklärlicher Umbau wird darin leichter sichtbar.

Wenn Sie Git verwenden, vergleichen Sie den Arbeitsstand vor und nach dem Auftrag mit den im Projekt üblichen Versionskontrollwerkzeugen. Ergänzen Sie in CLAUDE.md keine erfundenen Befehle. Halten Sie stattdessen fest, welche bestehende Projektanleitung für Tests oder Formatierung maßgeblich ist. Bei einem gemischten Diff bitten Sie zunächst um Erklärung, bevor Sie sachfremde Änderungen übernehmen.

Regel 4: Verifikation und Bericht verbindlich machen

Eine abgeschlossene Änderung braucht einen überprüfbaren Bericht. Schreiben Sie in CLAUDE.md, dass Claude Code geeignete Prüfungen ausführt, die bereits im Repository vorgesehen oder dokumentiert sind. Fordern Sie eine klare Trennung zwischen tatsächlich ausgeführten Prüfungen und solchen, die ausgelassen wurden.

Zum Beispiel:

Führe nach der Änderung die für den betroffenen Bereich dokumentierten Tests oder Prüfungen aus. Berichte, welche Befehle tatsächlich ausgeführt wurden und welches Ergebnis sie lieferten. Nenne Prüfungen, die nicht ausgeführt wurden, samt Grund. Behaupte keinen erfolgreichen Testlauf, wenn er nicht stattgefunden hat.

Vermeiden Sie es, einen bestimmten Testbefehl als allgemeingültig vorzugeben, wenn Sie nicht geprüft haben, ob er in Ihrem Projekt existiert. Ein nicht vorhandenes Skript oder ein unpassender Build-Schritt erzeugt zusätzliche Verwirrung und sagt nichts Verlässliches über die Änderung aus. Lassen Sie stattdessen die vorhandenen Projektanleitungen und Skripte maßgeblich sein.

Auch ein erfolgreicher Testlauf beweist nicht, dass der Auftrag vollständig erfüllt ist. Tests können einen falschen Umfang, eine ungewollte Konfigurationsänderung oder ein übersehenes Verhalten nicht zwingend erkennen. Der Bericht ist daher ein Teil der Prüfung, nicht deren Ersatz. Die Dokumentation zu Hooks beschreibt außerdem einen getrennten Mechanismus für bestimmte automatisierte Abläufe. Hooks können für definierte Prüfungen relevant sein, sind aber ebenfalls kein Grund, den Diff oder die Berechtigungen ungeprüft zu lassen.

FAQ: CLAUDE.md im Entwicklungsalltag einsetzen

Wie begrenzen Sie Claude Code auf bestimmte Dateien?

Nennen Sie in CLAUDE.md das Ziel, die erlaubten Verzeichnisse oder Dateien und ausdrücklich ausgeschlossene Bereiche. Legen Sie zusätzlich fest, dass Claude Code bei unklarer Zuständigkeit erst nachfragt. Das ist eine Arbeitsanweisung, keine Dateisystem-Sperre: Wenn Sie technische Zugriffsbeschränkungen brauchen, müssen Sie die Berechtigungsregeln und die Umgebung gesondert konfigurieren.

Welche Regeln helfen gegen unnötige Änderungen?

Schreiben Sie überprüfbare Projektregeln auf: den erlaubten Änderungsumfang, einen kurzen Plan vor der Umsetzung, minimale Änderungen und einen Bericht über passende Prüfungen. Verweisen Sie auf den bestehenden Stil und die projektspezifischen Prüfwege. Allgemeine Wünsche wie „arbeite sorgfältig“ sind weniger hilfreich, weil sie weder den Umfang noch ein prüfbares Ergebnis festlegen.

Kann CLAUDE.md unbestätigte Aktionen verhindern?

Nein. CLAUDE.md liefert Projektanweisungen, ist aber keine Berechtigungssperre. Für Aktionen, die eine Bestätigung erfordern oder technisch begrenzt werden müssen, prüfen Sie die Berechtigungseinstellungen und gegebenenfalls geeignete Hooks. Kontrollieren Sie weiterhin den Diff, bevor Sie Änderungen übernehmen, und klären Sie, welche Schutzmaßnahmen in Ihrer Arbeitsumgebung tatsächlich eingerichtet sind.

Wie fordern Sie eine belastbare Verifikation?

Legen Sie in CLAUDE.md fest, dass Claude Code die im Repository dokumentierten Tests oder Prüfungen verwendet. Der Abschlussbericht soll die tatsächlich ausgeführten Befehle und Ergebnisse nennen sowie ausgelassene Prüfungen mit Begründung aufführen. So können Sie nachprüfen, was wirklich getestet wurde, statt sich auf eine pauschale Aussage wie „alles funktioniert“ zu verlassen.

Einen kleinen Auftrag als Testlauf verwenden

Sie erkennen erst im Arbeitsablauf, ob Ihre Regeln verständlich sind. Wählen Sie deshalb eine klar abgegrenzte, risikoarme Aufgabe, bei der Sie das erwartete Ergebnis und den zuständigen Projektbereich benennen können. Der Testlauf soll nicht beweisen, dass Claude Code nie abweicht. Er soll zeigen, wo Ihre Anweisungen zu offen, widersprüchlich oder im Repository nicht überprüfbar sind.

Gehen Sie in dieser Reihenfolge vor:

1. Auftrag eingrenzen: Formulieren Sie das gewünschte Verhalten und nennen Sie die erlaubten Dateien oder den relevanten Bereich.
2. Plan abgleichen: Prüfen Sie, ob Claude Code die betroffenen Stellen und den vorgesehenen Prüfweg korrekt beschreibt.
3. Dateiliste kontrollieren: Vergleichen Sie die geänderten Dateien mit der vereinbarten Grenze.
4. Diff prüfen: Suchen Sie nach Umstrukturierungen, Konfigurationsänderungen oder Formatierung, die nicht zur Aufgabe gehören.
5. Prüfbericht verifizieren: Kontrollieren Sie, ob die genannten Tests tatsächlich ausgeführt wurden und ob ausgelassene Prüfungen nachvollziehbar begründet sind.
6. Anweisung nachschärfen: Ändern Sie nur die Regel, die den beobachteten Fehler erklären kann. Ist etwa unklar, ob Tests geändert werden dürfen, benennen Sie diesen Fall ausdrücklich.

Notieren Sie bei der Auswertung nicht nur, ob eine Änderung „gut“ oder „schlecht“ war. Halten Sie fest, welche konkrete Anweisung missverstanden wurde, welche Datei außerhalb des Umfangs lag oder welche Prüfung im Bericht fehlte. So wird CLAUDE.md schrittweise zu einer projektspezifischen Arbeitsvereinbarung statt zu einer Sammlung unverbindlicher Appelle.

Abschlussprüfung für Ihre CLAUDE.md

Bevor Sie die Regeln teamweit übernehmen, prüfen Sie, ob Sie auf jede Frage eine konkrete Antwort geben können:

• Ist das gewünschte Arbeitsergebnis klar genug, um den passenden Änderungsumfang zu erkennen?
• Sind erlaubte Bereiche, ausgeschlossene Änderungen und das Vorgehen bei Unsicherheit benannt?
• Fordert die Anweisung einen Plan, wenn der Auftrag unklar oder umfangreich ist?
• Bedeutet „minimal“ im Projektkontext, dass unnötiges Refactoring und unabhängige Bereinigungen ausbleiben?
• Gibt es im Repository dokumentierte Prüfwege, auf die Sie verweisen können?
• Verlangt die Regel einen wahrheitsgemäßen Bericht über ausgeführte und ausgelassene Prüfungen?
• Können Sie Abweichungen anhand von Dateiliste, Diff und Versionskontrolle nachvollziehen?

Falls die Antwort auf eine dieser Fragen fehlt, präzisieren Sie die jeweilige Regel, statt weitere allgemeine Formulierungen hinzuzufügen. Bewahren Sie Ihre Änderungen an CLAUDE.md außerdem in der Versionskontrolle auf und überprüfen Sie sie wie andere Projektänderungen. Eine Projektanweisung kann zur Datenschutz- und Arbeitsumgebungsprüfung beitragen, ersetzt diese aber nicht; die Datenschutzhinweise von Kvmkit erläutern den Umgang mit Datenschutzinformationen im Kvmkit-Angebot. Entscheidend bleibt, dass Sie die Datenflüsse Ihrer konkreten Entwicklungsumgebung selbst bewerten.

Den passenden Arbeitsweg für Ihr Team wählen

Für ein bestehendes Team mit einer stabilen Entwicklungsumgebung ist die lokale Arbeit meist der einfachste Weg, wenn Dateien, Berechtigungen und Prüfwerkzeuge dort bereits kontrolliert sind. Sie behalten den unmittelbaren Zugriff auf Repository und Projektumgebung, müssen aber selbst dafür sorgen, dass Anweisungen, Berechtigungen und Versionskontrolle sinnvoll zusammenspielen.

Eine entfernte Entwicklungsumgebung kann für zeitlich begrenzte Tests oder getrennte Arbeitsplätze interessant sein. Sie bringt jedoch eigene Fragen zu Zugang, Datenschutz, Netzwerkabhängigkeit und Übergabe mit sich. Ein gemieteter Mac ist nicht automatisch sicherer und macht CLAUDE.md nicht verbindlicher. Wenn Sie nur eine vorübergehende Mac-Umgebung benötigen, statt zusätzliche Hardware zu kaufen, können Sie das Angebot von Kvmkit für Mac-Umgebungen mit der vorhandenen Lösung vergleichen. Bei dauerhaftem, gleichbleibendem Bedarf oder Anforderungen an lokale physische Anschlüsse kann ein eigenes Gerät die passendere Wahl sein.

Beginnen Sie unabhängig vom Arbeitsweg mit einem kleinen Auftrag und prüfen Sie die vier Regeln anhand des tatsächlichen Diffs. Wenn Claude Code den Umfang einhält, den Plan nachvollziehbar umsetzt und ehrlich über die Prüfungen berichtet, behalten Sie die Formulierungen bei. Wenn nicht, verschärfen Sie genau die unklare Grenze. CLAUDE.md macht Änderungen besser lenkbar; Codeprüfung, Versionskontrolle und erforderliche technische Berechtigungen bleiben Ihre Verantwortung.

FAQ