Warum Coding-Agenten Ihre Anweisungen ignorieren

Warum Coding-Agenten Ihre Anweisungen ignorieren

Coding-Agenten ignorieren Ihre Anweisungen aus vier Gründen. Keiner davon ist, dass Sie zu höflich waren. Die Regel befand sich nie im Kontextfenster. Die Regel war zu vage, um eine Handlung daran zu prüfen. Etwas anderes im Kontext widersprach ihr, meistens der Code, den der Agent gerade gelesen hatte. Oder die Regel ist zwar noch geladen, steht aber weit hinter der aktuellen Eingabe, und der Agent arbeitet mit dem, was sich in der Nähe befindet.

Jede Ursache erfordert eine eigene Lösung. Daher müssen Sie sie zuerst unterscheiden. Großbuchstaben und das Wort IMPORTANT sind keine Diagnose. Die folgenden Mechanismen verwenden Claude Code als Beispiel, weil sein Lade- und Komprimierungsverhalten mit Stand August 2026 ausführlich dokumentiert ist. Andere Tools unterscheiden sich in den Details, verhalten sich im Wesentlichen aber genauso.

Zwei Begriffe vorab. Das Kontextfenster ist der Textblock, den das Modell in einem bestimmten Durchlauf sieht: System-Prompt, Ihre Anweisungsdateien, die Unterhaltung und jede Datei, die der Agent gelesen hat. Der Harness ist das Programm um das Modell herum, also die Komponente, die Dateien vom Datenträger liest und diesen Block zusammenstellt. Fast jede Beschwerde in diesem Beitrag richtet sich eigentlich gegen den Harness und nicht gegen das Modell.

Ihre Instruktionsdatei ist eine Nachricht, keine Einstellung

Eine Instruktionsdatei ist keine Konfiguration. Nichts in der Laufzeit liest CLAUDE.md und setzt die Vorgabe durch. Das Harness liest die Datei von der Festplatte und fügt den Text in die Unterhaltung ein. In Claude Code wird dieser Inhalt als Benutzernachricht nach dem System-Prompt übermittelt. Das Modell sieht Ihre Regeln daher genauso wie alles andere, was Sie eingegeben haben.

Das hat eine unangenehme Konsequenz. Ihre Regeln stehen mit jedem anderen Text im Fenster in Konkurrenz, und zwar auf derselben Ebene. Eine Regel ist eine Behauptung. Die Datei, die der Agent gerade geöffnet hat, ist ein Beleg. Wenn beides nicht übereinstimmt, setzt sich der Beleg häufig durch. Es wird kein Fehler ausgelöst, weil aus Sicht des Modells nichts schiefgelaufen ist.

Die offizielle Dokumentation sagt es eindeutig: Instruktionsdateien werden als Kontext behandelt, nicht als erzwungene Konfiguration. Wenn Sie eine Aktion unabhängig von der Entscheidung des Modells blockieren möchten, benötigen Sie einen Hook und keinen Satz. Merken Sie sich diese Aussage. Die meisten Lösungen am Ende dieses Beitrags wenden sie auf einen konkreten Fall an.

Welche Anweisungsdateien werden geladen und wann

Claude Code geht den Verzeichnisbaum ab dem Verzeichnis nach oben, in dem Sie den Prozess gestartet haben. Jede CLAUDE.md und CLAUDE.local.md vom Dateisystemstamm bis zu Ihrem Arbeitsverzeichnis wird beim Start vollständig geladen. Die Dateien werden in dieser Reihenfolge zusammengeführt. Die Datei, die dem Startverzeichnis am nächsten liegt, wird zuletzt gelesen. Innerhalb eines Verzeichnisses wird die Datei .local nach der Hauptdatei angehängt.

Dateien in Unterverzeichnissen unterhalb Ihres Arbeitsverzeichnisses verhalten sich anders. Sie werden beim Start nicht geladen. Sie werden geladen, wenn der Agent eine Datei in diesem Verzeichnis liest. Das gilt auch für pfadbezogene Regeln in .claude/rules/ mit einem paths:-Frontmatter-Feld. Sie werden in den Kontext aufgenommen, sobald eine passende Datei gelesen wird, nicht bei jedem Turn.

