CLAUDE.md im Team: Regeln festhalten, Memory sinnvoll nutzen

Der Nutzen: weniger wiederholte Einarbeitung. Ein hypothetisches Rechenbeispiel: Vier Entwickler, die in jeweils fünf Sitzungen drei Minuten lang den Arbeitskontext erneut erklären, kommen zusammen auf 60 Minuten pro Woche. Eine gemeinsame Anweisungsdatei bündelt diese Informationen an einer Stelle. Ob sich das lohnt, zeigt der Vergleich zwischen eingesparten Wiederholungen und Pflegeaufwand; eine Zeitersparnis ist nicht garantiert.

Was ist CLAUDE.md?

CLAUDE.md ist eine Markdown-Datei mit Anweisungen, die Claude Code für ein Projekt, den persönlichen Arbeitsablauf oder die Organisation einliest. Sie ist die dauerhaft gültige Arbeitsgrundlage des Teams. Auto Memory ist das begleitende Notizbuch, das Claude selbst führt. Die Arbeitsgrundlage pflegt das Team, das Notizbuch schreibt Claude. Beides fließt als Kontext in seine Entscheidungen ein. Anthropics Dokumentation zu Memory

Entscheidend ist, was über einzelne Sitzungen hinaus gelten soll. Ein vorgeschriebener Testbefehl gehört in die Anweisungsdatei. Die Rückmeldung, dass eine bestimmte Erklärung zu ausführlich war, kann als erlernte Präferenz gespeichert werden. Die aktuelle Aufgabe gehört ins Gespräch.

Diese Aufteilung folgt der offiziellen Dokumentation zur Verzeichnisstruktur. Für den Einstieg ist kein umfangreicher .claude-Ordner nötig. Zunächst reicht die Anweisungsdatei; weitere Dateien kommen hinzu, sobald sie einen klaren Zweck erfüllen.

Wohin gehört CLAUDE.md: ins Projekt, ins Benutzerverzeichnis oder in die Organisation?

Für ein kleines Team bietet sich eine gemeinsame Projektdatei im Stammverzeichnis des Repositorys an, die in die Versionsverwaltung aufgenommen wird. Persönliche Vorlieben gehören in die Benutzerdatei, damit andere Teammitglieder sie nicht versehentlich übernehmen.

Das sind die dokumentierten Geltungsbereiche und Speicherorte. Zentral verwaltete Organisationsdateien lassen sich nicht über individuelle Einstellungen ausschließen. Ihre textlichen Vorgaben bleiben dennoch Anweisungen zur Orientierung.

Beim Start lädt Claude Anweisungsdateien aus dem Arbeitsverzeichnis und den übergeordneten Verzeichnissen. Anweisungen in Unterverzeichnissen kommen hinzu, sobald Claude dort mit Dateien arbeitet. Die Inhalte werden zusammengeführt: Eine spezifischere Datei hebt widersprüchliche Anweisungen an anderer Stelle also nicht auf. Benutzer- und Projektvorgaben sollten zueinander passen. So werden Anweisungen geladen

CLAUDE.md-Beispiel für ein kleines Produktteam

In die Datei gehören Entscheidungen, die wiederkehrende Fehler verhindern. Das folgende Beispiel setzt ein TypeScript-Produkt mit pnpm und bereits definierten Skripten für lint, typecheck und test voraus. Vor dem Commit müssen die Befehle und Pfade durch solche ersetzt werden, die im eigenen Repository geprüft wurden.

Jeder Abschnitt erklärt in einer Zeile, warum er enthalten ist. Es handelt sich um vorgeschlagene Teamkonventionen, nicht um Standardeinstellungen von Anthropic.

# Product Team Instructions

## Product Intent
Why: Keep implementation tied to the customer problem.
- Read the task's acceptance criteria before changing code.
- Ask when missing product behavior would change the solution.

## Working Commands
Why: Make verification repeatable across teammates and sessions.
- Use pnpm for this repository; keep pnpm-lock.yaml consistent.
- Run pnpm lint and pnpm typecheck for application changes.
- Run pnpm test for behavior changes; report any checks not run.

## Change Boundaries
Why: Keep reviews small and dependencies deliberate.
- Follow nearby patterns before adding a new abstraction.
- Ask before adding a runtime dependency or changing public APIs.
- Keep unrelated cleanup out of the change.

## Data and Migrations
Why: Make data changes reviewable and reversible where possible.
- Add schema changes through the existing migration workflow.
- Describe compatibility and rollback concerns in the handoff.
- Use synthetic data in examples and tests.

## Quality
Why: Catch user-visible regressions before review.
- Add a focused regression test when fixing a behavior bug.
- Check loading, empty and error states when changing UI flows.
- State remaining uncertainty instead of calling unchecked work done.

