Wer Ihre Claude-Code-Anweisungen pflegt und woran Sie erkennen, dass sie noch helfen

Wie Anweisungsdateien aus dem Ruder laufen

Ohne verantwortliche Person driftet eine CLAUDE.md meist auf dieselbe Weise: Review-Befunde und Vorfälle fügen Zeilen hinzu, niemand entfernt welche, und die Datei sammelt umbenannte Befehle, widersprüchliche Regeln und Umgehungen für Grenzen, die ein älteres Modell hatte. Die Claude-Code-Dokumentation benennt die Kosten genau: Dateien mit mehr als 200 Zeilen verbrauchen mehr Kontext und werden schlechter befolgt, und wenn sich zwei Anweisungen widersprechen, wählt Claude unter Umständen willkürlich eine aus.

Abhilfe schaffen klare Verantwortung und eine Routine, die Einträge auch entfernt, nicht eine bessere Vorlage. Anthropics Leitfaden zu Context Engineering empfiehlt die kleinste Menge an Anweisungen, die das erwartete Verhalten vollständig beschreibt: minimal beginnen und nur für Fehlermuster ergänzen, die sich im Test zeigen.

Wem welche Datei gehört

Claude Code lädt Anweisungen aus mehreren Ebenen, und jede braucht eine andere verantwortliche Stelle. Der Leitfaden von Claude Code zu großen Codebasen sagt, dass typischerweise die Verantwortlichen eines Verzeichnisses dessen Datei pflegen, was sich an der bestehenden Code-Verantwortung orientieren kann.

• Verwaltete CLAUDE.md, auf jeden Rechner verteilt: das Plattform- oder Security-Team, für organisationsweite Hinweise. Regeln, die gelten müssen, gehören in die verwalteten Einstellungen, denn die Datei leitet an und erzwingt nichts.
• CLAUDE.md oder AGENTS.md im Wurzelverzeichnis: das Team, das Build und Konventionen des Repositorys verantwortet, meist Plattform oder die technische Leitung.
• CLAUDE.md-Dateien in Paketen und .claude/rules mit Pfaden: das Team, dem dieser Code gehört, durchgesetzt über CODEOWNERS.
• CLAUDE.local.md und ~/.claude/CLAUDE.md: der einzelne Engineer. Sie werden nicht geprüft und dürfen daher keine Teamregeln enthalten.
• Auto Memory: von Claude geschrieben, pro Repository auf einem Rechner gespeichert und nicht geteilt. Alles, worauf sich das Team verlässt, gehört stattdessen in eine geprüfte Datei.

Festhalten, warum jeder Eintrag existiert

Ein Eintrag, den niemand erklären kann, wird nie entfernt. Claude Code entfernt HTML-Kommentare auf Blockebene aus CLAUDE.md, bevor der Inhalt das Modell erreicht, sodass Notizen für Maintainer keinen Kontext kosten. Wir nutzen sie für Verantwortliche, Grund und die Art, wie sich prüfen lässt, ob der Eintrag noch wirkt.

<!-- owner: @example-org/billing | added 2026-08 after review findings on float maths | check: billing replay tasks -->
- Represent amounts with the Money type in src/billing/money.ts. Never use floating point for money.

<!-- owner: @example-org/billing | added 2026-05 | revisit after the next model change -->
- Integration tests need `docker compose up db` before `pnpm test:integration`.

Eine Prüfroutine, die so viel entfernt, wie sie hinzufügt

1. 1

   Jede Änderung wie Dokumentation prüfen

   Änderungen an Anweisungsdateien laufen über Pull Requests mit dem Code Owner der Datei als Pflicht-Reviewer, auch wenn Claude sie selbst vorschlägt.

2. 2

   In festen Abständen ein Audit laufen lassen

   Das /doctor prompt-audit von Claude Code, verfügbar ab v2.1.283, meldet Verweise auf fehlende Dateien oder Befehle, Anweisungen für ältere Modelle und Widersprüche und ändert nichts, bis Sie die Änderungen freigeben.

3. 3

   Nach Modellwechseln erneut prüfen

   Der Leitfaden zu großen Codebasen weist darauf hin, dass Anweisungen, die eine Schwäche eines älteren Modells umgehen, zum Ballast werden, sobald ein neueres Modell den Fall selbst beherrscht.

4. 4

   Prüfen, was tatsächlich geladen wird

   Führen Sie /context aus, um zu sehen, welche Memory-Dateien geladen wurden, und protokollieren Sie mit einem InstructionsLoaded-Hook, wann Pfadregeln und verschachtelte Dateien geladen werden.

Testen, ob ein Eintrag noch hilft

Für wichtige Einträge lohnt ein kleiner Vergleich. In einem hypothetischen Billing-Paket nehmen Sie fünf frühere Aufgaben, die Beträge betreffen, und lassen jede dreimal mit dem Money-Eintrag und dreimal ohne ihn laufen, jeden Lauf in einer isolierten Kopie, deren Historie vor der ursprünglichen Änderung endet, ohne spätere Refs, Auto Memory oder Dateien aus früheren Läufen. Ein Skript prüft jeden Diff auf Gleitkomma-Arithmetik mit Beträgen. Nehmen Sie auch Aufgaben dazu, bei denen die Regel nichts ändern sollte, denn Anthropics Leitfaden zur Evaluierung warnt, dass einseitige Testsätze das Verhalten in eine Richtung drängen.

Entfernen oder verschieben Sie einen Eintrag, wenn eines davon zutrifft:

• Läufe mit und ohne ihn verhalten sich gleich, das Modell tut es also ohnehin oder ignoriert ihn.
• Er nennt Dateien oder Befehle, die es nicht mehr gibt.
• Ein Linter, Hook oder CI-Check setzt dasselbe durch, was stärker ist als ein Satz.
• Er betrifft nur einen Bereich und gehört daher in eine Pfadregel oder einen Skill, der bei Bedarf geladen wird.

Wo Schulung ins Spiel kommt

Verantwortung scheitert, wenn Engineers nicht wissen, wann sie einen Eintrag ergänzen sollen. Die Claude-Code-Dokumentation liefert einen brauchbaren Test: einen Eintrag ergänzen, wenn Claude denselben Fehler zweimal macht, wenn ein Review etwas findet, das Claude hätte wissen sollen, oder wenn Sie dieselbe Korrektur erneut eintippen. Genau das üben wir in Team-Schulungen auf Ihren eigenen Repositories, sobald Verantwortung und Prüfroutine stehen.

Claude-Code-TrainingSteuern, welchen Kontext ein Agent mitführt