Regeldateien: AGENTS.md und CLAUDE.md

Ein Coding-Agent beginnt jede Sitzung ohne Erinnerung an die letzte. Was er trotzdem über dein Projekt weiß, steht in einer Datei, die er beim Start von selbst liest. Je nach Werkzeug heißt sie AGENTS.md, CLAUDE.md oder ähnlich; das Prinzip ist überall dasselbe: eine Textdatei im Projektordner, die in jede Sitzung geladen wird.

Was hineingehört

Die Leitfrage ist: Was kann der Agent nicht selbst herausfinden? Ordnerstruktur und Programmiersprache sieht er. Deine Absichten nicht.

• Zweck in zwei Sätzen. Was ist das hier, für wen, in welchem Zustand – live oder Prototyp?
• Befehle. Wie wird gebaut, getestet, gestartet. Wörtlich, zum Kopieren.
• Abweichungen vom Üblichen. Alles, wo die naheliegende Annahme falsch wäre: „Deutsch in der Du-Form“, „kein Client-JavaScript“.
• Verbote mit Grund. Was nie passieren darf, und warum.
• Definition von fertig. Welche Prüfungen bestanden sein müssen, bevor etwas als erledigt gilt.
• Wegweiser. Wo die ausführliche Dokumentation liegt – der Verweis, nicht ihr Inhalt.

# Projektregeln

Onlineshop-Frontend, LIVE. Jede Änderung auf main ist sofort öffentlich.

## Befehle
- Prüfen: npm run build && npm test
- Starten: npm run dev

## Regeln
- Nie direkt auf main arbeiten, weil dort kein Review stattfindet.
- Texte auf Deutsch, Du-Form.
- Fertig ist eine Änderung erst, wenn Build und Tests grün sind.

Details zum Deployment: docs/BETRIEB.md

Was sie verstopft

Jede Zeile wird in jeder Sitzung mitgelesen und verdrängt etwas anderes aus der Aufmerksamkeit des Modells. Drei Dinge gehören deshalb nicht hinein:

• Was im Code steht. Eine Liste aller Dateien veraltet am Tag nach dem Schreiben.
• Geschichte. Wie es früher war, interessiert nur bei einer konkreten Rückfrage. Das gehört in ein eigenes Dokument.
• Zugangsdaten. Nie. Nur der Ort, an dem sie liegen.

Als Richtwert: Was über hundert Zeilen hinauswächst, wird in Themen aufgeteilt, auf die die Regeldatei nur verweist.

Begründen statt brüllen

„NIEMALS force-pushen!!!“ wird befolgt – bei genau diesem Befehl. „Nie force-pushen, weil andere auf demselben Branch arbeiten“ wird auch befolgt, wenn der Agent auf einem anderen Weg dieselbe Wirkung erzielen könnte. Die Begründung macht aus einer Einzelregel ein Prinzip, das der Agent auf Fälle überträgt, die du nicht bedacht hast.

Drei Ebenen

Die meisten Werkzeuge lesen Regeln aus mehreren Orten und legen sie übereinander: deine persönlichen Regeln für alle Projekte, die Projektdatei im Hauptordner und bei Bedarf Unterordner-Dateien für einen Teilbereich. Persönlich ist, wie du arbeiten willst. Projektbezogen ist, was für alle gilt, die an dem Projekt arbeiten – diese Datei gehört in die Versionskontrolle.

Die Pflege in zwei Regeln

Macht der Agent denselben Fehler zum zweiten Mal, kommt eine Zeile dazu. Wurde eine Zeile ein Vierteljahr nicht gebraucht oder stimmt nicht mehr, kommt sie weg. Eine Regeldatei, die nur wächst, wird irgendwann überlesen – von Modellen genauso wie von Menschen.

Was sich als fester Ablauf herausstellt, gehört nicht in die Regeldatei, sondern in einen Skill. Das ist Stoff im Experten-Pfad Agenten im Betrieb.