Der Init

Ein Agent beginnt jede Sitzung mit leerem Kontextfenster. Das Gespräch von gestern steht nicht mehr darin. Über die Nacht bleibt allein, was auf der Platte liegt, und dafür gibt es zwei Wege: eine Datei, die Sie schreiben, und Notizen, die sich neuere Werkzeuge selbst anlegen. Von der Datei handelt dieses Kapitel, von den Notizen Kapitel 05.

Diese Datei müssen Sie nicht schreiben. Beim ersten Mal schreibt sie der Agent selbst, und deshalb heißt dieses Kapitel „Der Init“.

Der Befehl

Bei Claude Code heißt er /init, andere Werkzeuge haben einen ähnlichen. Er sieht das Projekt durch und legt die Datei an. Laut Gedächtnis-Doku (externe Seite, code.claude.com) untersucht Claude dabei den Code und schreibt eine Datei mit den Befehlen zum Bauen, den Anweisungen zum Testen und den Konventionen des Projekts, die es dabei entdeckt.

Drei Dinge daran sind im Alltag wichtig.

Er liest den Bestand, statt zu fragen. Was in der Datei landet, hat er im Projekt gefunden: die Skripte aus der Paketdatei, die Testbefehle, die Ver­zeich­nis­struktur, erkennbare Konventionen. Wer Regeldateien anderer Agenten im Projekt hat, findet auch deren Inhalt darin wieder.

Eine vorhandene Datei wird nicht überschrieben. Läuft der Befehl ein zweites Mal, schlägt er Verbesserungen vor. Das macht ihn auch später brauchbar, etwa wenn ein Projekt sich stark verändert hat.

Es gibt inzwischen einen mehrstufigen Ablauf, der über die Bestandsaufnahme hinausgeht. Er fragt zuerst, was überhaupt eingerichtet werden soll. Danach erkundet er laut Doku (externe Seite, code.claude.com) den Code mit einem Subagenten, schließt Lücken durch Rückfragen und legt einen Vorschlag zur Durchsicht vor, bevor er auch nur eine Datei schreibt.

Der Unterschied ist die Rückfrage. Die einfache Fassung schreibt, was sie sieht. Die mehrstufige fragt nach, wo sie nichts sieht.

Was dabei herauskommt

Eine Bestandsaufnahme, und die ist genau so viel wert, wie eine Bestandsaufnahme wert ist. Sie enthält, was im Projekt steht. Sie enthält nicht, woran Sie letzte Woche zwei Stunden verloren haben.

Genau darin liegt der Wert der Datei, und er entsteht erst danach: Zeile für Zeile, immer dann, wenn etwas zum zweiten Mal schiefgegangen ist.

Dafür gibt es inzwischen eine Messung. Eine Arbeit vom Februar 2026 hat Agenten dieselben Aufgaben mit und ohne Kontextdatei lösen lassen, einmal mit maschinell erzeugten Dateien und einmal mit solchen, die Entwickler selbst committet hatten. Drei der fünf Verfasser forschen laut Volltext (externe Seite, arxiv.org) an der ETH Zürich. Zwei arbeiten bei LogicStar (externe Seite, logicstar.ai), einer Firma, die Coding-Agenten am eigenen Repository misst und danach verbessert.

Das Ergebnis der Messung (externe Seite, arxiv.org): Eine Kontextdatei hebt den Anteil gelöster Aufgaben im Allgemeinen nicht, und die Kosten der Inferenz steigen dabei im Schnitt um mehr als 20 Prozent.

Hier wird der Befund gern abgeschnitten, und dann liest er sich wie ein Urteil über Pro­jekt­an­wei­sungen überhaupt. Der Satz danach in derselben Arbeit (externe Seite, arxiv.org) trennt zwei Teile der Datei: Die Anweisungen in den Kontextdateien befolgen die Agenten gut. Die Übersichten über das Repository helfen nicht, obwohl sie beliebt sind und von den Anbietern der Modelle empfohlen werden.

Woher die Mehrkosten kommen, erklärt Abschnitt 4.3 im Volltext (externe Seite, arxiv.org): Gerade weil die Agenten den Anweisungen folgen, testen sie mehr und durchsuchen mehr Dateien.

Anweisungen wirken also, und sie kosten Schritte. Was ins Leere geht, ist die Übersicht über das Projekt, und die ist genau der Teil, den der Init schreibt. Er bleibt trotzdem der richtige Anfang: Er legt die Datei an und sammelt die Befehle ein. Alles, was danach zählt, kommt von Ihnen.