Dieser Unterschied erklärt einen großen Teil der gemeldeten Fehler. Sie legen eine Regel in packages/api/CLAUDE.md ab, stellen eine Frage zur API, und der Agent antwortet, ohne jemals eine Datei unter packages/api/ zu öffnen. Die Regel wurde nicht ignoriert. Sie war nie im Kontext vorhanden. Wenn Ihr Repository die Hinweise auf separate Anweisungsdateien pro Paket in einem Monorepo verteilt, sollten Sie dies jedes Mal zuerst prüfen.

Es gibt noch eine weitere Falle beim Laden. Sie ist die häufigste Ursache für die Meldung „Der Agent hat meine Anweisungen ignoriert“: Claude Code liest CLAUDE.md, nicht AGENTS.md. Ein Repository, das sich auf AGENTS.md standardisiert hat und keine CLAUDE.md besitzt, gibt Claude Code überhaupt nichts zum Laden. Die unterstützte Brücke ist eine CLAUDE.md, deren erste Zeile @AGENTS.md lautet. Sie bindet die Datei beim Start ein. Darunter können zusätzliche Claude-spezifische Hinweise stehen. Ein Symlink funktioniert ebenfalls, wenn Sie nichts ergänzen müssen. Welche Inhalte grundsätzlich in diese Datei gehören, ist eine separate Frage. Sie wird unter Anweisungen für den Agenten von menschlicher Dokumentation trennen behandelt.

Bestätigen Sie, dass die Datei geladen wurde, bevor Sie sie neu schreiben

Ändern Sie den Wortlaut erst, wenn Sie nachgewiesen haben, dass der Agent die Datei sehen kann. Es gibt zwei Prüfungen. Beginnen Sie mit der kostengünstigen.

Führen Sie /context innerhalb der Sitzung aus. Der Befehl gibt das aktuelle Fenster nach Kategorien aufgeschlüsselt aus. Die Liste Memory files nennt alle Anweisungsdateien, die tatsächlich geladen wurden. Fehlt eine Datei in dieser Liste, ist sie nicht Teil der Unterhaltung. Dann kann nichts, was Sie darin schreiben, wirksam werden. /memory listet die Dateipfade auf und öffnet sie zur Bearbeitung, auch wenn sie noch nicht existieren.

Für eine belastbarere Prüfung protokollieren Sie die Ladevorgänge. Das Hook-Ereignis InstructionsLoaded wird jedes Mal ausgelöst, wenn eine CLAUDE.md oder eine Regeldatei in den Kontext gelangt. Sein Matcher zeigt, warum der Ladevorgang ausgelöst wurde: session_start, nested_traversal, path_glob_match, include oder compact. Fügen Sie dies in .claude/settings.json ein:

{
  "hooks": {
    "InstructionsLoaded": [
      {
        "matcher": "nested_traversal",
        "hooks": [
          {
            "type": "command",
            "command": "cat >> /tmp/instructions-loaded.log"
          }
        ]
      }
    ]
  }
}

Das Hook empfängt seine Nutzdaten als JSON über die Standardeingabe. cat hängt daher den vollständigen Datensatz an. Überwachen Sie die Datei mit tail -f /tmp/instructions-loaded.log, während Sie arbeiten. Der Exit-Status dieses Ereignisses wird ignoriert. Das Hook kann daher nur beobachten, aber nicht blockieren. Wenn Ihre verschachtelte Datei während einer Sitzung, in der Sie ihren Ladevorgang erwartet haben, nie in diesem Protokoll erscheint, beenden Sie die Überarbeitung. Das Problem liegt an der Platzierung.

Was eine lange Sitzung mit Ihren Regeln macht

Hier wirken zwei getrennte Effekte. Sie erfordern unterschiedliche Maßnahmen.

Distanz. Eine Regel, die in Turn 1 angegeben wurde, befindet sich in Turn 90 noch im Kontextfenster. Dort konkurriert sie mit 90 Text-Turns, die aktueller und spezifischer für Ihre derzeitige Aufgabe sind. Sie können diesen Effekt nicht durch Konfiguration beseitigen, aber Sie können ihn messen. Führen Sie dieselbe Aufgabe in einer neuen Sitzung aus. Gilt die Regel dort, schlägt aber im Verlauf einer langen Sitzung fehl, ist die Distanz die Ursache.

