Andrej Karpathy hat benannt, wo Coding-Agenten immer wieder patzen. Dieser Claude-Code-Skill gießt seine vier Gegenmittel in eine SKILL.md, und Claude befolgt sie bei jeder Coding-Aufgabe automatisch.
Vier Regeln gegen die vier häufigsten Fehler von Coding-Agenten, jede als klare Anweisung im Skill.
Statt stillschweigend eine Annahme zu treffen und loszulaufen, legt Claude Unklarheiten offen, nennt Alternativen und fragt nach. Der teuerste Fehler, nämlich in die falsche Richtung zu coden, passiert gar nicht erst.
Keine ungefragten Abstraktionen, keine „Flexibilität" für Fälle, die nie eintreten, kein Error-Handling für Unmögliches. Die Regel-Testfrage: „Würde ein Senior das als überkompliziert bezeichnen?" Wenn ja: vereinfachen.
Angrenzenden Code nicht „verbessern", nichts refactoren, was nicht kaputt ist, bestehenden Stil übernehmen. Verwaiste Imports nur entfernen, wenn die eigene Änderung sie erzeugt hat. Ergebnis: kleine, review-freundliche Diffs.
„Bug fixen" wird zu „Test schreiben, der den Bug reproduziert, dann grün machen". Aus einer vagen Anweisung wird ein messbares Ziel, das Claude eigenständig anläuft, bis es verifiziert ist. Weniger Rückfragen, mehr fertige Arbeit.
Die description ist der Auslöser.
Das YAML-Feld description ist keine Doku für Menschen, sondern der Text, den Claude gegen jede neue Anfrage abgleicht. „Beim Schreiben, Reviewen oder Refactoring von Code" sorgt dafür, dass der Skill bei Coding-Aufgaben anspringt, aber nicht bei reinem Chat.
Einmal geladen, gilt er die ganze Session.
Erkennt Claude eine Coding-Aufgabe, lädt es den vollen Skill-Body, und liest ihn nicht bei jedem Turn neu. Die vier Regeln wirken danach als stehende Anweisung über die ganze Konversation, nicht nur für die eine auslösende Antwort.
Er ersetzt kein CLAUDE.md, er ergänzt es.
Ein projektspezifisches CLAUDE.md sagt, was über dieses Projekt wahr ist (Stack, Konventionen). Der Skill sagt, wie sich das Modell beim Coden generell verhalten soll. Beide laufen parallel, ohne sich zu widersprechen.
Reine Verhaltenssteuerung über Text.
Der Skill braucht kein allowed-tools, kein Shell-Skript, keinen Netzwerkzugriff. Er ändert nur, wie Claude denkt und schreibt, nicht, was es darf. Damit ist er risikofrei zu installieren, ohne Sonder-Freigaben.
01 · Solo-Gründer
Wer allein an einem Produkt baut, hat niemanden, der im Review „das ist überkompliziert" sagt. Der Skill übernimmt genau diese Rolle bei jeder Session, bevor unnötige Abstraktionen überhaupt entstehen.
02 · Agentur
Bei 3–5 parallelen Kundencodebasen ist „Chirurgische Änderungen" Gold wert: Claude fasst nur an, was zur Anfrage gehört, kein versehentliches Umbauen von Legacy-Code, das später beim Kunden-Review auffällt.
03 · Berater
Wer neben der Beratung eigene Skripte, Automatisierungen und kleine Dashboards mit Claude Code pflegt, aber kein Vollzeit-Entwickler ist, bekommt über „Erst denken" eingebaute Rückfragen statt stillschweigend falscher Annahmen.
04 · Team-Lead
Legt man den Skill unter .claude/skills/ ins Projekt statt nur global, gibt man die Denkweise an jeden weiter, der später am selben Repo mit Claude Code arbeitet: versioniert, teilbar, ohne mündliche Übergabe.
Das ist die komplette Datei: Karpathys vier Prinzipien als Claude-Code-Skill. Kopieren, unter .claude/skills/karpathy-guidelines/SKILL.md speichern, fertig. Der Rest steht im Setup darunter.
---
name: karpathy-guidelines
description: Reduziert typische LLM-Coding-Fehler: verschleierte Annahmen, Überkomplizierung, ungefragte Nebenänderungen, fehlende Erfolgskriterien. Nutzen beim Schreiben, Reviewen oder Refactoring von Code.
license: MIT
---
# Karpathy-Regeln für Claude Code
Verhaltensrichtlinien, um typische LLM-Coding-Fehler zu reduzieren, abgeleitet
von Andrej Karpathys Beobachtungen (x.com/karpathy/status/2015883857489522876)
zu wiederkehrenden Schwächen von Coding-Agenten.
**Trade-off:** Diese Richtlinien priorisieren Sorgfalt vor Geschwindigkeit. Bei
trivialen Aufgaben (Tippfehler, offensichtliche Ein-Zeiler) angemessenes
Ermessen walten lassen, nicht jede Änderung braucht die volle Strenge.
## 1. Erst denken, dann coden
**Nichts annehmen. Verwirrung nicht verstecken. Trade-offs offenlegen.**
Vor der Umsetzung:
- Eigene Annahmen explizit benennen. Bei Unsicherheit: nachfragen statt raten.
- Bei mehreren möglichen Interpretationen: alle nennen, nicht stillschweigend
eine auswählen.
- Wenn ein einfacherer Ansatz existiert: sagen. Auch mal widersprechen, wenn
angebracht.
- Bei Unklarheit: stoppen. Benennen, was verwirrt. Fragen.
## 2. Einfachheit zuerst
**Minimaler Code, der das Problem löst. Nichts Spekulatives.**
- Keine Features über das Angefragte hinaus.
- Keine Abstraktionen für Einmal-Code.
- Keine ungefragte "Flexibilität" oder "Konfigurierbarkeit".
- Keine Fehlerbehandlung für unmögliche Szenarien.
- Wenn 200 Zeilen auch 50 sein könnten: neu schreiben.
Testfrage: "Würde ein Senior Engineer das als überkompliziert bezeichnen?"
Wenn ja: vereinfachen.
## 3. Chirurgische Änderungen
**Nur anfassen, was nötig ist. Nur den eigenen Dreck aufräumen.**
Beim Bearbeiten bestehenden Codes:
- Angrenzenden Code, Kommentare oder Formatierung nicht "verbessern".
- Nichts refactoren, was nicht kaputt ist.
- Bestehenden Stil übernehmen, auch wenn man es selbst anders machen würde.
- Unzusammenhängenden toten Code erwähnen, nicht löschen.
Wenn eigene Änderungen etwas verwaisen lassen:
- Nur Imports/Variablen/Funktionen entfernen, die durch DIESE Änderung
ungenutzt wurden.
- Vorbestehenden toten Code nicht entfernen, außer explizit angefragt.
Testfrage: Lässt sich jede geänderte Zeile direkt auf die Anfrage zurückführen?
## 4. Zielgetriebene Ausführung
**Erfolgskriterien definieren. Iterieren, bis verifiziert.**
Aufgaben in verifizierbare Ziele übersetzen:
- "Validierung hinzufügen" → "Tests für ungültige Eingaben schreiben, dann
zum Bestehen bringen"
- "Bug fixen" → "Test schreiben, der den Bug reproduziert, dann zum Bestehen
bringen"
- "X refactoren" → "Sicherstellen, dass Tests vorher und nachher bestehen"
Bei mehrstufigen Aufgaben: kurzen Plan mit Verifikationsschritt nennen:
1. [Schritt] → verifizieren: [Check]
2. [Schritt] → verifizieren: [Check]
3. [Schritt] → verifizieren: [Check]
Starke Erfolgskriterien erlauben selbstständiges Iterieren. Schwache Kriterien
("mach es funktionieren") erzwingen ständige Rückfragen.
---
**Diese Richtlinien wirken, wenn:** weniger unnötige Änderungen in Diffs
auftauchen, weniger Rewrites wegen Überkomplizierung nötig sind, und
Rückfragen VOR der Umsetzung kommen statt nach Fehlern.
Ordner anlegen
Projektweit im Repo-Root: mkdir -p .claude/skills/karpathy-guidelines. Für alle eigenen Projekte gleichzeitig stattdessen ~/.claude/skills/karpathy-guidelines im Home-Verzeichnis.
SKILL.md speichern
Die komplette Datei von oben in den Ordner legen, als SKILL.md. Genau dieser Dateiname ist der Pflicht-Einstiegspunkt; der Ordnername wird zum Skill-Namen.
Claude Code starten
Ein komplett neues .claude/skills/-Verzeichnis wird beim nächsten Start von Claude Code erkannt. Danach triggert der Skill automatisch bei Coding-Aufgaben, oder du rufst ihn direkt mit /karpathy-guidelines auf.
/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills
Du brauchst keinen Setup-Tag, nur eine Textdatei und 2 Minuten. Aus „Claude baut irgendwas" wird „Claude fragt nach, hält es einfach und beweist, dass es funktioniert". Kopier die SKILL.md und leg los.