## Project References
Why: Point to maintained decisions without copying the whole wiki.
- Read docs/product-decisions.md when product behavior is unclear.
- Read docs/release-checklist.md before preparing a release.

Die Verweise in diesem Beispiel sind gewöhnliche Anweisungen, die Dokumente bei Bedarf zu lesen. Die Dokumente müssen angelegt oder die Pfade ersetzt werden. Auf automatische Imports wird hier bewusst verzichtet.

Nach dem Speichern eine Sitzung im Repository starten und mit /context prüfen, welche Memory-Dateien beim Start geladen wurden. Mit /memory lässt sich die Anweisungsdatei öffnen und bearbeiten. Anschließend zeigt eine kleine echte Aufgabe, ob die Befehle und Grenzen Claude sinnvoll unterstützen. Memory prüfen

Regeln für bestimmte Dateitypen gezielt auslagern

Eine Regel gehört nach .claude/rules/, wenn sie für die meisten Aufgaben keine Rolle spielt. Bei einer Änderung am Frontend müssen beispielsweise nicht sämtliche Konventionen für API-Handler im Kontext stehen.

Dafür die Datei .claude/rules/api.md mit einem paths-Kopfbereich anlegen. Ein Glob ist ein Muster für Dateinamen; src/api/**/*.ts erfasst TypeScript-Dateien in diesem Verzeichnis und seinen Unterverzeichnissen.

---
paths:
  - "src/api/**/*.ts"
---

# API Rules
- Validate external input before passing it to application logic.
- Use the existing error response format.
- Add a focused test when changing an endpoint's behavior.

Das Muster bestimmt, wann die Anweisung in den Kontext aufgenommen wird. Ohne paths wird die Regel bei jedem Start geladen. Eine lange Anweisungsdatei nur in mehrere Regeldateien aufzuteilen spart daher keinen Kontext, solange deren Laden nicht auf passende Dateien begrenzt wird. Pfadabhängige Regeln

Imports teilen Inhalte – und laden sie vollständig in den Kontext

Ein Import wie @docs/team-conventions.md in CLAUDE.md lädt die referenzierte Datei beim Start in den Kontext. Relative Pfade werden ausgehend von der Datei aufgelöst, die den Import enthält. Der eigentliche Import muss außerhalb von Markdown-Backticks und Codeblöcken stehen; darin wird er als wörtlicher Text behandelt. Für Projektimports außerhalb des Arbeitsverzeichnisses wird eine Zustimmung abgefragt. Import-Syntax

Eine kurze Konvention, die ein anderes Team bereits pflegt und die in jeder Sitzung gebraucht wird, eignet sich für einen Import. Bei einer langen Release-Checkliste ist ein einfacher Verweis wie im Einstiegsbeispiel sinnvoller. Ein Import ordnet die Anweisungen neu; er verringert nicht die Textmenge, die Claude beim Start liest.

AGENTS.md ist schon vorhanden? Teamregeln an einer Stelle pflegen

Ab Version 2.1.277 kann Claude Code bei verfügbarer Unterstützung AGENTS.md direkt anstelle von CLAUDE.md verwenden. Für dieses Standardverhalten gilt eine wichtige Bedingung: Weder im Arbeitsverzeichnis noch in einem übergeordneten Verzeichnis darf eine CLAUDE.md, .claude/CLAUDE.md oder CLAUDE.local.md liegen. Benutzer- und Organisationsdateien verhindern diesen Rückgriff auf AGENTS.md nicht. So wird AGENTS.md geladen

Damit wird CLAUDE.local.md leicht zur Stolperfalle. Wer persönliche Projektnotizen ergänzt, kann dadurch verändern, welche gemeinsame Anweisungsdatei in der eigenen Sitzung geladen wird.

Wenn beide Dateien benötigt werden, lässt sich unter /config die Einstellung Project instructions auf claude-md-and-agents-md setzen. Alternativ kann eine benachbarte CLAUDE.md den Import @AGENTS.md enthalten. Dieser funktioniert auch, wenn das direkte Laden von AGENTS.md noch nicht unterstützt wird. Zwei getrennte Kopien der Teamregeln sollten vermieden werden. Unser Leitfaden zur Einrichtung von AGENTS.md erläutert diese Entscheidung ausführlicher.

Claude Code Memory: Auto Memory für erlerntes Projektwissen nutzen

Mit Auto Memory kann Claude nützliche Vorlieben, Korrekturen und Projektinformationen zwischen Gesprächen speichern. Claude entscheidet selbst, was aufbewahrt wird; in einer Sitzung kann auch nichts hinzukommen. In lokalen Sitzungen ist die Funktion standardmäßig aktiviert. Auto Memory