Komprimierung. Wenn das Kontextfenster voll ist, fasst das Harness die bisherige Unterhaltung zusammen und setzt die Sitzung auf Grundlage dieser Zusammenfassung fort. Erhalten bleibt, was der Zusammenfasser für wichtig hält. Das entspricht nicht unbedingt dem, was Sie für wichtig halten. Claude Code dokumentiert das Verhalten für jeden Mechanismus. Die Unterschiede sind erheblich. Die Projektwurzel CLAUDE.md und Regeln ohne Geltungsbereich werden nach einer Komprimierung erneut von der Festplatte geladen. Der automatische Speicher wird ebenfalls von der Festplatte erneut geladen. Regeln mit paths:-Frontmatter gehen verloren, bis wieder eine passende Datei gelesen wird. Verschachtelte CLAUDE.md-Dateien in Unterverzeichnissen gehen verloren, bis erneut eine Datei in diesem Unterverzeichnis gelesen wird.

Ordnen Sie Ihre Anweisungen anhand dieser Tabelle. Daraus ergibt sich die Reihenfolge ihrer Anfälligkeit. Eine Regel, die Sie nur im Chat eingegeben haben, ist in der Sitzung am anfälligsten. Sie bleibt nur erhalten, wenn die Zusammenfassung sie zufällig übernimmt. Eine Regel in packages/api/CLAUDE.md folgt als Nächstes. Sie wurde einmal geladen, aus der Zusammenfassung entfernt und wird erst beim nächsten Lesen in diesem Verzeichnis wieder geladen. Eine Regel in der Datei der Projektwurzel ist am dauerhaftesten, weil sie jedes Mal erneut von der Festplatte gelesen wird.

Wenn eine Anweisung für die gesamte Sitzung gelten muss, gehört sie ohne paths:-Frontmatter in die Datei der Projektwurzel. Alles andere ist ein bewusster Kompromiss. Verwalten des Inhalts im Kontextfenster behandelt /compact mit einem Fokusargument und /clear zwischen voneinander unabhängigen Aufgaben. Beide Faktoren beeinflussen, wie häufig der Zusammenfasser entscheidet, welche Ihrer Regeln erhalten bleiben.

Warum der umgebende Code die Regel überstimmt

Dies ist der Fehler, den Menschen am häufigsten beschreiben und am seltensten diagnostizieren. In Ihrer Datei steht, dass der Datenbankzugriff über die Repository-Schicht erfolgt. Der Agent schreibt einen Handler, der das ORM (Object-Relational Mapper) direkt aufruft. Sie wurden nicht aus Stilgründen ignoriert. Die Belege haben sich gegen Sie durchgesetzt.

Eine Regel beschreibt eine Präferenz. Der Code demonstriert eine solche Präferenz. Wenn der Agent drei Dateien in dem Modul öffnet, das er bearbeiten soll, und alle drei das ORM direkt aufrufen, enthält der Kontext auf der einen Seite einen abstrakten Satz und auf der anderen Seite drei konkrete, aktuelle und zur Aufgabe passende Beispiele. Das lokale Muster zu übernehmen, ist normalerweise das richtige Verhalten. Hier ist es nur deshalb falsch, weil Sie etwas wissen, das dem Kontext fehlt: Diese Dateien sind Legacy-Code.

Schreiben Sie das also in die Regel. Regeln, die ihre eigenen Gegenbelege benennen, bewähren sich in einem realen Repository. Regeln, die nur eine allgemeine Präferenz formulieren, tun das nicht.

Neuer Datenbankzugriff erfolgt über app/repositories/. Dateien unter app/legacy/ rufen das ORM weiterhin direkt auf. Das ist alter Code und nicht das gewünschte Muster. Übernehmen Sie ihn nicht.

Der zweite Satz erfüllt den entscheidenden Zweck. Er teilt dem Agenten mit, was er gleich vorfinden wird und wie er es einordnen soll, bevor er es vorfindet. Dieselbe Korrektur gilt für jede Regel, der Ihr Repository sichtbar widerspricht: einen Commit-Stil, dem Ihre Historie nicht folgt, eine Teststruktur, die die Hälfte Ihrer Testsuite ignoriert, oder eine Importkonvention, die nur in neuem Code gilt. Wo immer der Code der Datei widerspricht, benennen Sie diese Abweichung in der Datei.