Die Datei

Sie liegt im Pro­jekt­ver­zeichnis und ist gewöhnliches Markdown. Je nach Werkzeug heißt sie anders: CLAUDE.md bei Claude Code, AGENTS.md bei vielen anderen, und Claude Code liest inzwischen auch die fremde Datei, wenn keine eigene im Projekt liegt. Inhaltlich ist es dieselbe Sache.

AGENTS.md ist dabei der her­stel­ler­über­grei­fende Standard, entstanden aus der Zusammenarbeit mehrerer Anbieter und heute bei der Linux Foundation. Die Projektseite des Standards (externe Seite, agents.md) beschreibt sie als festen, vorhersehbaren Ort für den Kontext und die Anweisungen, die KI-Agenten beim Programmieren an einem Projekt brauchen, und nennt über 60.000 offene Projekte, die eine solche Datei führen, abgerufen am 3. August 2026. Ein Erhebungsdatum steht nicht dabei.

Ein einziger Dateiname ist daraus trotzdem nicht geworden. Dieselben Werkzeuge, die auf der Unterstützerliste des Standards stehen, führen daneben ihr eigenes Regelverzeichnis weiter, Cursor und GitHub Copilot etwa. Claude Codes Init liest deren beide Formate ohne weiteres aus. Ist die Umgebungsvariable für den mehrstufigen Ablauf gesetzt, kommen vier weitere dazu, darunter AGENTS.md selbst, macht sechs Formate zusammen, was beim Antreten in einem fremden Projekt einiges spart. Ein eigener Befehl, /import, geht weiter und holt die gesamte Einrichtung eines unterstützten Agenten herüber, samt eigenen Befehlen und Skills.

Warum nicht die README

Weil sie zwei verschiedene Leser haben. Der Standard (externe Seite, agents.md) sagt es in einem Satz: Eine README ist für Menschen da, mit Schnellstart, Pro­jekt­be­schrei­bung und Regeln fürs Mitmachen.

Eine README erklärt, worum es geht und wie man mitmacht. Die Projektanweisung sagt, was beim Arbeiten zu beachten ist, und zwar in einer Form, die für Menschen unhöflich wäre: als Liste von Regeln, mit ausdrücklichen Verboten und mit Wiederholungen an den Stellen, wo es darauf ankommt.

Was Sie hinzufügen

Die kürzeste brauchbare Antwort: alles, was Sie sonst ein zweites Mal erklären.

Der Hersteller nennt vier Anlässe, und alle vier sind Beobachtungen statt Kategorien:

• Der Agent macht denselben Fehler zum zweiten Mal.
• Sie tippen eine Korrektur, die Sie letzte Sitzung schon getippt haben.
• Eine Durchsicht findet etwas, das er über dieses Projekt hätte wissen müssen.
• Ein neuer Kollege bräuchte denselben Hinweis.

Alle vier haben dieselbe Form: Etwas ist bereits passiert. Was ein Agent sich selbst aus dem Code erschließen kann, bleibt draußen; das hat schon der Init erledigt.

Konkret schlägt allgemein

Der Unterschied ist größer, als er aussieht. „Formatiere den Code ordentlich“ ist eine Absichtserklärung, „Zwei Leerzeichen einrücken“ ist eine Anweisung. „Teste deine Änderungen“ kann man nicht befolgen, npm test vor dem Commit ausführen schon.

Die Regel dahinter: Schreiben Sie nur Sätze, bei denen Sie hinterher feststellen können, ob sie befolgt wurden.

Die Datei ist Kontext

Der Hersteller schreibt es als Einschränkung in seine Dokumentation (externe Seite, code.claude.com): Claude behandelt diese Dateien als Kontext, keine durchgesetzte Konfiguration. Die Datei wird gelesen und meistens befolgt, und „meistens“ ist bei einer Regel, auf die man sich verlässt, dasselbe wie nein.

Das ist eine Eigenschaft der Sache: Ein Modell verarbeitet Text, und Ihre Regeln sind Text. Dem Werkzeug fehlt dabei nichts. Wer etwas verbindlich verhindern will, braucht einen Mechanismus daneben, der nicht aus Text besteht. Wie das geht, steht in Kapitel 12.

seitlich verschiebbar

