Es gibt eine Frage, die den, der Claude ausschöpft, von dem trennt, der mit ihm ringt: Erklärst du ihm dein Projekt jedes Mal neu, wenn du eine Sitzung öffnest? Lautet die Antwort ja, lässt du die Hälfte des Werts liegen. Der Trick ist nicht, bessere Prompts zu schreiben. Es ist, ein einziges Mal eine Datei zu schreiben, die Claude bei jedem Start automatisch liest: die CLAUDE.md.
Es ist die billigste und lohnendste Änderung, die du machen kannst. Vier gut gesetzte Zeilen, und du hörst für immer auf, dich zu wiederholen. In diesem Leitfaden geht es darum, was hineingehört, was draußen bleibt und wie du sie strukturierst, damit sie wirklich funktioniert.
Hinweis
CLAUDE.md ist weder ein Prompt noch eine Dokumentation. Es ist dauerhafter Kontext: die Regeln und Daten, die für alle deine Sitzungen in diesem Projekt gelten. Claude lädt sie beim Öffnen des Ordners von selbst, ohne dass du sie in den Chat einfügen musst.
Was CLAUDE.md ist und warum es Claude vervielfacht
Es ist eine Textdatei im Markdown-Format, die du in den Ordner deines Projekts legst. Mehr nicht: reiner Text. Das Besondere daran ist, dass Claude sie beim Start jeder Sitzung automatisch liest und ihren Inhalt als übergeordnete Anweisungen behandelt.
Der Unterschied zu einem normalen Chat ist brutal. Ohne CLAUDE.md beginnt jede Unterhaltung bei null: Claude weiß nicht, was dein Projekt ist, welchen Stack du nutzt, wie du dir das Schreiben wünschst oder welche Dateien unantastbar sind. Diese Lücke füllst du von Hand, wieder und wieder, und verschwendest deine Zeit und seine Aufmerksamkeit. Mit CLAUDE.md ist dieser Kontext schon geladen, bevor du ein einziges Wort schreibst.
Deshalb „vervielfacht“ es: Es macht Claude nicht klüger, es macht ihn mehr zu deinem. Er hört auf zu raten und startet ausgerichtet auf deine Arbeitsweise. Die erste Antwort jeder Sitzung ist schon die gute, nicht erst die dritte.
Was rein muss (und was draußen bleibt)
Hier ist der häufigste Fehler: die CLAUDE.md als Sammelbecken zu behandeln, in das man alles kippt, was man über das Projekt weiß. Falsch. Alles, was du dort hineinschreibst, belegt in jeder Sitzung Kontext und konkurriert um die Aufmerksamkeit des Modells. Eine riesige Datei verwässert die Anweisungen, auf die es wirklich ankommt.
Die Denkregel ist einfach: operative und stabile Anweisungen, keine Dokumentation. Wenn etwas stabil (gilt immer) und operativ ist (ändert, wie Claude arbeitet), kommt es rein. Wenn es sich jede Woche ändert oder nur für eine heutige Aufgabe taugt, geht es in den Chat.
Was HINEIN gehört:
- Was das Projekt ist in ein, zwei Sätzen. Das Wozu, nicht die Geschichte.
- Wie du willst, dass er arbeitet: Ton, Sprache, Detailgrad, ob er vor großen Änderungen um Erlaubnis fragen soll.
- Konventionen: Stack und Befehle (Code-Projekte), Ordnerstruktur, Namensgebung, Ausgabeformat.
- Ausdrückliche Verbote: welche Dateien oder Bereiche er niemals anfassen darf. Das ist der Abschnitt, der die meisten Fehler verhindert und den fast alle vergessen.
- Abkürzungen: Befehle oder Abläufe, die du oft wiederholst („zum Deployen nutzt man X“).
Was NICHT hinein gehört:
- Die Projektgeschichte oder bereits abgeschlossene Entscheidungen, die die heutige Arbeit nicht betreffen.
- Lange Dokumentation, die schon woanders lebt (besser: verlinke sie oder sag, wo sie steht).
- Anweisungen für eine einzige Aufgabe („beheb heute diesen Bug“): das ist ein Prompt.
- Geheimnisse, Schlüssel oder Passwörter. Niemals.
Achtung
Der Abschnitt mit den Verboten ist der wichtigste und der am meisten übersehene. „Ändere den Produktionsordner NICHT“, „lösch NIEMALS Daten, ohne mir vorher den Plan zu zeigen“, „fass die Konfigurationsdateien nicht an“. Aufzuschreiben, was NICHT passieren soll, verhindert 90 % der Schrecksekunden.
Eine empfohlene Struktur
Es gibt kein Pflichtformat, aber diese Struktur funktioniert, weil sie vom Allgemeinen zum Konkreten geht und die harten Regeln dorthin stellt, wo Claude sie sieht. Vier Blöcke:
- Über das Projekt — was es ist und wozu, in wenigen Sätzen.
- Wie zu arbeiten ist — Ton, Sprache, Freigabeablauf, Detailgrad.
- Konventionen — Stack, Struktur, Befehle, Format. Das Konkrete.
- Nicht anfassen — die ausdrücklichen Verbote, gut sichtbar.
Halte jeden Block kurz und in Listen. Claude liest fünf klare Stichpunkte besser als einen dichten Absatz. Und wenn dein Projekt wächst, teile auf: eine allgemeine CLAUDE.md mit deinen globalen Vorlieben und eine je Teilprojekt mit dessen Details. Die spezifischen kommen zu den allgemeinen hinzu, also wiederhole dich nicht: in der Marken-Datei steht der Ton, in der jedes Projekts nur, was sich ändert.
Kopierbare Vorlage
Das ist die Basisvorlage. Kopiere sie, lösch, was nicht passt, und füll die Klammern aus. In zwei Minuten hast du eine CLAUDE.md, die besser ist als 95 % der existierenden.
# [Projektname]
## Über das Projekt
[Was es ist, in 1-2 Sätzen.] Ich nutze es für [Hauptziel].
Zielgruppe / Kontext: [wer es nutzt oder für wen es ist].
## Wie ich möchte, dass du arbeitest
- Sprich mit mir auf Deutsch, direkt und ohne Umschweife.
- Vor großen oder unumkehrbaren Änderungen zeig mir den Plan und warte auf mein OK.
- Standardmäßig kleine, umkehrbare Aufgaben.
- Wenn etwas unklar ist, frag nach, bevor du etwas annimmst.
## Konventionen
- Stack / Werkzeuge: [Sprache, Framework, Apps].
- Struktur: [wo was liegt].
- Wichtige Befehle: [Build / Test / Deploy, sofern zutreffend].
- Ausgabeformat: [wie du die Antworten willst].
## NICHT anfassen (wichtig)
- [unantastbare Dateien, Ordner oder Bereiche].
- Lösch oder überschreib [X] niemals, ohne vorher Bescheid zu geben.
- Keine Geheimnisse, Schlüssel oder sensiblen Daten einfügen.Drei Beispiele je nach deinem Fall
Die Vorlage ist dieselbe; was sich ändert, ist die Füllung. Drei echte Fälle.
Code-Projekt. Hier steckt der Wert in den technischen Konventionen. Stack und Versionen, Build- und Test-Befehl, Ordnerstruktur, Codestil („nutze striktes TypeScript, kein any“) und die kritischen Verbote („fass migrations/ nicht an, kein direkter Push auf main“). Claude hört auf, sich Befehle auszudenken, und respektiert deine Architektur ab der ersten Nachricht.
Marke oder Unternehmen. Hier zählt die Stimme. Ton („direkt, praktisch, ohne Füllwörter, ohne Emojis“), welche Wörter zu verwenden und welche zu vermeiden sind, Textformat, Sprache und Stilregeln („versprich niemals garantierte Ergebnisse“). Was im Code technische Konventionen sind, sind bei der Marke Stimm-Konventionen. Das Ergebnis: Alles, was Claude schreibt, klingt nach dir, nicht nach generischer KI.
Nicht-technische Nutzung. Dokumente ordnen, planen, E-Mails verfassen. Programmieren muss man nicht können. Du schreibst hinein, wie du arbeitest („sortier mir immer nach Datum“, „Zusammenfassungen als Stichpunkte, höchstens fünf“), deine üblichen Ordner und was nicht anzufassen ist („verschieb nichts aus dem Ordner Wichtig, ohne mir vorher zu zeigen, was du vorhast“). Dieselbe Datei, dieselbe Wirkung: Du hörst auf, in jeder Sitzung das Offensichtliche zu erklären.
Der Fehler, der eine gute CLAUDE.md ruiniert
Sie schreiben und vergessen. Eine CLAUDE.md ist ein lebendes Dokument: Wenn du merkst, dass du eine Anweisung im Chat zwei- oder dreimal wiederholst, gehört diese Anweisung in die Datei. Füg sie hinzu. Und umgekehrt: Wenn eine Regel nicht mehr gilt, lösch sie, denn der angesammelte Ballast wiegt ebenfalls.
Behandle sie als das, was sie ist: den Arbeitsvertrag zwischen dir und Claude. Je klarer und aktueller, desto besser arbeitet er. Der Unterschied zwischen dem, der mit dem Werkzeug ringt, und dem, der es ausschöpft, läuft fast immer auf das hinaus: Der Zweite hat seine Regeln ein einziges Mal in einer Datei aufgeschrieben und für immer aufgehört, sie zu wiederholen.
Öffne dein Projekt, leg eine CLAUDE.md mit der Vorlage von oben an und füll die vier Blöcke aus. Es ist das Lohnendste, was du heute mit Claude tun wirst.