Zum Hauptinhalt springen

Claude Kontext geben: CLAUDE.md und bessere Prompts

Claude Code funktioniert sofort gut, wird aber deutlich effektiver, wenn es die Konventionen deines Projekts kennt und du ein paar Prompt-Gewohnheiten anwendest. Diese Anleitung behandelt beides.


Teil 1 — CLAUDE.md: das Gedächtnis deines Projekts

Was es ist

CLAUDE.md ist eine einfache Markdown-Datei, die Claude automatisch zu Beginn jeder Sitzung in diesem Verzeichnis liest. Stell dir vor, es ist die Einweisung, die du einem fähigen neuen Teamkollegen am ersten Morgen geben würdest: wie das Team arbeitet, was zu vermeiden ist und wo die wichtigen Teile sind.

Du musst nicht in Prompts darauf verweisen oder sie manuell anhängen. Wenn die Datei existiert, hat Claude sie bereits gelesen.

Wo sie sich befindet

Claude sucht an mehreren Stellen und führt zusammen, was es findet, von allgemein bis spezifisch:

Ort

Umfang

Gut für

~/.claude/CLAUDE.md

Jedes Projekt auf deinem Computer

Persönliche Vorlieben (zum Beispiel „Ich verwende pnpm, nicht npm" oder „immer Tests vorschlagen").

<repo-root>/CLAUDE.md

Dieses Projekt

Architektur, Konventionen und Befehle. Das ist die wichtigste.

<subdir>/CLAUDE.md

Dieses Unterverzeichnis (wird bei Bedarf geladen, wenn Claude Dateien in diesem Verzeichnis liest, nicht beim Sitzungsstart)

Modulspezifische Regeln (zum Beispiel unterschiedliche Konventionen in frontend/ vs api/).

Die meisten Teams benötigen nur die Datei im Projekt-Root. Committe sie zu Git, damit das ganze Team davon profitiert.

Wie sie geladen wird (und was sie kostet)

Die Dateien in und über deinem Arbeitsverzeichnis werden beim Sitzungsstart gelesen und an Claude als Benutzernachricht unmittelbar nach dem System-Prompt übermittelt (nicht in den System-Prompt selbst eingebettet). Dateien im Unterverzeichnis CLAUDE.md werden später bei Bedarf geladen, wenn Claude Dateien in diesem Unterverzeichnis liest. Es gibt keine Zusammenfassung oder Kürzung, und sie wird nicht bei jedem Durchgang von der Festplatte neu gelesen. Wenn du die Datei während einer Sitzung bearbeitest, wird die Änderung beim nächsten Ausführen von /compact oder beim Öffnen über /memory übernommen; andernfalls tritt sie in deiner nächsten Sitzung in Kraft.

Für Claude for Enterprise-Kunden ist die Kostensituation besser als „bei jeder Anfrage geladen

In der Praxis bedeutet dies, dass eine große CLAUDE.md einmal pro Sitzung vollständige Tokens kostet, plus einmal nach jeder Leerlaufpause, die lang genug ist, damit der Cache abläuft, anstatt einmal pro Nachricht. Es ist immer noch sinnvoll, die Datei für Kontextfensterplatz und Signal-Rausch-Verhältnis schlank zu halten, aber du musst Zeilen nicht nur zur Kontrolle der Pro-Nachricht-Ausgaben rationieren. Im Enterprise-Nutzungs-Dashboard wird der Speicherplatz der Datei fast vollständig als Cache-Read-Tokens anstelle von Standard-Input-Tokens angezeigt.

Erste Schritte: Führe /init aus

Gib in jedem Projekt /init ein. Claude wird die Codebasis erkunden und einen CLAUDE.md für dich entwerfen, der Build-Befehle, Test-Befehle, eine Strukturübersicht und alle erkannten Konventionen abdeckt. Überprüfe den Entwurf, entferne alles Ungenaue und committe ihn. Dies dauert etwa fünf Minuten und zahlt sich dauerhaft aus.

Was wirklich hineingehört

Strebe eine Datei an, die kurz und signaldicht ist — unter etwa 200 Zeilen. Jede Zeile wird bei jeder Anfrage in den Kontext geladen, daher sollte jede ihren Preis wert sein.

Wert zu inkludieren:

  • Befehle — wie man lokal baut, testet, linted und ausführt. Claude wird diese ausführen, daher ist Genauigkeit wichtig.

  • Konventionen — Benennung, Fehlerbehandlung, Datei-Layout und „wir verwenden X, nicht Y"-Entscheidungen."

  • Architektur in drei Sätzen — was die Hauptteile sind und wie sie kommunizieren.

  • Harte Einschränkungen — zum Beispiel „schreibe niemals in die Produktionsdatenbank aus Tests

  • Bekannte Fallstricke — die Probleme, über die jeder neue Ingenieur stolpert.