eigene Darstellung, Stand 03.08.2026

Der zweite Init

Nach ein paar Monaten steht in der Datei mehr, als hineingehört. Dafür gibt es inzwischen einen eigenen Prüfbefehl, bei Claude Code heißt er /doctor. Was er zur Streichung vorschlägt, deckt sich mit der Messung von oben. Laut Doku (externe Seite, code.claude.com) streicht er, was Claude aus dem Code ableiten kann, etwa den Aufbau der Verzeichnisse, Listen der Abhängigkeiten und Übersichten über die Architektur. Es bleiben die Fallstricke, die Begründungen und die Konventionen, die von den Voreinstellungen des Werkzeugs abweichen.

Das ist dieselbe Trennlinie wie beim ersten Init, von der anderen Seite gelesen.

Daneben gibt es einen Aufruf, der nach Überholtem und Widersprüchlichem sucht, /doctor prompt-audit. Die Dokumentation (externe Seite, code.claude.com) beschreibt, wonach er schaut: Anweisungen, die für ältere Modelle geschrieben sind, Verweise auf Dateien oder Befehle, die es nicht gibt, und Dateien, die einander widersprechen.

Das Ergebnis ist ein Bericht mit Ände­rungs­vor­schlägen. In Ihren Dateien ändert sich nichts, bis Sie den Agenten bitten, sie anzuwenden. Der Aufruf braucht Claude Code ab Version 2.1.283.

Eine einzige Datei reicht, solange man allein an einem Projekt arbeitet. Sobald mehrere Projekte, mehrere Rechner oder mehrere Leute dazukommen, stellt sich die Frage, wo eine Regel eigentlich gelten soll.

Vier Geltungsbereiche

Bei Claude Code können die Anweisungen an vier Stellen liegen, und jede hat eine andere Reichweite. Die Pfade in der Tabelle sind die von Claude Code. Von weit nach eng:

Die Trennung von Projekt und Lokal ist die praktisch wichtigste. Was im Team gilt, gehört in die eingecheckte Datei; Ihre Testdaten, Ihre Sandbox-Adressen und Ihre Vorlieben gehören daneben und in die .gitignore.

Ein Zugang gehört in keine der vier. Die lokale Datei sieht danach aus, weil sie nicht eingecheckt wird. Sie wird aber bei jedem Start vollständig gelesen, und damit stünde ein Schlüssel in jeder einzelnen Anfrage. Zugänge liegen im Schlüsselbund oder in der Umgebung des Prozesses; die Projektanweisung sagt höchstens, wie sie heißen und wo man sie sucht.

Werkzeuge, die AGENTS.md lesen, teilen anders ein. Der Standard selbst beschreibt Dateien im Projekt: eine an der Wurzel und bei Bedarf weitere in Unterordnern, etwa je Paket eines großen Repositorys. Codex legt eine persönliche Datei davor, ~/.codex/AGENTS.md, und liest dann von der Wurzel des Repositorys bis zum Arbeits­ver­zeichnis je Ordner höchstens eine Datei (externe Seite, learn.chatgpt.com). Liegt dort eine AGENTS.override.md, nimmt Codex sie anstelle der gewöhnlichen.

Der Init aus Ebene 1 erzeugt die Projektdatei. Die Benutzerdatei ist Ihre eigene Angelegenheit und wächst über Projekte hinweg; der mehrstufige Ablauf bietet inzwischen an, sie mit anzulegen.

Die Dateien stapeln sich

Das ist der Punkt, an dem die Erwartung am häufigsten danebenliegt. Die Dateien verhalten sich nicht wie Einstellungen, bei denen die speziellere die allgemeinere ersetzt. Sie werden aneinandergehängt, von weit nach eng.

Der Agent liest also im Zweifel alles: die Regeln Ihrer Firma, Ihre eigenen, die des Projekts und Ihre lokalen. Dazu kommt, dass beim Start der Verzeichnisbaum nach oben abgelaufen wird. Wer in einem Unterordner arbeitet, bekommt auch die Anweisungen der Ordner darüber.

Für ein einzelnes Repository ist das unproblematisch. In einem großen Verbund mit vielen Teams sammelt sich dabei Fremdes an, und dafür gibt es eine Ausschlussliste.

Codex hängt seine Dateien ebenso aneinander, von der persönlichen bis zu der im Arbeits­ver­zeichnis, und hört auf, weitere anzuhängen (externe Seite, learn.chatgpt.com), sobald sie zusammen 32 KiB erreichen.