Eine vage Regel kann nicht geprüft und daher nicht befolgt werden

„Schreiben Sie sauberen Code.“ „Vermeiden Sie Overengineering.“ „Halten Sie es einfach.“ „Gehen Sie bei Migrationen vorsichtig vor.“ Keine dieser Regeln lässt sich anhand einer konkreten Aktion prüfen, weder durch den Agenten noch durch Sie. Ein Agent, der eine Regel erhält, die er nicht anhand seiner eigenen Ausgabe prüfen kann, rät. Sie bewerten dieses Raten nach Gefühl.

Wenden Sie auf jede Zeile Ihrer Datei den folgenden Test an. Schreiben Sie den Shell-Befehl, der mit einem Exit-Code ungleich 0 beendet wird, wenn die Regel verletzt ist. Wenn Sie diesen Befehl nicht schreiben können, ist die Regel nicht prüfbar. Vergleichen Sie die folgenden Paare:

• Nicht prüfbar: „Halten Sie Funktionen klein.“ Prüfbar: „Eine Funktion mit mehr als 60 Zeilen benötigt einen Kommentar darüber, der erklärt, warum sie so lang ist.“
• Nicht prüfbar: „Testen Sie Ihre Änderungen.“ Prüfbar: „Führen Sie npm test aus und geben Sie die Anzahl der Fehler aus, bevor Sie eine Aufgabe als abgeschlossen bezeichnen.“
• Nicht prüfbar: „Halten Sie die Dateien organisiert.“ Prüfbar: „HTTP-Handler liegen in src/api/handlers/. In dieses Verzeichnis gehört nichts anderes.“
• Nicht prüfbar: „Formatieren Sie den Code korrekt.“ Prüfbar: „Verwenden Sie in .ts-Dateien eine Einrückung mit 2 Leerzeichen.“

„Vermeiden Sie Overengineering“ geben viele zuerst auf, weil die Korrektur nicht in einem kürzeren Satz besteht, sondern in einem längeren: Wenn Sie konkret festlegen, was die kleinste funktionierende Änderung tatsächlich bedeutet, erhält der Agent Kriterien, anhand derer er seinen eigenen Diff prüfen kann.

Bei der Größe besteht dasselbe Problem unter einer anderen Bezeichnung. Die Richtlinien von Claude Code zielen auf weniger als 200 Zeilen pro Anweisungsdatei ab und stellen ausdrücklich fest, dass längere Dateien die Befolgung verschlechtern. Eine Datei mit 700 Zeilen ist keine eindeutigere Anweisung. Sie besteht aus 700 Aussagen, die sich mit größerer Wahrscheinlichkeit gegenseitig widersprechen. Außerdem wird sie bei jedem einzelnen Durchlauf auf Ihr Kontextfenster angerechnet, was sich direkt in Ihrem Token-Verbrauch zeigt. Eine Struktur, bei der jede Regel unter einer Überschrift steht, die ein Leser schnell erfassen kann, wird unter dem Schreiben einer Anweisungsdatei, die ein Agent ausführen kann beschrieben.

So diagnostizieren Sie das Problem in zehn Minuten

Führen Sie diese Schritte in der angegebenen Reihenfolge aus. Wenn Sie direkt zum letzten Schritt springen, endet das häufig in einer langen Datei voller aggressiv formulierter Regeln, die trotzdem nicht funktionieren.

