AIDiveFünf Gewohnheiten, fünf Befehle
Jede Liste mit Claude-Code-Gewohnheiten sagt dir, was du tun sollst. Diese hier macht aus jeder Gewohnheit einen Befehl, den Claude Code ausführt, damit die Gewohnheit gilt, egal ob das Modell sie liest. Wir haben alle fünf an einem echten Repo getestet, ledgerly, einer kleinen Rechnungs-API mit Node 20 und TypeScript, mit Claude Code 2.1.294.
Der Grund steht in den Best Practices von Anthropic: Eine Zeile wie "Always typecheck before you finish" in deiner CLAUDE.md "works most of the time, not every time". Die fünf Befehle unten sind /goal, ein PreToolUse-Hook, /context mit /clear, /skill-doctor und ein schreibgeschützter Reviewer-Subagent.
Warum eine aufgeschriebene Gewohnheit durchrutscht
CLAUDE.md ist die Anweisungsdatei, die Claude zu Beginn jeder Session liest, eine Readme für ein neues Teammitglied: Befehle, Konventionen und Regeln. Dort landen die meisten Gewohnheiten, die wichtigsten oft in Großbuchstaben, etwa "NEVER edit src/store/migrations.ts".
Die Memory-Doku von Anthropic sagt deutlich, was diese Datei ist: Claude liest sie als Kontext, nicht als erzwungene Konfiguration. Jede Zeile ist ein Ratschlag, der gegen die aktuelle Aufgabe abgewogen wird. Es ist der Unterschied zwischen einer Code-Review-Checkliste auf einer Wiki-Seite und einem Check in deiner CI-Pipeline: Die erste hängt davon ab, dass jemand sie liest, der zweite läuft in jedem Fall.
Die Übung: Öffne deine CLAUDE.md und markiere jede Zeile, die jedes einzelne Mal gelten muss. Den Rest lässt du, wo er ist, denn die Datei bleibt der richtige Ort für das, was Claude aus deinem Code nicht ableiten kann, und die Doku empfiehlt unter 200 Zeilen pro Datei.
Gewohnheit eins: sag, wie "fertig" aussieht
Claude hört auf, wenn die Arbeit fertig aussieht. Wenn nichts festlegt, ob sie es wirklich ist, so die Best Practices von Anthropic, wirst du selbst zur Testsuite.
/goal legt einmal eine Ziellinie fest. Nach jedem Turn liest ein kleines, schnelles Modell die Unterhaltung und antwortet mit erfüllt, noch nicht erfüllt oder unmöglich. Es kann weder Befehle ausführen noch Dateien lesen, also formuliere die Bedingung so, dass Claudes eigene Ausgabe sie belegen kann, zum Beispiel die vollständige Testausgabe.
| Lauf auf ledgerly | Was wir sahen |
|---|---|
| Normale Session, gleiche Feature-Anfrage | Die Tests liefen in einem eingeklappten Tool-Aufruf; die Antwort sagte "pnpm test passes (37/37)" |
Mit /goal und der Bedingung "full pnpm test output printed" |
Die Antwort gab den ganzen Lauf aus, "Tests 44 passed (44)", dann "Goal achieved (45s · 1 turn · 5.1k tokens)" |
Tippe /goal allein, um den Status zu sehen, und /goal clear, um es zu entfernen. Für einen Einzeiler-Fix brauchst du es nicht; laut Doku ist es bei langen Läufen am wichtigsten, wo Claude einen Turn manchmal mit offenen Punkten beendet.
Gewohnheit zwei: eine Regel, die nicht brechen kann
Eine Regel in Großbuchstaben wird meistens beachtet, und genau das ist das Problem. Ein Hook ist ein kleines Skript, das Claude Code von selbst zu einem festen Zeitpunkt ausführt; ein PreToolUse-Hook läuft vor jedem Tool-Aufruf. Unserer liest den Dateipfad und gibt bei src/store/migrations.ts "migrations.ts is append-only: add a new migration file instead" aus und beendet sich mit Exit-Code 2. Der Hooks-Guide sagt, Exit-Code 2 blockiert den Aufruf und schickt die Meldung an Claude zurück, und die Sperre gilt auch dann, wenn die Berechtigungsabfragen abgeschaltet sind.
In unseren Läufen: Mit der Regel in der CLAUDE.md lehnte Claude die Änderung von selbst ab. Ohne die Regel ging Claude zweimal an die Migrationsdatei und der Hook blockierte beide Änderungen; Claude bearbeitete den Rest und meldete "A project hook blocked both of my edits to that file." In zwei späteren Läufen las es zuerst das Hook-Skript und versuchte die Datei gar nicht erst.
Ein Hook blockiert nur, was er erkennen kann, einen Pfad oder einen Befehl. Regeln, die Urteilsvermögen brauchen, wie "schreibe sauberen Code", bleiben in der CLAUDE.md, und ein enger Match verhindert, dass der Hook deine eigene Arbeit blockiert.
Gewohnheit drei: eine Aufgabe, ein Kontext
Der Kontext ist alles, was das Modell bei jedem Turn sieht: deine Anweisungen, die gelesenen Dateien und die ganze Unterhaltung. /context zeigt ihn als Raster; /clear leert die Unterhaltung, während Dateien und Einstellungen bleiben.
/context auf ledgerly |
Gesamt | Nachrichten |
|---|---|---|
| Nach der erledigten Aufgabe | 57.5k von 1m Tokens | 26.4k Tokens |
Nach /clear |
31.1k von 1m Tokens | 130 Tokens |
Die Doku: /clear zwischen unabhängigen Aufgaben kostet nichts, und nach zwei fehlgeschlagenen Korrekturen leerst du den Kontext und schreibst einen besseren Prompt. Mitten in einer Aufgabe nimmst du stattdessen /compact mit einem Fokus.
Gewohnheit vier: lade nur, was du nutzt
Ein Skill ist eine verpackte Anweisung, die Claude lädt, wenn eine Aufgabe dazu passt. Der vollständige Skill wird nur geladen, wenn er läuft, aber sein einzeiliger Eintrag steht bei jedem Turn im Prompt, und das Budget für diese Einträge liegt bei etwa 1% des Context Windows, sodass die am wenigsten genutzten Skills als Erste ihre Beschreibungen verlieren.
/skill-doctor listet jeden Skill mit seinen Kontextkosten und deiner Nutzungshäufigkeit auf. Auf unserer Maschine meldete er:
| Art | Geladen, aber nie aufgerufen |
|---|---|
| Persönliche Skills | 13 |
| Von claude.ai synchronisiert | 14 |
| Plugin-Skills | 25 |
Außerdem nannte er 4 Plugins, die zuletzt nicht genutzt wurden. Schalte einen Skill in /skills ab; synchronisierte Skills kommen zurück, wenn du sie löschst, also schalte sie auf claude.ai ab; Plugin-Skills laufen über den Plugin-Manager. Ein Listeneintrag ist klein, das hier räumt also Rauschen auf, statt deinen Kontext zur Hälfte freizugeben.
Gewohnheit fünf: frische Augen auf dem Diff
Ein Subagent ist eine zweite Claude-Session für genau eine Aufgabe, mit eigenem leerem Kontext, die eine Zusammenfassung zurückgibt. Die Doku von Anthropic sagt es klar: Dieselbe Aufgabe an einen Subagent zu übergeben macht die Antwort nicht besser, aber ein frischer Reviewer hilft, weil er deine Überlegungen nicht gesehen hat.
Unser Reviewer liegt in .claude/agents/reviewer.md mit schreibgeschützten Tools: Read, Grep, Glob, Bash(git diff:*) und Bash(git status:*). Beim Diff für überfällige Rechnungen fand das eigene Review der Autoren-Session einen echten Bug: Rechnungen mit gleichem Fälligkeitsdatum wurden nach der id als Text sortiert. Der Reviewer fand denselben Bug und den fehlenden Test in 28 Sekunden und prüfte dann jede README-Konvention einzeln. Außerdem behauptete er, der Typecheck sei sauber, was seine Tools nicht ausführen konnten, und die Hauptsession markierte das als ungeprüft. Rufe ihn einmal pro Feature auf, vor dem Merge.
Welche Gewohnheit zuerst einrichten
Fang mit dem Hook an, bei der Regel, die in deinem Repo schon mehr als einmal gebrochen wurde. /clear und /skill-doctor kosten nichts. Spare dir /goal für lange Läufe und den Reviewer für den Merge auf. Die Regel zum Mitnehmen: Wenn eine Gewohnheit jedes Mal gelten muss, mach daraus etwas, das Claude Code ausführt, nicht etwas, das Claude liest.