Widersprüche werden nicht gemeldet

Aus dem Stapeln folgt das Problem, das man am seltensten bemerkt. Die Dokumentation (externe Seite, code.claude.com) ist da deutlich: Widersprechen sich zwei Anweisungen, nimmt Claude womöglich eine davon nach Belieben.

Es gibt keine Fehlermeldung, keine Warnung, keinen Hinweis. Der Agent nimmt eine von beiden, und beim nächsten Mal vielleicht die andere. Genau so entsteht der Eindruck, ein Werkzeug halte sich mal an die Regeln und mal nicht.

So steht es für Claude Code. Der Standard AGENTS.md legt für diesen Fall eine Regel fest: Es gilt die Datei, die der bearbeiteten am nächsten liegt (externe Seite, agents.md), und eine ausdrückliche Anweisung im Chat geht allem vor. Codex kommt über die Reihenfolge dorthin. Die nähere Datei steht im zusammengesetzten Text weiter hinten und hat laut Dokumentation (externe Seite, learn.chatgpt.com) deshalb Vorrang vor der früheren.

seitlich verschiebbar

eigene Darstellung, Stand 03.08.2026

Praktisch heißt das: Wenn eine Anweisung unzuverlässig befolgt wird, geht der erste Blick in die anderen Dateien und erst danach in die Formulierung. Häufig steht dort das Gegenteil, ein halbes Jahr älter und längst vergessen.

Von Hand muss man dafür nicht suchen. /doctor prompt-audit geht die Dateien auf Widersprüche durch, auf Verweise zu Dateien oder Befehlen, die es nicht gibt, und auf Anweisungen, die für ältere Modelle geschrieben wurden. Er deckt standardmäßig CLAUDE.md, CLAUDE.local.md und AGENTS.md ab, dazu Regeln, Skills, Befehle, Subagenten und Ausgabestile unter .claude/ im Projekt und im Benut­zer­ver­zeichnis. Ein Pfad als Argument engt ihn auf eine Datei oder einen Ordner ein. Das Ergebnis ist ein Bericht, geändert wird erst auf Zuruf. Der Aufruf läuft über den mitgelieferten Skill /claude-api und fehlt, solange dieser abgeschaltet ist.

Zweihundert Zeilen

Für die Länge gibt es eine Empfehlung, und sie hat zwei Begründungen. Die Doku (externe Seite, code.claude.com) rät zu weniger als 200 Zeilen je CLAUDE.md: Längere Dateien belegen mehr Kontext und werden schlechter befolgt.

Die erste Begründung ist eine Kostenfrage: Die Datei steht bei jedem Schritt im Kontext. Die zweite ist die unangenehmere. Mehr Regeln führen zu weniger Befolgung. Wer bei ausbleibender Wirkung nachlegt, verstärkt das Problem, das er zu lösen versucht.

Das ist der Grund, warum eine gepflegte Projektanweisung regelmäßig kürzer wird. Eine Regel, die ein halbes Jahr lang nicht gebraucht wurde, kommt raus.

Ein Detail, das dabei hilft: Auszeichnungen, die in Markdown ein Kommentar sind, werden vor dem Einspeisen entfernt. Eine Wartungsnotiz für den nächsten Menschen kostet damit keinen Platz im Kontext, und beim Aufräumen weiß man wieder, warum eine Zeile dort steht. Das gilt allerdings nur für Kommentare, die für sich stehen. Innerhalb eines Codeblocks bleiben sie erhalten, denn dort sind sie Teil des Beispiels.

Was stattdessen wohin gehört

Nicht alles, was ein Agent wissen soll, gehört in diese eine Datei. Die Faustregeln:

Gilt immer und ist kurz: Projektanweisung.

Gilt nur für bestimmte Dateien: eine pfadgebundene Regel. Sie liegt in einem eigenen Verzeichnis und nennt im Kopf ein Muster wie src/api/**/*.ts; geladen wird sie erst, wenn der Agent eine passende Datei anfasst. Im Kopf zählt dabei nur das Feld paths, alles andere wird ohne Fehlermeldung ignoriert. Lässt sich das YAML dort nicht lesen, gilt die Regel danach für jede Datei statt für keine, ebenso ohne Warnung: dieselbe Stille wie beim Widerspruch weiter oben. Trotzdem ist sie der wirksamste Hebel gegen die Zweihundert-Zeilen-Grenze, weil sie den Kontext nur dann belastet, wenn sie überhaupt zur Sache gehört.