1. Prüfen Sie, ob die Regel geladen wurde. Führen Sie /context aus und lesen Sie die Liste der Memory-Dateien. Wenn die Datei dort nicht aufgeführt ist, korrigieren Sie den Speicherort und beenden Sie die Prüfung. Die übrigen Schritte sind bis dahin nicht relevant.
2. Reproduzieren Sie das Problem in einer neuen Sitzung. Starten Sie eine neue Sitzung und stellen Sie die kleinste Aufgabe, die die Regel auslösen sollte. Wenn die Regel dort funktioniert, aber in einer langen Sitzung nicht, deutet das auf die Kontextdistanz oder eine Komprimierung hin. Wenn sie auch in der neuen Sitzung nicht funktioniert, liegt das Problem in der Regel selbst.
3. Entfernen Sie konkurrierende Vorgaben. Fordern Sie dieselbe Änderung in einem Verzeichnis an, dessen vorhandener Code die Regel bereits befolgt. Kehrt die Befolgung dort zurück, haben die umgebenden Codevorgaben Ihre Formulierung überstimmt.
4. Suchen Sie nach einem Konflikt. Zwei Dateien mit unterschiedlichen Vorgaben für dasselbe Verhalten sind ein dokumentierter Fehler. Das Modell kann eine der Vorgaben beliebig auswählen und teilt Ihnen diese Auswahl nicht mit.
5. Formulieren Sie die Regel prüfbar und testen Sie erneut. Schreiben Sie die Regel mit einem konkreten Pfad und einer Bedingung neu. Eine deutlich höhere Befolgungsrate zeigt, dass die Formulierung die Ursache war.

Schritt 4 besteht aus einem einzigen Befehl. Durchsuchen Sie jede Quelle für Anweisungen nach dem Thema, nicht nur die Datei, die Sie gerade bearbeitet haben:

grep -rni "migration" --include="CLAUDE.md" --include="CLAUDE.local.md" .
grep -rni "migration" .claude/rules/ ~/.claude/CLAUDE.md ~/.claude/rules/ 2>/dev/null

Ein Treffer in zwei Dateien mit unterschiedlichen Vorgaben ist die Ursache. Löschen Sie eine davon. Versuchen Sie nicht, die Vorgaben mit einer stärkeren Formulierung zu priorisieren, da es keine Priorisierungslogik gibt, auf die Sie sich berufen können.

Die wirksamsten Korrekturen in der richtigen Reihenfolge

Jeder folgende Schritt hat eine größere Wirkung als der vorherige und verursacht höhere Einrichtungskosten. Beginnen Sie oben, wenn sich eine Regel mit geringem Aufwand umformulieren lässt. Gehen Sie weiter nach unten, sobald eine Regel so wichtig ist, dass gelegentliche Verstöße nicht akzeptabel sind.

1. Formulieren Sie die Regel konkret. Nennen Sie einen Pfad, einen Befehl oder eine Bedingung. Fügen Sie die Gegenbelege hinzu, die der Agent im Repository findet, wie zuvor gezeigt. Das kostet nichts und behebt überraschend viele Fälle.
2. Platzieren Sie die Regel näher an dem, was sie steuert. Verwenden Sie ein verschachteltes CLAUDE.md, eine auf einen Pfad beschränkte Regel in .claude/rules/ oder einen Kommentar am Anfang der Datei selbst. Die Regel wird dann beim selben Lesevorgang wie der zugehörige Code eingelesen. Akzeptieren Sie den Nachteil: Alles, was auf diese Weise geladen wird, fällt bei der nächsten Komprimierung aus dem Kontext und kehrt beim nächsten passenden Lesevorgang zurück.
3. Verlagern Sie die Durchsetzung in einen Hook. Prosa bittet. Ein Hook entscheidet. Hooks werden bei festen Ereignissen im Lebenszyklus als Code ausgeführt und greifen unabhängig davon, zu welchem Schluss das Modell kommt.
4. Übergeben Sie die Regel an ein deterministisches Tool und löschen Sie die Prosa. Formatierung, Importreihenfolge, Zeilenlänge, verbotene Imports und das Format von Commit-Nachrichten. ruff format, prettier --write, eslint oder ein pre-commit-Hook. Der Formatter ist jedes Mal korrekt und verbraucht keine Tokens. Der Satz ist meistens korrekt und verbraucht bei jeder Interaktion Tokens.

Schritt 3 vollständig. Angenommen, der Agent darf Migrationsdateien niemals bearbeiten. Fügen Sie dies in .claude/settings.json ein:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/guard-migrations.sh"
          }
        ]
      }
    ]
  }
}

Und dies in .claude/hooks/guard-migrations.sh:

#!/usr/bin/env bash
set -euo pipefail

path=$(jq -r '.tool_input.file_path // empty')

