Deine Instruktionsdateien sind Adressierung, keine Fragmentierung

In der Welt der Agent-Tools geht ein ordnungsliebender Impuls um: eine Instruktionsdatei, die alle beherrscht. Jeder Coding-Agent hat sich seine eigene Dotfile zugelegt, eine CLAUDE.md oder das Äquivalent, und ein Team, das mehrere davon betreibt, pflegt am Ende einen kleinen Stapel Beinah-Duplikate, die mit jeder unachtsamen Änderung ein Stück weiter auseinanderdriften. Dagegen hat ein einziger Standard, den jedes Tool liest, offensichtlichen Reiz, und der Fall für AGENTS.md wurde direkt gegen Claude Code eingereicht: eine Claude-spezifische Datei reist schlecht zu Mitarbeitern auf anderen Tools, also soll ein gemeinsamer Standard den Kontext tragen und niemand mehr zwei Kopien führen müssen. Die Duplikation ist real und der Ärger verdient.

Sieh dir an, wie diese Anfrage tatsächlich gelöst wurde. Nicht mit einer universellen Datei, die die anderen verschlingt, sondern mit einem Verweis. Der Maintainer-Kommentar, der das Issue schloss, riet dazu, die eigene CLAUDE.md zu einem einzeiligen Import der gemeinsamen Datei zu machen, einem Include von AGENTS.md, damit der gemeinsame Kontext beim Sitzungsstart lädt und alle tool-spezifischen Zeilen daneben stehen statt an seiner Stelle. Ein Symlink zwischen den beiden Namen wird ebenfalls angeboten, aber der ist der Grenzfall: ein Symlink ist eine einzige Datei, die zwei Namen trägt, ohne Platz, an dem irgendetwas danebenstehen könnte, also ist er nur dann der richtige Zug, wenn du keine tool-spezifischen Zeilen zu verlieren hast. Die interessante Option ist der Import, denn das Heilmittel gegen Duplikation entpuppte sich als Referenz und nicht als Verschmelzung: Halte das Gemeinsame an einem Ort, und halte das Adressierte adressiert. Merk dir diese Form, denn sie klärt weniger, als es aussieht.

Ein Import löst das Laden. Er stellt die gemeinsame Datei und die native Datei einem Agenten in einer Sitzung vor Augen, was das gesamte Problem war, um das sich die Duplikat-Beschwerde drehte. Was er nicht berührt, ist die Zuständigkeit: welche Zeilen zu diesem Repository gehören und zu jedem reisen, der es klont, und welche Zeilen zu mir gehören und niemals in eine gemeinsame Datei committet werden dürfen. Das ist die Unterscheidung, die die Alles-verschmelzen-Variante des Vorschlags nicht sehen kann, weil sie diese Dateien als Kopien einer einzigen Sache liest, die verstreut wurde. Manche sind es. Die meisten nicht. Sie sehen gleich aus, weil Markdown das einzige Format ist, das eine von ihnen hat, so wie ein Memo, ein Hypothekenvertrag und ein Erpresserbrief alle nur Text sind. Gleichheit des Behälters ist nicht Gleichheit des Inhalts, und die Instruktionsdateien, die ein ernsthaftes Agent-Setup ansammelt, beantworten verschiedene Fragen, für verschiedene Leser, unter verschiedenen Regeln darüber, wer sie bearbeiten darf. Wirf sie zusammen, weil sie eine Dateiendung teilen, und du hast kein Versehen beseitigt. Du hast die Adressierung beseitigt.

Eine Adresse ist nur das Paar von Fakten, das entscheidet, wohin eine Zeile gehört: worauf sie sich bezieht und wie schnell sie sich ändert. In einem Netzwerk ist die Adresse das, was sagt, für wen ein Paket bestimmt ist, und der Wert davon, unterschiedliche zu haben, liegt nicht darin, dass Adressen angenehm zu pflegen wären, sondern darin, dass sich ohne sie nichts routen lässt. Mit Instruktionsdateien ist es genauso. Jede Zeile ist adressiert, und die Frage, die sie ordnet, ist nicht, welches Tool sie parst, sondern worüber sie eine Aussage macht. Es gibt drei solche Geltungsbereiche, und der Grund, warum der Konsolidierungs-Vorschlag stimmig klingt, ist, dass er nur einen von ihnen klar ins Auge fasst.