Ist ein mehrschrittiges Verfahren, das man selten braucht: ein Skill. Der wird erst geladen, wenn er aufgerufen wird oder passt.

Darf nicht passieren: ein Hook oder eine Einstellung. Beides steht in Kapitel 12.

Zwei Werkzeuge, eine Datei

Wer mit mehreren Agenten arbeitet, steht vor der Frage, ob er die Regeln doppelt pflegt. Seit Version 2.1.277 braucht es dafür oft gar keinen Umweg mehr: Liegt keine CLAUDE.md im Projekt, liest Claude Code eine vorhandene AGENTS.md von selbst.

Soll daneben etwas gelten, das nur Claude Code betrifft, bleibt der Verweis aus einer eigenen Datei, deren erste Zeile den Standard einbindet:

@AGENTS.md

## Claude Code

Für Änderungen unter `src/billing/` erst einen Plan zeigen.

Damit lesen beide Werkzeuge dasselbe, und toolspezifische Zusätze stehen darunter. Wer diese Datei aus der Zeit vor Version 2.1.277 schon angelegt hat, muss sie nicht rückbauen: Eine bereits eingebundene AGENTS.md liest Claude Code kein zweites Mal, ganz gleich, welcher der beiden Wege gerade greift.

Ein Symlink tut es ebenso, solange nichts dazukommen soll, mit einer Einschränkung unter Windows: Ein Repository-Symlink kommt dort ohne eigene Einstellung als einzeilige Textdatei an statt als Verweis. Wer das nicht ausschließen kann, nimmt die Einbindung.

Ein Einbinden spart allerdings keinen Platz. Die eingebundene Datei wird beim Start vollständig geladen. Es ist eine Ordnungsfrage; wer Kontext sparen will, braucht pfadgebundene Regeln.

Woran man merkt, dass sie nicht gelesen wird

Bevor man an der Formulierung feilt, lohnt die Prüfung, ob die Datei überhaupt angekommen ist. Dafür gibt es zwei Befehle, und sie beantworten verschiedene Fragen: Der eine zählt die Orte auf, an denen eine solche Datei liegen kann, auch die leeren. Der andere schlüsselt auf, was in dieser Sitzung wirklich im Fenster liegt, und nur er beantwortet die Frage hier. Beide stehen in Kapitel 05. Steht die Datei dort nicht, ist die Formulierung nicht das Problem.

Die häufigsten Ursachen: Der Agent wurde in einem anderen Verzeichnis gestartet, als man denkt. Die Datei liegt eine Ebene tiefer, als sie sollte. Bei einer AGENTS.md kommt eine dritte dazu, und sie ist die häufigste: Irgendwo im Pfad liegt doch eine CLAUDE.md oder eine CLAUDE.local.md, und die hat Vorrang.

Die Projektanweisung sieht aus wie Konfiguration und verhält sich nicht so. Wer das einmal verstanden hat, hört auf, sie zu verstärken, und fängt an, sie zu ergänzen.

Sie ist kein Systemprompt

Der Hersteller sagt in seinem Abschnitt zur Fehlersuche (externe Seite, code.claude.com), wie der Inhalt technisch ankommt: als Nachricht des Nutzers, die hinter der Systemanweisung steht.

Also als gewöhnliche Nachricht im Gespräch, ganz an dessen Anfang. Die Systemanweisung darüber bleibt unberührt. Der Satz gilt für Claude Code, ein anderes Werkzeug kann die Datei anders einhängen; die drei Folgen daraus hängen weniger am Wortlaut als daran, dass der Inhalt Text im Gespräch ist.

Sie konkurriert mit allem anderen im Gespräch. Was Sie in der Sitzung sagen, steht näher am Ende und wirkt stärker. Eine Regel aus Zeile 40 der Datei gegen eine ausdrückliche Bitte von eben verliert oft, und zwar zu Recht.

Sie unterliegt derselben Auf­merk­sam­keits­ver­tei­lung wie jeder andere Text. Was in der Mitte einer langen Datei steht, wird schlechter beachtet als was am Anfang oder am Ende steht. Das ist derselbe Effekt, der in Grundkurs, Kapitel 05 beschrieben ist.