Die Dateien liegen standardmäßig unter ~/.claude/projects/<project>/memory/. Worktrees und Unterverzeichnisse desselben Repositorys teilen sich auf einem Rechner dieses Memory-Verzeichnis. Ein Worktree ist ein weiterer Checkout des Repositorys; wer dort auf einem Branch arbeitet, erhält also kein unabhängiges Notizbuch. Mit anderen Teammitgliedern, Rechnern oder Cloud-Umgebungen werden diese Dateien nicht automatisch geteilt. Speicherort

MEMORY.md dient als Index. Zu Beginn einer Sitzung lädt Claude daraus die ersten 200 Zeilen oder 25KB – je nachdem, welche Grenze zuerst erreicht wird. Ausführliche Themendateien werden bei Bedarf gelesen. Die Grenze betrifft den beim Start geladenen Indexauszug, nicht die insgesamt speicherbare Menge an Memory-Inhalten. So wird Auto Memory geladen

Der zentrale Einstieg ist /memory: Der Befehl zeigt Speicherorte an, öffnet Dateien im Editor, bietet Zugriff auf den Auto-Memory-Ordner und erlaubt das Ein- und Ausschalten von Auto Memory. Mit /context lässt sich prüfen, welche CLAUDE.md- und Regeldateien beim Start geladen wurden. Memory verwalten

Der gewünschte Ablageort sollte klar sein. „Merk dir, dass ich kürzere Übergaben bevorzuge“ zielt auf eine erlernte Notiz. „Ergänze unseren vorgeschriebenen Testbefehl in CLAUDE.md“ zielt auf eine gepflegte Anweisung. Eine Regel für das ganze Team sollte nicht von einer Notiz im Home-Verzeichnis eines einzelnen Entwicklers abhängen.

Gewöhnliche Subagenten erhalten dieses Notizbuch nicht automatisch. Das Auto Memory des Hauptgesprächs wird dort nicht geladen. Eine Ausnahme sind Forks, die das übergeordnete Gespräch übernehmen; außerdem können Subagenten ein eigenes konfiguriertes Memory besitzen. Unser Leitfaden zu Claude Code Subagenten hilft bei der Aufteilung von Aufgaben zwischen Agenten. Memory-Verhalten bei Subagenten

Wie lässt sich Auto Memory ausschalten?

Welche Einstellung passt, hängt vom gewünschten Geltungsbereich ab:

• Für den eigenen Benutzer: /memory öffnen und Auto Memory ausschalten. Der Schalter speichert autoMemoryEnabled in ~/.claude/settings.json.
• Für ein einzelnes Projekt: "autoMemoryEnabled": false in dessen Einstellungen setzen. Für eine gemeinsame Projekteinstellung dient .claude/settings.json, für eine lokale Abweichung .claude/settings.local.json.
• Beim Start über die Umgebung: CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 setzen.

Diese Möglichkeiten zum Deaktivieren und die Speicherorte der Einstellungen sind dokumentiert. Wird Auto Memory ausgeschaltet, bleibt der separate Anweisungsmechanismus über CLAUDE.md verfügbar. Sollen auch alte Notizen verschwinden, müssen die betreffenden Markdown-Dateien ausdrücklich geprüft und gelöscht werden.

Auto Memory einmal im Monat aufräumen

Eine kurze redaktionelle Prüfung zeigt, welches Wissen Claude in künftige Aufgaben mitnehmen soll. Der monatliche Rhythmus ist ein Vorschlag für das Team, keine Vorgabe des Produkts.

1. /memory öffnen und den Auto-Memory-Ordner durchsehen. Zuerst MEMORY.md lesen, dann den Verweisen zu den eigentlichen Notizen folgen.
2. Überholten Kontext löschen. Erledigte Fristen, verworfene Pläne und nicht mehr gültige Ausnahmen entfernen. Unsichere Notizen am aktuellen Projektstand prüfen.
3. Wiederholte Korrekturen zusammenführen. Eine zutreffende Aussage genügt; mehrere leicht abweichende Fassungen helfen nicht weiter.
4. Dauerhafte Teamentscheidungen in gemeinsame Regeln überführen. Konventionen, die alle brauchen, in die versionierte CLAUDE.md oder eine gezielt geltende Regel verschieben. Anschließend die überflüssige persönliche Notiz entfernen.
5. Den Index kürzen. In MEMORY.md bleiben kurze Verweise, Details stehen in Themendateien. Sowohl Zeilenzahl als auch Dateigröße in Bytes mit der Grenze für das Laden beim Start abgleichen.
6. Eine neue Sitzung ausprobieren. Die Liste der Anweisungen mit /context prüfen und bei der nächsten echten Aufgabe auf veraltete Empfehlungen achten.