Der erste Geltungsbereich ist der Operator, also ich, unabhängig von jedem Projekt. Wie ein Agent mit mir reden soll, wann er innehalten und fragen muss, statt sich einen Weg um eine Wand herum auszudenken, wie er mit Secrets umgeht, was er tut, nachdem er dreimal auf dieselbe Weise gescheitert ist. Nichts davon ist ein Fakt über eine Codebasis. Es ist die Haltung, die jeder Agent in jedes Repository tragen soll, das er je berührt, und sie steht über ihnen allen, in meiner eigenen Konfiguration, in jede Sitzung eingespeist, gerade weil sie niemandes Projekteigentum ist. Versuch, sie in eine Datei pro Repository hinunterzudrücken, und deine einzigen Optionen sind, sie zu kopieren, wo sie in subtil verschiedene Versionen derselben Regel driftet, oder sie fallen zu lassen. Ein Import rettet dich hier nicht, und der Grund ist genau der Punkt der Zuständigkeit: eine gemeinsame Repo-Datei, die versuchte, meinen persönlichen Leitfaden einzubinden, würde ihn im Checkout eines Kollegen entweder nicht finden oder jeweils den anderen jeder Person hereinziehen. Die Operator-Ebene ist die Ebene, die nicht im gemeinsamen Artefakt reisen darf, also ist das gemeinsame Artefakt der eine Ort, an den sie nicht kann.

Der zweite Geltungsbereich ist das Projekt. Dieser Stack, diese Konventionen, dieses Constraint, das dich beißt, wenn du es nicht kennst, die lokalen Wahrheiten, die ein Agent braucht, um in diesem Repository nützlich zu sein und in keinem anderen. Das ist die Ebene, auf die AGENTS.md passt, und zwar gut passt, und die Ebene, die der Import tatsächlich teilt, denn das Build-Kommando und der Test-Runner und die Regel, die generierte Datei nie anzufassen, sind wahr, egal welches Tool sie liest. Wäre die ganze Debatte nur über diesen Geltungsbereich, hätten die Konsolidierer schlicht recht, und die ehrliche Fassung ihres Arguments ist, dass sie es haben. Die Dual-File-Vorschläge ahnen das bereits; sie trennen das gemeinsame Setup vom tool-spezifischen Material, statt beides in einen Topf zu werfen. Der Fehler liegt allein im Sprung von einer korrekten Aussage über die Projekt-Ebene zu einer Aussage über jede Ebene.

Der dritte Geltungsbereich ist die Umgebung: was tatsächlich installiert ist und läuft, dort wo der Agent läuft. Die Sub-Agenten, die diese Runtime definiert hat, die MCP-Server, die hier bereitgestellt und autorisiert sind, die Services und Timer auf genau diesem Host. Der Instinkt sagt, eine Zeile wie übergib diese Migration an den Schema-Sub-Agenten sei portabler Kontext, der zufällig in einer Claude-Datei gelandet ist, und das ist sie nicht, aber der Grund ist spezifischer als andere Tools können das nicht. Andere Agenten haben auch Sub-Agenten, und MCP wurde als client-übergreifend gebaut; die Definitionen sind gewöhnliche Dateien, die sich kopieren lassen. Was nicht portiert, ist die Auflösung: die Referenz bedeutet nur dort etwas, wo das, was sie benennt, tatsächlich eingerichtet ist. Wirf sie in eine universelle Datei, die auf einer Maschine gelesen wird, auf der dieser Server nie bereitgestellt wurde, und sie ist kein gemeinsamer Kontext, sie ist eine Referenz auf nichts. Innerhalb dieses Geltungsbereichs gibt es eine schnelle Achse und eine langsame, eine dauerhafte Bindung gegenüber lebendigem Zustand, aber sie beantworten dieselbe Frage, nämlich was gerade jetzt für diese Umgebung wahr ist, und diese Frage ist weder die des Projekts noch meine. (Prozedur-Dateien, die Skills und Slash-Kommandos, die danach adressiert sind, welche Aufgabe du gerade erledigst, statt nach dem Geltungsbereich, queren all das auf einer anderen Achse; sie sind eine echte Kategorie und ein eigenes Argument, und ich lasse sie hier beiseite.)