Sie ist verhandelbar. Ein hinreichend gut begründeter Auftrag setzt sich gegen sie durch. Bei einer Konvention ist das gewünscht, bei einer Sperre wäre es fatal.

Daraus folgt die Aufteilung, auf der dieses Kapitel beruht: Die Datei regelt, was üblich sein soll. Was gelten muss, gehört woandershin.

Die Grenze, an der man wechselt

Die erste Frage ist die, die am seltensten gestellt wird: Lässt sich die Sache maschinell prüfen oder verhindern? Wenn ja, gehört sie dorthin, auch wenn sie in der Datei bequemer stünde. Ein Hook läuft an seinem Ereignis, ein Prüflauf misst ein Ergebnis, und beide kommen ohne Rückfrage beim Modell aus.

Bleibt danach etwas übrig, entscheiden zwei weitere Fragen, ob die Datei genügt:

1. Wäre eine Verletzung sofort sichtbar? Ein falsch formatierter Code fällt beim Lesen auf. Ein Commit auf dem falschen Branch nicht.
2. Wäre eine Verletzung folgenlos rückgängig zu machen? Eine Datei umbenennen ja, eine Veröffentlichung nein.

Zweimal ja, und die Datei reicht. Bei einem Nein braucht es einen Menschen, der freigibt: Ein Fehler, den niemand bemerkt und niemand zurücknehmen kann, darf nicht an einer Formulierung hängen.

Ein Halbsatz in der Datei kann in allen Fällen danebenstehen und den Grund erklären. Der Unterschied zwischen beidem bleibt klar: Einstellungen werden durchgesetzt, unabhängig davon, was das Modell entscheidet. Die Projektanweisung prägt Verhalten.

Wie eine Regel entsteht, die wirkt

Die brauchbaren Zeilen einer Projektanweisung haben fast alle dieselbe Geschichte: Etwas ist schiefgegangen, und statt es zu korrigieren, wurde es verhindert. Hashimoto beschreibt es in seinem Text zum Harness (externe Seite, mitchellh.com) als Haltung: Wann immer ein Agent einen Fehler macht, nimmt man sich die Zeit, eine Lösung zu bauen, mit der er genau diesen Fehler nie wieder macht.

Praktisch heißt das eine Reihenfolge, die man sich angewöhnen muss, weil sie der Bequemlichkeit widerspricht:

Erst messen, dann formulieren. Was genau ist passiert, und woran lag es? Häufig ist die naheliegende Erklärung falsch, und die Regel, die daraus entsteht, verhindert etwas anderes als das, was schiefging.

Den Grund mitschreiben. Eine Regel ohne Begründung wird beim nächsten Aufräumen gestrichen, weil niemand mehr weiß, wofür sie da war. Ein Halbsatz genügt.

Danach prüfen, ob sie wirkt. Eine Regel, die nie angeschlagen hat, ist ungetestet und keineswegs bewiesen. Die Arbeit aus Tiefe 1 (externe Seite, arxiv.org) zieht denselben Schluss für die Datei als Ganzes: Jeder Versuch, die Leistung zu verbessern, gehört vor dem Einsatz gründlich gemessen. Zwei der Verfasser arbeiten bei LogicStar (externe Seite, logicstar.ai), und genau dieses Messen verkauft die Firma.

Ein einzelner gelungener Lauf belegt das nicht. Dasselbe Modell beantwortet dieselbe Frage zweimal verschieden, und eine Regel, die einmal befolgt wurde, kann beim dritten Mal untergehen.

Die Datei wächst nicht linear

Ein Muster, das man nach einigen Monaten bemerkt: Groß wird die Datei durch Regeln, die nie wieder gelesen werden, und kaum durch neue.

Drei Sorten Ballast, alle mit demselben Ursprung:

Was der Code schon sagt. Verzeichnisbäume, Abhän­gig­keits­listen, Archi­tek­tur­über­sichten. Der Agent kann das nachsehen, und jede Kopie davon veraltet.

Was einmal galt. Die Regel zur Bibliothek, die vor drei Monaten ersetzt wurde, oder die Anweisung, die für ein älteres Modell geschrieben wurde. Sie schadet doppelt: Sie kostet Platz, und sie widerspricht womöglich einer neueren. /doctor prompt-audit sucht gezielt nach Anweisungen für ältere Modelle und nach Verweisen auf Dateien oder Befehle, die es nicht mehr gibt.

