Claude Code Rules: Schluss mit der einen riesigen CLAUDE.md

Stell dir deine CLAUDE.md vor. Sie fing klein an. Dann kamen Testing-Konventionen dazu. Dann API-Patterns. Dann Deployment-Schritte, Datenbank-Schema-Notizen, eine Liste von Antipatterns. Ein halbes Jahr später hat sie 500+ Zeilen — und Claude liest jede einzelne davon, bei jeder Session, egal ob die aktuelle Aufgabe irgendwas mit Testing, Deployment oder gar keinem von beidem zu tun hat.

Schlimmer: Wenn im Team jeder mit Claude, Codex oder was auch immer arbeitet, jeder mit eigenen Instruktionen, driftet das auseinander. Am Ende weiß niemand mehr genau, welche Instruktion wo eigentlich gilt.

Rules lösen das Wachstumsproblem. Statt einer Datei, die jedes Mal komplett geladen wird, bekommst du einen Ordner mit kleinen, pfad-gebundenen Markdown-Dateien, die nur laden, wenn die aktuelle Aufgabe den jeweiligen Pfad wirklich betrifft.

Wie es funktioniert#

Rules leben in .claude/rules/. Im Frontmatter jeder Datei steht, wann sie laden soll — meistens ein paths-Pattern, Glob-Syntax, dieselbe, die du von der .gitignore kennst. Fasst du eine Datei unter api/ mit .ts-Endung an, lädt die passende Rule. Fasst du was unter frontend/ an, lädt eine andere. Rules lassen sich auch verschachteln — sie werden rekursiv gefunden, also können Backend-Rules in backend/ liegen, Frontend-Rules in frontend/, und jede taucht nur auf, wenn sie relevant ist.

Das Ergebnis: Deine CLAUDE.md bleibt kurz — der stabile, immer wahre Kern — und alles Situative liegt in einer Rule, die bei Bedarf lädt, statt von Anfang an jeden Context zuzumüllen.

Im Video#

00:00 — Das Problem: jeder im Team mit anderem Agent, anderen, driftenden Instruktionen
01:48 — Was ein Rules-Ordner eigentlich ist (.claude/rules/)
03:32 — Das Frontmatter-Format: paths, und wie das Pattern-Matching funktioniert
04:44 — Live-Demo: eine 532-Zeilen-CLAUDE.md in Rules aufsplitten
05:40 — Das Ergebnis: ~35 Zeilen bleiben in der CLAUDE.md, der Rest wird nach Thema aufgeteilt
06:33 — Test: ein neuer API-Endpoint, und die richtige Rule lädt
06:56 — Team-Workflow: CLAUDE.md für Codeowners sperren, neue Rules über PR vorschlagen

Eine 532-Zeilen-Datei wirklich aufsplitten#

Im Video ist der Ausgangspunkt eine echte CLAUDE.md für ein Kursprojekt: 532 Zeilen, komplett geladen bei jeder Session. Claude bekommt den Auftrag, sie zu analysieren und vorzuschlagen, wie man sie in Rules aufteilt — und kommt mit einem Plan zurück: rund 35 Zeilen bleiben in der CLAUDE.md (Kern-Architektur, Antipatterns), der Rest wird pfad-gebunden aufgeteilt — eine Rule für Datenbank-Schema und Types, eine für Services, eine für API-Routes.

Jede Rule bekommt ein paths-Pattern, das genau auf den Code zeigt, den sie regelt. Session neu starten, einen neuen API-Endpoint anlegen — und im Transkript siehst du direkt die Bestätigung: die API-Routes-Rule lädt, und nur die.

Daraus einen Team-Prozess machen#

Sobald Rules existieren, kannst du die CLAUDE.md selbst sperren, sodass nur Codeowner sie anfassen dürfen, und jede neue Rule über einen Pull Request laufen lassen — jemand schlägt eine neue Rule vor, die Codeowner reviewen sie, sie wird gemergt oder eben nicht. Das ist ein echter Review-Prozess für das, was dein AI-Assistent annehmen darf, statt dass jeder Entwickler still eine gemeinsame Instruktionsdatei editiert.

Eine Idee, die einen Versuch wert ist: den Agenten am Ende einer Session sich selbst fragen lassen "was davon hätte eigentlich eine Rule sein können?" — kein eingebautes Feature, nur ein Prompt, den du selbst hinzufügst, aber er macht aus deinem Rule-Set etwas, das aus echter Nutzung wächst, statt aus Vorab-Rätselei.

Worum es eigentlich geht#

Die CLAUDE.md sollte kurz bleiben — die zwei, drei Absätze, die immer gelten, egal woran du gerade arbeitest. Alles andere — Testing-Konventionen, Deployment-Schritte, Schema-Eigenheiten — gehört in eine Rule, die nur auftaucht, wenn die Aufgabe sie wirklich braucht. Eine Datei, die endlos wächst, ist keine Dokumentation mehr. Sie ist Rauschen, durch das sich dein Agent bei jedem einzelnen Run wühlen muss.