Bis hierher ist das ein Argument dafür, getrennte Dateien zu behalten, was ein import-basierter einzelner Einstiegspunkt bereits würdigt, und ein fairer Leser kann trotzdem fragen, warum es zählt, ob die Zeilen in einer physischen Datei liegen oder in mehreren zusammengenäht. Hier ist der Grund. Sortiere denselben Inhalt nicht danach, worauf er sich bezieht, sondern danach, wer ihn schreiben darf. Die gemeinsame Datei eines Repositories ist von jedem beschreibbar, der einen Pull Request öffnen kann, und sie kommt in jedem Repository, das du von einem Fremden klonst, bereits geschrieben an. Mein Operator-Leitfaden ist nur von mir beschreibbar. Das sind verschiedene Vertrauensstufen, und heute werden sie durch fast nichts auseinandergehalten außer der Tatsache, dass es verschiedene Dateien sind, die mit unterschiedlichem Rang gelesen werden. Verschmilz sie zu einem Dokument, das der Agent mit einer einzigen Autoritätsstufe konsumiert, und du hast Text, den ein Fremder bearbeiten kann, in dieselbe Datei gelegt wie die Regel, deren ganze Aufgabe es ist, innehalte und frag einen Menschen zu sagen. Die Operator-Ebene ist das Einzige im Stapel, das ein Repository überstimmen kann, was der genaue Grund ist, warum sie nicht in einem liegen darf. Das ist auch, warum nimm doch einfach ein Include nicht der Einwand ist, als der er klingt: ein Include, das eine nicht vertrauenswürdige Repository-Datei in den vertrauenswürdigen Kontext des Operators zieht, ist nicht die Lösung, es ist die Schwachstelle, und die sichere Richtung der Referenz ist das genaue Gegenteil von der, die die aufgeräumte Variante will.

Damit in der Hand ist die Unterscheidung leicht zu benennen, und es ist die, die der Verschmelzungs-Vorschlag nie trifft. Fragmentierung ist, wenn viele Dateien dieselbe Frage beantworten: vier AGENTS.md-artige Dateien über vier Tools, die alle dieselben Build-Schritte herunterbeten, was absolut zu einer gemeinsamen Projektdatei zusammengefasst werden sollte, und in diesem Punkt ist der Standard ein echter Gewinn. Schichtung ist, wenn ein paar Dateien je eine andere Frage beantworten, auf einem anderen Geltungsbereich, unter anderen Schreibrechten. Ein Import komponiert Schichten und lässt dabei jede in der Zuständigkeit dessen, der sie besitzen soll; ein Fallback, der die native Datei liest und stoppt, komponiert gar nichts, er lässt bloß eine Schicht fallen. Und sieh, wie eng die tatsächlich strittige Frage ist. Fast niemand plädiert dafür, die stehenden Regeln des Operators oder die laufenden Services des Hosts in eine gemeinsame Repo-Datei zu legen; in dem Moment, in dem du es klar aussprichst, ist es offensichtlich falsch. Nur eine Grenze ist wirklich umstritten, die Operator-Grenze, und sie wird von niemandem laut bestritten, was genau die Art ist, wie sie erodiert. Schichten kollabieren nicht, weil jemand eine Verschmelzung verordnet. Sie kollabieren, weil eine gemeinsame Datei, sobald sie die Konvention ist, zu der Datei wird, nach der die Leute greifen, und operator- und umgebungsbezogene Zeilen mit jeder bequemen Änderung ein Stück weit hineinsickern.

Ich betreibe eine ganze Reihe von Agenten, und was das System lesbar hält, ist nicht, dass alles in einer Datei liegt. Es ist, dass ich immer eine enge Frage beantworten kann: welche Instruktion welchen Agenten erreicht, und wer sie dort hinlegen durfte. Die operative Haltung sitzt an einem Ort über jedem Projekt, also gibt es eine Kopie zu ändern und sie ändert sich für alle auf einmal, und nichts, was ein Repository mitliefert, kann sie überschreiben. Jedes Projekt nennt seine eigenen Wahrheiten und reist mit seinem eigenen Repo. Die Umgebungs-Ebene bleibt, wo sie sich auflöst. AGENTS.md ist eine gute Lösung für die Ebene, für die es gebaut wurde, und der Import, der die Debatte schloss, ist der richtige Weg, diese Ebene zu teilen. Was kein Vorschlag mit gemeinsamer Datei beantwortet hat, und was ein Import auch nicht beantwortet, ist der Vorrang: wenn die Projektdatei tu dies sagt und mein Operator-Leitfaden tu dies niemals sagt, hat eine einzelne verschmolzene Datei genau eine Regel, die Dokumentreihenfolge, und ein Stapel von Schichten lässt dich immerhin sagen, welche gewinnt und warum. Das ist der ungelöste Teil, und er ist ein Argument dafür, die Schichten benennbar zu halten, nicht dafür, sie zu einer Textwand zu verrühren, die technisch kürzer ist und die einzige Frage, auf die es ankommt, nicht mehr beantwortet.