Was allgemein gilt. „Schreibe sauberen Code“ ist in jeder Datei richtig und in keiner nützlich.

Was bleibt, sind die Fallstricke, die Begründungen und alles, was in diesem Projekt anders ist als anderswo.

Was das Verdichten überlebt

Wenn eine Sitzung lang wird, fassen die Werkzeuge den bisherigen Verlauf zusammen. Was dabei mit den Anweisungen geschieht, ist eine Frage, die im Alltag zählt, und die naheliegende Antwort ist falsch.

Das Gespräch wird ersetzt. Die Her­stel­ler­do­ku­men­ta­tion (externe Seite, code.claude.com) beschreibt den Vorgang so: Eine strukturierte Zusammenfassung tritt an die Stelle des Gesprächs. Was Sie vereinbart haben, steht danach also in einer Zusammenfassung, die jemand anders geschrieben hat.

Genau darin liegt der Unterschied, der zählt. Ihre Anweisungen verhalten sich danach auf drei verschiedene Weisen, und welche gilt, hängt allein daran, wie sie geladen wurden:

Die Datei im Projektstamm wird neu von der Platte gelesen. Sie steht danach wortgleich wieder da, unabhängig davon, wie gut zusammengefasst wurde. Dasselbe gilt für die Notizen, die sich das Werkzeug selbst anlegt.

Pfadgebundene Regeln und Anweisungen aus Unter­ver­zeich­nissen fallen heraus und kommen erst zurück, wenn dort wieder eine passende Datei angefasst wird. Die Doku zum Kontextfenster (externe Seite, code.claude.com) nennt den Grund: Solche Regeln und Dateien laden erst in den Gesprächsverlauf, wenn Claude ihre auslösende Datei liest, schreibt oder bearbeitet. Beim Verdichten werden sie deshalb mit allem anderen zusammengefasst und verschwinden.

Wer eine solche Regel behalten will, streicht die Pfadbindung oder verschiebt sie in die Stammdatei. Das kostet dann allerdings genau den Platz, den die Pfadbindung eingespart hat.

Was nur im Gespräch stand, hängt an der Zusammenfassung. Es kann darin stehen, ausführlich oder als Halbsatz, und es kann fehlen. Die Dokumentation formuliert das von der anderen Seite her: Wenn eine Anweisung nach dem Verdichten verschwunden ist, wurde sie entweder nur im Gespräch gegeben oder sie liegt in einer Datei, die noch nicht neu geladen wurde.

Daraus folgt ein Schluss, der schärfer ist als „schreib es auf“: Über das Überleben entscheidet, wer die Auswahl trifft. Er gilt für alle Orte, an denen ein Agent nachsieht, und steht als Merksatz in Kapitel 05. Für die Projektanweisung kommt hier die Feinheit dazu, dass sie in drei Fassungen vorliegt und nur eine davon von selbst zurückkommt.

seitlich verschiebbar

eigene Darstellung, Stand 03.08.2026

Wenn Sie dieselbe Sache in einer langen Sitzung zum zweiten Mal erklären, schreiben Sie sie in die Datei.

Der eigene Aufbau

Diese Website entsteht mit genau dieser Mechanik, und ihre Projektanweisung ist eher ein Regelwerk als ein Leitfaden. Was daran nach mehreren Monaten brauchbar ist:

Eine Tabelle statt einer Liste. Jede Entscheidung mit Datum und Begründung, ergänzt statt neu geschrieben. Der Nebeneffekt ist, dass man beim Nachtragen sieht, ob eine ältere Zeile der neuen widerspricht.

Sätze über das, was nicht passieren darf, an einer Stelle gebündelt und ausdrücklich als solche gekennzeichnet. Sie stehen dort mit dem Wissen, dass sie eine Bitte bleiben, und die harten Fälle liegen zusätzlich als Prüflauf daneben.

Der Grund neben der Regel. Manche Zeilen sind zwei Absätze lang, weil die Regel allein beim nächsten Aufräumen unverständlich wäre. Das kostet Platz und ist es wert.

Was dabei nicht funktioniert hat: der Versuch, alles in eine Datei zu schreiben. Die Grenze ist keine Zeilenzahl. Sie liegt an dem Punkt, an dem man selbst nicht mehr weiß, was drinsteht. Danach schreibt man Regeln hinein, die schon dastehen, und irgendwann eine, die einer anderen widerspricht.