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:

Claude analyzes your codebase and creates a file with build commands, test instructions, and project conventions it discovers. (externe Seite, code.claude.com)

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 Verzeichnisstruktur, 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, und geht dann so vor:

It then explores your codebase with a subagent, fills in gaps via follow-up questions, and presents a reviewable proposal before writing any files. (externe Seite, code.claude.com)

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:

providing context files does not generally improve task success rates, while increasing inference cost by over 20% on average (externe Seite, arxiv.org)

Hier wird der Befund gern abgeschnitten, und dann liest er sich wie ein Urteil über Projektanweisungen überhaupt. Der Satz danach sagt, woran es liegt:

while instructions in the context files are well followed by coding agents, repository overviews, although popular and recommended by model providers, are not helpful (externe Seite, arxiv.org)

Anweisungen wirken also. 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 Projektverzeichnis 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 herstellerübergreifende Standard, entstanden aus der Zusammenarbeit mehrerer Anbieter und heute bei der Linux Foundation. Die Projektseite beschreibt sie als

a dedicated, predictable place to provide the context and instructions to help AI coding agents work on your project (externe Seite, agents.md)

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 sagt es in einem Satz:

README.md files are for humans: quick starts, project descriptions, and contribution guidelines. (externe Seite, agents.md)

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, gehört nicht hinein, 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:

Claude treats them as context, not enforced configuration. (externe Seite, code.claude.com)

Die Datei ist Kontext, keine durchgesetzte Konfiguration. Sie 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 08.

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:

it cuts content Claude can derive from the codebase, such as directory layouts, dependency lists, and architecture overviews, and keeps pitfalls, rationale, and conventions that differ from tool defaults (externe Seite, code.claude.com)

Weg kommt also, was der Agent im Code nachsehen kann. Es bleiben die Fallstricke, die Begründungen und die Konventionen, die in diesem Projekt anders sind als üblich.

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

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

Die Anweisungen können an vier Stellen liegen, und jede hat eine andere Reichweite. Von weit nach eng:

Bereich	Wo	Gilt für
Verwaltet	Systemverzeichnis, von der IT verteilt	alle Sitzungen auf dem Rechner
Benutzer	~/.claude/CLAUDE.md	alle Ihre Projekte
Projekt	./CLAUDE.md oder ./.claude/CLAUDE.md	dieses Projekt, geteilt über Git
Lokal	./CLAUDE.local.md	dieses Projekt, nur bei Ihnen

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.

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.

Sie überschreiben sich nicht, sie 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.

Widersprüche werden nicht gemeldet

Aus dem Stapeln folgt das Problem, das man am seltensten bemerkt. Die Dokumentation ist da deutlich:

if two rules contradict each other, Claude may pick one arbitrarily (externe Seite, code.claude.com)

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.

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.

Zweihundert Zeilen

Für die Länge gibt es eine Empfehlung, und sie hat zwei Begründungen:

target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence. (externe Seite, code.claude.com)

Die erste Hälfte 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 08.

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, wie der Inhalt technisch ankommt:

CLAUDE.md content is delivered as a user message after the system prompt (externe Seite, code.claude.com)

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 Aufmerksamkeitsverteilung 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 als Haltung:

It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again. (externe Seite, mitchellh.com)

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 zieht denselben Schluss für die Datei als Ganzes:

any attempts to improve performance should be rigorously evaluated before deployment (externe Seite, arxiv.org)

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ängigkeitslisten, Architekturübersichten. Der Agent kann das nachsehen, und jede Kopie davon veraltet.

Was einmal galt. Die Regel zur Bibliothek, die vor drei Monaten ersetzt wurde. Sie schadet doppelt: Sie kostet Platz, und sie widerspricht womöglich einer neueren.

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 nicht verworfen, es wird ersetzt. Die Herstellerdokumentation beschreibt den Vorgang als Replaces the conversation with a structured summary (externe Seite, code.claude.com). Was Sie vereinbart haben, ist danach also nicht weg, es steht 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 Unterverzeichnissen fallen heraus und kommen erst zurück, wenn dort wieder eine passende Datei angefasst wird. Die Dokumentation nennt den Grund:

Path-scoped rules and nested CLAUDE.md files load into message history when their trigger file is read, so compaction summarizes them away with everything else. (externe Seite, code.claude.com)

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.