case "$path" in
  */migrations/*)
    echo "Files under migrations/ are written by hand. Stop and ask first." >&2
    exit 2
    ;;
esac

exit 0

Führen Sie chmod +x .claude/hooks/guard-migrations.sh aus. Starten Sie anschließend eine neue Sitzung und bitten Sie den Agenten, eine Datei unter migrations/ zu bearbeiten. Die Bearbeitung wird abgelehnt, und Ihre Nachricht wird als Begründung zurückgegeben. Der Exit-Status 2 in PreToolUse blockiert den Tool-Aufruf, bevor er ausgeführt wird. Ihr stderr-Text wird dem Modell als Sperrnachricht übergeben. ${CLAUDE_PROJECT_DIR} wird zum Projektstammverzeichnis aufgelöst. Dadurch funktioniert der Hook unabhängig davon, in welchem Verzeichnis sich der Agent befindet. Der Agent muss der Regel weder zustimmen noch sich an sie erinnern oder sie noch im Kontext haben. Die Bearbeitung findet nicht statt.

Für ein pauschales Verbot ohne enthaltene Logik erledigt permissions.deny in Ihren Einstellungen dieselbe Aufgabe, ohne dass ein zu wartendes Skript erforderlich ist. Die Berechtigungsmodi legen fest, was ohne Ihre vorherige Rückfrage ausgeführt wird. Wenn eine Anweisung tatsächlich auf der System-Prompt-Ebene statt in einer Benutzernachricht stehen muss, platziert --append-system-prompt sie dort. Sie muss jedoch bei jedem Aufruf übergeben werden, weshalb sie sich besser für Skripte als für interaktive Arbeit eignet.

Was Sie nicht wegweisen können

Legen Sie klar fest, welcher Teil in Ihrer Verantwortung liegt. Platzierung, Formulierung, Konflikte zwischen Dateien und Dateigröße sind Probleme des Autors, für die der Autor Lösungen finden muss. Der Rest ist Modellverhalten. Eine bessere Formulierung wird es nicht beseitigen.

Zustimmung ist keine Befolgung. Ein Agent bestätigt eine Regel, gibt sie korrekt wieder und verstößt zwei Tool-Aufrufe später dagegen. Die Bestätigung kostet nichts und sagt nichts voraus. Betrachten Sie sie nicht als Fehlerbehebung und zählen Sie sie nicht als Test.

Bestimmte Gewohnheiten bleiben bestehen. Dazu gehören das Hinzufügen von Kommentaren, defensive Fehlerbehandlung, eine abschließende Zusammenfassung und das Ausführen des naheliegenden nächsten Befehls. Sie treten unter einer Regel, die sie verbietet, weiterhin auf, wenn auch seltener als zuvor. Sie können Ihre eigene Rate messen: Führen Sie dieselbe Aufgabe zehnmal in frischen Sitzungen aus und zählen Sie die Verstöße. Wenn diese Zahl null sein muss, gehört die Regel nicht in den Prompt.

Ihre eigene Sitzung wird zu einem Beispiel. Wenn der Agent in Turn 12 gegen die Regel verstößt und Sie dies zulassen, befindet sich der Verstoß nun als Demonstration im Kontext. Er ist wesentlich aktueller als die Regel. Korrigieren Sie einen Verstoß sofort, sobald Sie ihn erkennen. Ein nicht korrigierter Verstoß beeinflusst den restlichen Sitzungsverlauf.

Eine Anweisungsdatei ist keine Sicherheitsgrenze. Sie beeinflusst das Verhalten, erzwingt es aber nicht. Alles, bei dem ein Fehler hohe Kosten verursacht, etwa Zugangsdaten oder destruktive Befehle, gehört in Berechtigungen oder einen Hook. Geheimnisse für einen Agenten unzugänglich halten folgt demselben Prinzip für Daten: Bitten Sie einen Agenten nicht darum, eine Datei nicht zu lesen. Sorgen Sie dafür, dass die Datei nicht lesbar ist.

Die Kurzfassung: Beweisen Sie, dass die Datei geladen wurde. Machen Sie die Regel überprüfbar. Verschieben Sie sie neben das, was sie steuert. Wenn die Fehlerquote weiterhin relevant ist, entfernen Sie die Regel aus dem Fließtext. Eine Regel, die ein Agent nicht ignorieren kann, wurde nie vom Agenten verlangt.

FAQ

Warum ignoriert Claude Code meine CLAUDE.md?

Prüfen Sie zuerst, ob die Datei geladen wurde, bevor Sie annehmen, dass sie ignoriert wurde. Führen Sie /context aus und sehen Sie in der Liste Memory files nach. Eine Datei, die dort nicht aufgeführt ist, gehört nicht zur Unterhaltung. Anweisungsdateien werden nach der Systemaufforderung als User-Nachricht übermittelt und als Kontext behandelt, nicht als verbindliche Konfiguration. Daher gibt es keine strikte Garantie für ihre Einhaltung. In der Praxis liegt meist einer von vier Fällen vor: Die Datei befindet sich in einem Unterverzeichnis, aus dem der Agent nie gelesen hat, zwei Dateien widersprechen sich und das Modell wählt eine davon beliebig aus, die Regel ist zu vage, um eine Aktion daran zu prüfen, oder der umgebende Code zeigt das Gegenteil der Regel.

Ändert das Bearbeiten der Anweisungsdatei während einer Sitzung etwas?

Nicht für die Kopie, die sich bereits in der Unterhaltung befindet. Dateien oberhalb Ihres Arbeitsverzeichnisses werden beim Start vollständig geladen. Der vom Modell gehaltene Text stammt daher vom Zeitpunkt des Starts. Um eine Änderung zu übernehmen, starten Sie eine neue Sitzung oder bitten Sie den Agenten, die Datei mit seinen normalen Dateiverarbeitungswerkzeugen erneut zu lesen. Dadurch wird die aktuelle Version als neue Nachricht in die Unterhaltung eingefügt. Nach einer Komprimierung wird die Datei im Projektstamm erneut von der Festplatte gelesen. Auch auf diesem Weg gelangt die neue Version in die Unterhaltung.

Welche Datei hat Vorrang, wenn eine CLAUDE.md im Stammverzeichnis und eine verschachtelte Datei widersprüchliche Regeln enthalten?

Keine von beiden zuverlässig. Erkannte Dateien werden aneinandergehängt und nicht gegenseitig überschrieben. Ihre Reihenfolge verläuft vom Stammverzeichnis des Dateisystems bis zu Ihrem Arbeitsverzeichnis. Die Datei im nächstgelegenen Verzeichnis wird daher lediglich zuletzt gelesen. Es gibt keine Vorrangslogik, die Widersprüche auflöst. In der Dokumentation von Claude Code steht, dass widersprüchliche Regeln beliebig aufgelöst werden können. Schreiben Sie verschachtelte Dateien als Ergänzungen und nennen Sie den Pfad, für den sie gelten. Entfernen Sie den Widerspruch, statt zu versuchen, ihn durch eine Regel mit höherem Vorrang zu überstimmen.

Bleiben meine Anweisungen nach /compact erhalten?

Das hängt davon ab, wie sie geladen wurden. Die Datei im Projektstamm CLAUDE.md, Regeln ohne Gültigkeitsbereich und der automatische Speicher werden nach einer Komprimierung erneut von der Festplatte eingefügt. Regeln mit paths:-Frontmatter und verschachtelte CLAUDE.md-Dateien in Unterverzeichnissen gehen verloren, bis eine passende Datei erneut gelesen wird. Alles, was Sie nur in den Chat eingegeben haben, bleibt nur erhalten, wenn der Zusammenfassungsprozess es beibehalten hat. Wenn eine Regel während der gesamten Sitzung gelten muss, legen Sie sie ohne paths:-Frontmatter in der Datei im Projektstamm ab.

Wann sollte eine Regel zu einem Hook statt zu Prosa werden?

Wenn die Prüfung deterministisch ist und die Kosten eines übersehenen Falls höher sind als die Kosten für ein kleines Skript. Einschränkungen für Dateipfade, erforderliche Befehle vor einem Commit und verbotene Tool-Aufrufe gehören dazu. Ein PreToolUse-Hook, der mit Status 2 beendet wird, blockiert den Tool-Aufruf direkt und übergibt seinen stderr-Text als Begründung an das Modell. Die Regel gilt dadurch unabhängig davon, ob sie noch im Kontext vorhanden ist. Alles, was ein Formatter oder Linter entscheiden kann, sollte von diesem Tool übernommen und vollständig aus der Anweisungsdatei entfernt werden.