# CLAUDE.md 2026 einrichten: Vorlage und 6 Regeln > Eine sofort verwendbare CLAUDE.md-Vorlage, 6 Regeln, damit die Datei aktuell bleibt, und eine Analyse einer im laufenden Betrieb verwendeten Datei aus einem aktiven Unternehmen. Enthält offizielle Zitate von Anthropic. Source: https://ailoot.ai/blog/de/claude-md-template/ Canonical: https://ailoot.ai/blog/de/claude-md-template/ Language: de Publisher: Ailoot (https://ailoot.ai/) Translation: guide-126 Revision: sha256-59158790dac94d01211705084ac6e1b557e4c9008e450a4a3fd590554fbd08d8
Das Wichtigste CLAUDE.md ist eine Textdatei im Stammverzeichnis eines Projekts, die Claude Code zu Beginn jeder Sitzung liest. Ohne sie fängt der Agent jedes Mal von vorn an: Du verbringst 5-10 Minuten damit zu sagen: „Hallo, ich arbeite an diesem Projekt, das ist meine Zielgruppe und so ist mein Stil.“ Für eine kompakte Ausgangsdatei sind 100-200 Zeilen ein sinnvolles Prüfziel, keine technische Obergrenze. Die Vorlage enthält 6 Abschnitte (Beschreibung, Tools, Struktur, Dateiverweise, Regeln und Sprache) und wird jedes Mal aktualisiert, wenn Claude einen Fehler macht. Dieser Artikel enthält eine sofort verwendbare Vorlage, 6 Regeln, eine Analyse einer im laufenden Betrieb verwendeten Datei aus einem aktiven Unternehmen und eine 12-Punkte-Prüfliste.
Materialien zum Vibe Coding: Tools, Fallstudien, Fehler. [Ailoot-Anleitungen](https://ailoot.ai/docs/).
[Ailoot-Anleitungen](https://ailoot.ai/docs/)
## Warum braucht man CLAUDE.md, und warum vergisst Claude ohne sie das Projekt?
Das Wichtigste In Claude Code beginnt jeder neue Chat mit leerem Kontext. CLAUDE.md ist die einzige Datei, die Claude automatisch in jede neue Sitzung lädt. Ohne sie arbeitet der Agent wie ein Praktikant am ersten Tag: Er weiß nichts über dein Unternehmen, deinen Stil oder deine Regeln. Mit ihr arbeitet er wie ein Mitarbeiter im zweiten Jahr.
Du öffnest Claude Code am Dienstag und erklärst: „Ich arbeite an diesem Projekt, das sind die Tools, tu das nicht.“ Es funktioniert. Am Donnerstag ist derselbe Chat schon beendet, also wiederholst du alles. Am Samstag wieder, am Montag noch einmal. So sieht die Arbeit mit einem Agenten ohne CLAUDE.md aus: Jedes neue Fenster ist ein unbeschriebenes Blatt in Gestalt eines Praktikanten, dem du immer wieder dasselbe sagen musst. Früher habe ich für jede Sitzung 5-10 Minuten mit diesem Warm-up verbracht. Die Prompts wurden lang, weil ich den gesamten Kontext manuell mitgeben musste. Und das Ergebnis blieb generisch: Der Agent kannte meine Zielgruppe, meine Wirtschaftlichkeit und meine Prinzipien nicht.
Hinweis Das ist kein Problem mit dem Gedächtnis des Modells. Es liegt an der Architektur. Claude Code beginnt absichtlich jede Sitzung mit einem sauberen Kontext; andernfalls würden verschiedene Projekte auf demselben Computer durcheinandergeraten. CLAUDE.md ist der Mechanismus, mit dem du dem Agenten mitteilst, was er laden soll.
Mit einer gepflegten CLAUDE.md fällt das Warm-up weg. Alle Regeln, die du früher in jedem Chat wiederholen musstest, stehen in einer Datei und erscheinen automatisch zu Beginn jeder Sitzung. Der Prompt wird kurz: „Mach X“ statt „Ich arbeite an Projekt Y, die Tools sind Z, tu A und B nicht, und denk übrigens auch an C.“ Dann hören auch die wiederholten Fehler auf. Jeder Fehler des Agenten ist ein Grund, CLAUDE.md um eine Zeile zu ergänzen. Nach einem Monat hast du eine lebendige „Projektverfassung“, und Claude tappt nicht mehr in dieselben bekannten Fallen. Und es gibt eine dritte Ebene: Der Agent schreibt nicht mehr ins Leere. Über `CLAUDE.md` verweise ich Claude auf Ordner mit Kontext: wo Informationen über Zielgruppe, Preise und Branding zu finden sind. Ohne diese Verweise schreibt der Agent „hochwertige Lösungen“, ohne meine Wirtschaftlichkeit zu kennen; dadurch werden sie abstrakt, formelhaft und „wie bei allen anderen“. ## Was ist CLAUDE.md, und in welcher Reihenfolge liest Claude sie?
Das Wichtigste CLAUDE.md ist eine Textdatei im Markdown-Format. Claude Code sucht gleichzeitig an vier Stellen danach: auf Systemebene, auf Benutzerebene, im Projektstammverzeichnis und in lokalen Notizen. Alle vier werden zu Beginn jeder Sitzung in den Kontext geladen. Beim Dateinamen wird zwischen Groß- und Kleinschreibung unterschieden: Verwende immer `CLAUDE.md` mit Großbuchstaben.
Anthropic beschreibt CLAUDE.md in der offiziellen Dokumentation so:
CLAUDE.md-Dateien sind Markdown-Dateien mit dauerhaften Anweisungen für dein Projekt, deinen persönlichen Workflow oder deine gesamte Organisation. Du schreibst sie als Klartext, und Claude liest sie zu Beginn jeder Sitzung.
— Anthropic, code.claude.com/docs/en/memory
Die vier Stellen, an denen Claude Code nach CLAUDE.md sucht, in aufsteigender Prioritätsreihenfolge: | Ebene | Speicherort | Zweck | |----|----|----| | **Organisation** | `/Library/Application Support/ClaudeCode/CLAUDE.md` auf Mac, `/etc/claude-code/CLAUDE.md` auf Linux | Regeln, die der Unternehmensadmin über MDM für das ganze Team bereitstellt. Als Einzelperson brauchst du das nicht. | | **Benutzer** | `~/.claude/CLAUDE.md` | Persönliche Regeln, die für alle deine Projekte gelten. „Antworte immer in der bevorzugten Sprache des Benutzers“, „Verwende keine Gedankenstriche.“ | | **Projekt** | `./CLAUDE.md` im Projektstammverzeichnis oder `./.claude/CLAUDE.md` | Regeln für ein bestimmtes Projekt: Tools, Ordnerstruktur, Geschäftslogik. Diese Datei wird in git eingecheckt. | | **Lokal** | `./CLAUDE.local.md` | Deine persönlichen Notizen zu diesem Projekt, die nicht in git gehören. Zum Beispiel vorübergehende Experimente oder persönliche Vorlieben, die das Team nicht kennen muss. | Alle vier Dateien werden gleichzeitig in den Kontext geladen. Wenn Regeln einander widersprechen, sagt Anthropic in der Dokumentation ausdrücklich, dass nicht bekannt ist, welche davon Vorrang hat; Claude könnte willkürlich eine davon auswählen. Deshalb ist es einfacher, alles Kritische in der Projektdatei CLAUDE.md zu belassen und Duplikate zu vermeiden.
Tipp Beim Dateinamen wird strikt zwischen Groß- und Kleinschreibung unterschieden. Verwende `CLAUDE.md` mit Großbuchstaben, dann liest Claude die Datei. `claude.md` oder `Claude.md` liest es nicht. Dasselbe gilt für `CLAUDE.local.md`. Das ist ein typischer Fehler von Claude-Code-Neulingen: Sie erstellen eine Datei, schreiben die Anweisungen hinein, fragen sich, warum es nicht funktioniert, und entdecken dann, dass der Dateiname kleingeschrieben ist.
Es gibt ein technisches Detail, über das fast niemand schreibt, das aber viel seltsames Verhalten erklärt.
Der Inhalt von CLAUDE.md wird nach dem System-Prompt als Benutzernachricht gesendet und ist kein Teil des System-Prompts. Claude liest ihn und versucht, ihn zu befolgen, aber die strikte Einhaltung ist nicht garantiert.
— Anthropic, code.claude.com/docs/en/memory
Mit anderen Worten: CLAUDE.md ist streng genommen kein „System-Prompt“. Es ist die erste Benutzernachricht, die Claude sieht. Ihre Regeln sind also starke Empfehlungen, keine Gesetze. Soll eine Regel durchgesetzt werden, nutze einen getesteten Hook für das abgedeckte Ereignis und Berechtigungen oder Umgebungsisolierung für weitergehende Zugriffsgrenzen. Dass ein Hook automatisch ausgeführt wird, macht seine Prüfungen nicht vollständig. Die Abgrenzung zwischen `hooks` und `CLAUDE.md` erkläre ich weiter unten. ## Wie schreibt man in 5 Minuten eine minimale CLAUDE.md (sofort verwendbare Vorlage)?
Das Wichtigste Kopiere die Vorlage, ersetze die Felder in eckigen Klammern und speichere sie im Projektstammverzeichnis als `CLAUDE.md`. Das reicht, damit Claude nicht mehr in jeder Sitzung von vorn anfängt. Du kannst sie nach und nach erweitern, indem du dich an die Regel hältst: „Nach jedem Fehler des Agenten eine Zeile ergänzen.“
Unten findest du eine Vorlage, die ich in Dutzenden meiner Projekte getestet habe. Sie hält die Datei bei etwa 80-120 Zeilen, entsprechend Anthropics Empfehlung, möglichst unter 200 Zeilen zu bleiben. Mit dieser Vorlage liefert der Agent die sinnvollsten Ergebnisse. ```markdown # [PROJECT NAME] - project navigation This document is the project map. Read it at the start of every session to understand where things are and how to work with them. ## What this project is **[NAME]** - [one sentence: what it is and who it’s for]. [1-2 sentences: what problem it solves and how]. Details are in `business/INDEX.md`. ## Reading order at the start of every session 1. `about-me/INDEX.md` - who I am and how I think 2. `business/INDEX.md` - what we do (product, audience, economics) 3. `CLAUDE.md` (this file) - repo rules, tools, navigation 4. Task area: the relevant file from `business/`, `plans/`, `mastery/` or the feature folder in the code Principle: layer 1 (about me) comes before layer 2 (business) for a reason. First, **who** is thinking, then **about what**. ## Repository structure [NAME]/ ├── CLAUDE.md ← this file, navigation ├── about-me/ ← digital projection of you (how you think, what you value) │ └── INDEX.md ├── business/ ← the business’s second brain │ ├── INDEX.md │ ├── audience/ ← customer profile │ ├── products/ ← products, prices │ ├── goals/ ← goals, metrics │ └── economics/ ← unit economics, revenue ├── plans/ ← technical plans (one plan = one feature) ├── retrospectives/ ← reflections after each session └── (project code) ### Where to find things | What you need | Where to look | |---|---| | Why we’re building the project, and for whom | `business/INDEX.md` | | Target customer, pains, desires | `business/audience/` | | Product, plans, prices | `business/products/` | | Goals and metrics | `business/goals/` | | Economics | `business/economics/` | | Technical plans | `plans/` | ## Tools [INSERT TOOLS - for example: Next.js 14, TypeScript, Tailwind CSS, Prisma + PostgreSQL]. ## Repo rules 1. Never hardcode dynamic data (prices, dates, figures) - get everything from files in `business/` and the LIVE marker. 2. Don’t publish without my explicit command. 3. Before `git push`, run `npm run build` and check that it builds without errors or warnings. 4. Add files by name with `git add`. Never use `git add .` or `git add -A`. 5. Don’t read `.env` in full. To check a variable, use `grep "^VAR=" .env`. ## Big features = a plan in `plans/` Any task lasting more than an hour must be written up as a plan in the `plans/` folder: 1. Filename: `YYYY-MM-DD-feature-name.md`. 2. Divide the plan into phases. Mark each phase `[ ]` or `[x]`. 3. At the end of the plan, add a summary: whether it was fully implemented and what remains. ## End-of-feature cycle After each feature is complete, go through these 5 steps: 1. Find errors → prove them with an example → fix them. 2. What was missed (edge cases, input validation, error handling). 3. Is this a real problem in our project? Check `business/` and `plans/`. 4. Take a fresh look: reread the diff as if you’re seeing it for the first time. 5. Security review. Especially: personal data and third-party materials. ## End-of-session reflection In `retrospectives/YYYY-MM-DD_short-name.md`, record: 1. What the task was. 2. How it was solved. 3. Whether it was solved - yes / no / partially. 4. What could have been done better. 5. What was learned about the user or project. ## Language Always respond in the user’s preferred language. Use hyphens only, not em dashes. ``` Damit Claude diese Vorlage automatisch für dein Projekt ausfüllt, gib ihm diesen Prompt. Claude liest den Kontext und füllt die Felder in eckigen Klammern aus:
Prompt: CLAUDE.md für mein Projekt ausfüllen ``` Create a CLAUDE.md file at the project root using this template: [INSERT THE ENTIRE TEMPLATE FROM ABOVE] Proceed as follows: Read about-me/INDEX.md and business/INDEX.md to understand the project context and me as the author. Fill in all the square-bracketed fields in the template based on what you find in those folders. If some information is missing, ask me clarifying questions one at a time, with 3-4 answer options. Versuche, die erstellte CLAUDE.md unter 200 Zeilen zu halten. Prüfe bei größerem Umfang Duplikate und lagere ausführliche Verfahren in verlinkte Dateien aus. Bewahre wesentliche Planungs-, Reflexions- und Repository-Regeln und teste sie an repräsentativen Aufgaben. Show me the final file and ask what should be revised. Always respond in the user’s preferred language. ```
Falls du noch keine Ordner `about-me/` und `business/` hast, ist das kein Problem. Claude wird Rückfragen stellen und anhand der verfügbaren Informationen eine minimale CLAUDE.md erstellen. Die Ordner kannst du später anlegen, sobald du weißt, was hineingehört. ## Welche 6 Regeln machen CLAUDE.md zu einem lebendigen Dokument?
Das Wichtigste Diese 6 Regeln sind eine Verdichtung der Erfahrungen aus Dutzenden Projekten. Sie machen aus CLAUDE.md „einer Datei, die wir erstellt und vergessen haben“ ein Arbeitsdokument, das Claude in jeder Sitzung zu Rate zieht.
### Regel 1. Unter 200 Zeilen bleiben Anthropic formuliert es in der offiziellen Dokumentation knapp:
Halte CLAUDE.md unter 200 Zeilen. Längere Dateien verbrauchen mehr Kontext und verringern die Befolgung der Anweisungen.
— Anthropic, code.claude.com/docs/en/memory
Eine lange CLAUDE.md arbeitet aus zwei Gründen gegen sich selbst. Erstens verbraucht sie Tokens. Eine 800 Zeilen lange Anweisungsdatei wird in jedes Fenster geladen und beansprucht in jeder Sitzung mehrere tausend Tokens deines Budgets. Bei einem Pro-Abonnement mit Tageslimit verringert das die verfügbare Sitzungszahl merklich. Zweitens beginnt das Modell, die Regeln zu ignorieren. Die Dokumentation empfiehlt, möglichst unter 200 Zeilen zu bleiben, um Kontextverbrauch zu verringern und die Befolgung der Anweisungen zu verbessern. Sie belegt keine scharfe Ausfallgrenze bei Zeile 201. Prüfe Relevanz, Widersprüche, geladenes Tokenvolumen und tatsächliche Aufgabenergebnisse, bevor du Inhalte auslagerst.
Warnung Wenn du bereits bei 300-500 Zeilen angekommen bist, keine Panik - verteile die Inhalte auf mehrere Ordner. Lege ausführliche Regeln zum Beispiel für das Designsystem in `business/assets/brand-guidelines.md` ab. CLAUDE.md kann dann mit einer Zeile darauf verweisen: „Wenn du an der UI arbeitest, sieh in `business/assets/brand-guidelines.md` nach.“ Das Prinzip der Verweise: CLAUDE.md ist ein Inhaltsverzeichnis, kein Buch.
### Regel 2. Jede Sitzung mit einer Rückschau beenden Schreibe in CLAUDE.md: „Halte am Ende jeder Sitzung fest, was du getan und gelernt hast, in `retrospectives/YYYY-MM-DD_*.md`.“ Sobald du diese Zeile hinzufügst, beendet Claude jede Sitzung von selbst mit einer Rückschau; du musst nicht darum bitten. Warum eine Rückschau: - Zwei Wochen später kannst du eine alte Rückschau öffnen und dich daran erinnern, warum du diesen Weg gewählt hast. - Wenn du nach einem Monat zum Projekt zurückkehrst, hast du eine fertige Übersicht über die jüngsten Entscheidungen. - Wenn du im Team arbeitest, kann ein Partner die Rückschau lesen und den aktuellen Stand in 2 Minuten ohne Telefonat verstehen. ### Regel 3. Nach jeder abgeschlossenen Aufgabe einen Commit erstellen In meiner CLAUDE.md steht: „Erstelle nach jeder abgeschlossenen Aufgabe einen git-Commit mit einer aussagekräftigen Nachricht.“ Claude beginnt dann von selbst, die Arbeit in atomare Commits aufzuteilen. Das bringt dir zwei Vorteile. Erstens kannst du bei einem Fehler einen einzelnen Vorgang rückgängig machen statt „alles, was ich heute getan habe“. Zweitens wird die Commit-Historie zu einem Arbeitsprotokoll, das zeigt, was sich in welcher Reihenfolge geändert hat. ### Regel 4. Immer den Ordner `business/` zu Rate ziehen Bei jeder Aufgabe, die Kunden, Produkte oder Texte betrifft, sollte der Agent zuerst `business/INDEX.md` und die dort verlinkte relevante Datei öffnen. In meiner CLAUDE.md steht ausdrücklich: „Wenn du an der UI oder an Texten arbeitest, sieh zuerst in `business/audience/avatar.md` und `business/assets/brand-guidelines.md` nach.“ Ohne diese Regel schreibt Claude Texte „im allgemeinen Stil einer hochwertigen Website“. Mit ihr sind die Texte in deinem Stil, für deine Kunden und ohne deine verbotenen Wörter. ### Regel 5. Nach jedem Fehler des Agenten eine Regel ergänzen Das ist die wichtigste Regel, damit CLAUDE.md aktuell bleibt. Beispiele aus meiner eigenen CLAUDE.md, die nach bestimmten Fehlern hinzugefügt wurden: - „Niemals fremde WIP-Dateien mit `git add .` committen - Dateien namentlich zum Staging hinzufügen.“ - „Vor dem Pushen nach `main` `git log origin/main..main --oneline` prüfen - falls die Ausgabe nicht leer ist, nicht pushen.“ - „Keine Werte erfinden - aus `.env` oder dem Code übernehmen. Besonders URLs, Benutzernamen und Tokens.“ Jede dieser Zeilen ist die Spur eines konkreten Vorfalls. Einmal hat ein Agent den unfertigen Branch eines Partners committet. Einmal habe ich die ungepushten Commits einer anderen Person aufgenommen. Einmal hat ein Agent eine URL erfunden, die es gar nicht gibt. Aus jedem Fehler wird eine Regel, und dieselbe selbst zugefügte Wunde entsteht nicht noch einmal. ### Regel 6. Sicherheitsregeln in `.claude/settings.json` statt in CLAUDE.md ablegen In CLAUDE.md kannst du schreiben: „Fass `.env` nicht an“, aber das ist eine Bitte; Claude kann sie missachten, weil CLAUDE.md als Benutzernachricht und nicht als Gesetz geladen wird. Für kritische Sicherheit verwende `.claude/settings.json`, wo sich bestimmte Befehle strikt blockieren lassen. Die Sperrliste, die ich jedem neuen Projekt hinzufüge: - `rm -rf` (rekursives Löschen beliebiger Dateien). - `.env` vollständig einlesen (`Read .env`). - `export` und `curl` im selben Befehl (ein Muster zum Abfluss von Geheimnissen nach außen). - `git push --force` ohne ausdrückliche Genehmigung.
Warnung Der Unterschied ist einfach: Eine Regel in CLAUDE.md ist ein Ratschlag, gegen den der Agent verstoßen kann. Eine passende deny-Regel blockiert die abgedeckte Aktion im jeweils geltenden Berechtigungsablauf. Sie belegt keinen Schutz gegen jeden gleichwertigen Befehl, andere Tools oder einen anderen Berechtigungsmodus. Lege kritische Sicherheitsregeln in `settings.json` ab und alles andere in CLAUDE.md.
Weitere Anleitungen findest du bei [Ailoot](https://ailoot.ai/docs/).
[Ailoot-Anleitungen](https://ailoot.ai/docs/)
## Wie ist CLAUDE.md in einem aktiven Unternehmen strukturiert (Anatomie einer 280 Zeilen langen Datei)?
Das Wichtigste Ich analysiere die Struktur einer CLAUDE.md-Datei, die bei einem laufenden Online-Dienst verwendet wird. Die Datei ist etwa 280 Zeilen lang und hat 11 Abschnitte. Ich zeige, was jeder Abschnitt enthält und warum. Den tatsächlichen Text veröffentliche ich nicht; er enthält betriebliche Details. Das Gerüst lässt sich aber auf jedes Unternehmen übertragen.
Die meisten CLAUDE.md-Beispiele im Internet sind technische Vorlagen für Entwickler: „Verwende TypeScript“, „Schreibe keine Tests, die länger als 50 Zeilen sind.“ Für Unternehmer ist eine solche CLAUDE.md nutzlos - sie deckt die geschäftliche Seite nicht ab. Unten steht die Struktur meiner verwendeten CLAUDE.md. Ich habe die konkreten Regeln und Pfade entfernt, weil sie meine internen Abläufe widerspiegeln. Die Struktur und Logik der Abschnitte lassen sich aber auf jedes Projekt übertragen: Ergänze deine eigenen Gegebenheiten, und du erhältst eine funktionierende Datei. **1. Kurze Projektbeschreibung (15 Zeilen).** Was wir tun, wer die Zielgruppe ist und welche Produkte wir anbieten. Keine Zusammenfassung der Marketing-Website, sondern eine Übersicht für den Agenten, damit er versteht, „wohin die Reise geht“. **2. Über mich (10 Zeilen).** Ein Verweis auf den Ordner `about-me/` - eine digitale Projektion meiner Denkweise. Ton, Werte, Prinzipien, verbotene Wörter. Wenn Claude einen Text „in meinem Namen“ schreibt, liest es zuerst diesen Ordner, damit die Stimme passt. **3. Repository-Struktur (20 Zeilen).** Ein Verzeichnisbaum mit Kommentaren: wo der Code liegt, wo der Geschäftskontext zu finden ist, wo Pläne und Rückblicke abgelegt werden. Ohne diese Übersicht sucht Claude jedes Mal blind nach Dateien. **4. Tabelle „Wo finde ich was?“ (25 Zeilen).** Verweise von „Frage → Datei“. Bei einer Immobilienagentur könnte dort zum Beispiel stehen: „Benötige Hypothekenkonditionen → `business/products/mortgage.md`“ oder „Benötige den Tonfall für Beiträge → `business/assets/voice.md`“. Ersetze die Beispiele durch deine eigenen Dateien. Diese Tabelle ist das Herzstück von CLAUDE.md. Ohne sie rät der Agent, welche Datei die Antwort enthält. Mit ihr geht er direkt zur Quelle. **5. Zentrale Projektprinzipien (40 Zeilen, 10-15 Punkte).** Dieser Abschnitt wächst nach und nach und kostet am meisten Arbeit. Jeder Punkt dokumentiert einen konkreten Fehler. Für einen Online-Shop könnten die Regeln zum Beispiel lauten: „Preise und Lieferzeiten niemals fest codieren“, „Ein Produkt nur nach ausdrücklicher Anweisung veröffentlichen“ und „Vor der Veröffentlichung eines Produktangebots den Stil anhand des Markenglossars prüfen.“ Dieser Abschnitt ist die „Projektverfassung“. **6. Operative Planung (20 Zeilen).** Eine Auslösertabelle, die „Äußerung des Benutzers → Aktion“ zuordnet. Zum Beispiel: „Wenn ich sage ‚Plane die Woche‘, öffne `ops/monthly.md` und erstelle die Datei für die Woche.“ So wird Claude zu einem Betriebsassistenten, der den Kontext von Anweisungen versteht. **7. Tools (5 Zeilen).** Technologien. Kurz und ohne Ausschmückungen. **8. Veröffentlichung (15 Zeilen).** Schritt-für-Schritt-Verfahren, um Änderungen in der Produktion zu veröffentlichen: welche Befehle in welcher Reihenfolge auszuführen und was zu überprüfen ist. Früher musste ich es jedes Mal erklären. Jetzt weiß Claude Bescheid. **9-12. Sicherheit (35 Zeilen).** Vier separate Unterabschnitte: Regeln für die Arbeit mit `.env`, Zugriff auf die Produktionsdatenbank, sichere Befehle für Demos (Bildschirmaufnahmen, Streams, Screenshots, damit Tokens nicht versehentlich offengelegt werden) und Regeln für das Rotieren von Geheimnissen. **13. Der Ordner `plans/` (10 Zeilen).** Der Planstandard: Dateiname, Phasenstruktur und Inhalt des Zusammenfassungsblocks. **14. Der Ordner `retrospectives/` (5 Zeilen).** Der Rückblickstandard: Vorlage, Dateiname und Inhalt. **15. Live-Datenbankdaten (15 Zeilen).** Eine Regel zur Kennzeichnung „aktueller Daten“: Wenn eine Datei vorschreibt, dass Zahlen aktuell sein müssen, ruft der Agent sie aus der Quelle ab, statt veraltete Werte zu verwenden. So sinkt das Risiko, dass Claude die Zahlen von gestern verwendet. **16. Sprache (3 Zeilen).** „Antworte immer in der bevorzugten Sprache des Benutzers. Verwende nur Bindestriche, keine Gedankenstriche.“ Insgesamt etwa 280 Zeilen. Das überschreitet das Kompaktheitsziel, macht die Datei aber nicht ungültig. In diesem Beispiel blieb sie nützlich. Ob sie so bleiben sollte, muss anhand des gemessenen Kontextverbrauchs und repräsentativer Aufgaben entschieden werden. Tabellen sind nicht automatisch tokensparender als Fließtext.
Tipp Die Struktur, die ich über ein Jahr Arbeit entwickelt habe, ist kein Dogma. Das Gerüst sieht so aus: Beschreibung (1-2 Abschnitte), Struktur und Verweise (2-3 Abschnitte), Regeln/Prinzipien (1 großer Abschnitt), operative Abläufe (2-3 auf dein Unternehmen zugeschnittene Abschnitte) und Kleinigkeiten (Sprache, Kontakte). Fülle es mit Einzelheiten aus deinem Unternehmen. Die wichtigste Regel: Jeder Abschnitt sollte die Frage beantworten: „Würde Claude ohne diese Information einen Fehler machen?“ Falls nicht, streiche ihn.
## Was macht der Befehl `/init`, und warum reicht er nicht aus?
Das Wichtigste Der Befehl `/init` in Claude Code erstellt automatisch eine einfache CLAUDE.md, indem er das Projekt scannt und Tools sowie Build-Befehle auflistet. Das ist ein guter Ausgangspunkt, aber ohne Geschäftskontext und Prinzipien bleibt die Datei technisch und allgemein. Nutze `/init` als ersten Schritt und ergänze sie anschließend von Hand.
Anthropic beschreibt den Befehl in der Dokumentation so:
Führe /init aus, um automatisch eine erste CLAUDE.md zu erstellen. Claude analysiert deinen Code und legt eine Datei mit Build-Befehlen, Testanweisungen und erkannten Projektkonventionen an.
— Anthropic, code.claude.com/docs/en/memory
Was `/init` gut macht: - Erkennt die Tools anhand von `package.json`, `Cargo.toml` und `pyproject.toml`. - Listet Build- und Testbefehle auf. - Übernimmt Konventionen aus vorhandenen Dateien (`.eslintrc`, `.prettierrc`). - Erkennt vorhandene Cursor-Regeln (`.cursorrules`, `.cursor/rules/`) und Copilot-Regeln und übernimmt relevante Teile. Im Modus `CLAUDE_CODE_NEW_INIT=1` erkennt es `AGENTS.md`. Was `/init` nicht macht: - Es weiß nicht, wer deine Kunden sind. - Es kennt deine verbotenen Wörter für Texte nicht. - Es ergänzt keine Regeln zu Fehlern des Agenten (weil es noch keine gegeben hat). - Es erstellt keine Tabelle „Wo finde ich was?“ für deine Geschäftsstruktur. Der richtige Ablauf sieht also so aus: 1. ### `/init` in Claude Code ausführen Du erhältst eine erste CLAUDE.md mit 30-50 Zeilen sowie Tools und Befehlen. Das ist das technische Fundament. 2. ### Die Vorlage aus diesem Artikel darauf aufbauen Verwende den Abschnitt „Eine minimale CLAUDE.md in 5 Minuten“. Ergänze Abschnitte zu Navigation, Verweisen und Prinzipien. 3. ### Die Felder in eckigen Klammern ausfüllen Gib Claude den Prompt: „Lies mein Projekt und fülle die Vorlage aus.“ Falls die Ordner `business/` und `about-me/` noch nicht existieren, wird Claude Rückfragen stellen. 4. ### Einen Belastungstest durchführen Sag Claude: „Lies meine CLAUDE.md und finde 10 Unklarheiten, die dazu führen könnten, dass du sie als Agent missverstehst.“ Du erhältst eine Liste mit möglichen Verbesserungen. 5. ### Danach mit der Datei arbeiten Ergänze nach jedem Fehler des Agenten eine Zeile. Nach einem Monat hast du eine auf dein Unternehmen zugeschnittene, lebendige CLAUDE.md. Prompt für Schritt vier:
Prompt: CLAUDE.md einem Belastungstest unterziehen ``` I have a CLAUDE.md. Tomorrow I’ll be building a feature based on it. Your task is to stress-test it. Find 10 reasons we could potentially fail: where CLAUDE.md is ambiguous and you, as an agent, might misunderstand it where there are gaps that would force you to make things up where rules contradict one another where I overestimate how much can be done in one day where I underestimate things (this is even worse) Don’t hold back. Criticize it harshly. I want to find these issues now, not in production. At the end, give me a list of specific changes: what to change and how, so these problems don’t happen. ```
## CLAUDE.md vs. AGENTS.md vs. MEMORY.md: Wer liest was im Jahr 2026?
Das Wichtigste Drei ähnliche Dateien werden oft verwechselt. CLAUDE.md enthält Projektregeln, die du selbst schreibst und die Claude Code in jeder Sitzung liest. AGENTS.md ist ein universeller Standard für andere Agenten (Codex, Cursor, Copilot); seit September 2026 liest Claude Code sie ebenfalls, wenn das Projekt keine CLAUDE.md hat. MEMORY.md enthält automatische Notizen, die Claude über deine Gewohnheiten für sich selbst schreibt. Alle drei können gleichzeitig existieren, ohne einander zu widersprechen.
| Datei | Wer schreibt sie? | Wer liest sie? | Wann wird sie geladen? | |----|----|----|----| | **CLAUDE.md** | Du, manuell | Claude Code (nativ) | Zu Beginn jeder Sitzung | | **AGENTS.md** | Du, manuell | Codex CLI, Cursor, GitHub Copilot CLI, Gemini CLI und seit Version 2.1.277 auch Claude Code, falls das Projekt keine CLAUDE.md hat | Zu Beginn jeder Sitzung | | **MEMORY.md** | Claude Code selbst | Claude Code (nativ) | Zu Beginn jeder Sitzung, die ersten 200 Zeilen (oder 25 KB, je nachdem, was kleiner ist) | Die wichtigste Frage, die Neulinge verwirrt, lautet: **Liest Claude Code `AGENTS.md`?** Vor September 2026 lautete die Antwort „nein“: In Anthropics Dokumentation wurde empfohlen, eine CLAUDE.md zu erstellen, die AGENTS.md importiert. Seit Version 2.1.277 (veröffentlicht am 18. September 2026) liest Claude Code AGENTS.md selbst, aber nur, wenn sich im Arbeitsordner oder darüber keine CLAUDE.md, `.claude/CLAUDE.md` oder `CLAUDE.local.md` befindet.

Claude Code kann AGENTS.md als Projektanweisungen lesen. Ein Repository, das bereits für andere Agenten eingerichtet ist, funktioniert daher ohne CLAUDE.md, Import oder Konfiguration.

— Anthropic, https://code.claude.com/docs/en/memory#agents-md
Wenn das Projekt eine CLAUDE.md hat, liest Claude Code standardmäßig nur diese und überspringt AGENTS.md. Du kannst das unter Project instructions in `/config` ändern: Die Einstellung `claude-md-and-agents-md` etwa veranlasst es, beide Dateien zu lesen. Eine andere Methode funktioniert in jeder Version: Füge in CLAUDE.md einen Import ein: ```markdown @AGENTS.md ## Claude Code Zusätzliche Regeln für Claude Code, die andere Agenten nicht benötigen. ``` Die Syntax `@filename` importiert eine andere Datei. Claude liest sie und lädt sie zusammen mit CLAUDE.md in den Kontext. Der Import führt nicht dazu, dass die Datei zweimal gelesen wird, selbst wenn Claude Code AGENTS.md selbst lesen kann. **Wann du AGENTS.md brauchst.** Wenn du parallel mit Claude Code und Codex CLI, Cursor oder Copilot arbeitest, erstelle AGENTS.md als zentrale Quelle, setze `@AGENTS.md` in CLAUDE.md und ergänze obenauf alle Claude-spezifischen Regeln. Wenn es keine solchen Regeln gibt, brauchst du keine CLAUDE.md zu erstellen: Seit Version 2.1.277 liest Claude Code AGENTS.md selbst. Wenn du ausschließlich mit Claude Code arbeitest, brauchst du keine AGENTS.md; verwende nur eine CLAUDE.md. Alle Optionen Schritt für Schritt findest du in [der Anleitung zur gemeinsamen Verwendung von AGENTS.md und CLAUDE.md in einem Projekt](https://ailoot.ai/blog/de/agents-md-claude-md-one-instruction-file/). **Was ist MEMORY.md?** Seit einem neueren Update legt Claude Code automatisch Notizen über dich unter `~/.claude/projects//memory/MEMORY.md` ab. Darin stehen Gesprächsgewohnheiten („Der Benutzer bevorzugt kurze Antworten“), wiederkehrende Formulierungen („Emojis im Code verboten“) und Verhaltensbeobachtungen („arbeitet mit macOS, verwendet zsh“). Das ist ein separates Gedächtnissystem und nicht CLAUDE.md. Du schreibst die Datei nicht von Hand; Claude erstellt sie anhand eurer Gespräche. Wenn MEMORY.md etwas enthält, das zu einer Regel werden sollte, verschiebe es nach CLAUDE.md. Wenn etwas unnötig oder falsch ist, kannst du es manuell löschen; es ist eine Textdatei.
Hinweis Um zu sehen, was zu Beginn einer Sitzung geladen wird, gib in Claude Code `/memory` ein. Der Befehl zeigt den Inhalt von CLAUDE.md, MEMORY.md und anderen geladenen Dateien. Das hilft bei seltsamem Verhalten von Claude: Öffne `/memory` und suche nach der Regel, die dafür verantwortlich sein könnte.
## Welcher Umfang ist für CLAUDE.md sinnvoll, und wie prüfst du eine lange Datei?
Das Wichtigste Längere Anweisungsdateien benötigen mehr Kontext und können relevante Regeln schwerer befolgbar machen, besonders bei Duplikaten und Widersprüchen. Anthropic empfiehlt, möglichst unter 200 Zeilen zu bleiben. Das ist weder eine technische Obergrenze noch eine allgemeingültige Vorhersage, wie viele Regeln der Agent befolgt.
In jedem Claude-Code-Fenster werden mehrere Ebenen in den Kontext geladen: Anthropics System-Prompt (geschätzt mehrere Zehntausend Tokens), deine CLAUDE.md, mit `@` importierte Dateien, MEMORY.md, der aktuelle Chatverlauf und der Inhalt der Dateien, die Claude öffnet. All das muss in den Kontext des Modells passen (200K Tokens für Sonnet, 1M für Opus). Je umfangreicher CLAUDE.md wird, desto weniger Platz bleibt für die aktuelle Arbeit. Eine Datei mit 1.000 Zeilen umfasst etwa 8.000 Tokens, die in jeder Sitzung erneut geladen werden. Bei einem Pro-Abonnement (nach meiner Erfahrung etwa 10-12 „intensive“ Prompts pro Tag) sinkt dadurch deine Kapazität um ein Viertel. Kosten sind nur ein Gesichtspunkt. Lange, irrelevante oder widersprüchliche Anweisungen können die Befolgung erschweren; eine allgemeingültige Zahl zuverlässig befolgter Regeln gibt es nicht. Teste repräsentative Aufgaben, die wichtige Regeln auslösen, halte Fehler fest und vergleiche das Verhalten nach einer gezielten Überarbeitung.
Überladene CLAUDE.md-Dateien führen dazu, dass Claude deine eigentlichen Anweisungen ignoriert.
— Anthropic, code.claude.com/docs/en/best-practices
Als Faustregel für die Größe gilt: - **80-120 Zeilen** – ein praktischer Ausgangsbereich für eine knappe Projektübersicht, keine garantierte Befolgungsquote. - **150-200 Zeilen** – ein sinnvoller Anlass, Relevanz zu prüfen und ausführliche Verfahren zu verlinken. - **200-300 Zeilen** – prüfe Tokenvolumen, Duplikate und Aufgabenergebnisse; das oben beschriebene 280-Zeilen-Beispiel kann weiterhin gut funktionieren. - **400+ Zeilen** – ein deutlicher Anlass für eine gezielte Prüfung, kein Beweis für Unbrauchbarkeit. Bewahre wesentliche Grenzen und lagere Details erst nach Prüfung der Verweise und Regeln aus. Die Zeilenzahl allein belegt weder Erfolg noch Scheitern. Wiederhole nach einer Änderung dieselben repräsentativen Aufgaben und prüfe wichtige Regeln, statt eine erfundene Befolgungsquote anzusetzen.
Warnung Wenn deine CLAUDE.md zu groß geworden ist, überarbeite sie nicht von Hand. Gib Claude diesen Prompt: „Lies CLAUDE.md und bewerte jede Zeile anhand der Frage: ‚Würde der Agent einen Fehler machen, wenn diese Zeile entfernt würde?‘ Gib eine Liste der Zeilen zurück, die sich ohne Nachteile entfernen lassen, samt Begründung.“ Claude entfernt dann, was objektiv nicht funktioniert.
Anthropic nennt in der Dokumentation einen direkten Test:
Frage bei jeder Zeile: „Wird Claude Fehler machen, wenn ich diese Zeile entferne?“ Wenn nicht, lösche sie.
— Anthropic, code.claude.com/docs/en/best-practices
Wende das auf jede Zeile an. Wenn die Antwort lautet „Es würde trotzdem richtig liegen“, entferne die Zeile. CLAUDE.md ist nicht der richtige Ort für Dokumentation, Entscheidungshistorie oder Philosophie. Sie enthält nur Regeln, die der Agent braucht, um Fehler zu vermeiden. ## Welche 7 Fehler machen CLAUDE.md nutzlos?
Das Wichtigste Das sind sieben häufige Fehler, die ich regelmäßig in den CLAUDE.md-Dateien anderer sehe. Jeder ist ein Grund, die Datei systematisch aufzuräumen. Meist sind es Varianten desselben Problems: CLAUDE.md soll ein universelles „Projektdokument“ sein, statt ein Arbeitswerkzeug für den Agenten zu bleiben.
### Fehler 1. „Sei ein guter Ingenieur“ Der häufigste Fehler. Menschen schreiben allgemeine Wünsche in CLAUDE.md: „Schreibe sauberen Code“, „Verwende Best Practices“, „Denk wie ein Senior Engineer.“ Diese Worte bedeuten nichts. Claude schreibt im allgemeinen Sinn bereits „sauberen Code“. Solche Zeilen belegen Kontext, ohne eine Entscheidung zu beeinflussen. Ersetze „Schreibe sauberen Code“ durch „Verwende 2 Leerzeichen für die Einrückung“, „Verwende in TypeScript kein `any`“ oder „Funktionen dürfen höchstens 30 Zeilen lang sein“. Konkret und überprüfbar. ### Fehler 2. Wiederholen, was Claude bereits weiß Beschreibungen üblicher Sprachkonventionen („In JavaScript sind Funktionen Objekte erster Klasse“, „TypeScript ist statisch typisiert“). Erklärungen zur Funktionsweise von npm, git oder docker. Claude hat all das während des Trainings gelernt. Es in CLAUDE.md zu wiederholen, bringt nichts und beansprucht nur Kontext. ### Fehler 3. Lange Schritt-für-Schritt-Anweisungen in CLAUDE.md Lange Anweisungen dazu, „wie man das Projekt bereitstellt“, „wie man eine Datenbankmigration schreibt“ oder „wie man eine neue Komponente einrichtet“. Dutzende Zeilen mit Einzelschritten. Das ist nicht der richtige Ort für lange Schritt-für-Schritt-Anweisungen. Hier gehören einzeilige Regeln hin. Lege ausführliche Anweisungen in `skills/` ab (einem separaten Claude-Code-Mechanismus, der bei Bedarf geladen wird) oder in `docs/`. Verwende in CLAUDE.md einen einzeiligen Verweis: „Öffne beim Erstellen einer neuen Migration `docs/migrations.md`.“ ### Fehler 4. Regeln, die bereits von einem automatischen Code-Analyzer geprüft werden „Verwende Semikolons“, „Lass keine ungenutzten Imports zurück“, „Verwende kein `var`.“ ESLint, Prettier und Biome erkennen all das - sie sind Linter (automatische Code-Prüfwerkzeuge). Ein Linter ist deterministisch: Er wird ausgeführt, findet einen Fehler und behebt ihn. Eine Regel in CLAUDE.md ist probabilistisch; der Agent kann sie vergessen. Es gibt keinen Grund, sie zu duplizieren - es ist einfacher, den Linter zu konfigurieren. ### Fehler 5. Geheimnisse in CLAUDE.md Ich habe Passwörter für Testkonten, API-Tokens für Sandboxen und Links zu authentifizierten Admin-Panels gesehen. All das stand in einer Datei, die in git eingecheckt und in den Kontext des Anthropic-Modells geladen wurde. Auf keinen Fall. Geheimnisse gehören in `.env`, das in `.gitignore` eingetragen ist. In CLAUDE.md sollte höchstens stehen: „Lies `.env` nicht vollständig ein; verwende `grep` für eine bestimmte Variable.“ ### Fehler 6. Eine Ablage mit 500+ Zeilen, die seit sechs Monaten nicht aufgeräumt wurde CLAUDE.md ist gewachsen, dupliziert die Hälfte von `docs/`, widerspricht sich an mehreren Stellen, und niemand weiß mehr, was darin steht. Der Agent beginnt, das meiste zu ignorieren. Das Team beschwert sich, dass „Claude Anweisungen nicht befolgt“, und ergänzt weitere Regeln, wodurch alles schlimmer wird. Anzeichen für eine vernachlässigte CLAUDE.md: mehr als 300 Zeilen, wiederholte Regeln in verschiedenen Abschnitten, veraltete Verweise auf nicht mehr vorhandene Dateien und „historische“ Notizen wie „2024 haben wir beschlossen, es so zu machen, dann haben wir es uns anders überlegt“. Die Lösung: Bitte Claude alle zwei Wochen, die Datei anhand von Anthropics Test zu prüfen: „Würde der Agent einen Fehler machen, wenn diese Zeile entfernt würde?“ Lösche alles, worauf die Antwort „nein“ lautet. ### Fehler 7. CLAUDE.md erstellen und vergessen Das ist das Gegenteil des vorherigen Fehlers. Die Datei wurde einmal vor zwei Monaten erstellt und seitdem nicht mehr angerührt. In der Zwischenzeit haben sich die Tools geändert, es kamen neue Ordner hinzu und neue Fehler der Agenten traten auf. CLAUDE.md weiß davon nichts, weil niemand sie aktualisiert hat. Ein deutliches Anzeichen: Du wiederholst in jeder Sitzung dieselbe Anweisung. „Mach X nicht“, „Fass Y nicht an“, „Denk an Z.“ Wenn du etwas mehr als zweimal wiederholt hast, gehört die Regel in CLAUDE.md und nicht in deinen Kopf.
[Ailoot-Anleitungen](https://ailoot.ai/docs/)
## Wie machst du CLAUDE.md mit einer Regel „Am Sitzungsende aktualisieren“ selbstlernend?
Das Wichtigste Die wichtigste Technik, mit der CLAUDE.md für mich vom Dokument zum lebendigen Werkzeug wurde, war eine einzige Ergänzung: „Prüfe am Ende jeder Sitzung, ob du etwas Neues über den Benutzer oder die Zusammenarbeit mit ihm gelernt hast, das nicht in CLAUDE.md steht, und ergänze eine Zeile.“ Innerhalb von zwei Monaten sammelten sich in der Datei individuelle Regeln an, ohne dass es dafür einen separaten Prozess brauchte.
Meine CLAUDE.md hat einen kurzen Abschnitt: ```markdown ## Self-learning At the end of every session, check: - Have I learned anything new about the user or how to work with them? - Did I break any rule that should now be recorded? If so, create or update a file in `about-me/feedback/` in this format: Rule (one-line rule) → Why (why it was added) → How to apply (when it applies). I don’t write the rules by hand - I say, “not like that, because this is how,” and you put it into a file. ``` Nachdem dieser Abschnitt in CLAUDE.md aufgenommen wurde, begann Claude am Ende jeder Sitzung zu fragen: „Gab es etwas Neues, das es wert ist, festzuhalten?“ Wenn ja, schlug es einen Entwurf für eine Regel vor, ich präzisierte ihn, und eine Datei wurde erstellt. Nach zwei Monaten auf diese Weise hatte ich mehr als zwei Dutzend Dateien unter `about-me/feedback/` - Regeln, die aus konkreten Fehlern gelernt wurden. Jede Datei ist eine Seite im Format Regel → Warum → Wie. Der Ordner wurde zu einem „zweiten Gedächtnis“, das meine persönlichen Vorlieben und Tabus festhält. Jeder Fehler wird nicht wiederholt, weil daraus eine Regel wird; die Regeln sammeln sich an und verstärken einander. Nach sechs Monaten kennt Claude mein Projekt besser, als ich mich nach einer einmonatigen Pause daran erinnere. ## Wie ergänzt man rechtliche Regeln, Marketing und Abläufe in CLAUDE.md?
Das Wichtigste Technische Anleitungen in CLAUDE.md sind nur die halbe Sache. Die andere Hälfte sind Geschäftsregeln: verbotene Formulierungen aufgrund rechtlicher Anforderungen, Formatvorgaben für externe Markentexte und betriebliche Gewohnheiten für die wöchentliche Teamarbeit. Deckt CLAUDE.md beide Seiten ab, wird Claude nicht nur zum Programmierer, sondern auch zum Redakteur und Betriebsassistenten.
Für die meisten Teams ist CLAUDE.md ein rein technisches Dokument: Tools, Build-Befehle, Programmierkonventionen. Das ist nützlich, aber es macht nur ein Drittel des Werts aus. Wenn ein Unternehmer CLAUDE.md pflegt, lohnt es sich, geschäftliche Abschnitte hinzuzufügen. Drei sind besonders wichtig: ### Rechtliche Regeln (für regulierte Märkte) Wenn du Texte in einer regulierten Branche veröffentlichst (Finanzen, Medizin, Arzneimittelwerbung, Kinderprodukte), haben verbotene Wörter rechtliches Gewicht und gehören als ausdrückliche Regeln in CLAUDE.md. Nicht in den Kopf einer Person, nicht auf einen Screenshot des Editors - sondern in eine Datei, die der Agent in jeder Sitzung sieht. Beispiel für ein Fintech-Projekt ohne Banklizenz: Redaktioneller Hinweis: Das folgende Beispiel zeigt das Format einer internen Regel für ein bestimmtes Projekt. Es ist keine allgemeine Erlaubnis, die aufgeführten Begriffe zu verwenden: Ob eine Aussage zulässig ist, hängt vom geltenden Recht und dem Status des Unternehmens ab. > 🚨 KRITISCH - Finanzformulierungen sind verboten. Verwende in Materialien für Kunden nicht: „Einlage“, „garantierte Rendite“ oder „Anlageprodukt“. Verwende stattdessen: „Sparkonto“, „erwartete Rendite“ und „variabel verzinsliches Produkt“. Grund sind die für dieses Projekt geltenden rechtlichen Anforderungen an die Werbung für Finanzdienstleistungen. Dieser Block in CLAUDE.md bewirkt etwas Einfaches: Jedes Mal, wenn du Claude bittest, Kundentexte zu schreiben, prüft der Agent sie anhand dieser Verbote. Ohne die Regel tauchen verbotene Wörter in jeder dritten Kampagne auf. Mit ihr vergisst du, dass es sie gibt. Dasselbe Vorgehen funktioniert für: - Medizinische Projekte (keine Behauptungen, etwas „behandle“ oder „heile“). - Arzneimittelwerbung (keine Behauptungen wie „am wirksamsten“; vorgeschriebene Warnhinweise). - Jede regulierte Branche mit eigenen Werbevorschriften. ### Marketingstil und Textformat Wenn du regelmäßig Texte veröffentlichst (soziale Medien, Newsletter, Websites), lohnt es sich, das Format in einem Absatz in CLAUDE.md zu dokumentieren. Hier ein Beispiel, was ein Influencer oder eine Agentur mit einem Messaging-Kanal schreiben könnte: > Verwende beim Schreiben von Kanalbeiträgen `style/posts.md` als Referenz. Nutze die zulässigen Formatierungsmarker des Kanals und vermeide „gefährliche“ Sonderzeichen. Beende den Beitrag mit einem CTA mit UTM-Tag nach diesem Schema: `utm_source=&utm_medium=&utm_campaign=`. Früher schrieb Claude Beiträge „im allgemeinen Stil einer Marketing-Website“. Jetzt hält es sich an dein Format, verwendet deine UTMs und verrät nicht, dass der Text von einer KI stammt. ### Betriebliche Gewohnheiten Auslösertabellen. Wenn du eine bestimmte Formulierung verwendest, weiß der Agent, welche Dateien er öffnen und welche Aktionen er ausführen soll. Hier ein Beispiel für ein Team, das wochenweise plant: > „Plane die Woche“ → öffne `ops/monthly.md`, erstelle im selben Ordner `YYYY-WNN.md` und verschiebe die Aufgaben aus `ops/backlog.md` unter die passenden Wochentage. „Was steht im Backlog?“ → lies `ops/backlog.md` und zeige den Inhalt als Liste. „Schließe die Woche ab“ → fülle den Abschnitt „Wochenzusammenfassung“ in der Datei der aktuellen Woche aus. Mit solchen Tabellen wird Claude vom „Helfer, der Code schreibt“ zum „Mitarbeiter“, der deine Geschäftsabläufe kennt. Jeden Montag sage ich: „Lass uns die Woche planen“, und Claude öffnet die richtigen Dateien, liest die Monatsziele und schlägt vor, wie die Aufgaben aufgeteilt werden können.
Hinweis Geschäftsspezifische Hinweise in CLAUDE.md sind sinnvoll, wenn du bereits einen Ordner `business/` mit konkretem Kontext zu Zielgruppe, Produkten und Zielen hast. Falls nicht, erstelle zuerst `business/` und füge dann Verweise darauf in CLAUDE.md ein. Andernfalls zeigen deine Anweisungen ins Leere.
## Wie prüfst du deine CLAUDE.md in 5 Minuten anhand einer 12-Punkte-Prüfliste?
Das Wichtigste Prüfe deine aktuelle CLAUDE.md anhand dieser Liste. Jeder Punkt dauert 30 Sekunden. Wenn du fünf oder mehr Fragen mit „Nein“ beantwortest, muss die Datei aufgeräumt werden.
1. **Umfang.** Ist die Datei knapp, mit ungefähr 200 Zeilen als Prüfziel statt als starre Bestehensgrenze? 2. **Name.** Heißt sie genau `CLAUDE.md` mit Großbuchstaben und nicht `claude.md`? 3. **Speicherort.** Liegt sie im Projektstammverzeichnis oder unter `./.claude/CLAUDE.md`? 4. **Projektbeschreibung.** Machen die ersten 5 Zeilen klar, worum es bei dem Projekt geht und für wen es gedacht ist? 5. **Tools.** Sind die Technologien ausdrücklich und ohne Ausschmückungen aufgeführt? 6. **Struktur.** Gibt es ein Repository-Diagramm mit Erläuterungen? 7. **Verweise.** Gibt es eine Tabelle „Frage → Datei“, die zeigt, wo Antworten zu finden sind? 8. **Prinzipien.** Gibt es einen Abschnitt mit Regeln, die mit „niemals“ und „immer“ beginnen? 9. **Konkretheit.** Ist jede Regel überprüfbar? („Verwende 2 Leerzeichen“, nicht „Schreibe schön“.) 10. **Selbstaktualisierung.** Gibt es eine Regel, am Ende der Sitzung zu prüfen, „was ergänzt werden sollte“? 11. **Rückblick.** Gibt es eine Regel, die Sitzungszusammenfassung in `retrospectives/` festzuhalten? 12. **Sicherheit.** Sind kritische Verbote (`.env`, `rm -rf`) auch in `.claude/settings.json` enthalten? Wenn du mehr als fünfmal „Nein“ geantwortet hast, öffne Claude und gib ihm diesen Prompt:
Prompt: CLAUDE.md anhand der Prüfliste prüfen ``` Read my CLAUDE.md and compare it with the checklist below. For each item, say: yes / no / partly, and what specifically to fix. Checklist: Für die Aufgabe ausreichend kompakt; bei ungefähr 200 Zeilen prüfen, ohne daraus eine starre Obergrenze zu machen Project description in the first 5 lines Tools listed explicitly Repository structure diagram included “Question → file” table included Principles section with rules included Every rule is specific and verifiable “Update at the end of the session” rule included “Reflect at the end of the session” rule included Critical prohibitions included in .claude/settings.json No duplicates of the same rule in different sections No dangling links to files that no longer exist After the audit, give me a list of specific changes that will make the file living. ```
## Was solltest du nach CLAUDE.md verwenden: Plan Mode, Skills oder Sub-Agenten?
Das Wichtigste CLAUDE.md ist das Fundament. Sobald sie funktioniert, stehen die nächsten Ebenen bereit: Plan Mode (Claude zuerst planen lassen und erst dann handeln), Skills (selten benötigtes Wissen aus CLAUDE.md in separate Dateien verschieben) und Sub-Agenten (isolierte Aufgaben in eigenen Kontexten).
CLAUDE.md ist das Fundament. Sobald sie funktioniert, kannst du drei Claude-Code-Mechanismen hinzufügen, die einander ergänzen. **Plan Mode.** Ein Modus, in dem Claude zunächst einen Änderungsplan erstellt, auf deine Genehmigung wartet und erst dann mit der Arbeit beginnt. Aktiviere ihn mit Shift+Tab oder dem Befehl `/plan`. Er löst den größten Schmerzpunkt beim Vibe Coding: „Ich habe Claude gebeten, eine Sache zu reparieren, und es hat das halbe Projekt umgeschrieben.“ Das passiert im Plan Mode nicht - du siehst den Plan, bevor der Agent Dateien anfasst. **Skills.** Separate `.md`-Dateien im Ordner `.claude/skills/`, die Wissen für eine bestimmte Art von Aufgabe enthalten. Ein Skill „Datenbankmigration schreiben“ enthält zum Beispiel ein konkretes Verfahren, eine Vorlage und Beispiele. Dieses Wissen steht nicht in CLAUDE.md, weil es zu umfangreich ist. Wenn Claude aber auf eine Aufgabe wie „Schreibe eine Migration“ stößt, lädt es den passenden Skill und befolgt ihn. **Sub-Agenten.** Wenn eine Aufgabe viel Kontext erfordert (zum Beispiel die Überprüfung eines umfangreichen Features), kann Claude einen separaten Sub-Agenten in einem eigenen, sauberen Kontext starten. Der Sub-Agent erledigt die Arbeit und liefert das Ergebnis zurück, ohne den Kontext deines Hauptchats zu überladen. Alle drei Mechanismen nutzen CLAUDE.md als Einstiegspunkt: Zu Beginn ihrer Arbeit lesen sie die Datei, um den Projektkontext zu verstehen. Deshalb funktionieren diese Funktionen auch mit einer veralteten CLAUDE.md schlecht. Zuerst das Fundament, dann die darauf aufbauenden Ebenen. **Nächster Schritt.** Erstelle im Projektstammverzeichnis eine Datei `CLAUDE.md`, kopiere die Vorlage vom Anfang dieses Artikels hinein und fülle die Felder in eckigen Klammern mit Hilfe des Hilfs-Prompts aus. Arbeite anschließend mit der Datei: Verwandle jeden Fehler des Agenten in eine neue Zeile. Nach zwei oder drei Wochen ist CLAUDE.md keine „Datei, die wir erstellt und vergessen haben“ mehr, sondern etwas, worauf Claude in jeder Sitzung tatsächlich zurückgreift. Wenn du ein komplettes Framework rund um `CLAUDE.md` aufbauen möchtest - einen `business/`-Ordner für ein Second Brain, einen `about-me/`-Ordner als digitale Projektion von dir, grundlegende Skills und einen eingerichteten Plan Mode - verwende die Schritte und Beispiele in diesem Artikel. [Ailoot-Anleitungen](https://ailoot.ai/docs/).
### Quellen - [Anthropic - Claude Code Memory](https://code.claude.com/docs/en/memory) - offizielle Dokumentation zu CLAUDE.md, MEMORY.md und der Ladereihenfolge - [Anthropic - Best Practices](https://code.claude.com/docs/en/best-practices) - Regeln zum Schreiben einer wirksamen CLAUDE.md und der Test „Würde Claude Fehler machen, wenn man diese Zeile entfernt?“ - [Anthropic Support - Give Claude Context](https://support.claude.com/en/articles/14553240-give-claude-context-claude-md-and-better-prompts) - Support-Anleitung zur Arbeit mit Kontext - [Ailoot Guides](https://ailoot.ai/docs/) - Dokumentation.
[Mit Ailoot weitermachen](https://ailoot.ai/).
[Mit Ailoot weitermachen](https://ailoot.ai/)
[Mit Ailoot weitermachen](https://ailoot.ai/)
## Fragen und Antworten ### Wird eine CLAUDE.md nach 200 Zeilen ungültig? Nein. Die Empfehlung ist ein Kompaktheitsziel, keine Parsergrenze oder garantierte Ausfallstelle. Prüfe Duplikate, Widersprüche und geladenen Kontext und teste wichtige Regeln an repräsentativen Aufgaben. Das 280-Zeilen-Beispiel des Artikels braucht dieselbe Bewertung. ### Was sollte aus einer wachsenden CLAUDE.md ausgelagert werden? Verschiebe ausführliche Verfahren, umfangreiches Referenzmaterial und die Entscheidungshistorie in passende Dokumente oder Skills. Behalte knappe Projektfakten, wesentliche Grenzen und klare Verweise in der Einstiegsdatei. Wiederhole nach der Änderung echte Aufgaben, um Verweise und wichtige Regeln zu prüfen. ## Ailoot · Das Unternehmen und sein Projektportfolio Ailoot baut auf bewährte Betriebserfahrung, einen großen Kundenstamm, stabilen Service und kontinuierliche KPI-Kontrolle. Das Unternehmen und sein Projektportfolio: Millionen von Kunden; monatliche Umsätze in Milliardenhöhe. Ailoot nutzt diese Betriebserfahrung für den API-Zugang zu KI-Funktionen in Kundenprodukten, Agenten, Anwendungen und Automatisierungen.