Auto-Memory-Dateien sind bearbeitbare Markdown-Dateien. Die Aufbewahrungsregeln für Gesprächsprotokolle räumen sie nicht automatisch auf. Überholte Notizen muss weiterhin jemand entfernen. Bearbeitung und Aufbewahrung

Fünf Situationen, in denen sich die Einrichtung lohnt

Ein guter Ausgangspunkt sind wiederkehrende Korrekturen, die Reviews bereits ausbremsen. Die folgenden vorgeschlagenen Arbeitsabläufe sind nach ihrem voraussichtlichen Nutzen für ein kleines Produktteam geordnet.

Zwei kleine Angebote, die darauf aufbauen könnten

Das größte Potenzial hat eine Prüfung der Anweisungen im Repository. Ein kleines Team könnte für einen Review bezahlen, der Befehle überprüft, widersprüchliche Vorgaben aufspürt und eine kurze Anweisungsdatei samt gezielt geltender Regeln vorschlägt. Das kleinste sinnvolle Ergebnis wäre ein geprüfter Pull Request mit einer wiederverwendbaren Prüfcheckliste. DataForSEO schätzt 260 monatliche US-Suchanfragen nach „claude project instructions“. Diese breite Suchanfrage umfasst auch Interesse außerhalb von Claude Code. Sie zeigt, dass das Thema gesucht wird, beziffert aber keine potenziellen Käufer. Eine allgemeine Vorlage lässt sich leicht kopieren; der bezahlte Mehrwert müsste deshalb in der fachlichen Beurteilung des konkreten Repositorys liegen.

Ein lokaler Bericht zum Zustand der Memory-Dateien könnte Teams mit vielen aktiven Repositorys helfen. Eine erste Version könnte zu große Indexdateien, fehlende Verweisziele und möglicherweise veraltete Notizen markieren. Die vorgeschlagenen Änderungen würde anschließend der Entwickler prüfen. DataForSEO schätzt 1,300 monatliche US-Suchanfragen nach „claude code memory“. Das belegt Interesse am Problem, nicht die Nachfrage nach genau diesem Tool. Die entscheidende Einschränkung: Am Alter einer Datei lässt sich nicht erkennen, ob eine Entscheidung überholt ist. Inhaltliche Entscheidungen gehören weiterhin in die Hände der Person, die das Projekt kennt.

Beide Schätzungen stammen aus US-englischen Keyword-Overview-Ergebnissen, die am 11. Oktober 2026 über die DataForSEO-Rechercheintegration der Website abgerufen wurden. Die beschriebenen Produkte sind Vorschläge, keine integrierten Features von Claude Code. Für ein einzelnes kleines Repository reichen zunächst die Datei und die monatliche Prüfung, bevor eines dieser Angebote gekauft oder entwickelt wird.

Memory liefert Kontext, setzt aber keine Grenzen durch

Ein „Tu das niemals“ in CLAUDE.md macht eine Aktion nicht unmöglich. Dasselbe gilt für Auto Memory und schriftliche Vorgaben der Organisation. Claude kann eine vage Anweisung falsch verstehen oder auf widersprüchliche Regeln stoßen. Anthropics Hinweis

Wenn eine Aktion unabhängig von Claudes Entscheidung blockiert werden muss, eignet sich ein PreToolUse-Hook, der vor der Tool-Aktion ausgeführt wird. Ein Hinweis zu geschützten Dateien kann die Absicht des Teams erklären; für das tatsächliche Blockieren braucht es eine implementierte Kontrolle. Unser Leitfaden zur Konfiguration von Claude Code Hooks erklärt die Einrichtung.

Für den Umfang der Anweisungen zählt, dass jemand sie tatsächlich pflegen kann. Anthropic empfiehlt, einzelne CLAUDE.md-Dateien unter 200 Zeilen zu halten. Diese Empfehlung ist von der Grenze für den beim Start geladenen Teil der MEMORY.md zu unterscheiden. Es gibt keinen Grund, die Einstiegsdatei auf eine vermeintliche Sollgröße aufzublähen. Auch das Verschieben sämtlicher Inhalte in Imports macht das Laden nicht günstiger. Wirksame Anweisungen schreiben

Häufige Fragen aus kleinen Teams

Der nächste Schritt für Montag: die Korrekturen aus den letzten Sitzungen durchgehen, wiederkehrende Teamentscheidungen in einer geprüften CLAUDE.md bündeln und sie an einer kleinen Aufgabe erproben. Die monatliche Memory-Prüfung gehört in den Teamkalender.

Unterstützung beim Aufbau eines verlässlichen Entwicklungsablaufs auf Basis dieser Konventionen bietet unser Service für KI-Produktionssysteme.