Nicht wert zu inkludieren:

  • Vollständige API-Dokumentation (Claude kann den Code direkt lesen).

  • Changelogs oder Verlauf.

  • Alles, das bereits aus dem Dateibaum offensichtlich ist.

  • Aspirative Regeln, die das Team tatsächlich nicht befolgt.

Wie oft man es aktualisiert

Behandle es wie ein lebendes Onboarding-Dokument, nicht wie eine Spezifikation.

  • Nach /init — überprüfe einmal, um den generierten Entwurf zu bereinigen.

  • Wenn Claude zweimal etwas falsch macht — das ist das Signal, dass eine Regel fehlt. Füge eine Zeile hinzu, um es zu beheben.

  • Wenn sich Konventionen ändern — zum Beispiel ein neues Framework, Test-Runner oder eine Reihe von Lint-Regeln.

  • Vierteljährlicher Überblick — lösche alles Veraltete, da veraltete Anweisungen schlimmer sind als keine.

Du kannst es auch während einer Sitzung hinzufügen: Öffne /memory, um die Datei direkt zu bearbeiten, oder frag Claude einfach, eine Regel zu „merken


Teil 2 — Prompt-Gewohnheiten, die sich in Claude Code auszahlen

Dies sind keine generischen Prompt-Engineering-Tipps; dies sind die Gewohnheiten, die am meisten zählen, wenn Claude eine echte Codebasis liest und bearbeitet.

1. Gib das Ergebnis an, nicht die Schritte

Claude kann die Codebasis selbst erkunden. Sag ihm was du willst und warum, und lass ihn herausfinden, wo.

❌ „Öffne userService.ts, finde die validate-Funktion, füge eine Null-Prüfung auf Zeile 42 hinzu.

✅ „Benutzer ohne E-Mail stürzen den Validierungsschritt ab. Mach es so, dass es das elegant handhabt und füge einen Test hinzu.

2. Gib ihm den Fehler wörtlich

Füge die vollständige Stack-Trace ein, anstatt sie zusammenzufassen. Der genaue Dateiname, die Zeilennummer und die Nachricht ermöglichen es Claude, die richtige Stelle schnell zu finden.

3. Begrenzen Sie große Aufgaben mit Plan Mode zuerst

Für alles, das mehr als ein paar Dateien berührt, drücke Shift+Tab zweimal, um in den Plan-Modus zu wechseln (der erste Druck aktiviert acceptEdits) und frag:

„Plane, wie du Rate Limiting zur öffentlichen API hinzufügen würdest. Ändere noch nichts."

Überprüfe den Plan, passe ihn im Gespräch an, wechsle dann den Modus und sag „mach Schritt 1.

4. Zeige auf Dateien, wenn du sie bereits kennst

Claude kann die Codebasis selbst durchsuchen, aber wenn du die relevante Datei bereits kennst, sag es — es ist schneller und verwendet weniger Tokens. Verwende @, um Pfade zu referenzieren, zum Beispiel @src/auth/login.ts.

5. Sag, wie „fertig" aussieht"

Beispiele sind „Tests bestehen

6. Eine Aufgabe pro Gespräch; /clear dazwischen

Lange Sitzungen sammeln Rauschen an. Wenn du von „den Login-Bug beheben" zu „das Abrechnungsmodul umgestalten" wechselst, führe /clear aus und starten Sie neu. Dein CLAUDE.md trägt den dauerhaften Kontext weiter, daher muss der Chat-Verlauf das nicht.

7. Korrigiere es wie einen Kollegen, nicht wie eine Suchmaschine

Wenn die erste Antwort falsch ist, musst du die ganze Anfrage nicht umformulieren. Sag einfach, was falsch ist — zum Beispiel „Das ändert die öffentliche API; behalte die Signatur gleich." Claude wird alles andere behalten und nur diesen Punkt anpassen.


Schnellreferenz

Möchte…

Mach das

Generiere einen anfänglichen CLAUDE.md

/init

Sehe, welches Gedächtnis Claude verwendet

/memory

Füge eine Regel während einer Sitzung hinzu

Öffne /memory, oder frag Claude, die Regel zu „merken

Starten Sie neu, aber behalten Sie das Projektgedächtnis

/clear

Referenziere eine bestimmte Datei in einem Prompt

@path/to/file

Hat dies deine Frage beantwortet?