Claude Code Regeln: So schreiben Sie CLAUDE.md und verwalten den agentischen Codierungskontext

Claude Code Regeln leben in CLAUDE.md-Dateien – Markdown-Dateien, die Sie in Ihrem Projekt-Repository, Ihrem Home-Verzeichnis oder Ihrer Organisationskonfiguration ablegen. Claude liest diese zu Beginn jeder Sitzung. Zusammen mit pfadbezogenen Regeln in .claude/rules/, einer settings.json für Berechtigungen und Auto Memory für gelernte Präferenzen gibt Ihnen das Regelsystem eine präzise, dauerhafte Kontrolle darüber, wie sich der Codierungsagent bei jeder Aufgabe verhält.

Was sind Claude Code Regeln?

Jede Claude Code Sitzung beginnt mit einem leeren Kontextfenster. Regeln sind die Art und Weise, wie Sie den benötigten Kontext vorladen, damit Claude nicht bei Null anfängt – oder denselben Fehler zweimal macht.

Zwei sich ergänzende Systeme kümmern sich darum:

CLAUDE.md-Dateien sind Markdown-Dateien, die Sie schreiben und die Claude zu Beginn jeder Sitzung liest. Verwenden Sie sie für Anweisungen, die immer gelten sollen: Build-Befehle, Code-Konventionen, Architekturentscheidungen, harte Einschränkungen.

Auto Memory sind Notizen, die Claude selbst schreibt, basierend auf Korrekturen und Präferenzen, die Sie ihm während der Sitzungen geben. Diese sammeln sich automatisch an; Claude entscheidet, was es wert ist, gespeichert zu werden, und liest diese Notizen in zukünftigen Sitzungen erneut ein.

Beide werden zu Beginn der Sitzung in den Kontext geladen, aber sie sind keine erzwungene Konfiguration. Es sind Anweisungen, denen Claude als Kontext folgt. Für eine harte Durchsetzung – das Blockieren eines bestimmten Befehls, unabhängig davon, was Claude zu tun beschließt – benötigen Sie einen PreToolUse-Hook oder eine deny-Regel in settings.json. Die Unterscheidung ist wichtig für autonome Läufe, bei denen Sie vorhersagbares Verhalten wünschen, nicht probabilistische Compliance.

CLAUDE.md-Dateipfade und Gültigkeitsbereich

Claude Code lädt CLAUDE.md-Dateien von mehreren Orten, die jeweils einen anderen Gültigkeitsbereich abdecken. Sie werden in der Reihenfolge von breit nach spezifisch geladen:

Ort	Gültigkeitsbereich	Wofür es gedacht ist
~/.claude/CLAUDE.md	Alle Projekte auf Ihrem Rechner	Persönliche Präferenzen, globale Arbeitsablaufgewohnheiten
./CLAUDE.md (Repository-Stammverzeichnis)	Alle Sitzungen in diesem Projekt	Projektkonventionen, Build-Befehle, teamweit geteilte Regeln
./CLAUDE.local.md (Repository-Stammverzeichnis)	Nur Ihre lokalen Sitzungen	Entwicklerspezifische Präferenzen; zu .gitignore hinzufügen
./src/CLAUDE.md (Unterverzeichnis)	Sitzungen, die Dateien in diesem Verzeichnis betreffen	Modulspezifische Regeln, die nicht projektweit gelten

Alle gefundenen Dateien werden aneinandergereiht in den Kontext geladen – sie überschreiben sich nicht gegenseitig. Innerhalb dieser Verkettung werden Inhalte vom Dateisystem-Stammverzeichnis bis zu Ihrem Arbeitsverzeichnis zuletzt am spezifischsten angeordnet, sodass eine Projektanweisung nach einer Benutzeranweisung erscheint. Das ergibt eine natürliche Spezifität: Eine Projektregel gewinnt, wenn sie mit einer Benutzerebene-Regel kollidiert.

Sie können zusätzliche Dateien mit @path-Referenzen in jeder CLAUDE.md importieren:

@./docs/architecture.md
@./CONTRIBUTING.md

Importierte Dateien werden zu Beginn der Sitzung geladen, genau wie die CLAUDE.md selbst. Importe sind nützlich für die Organisation, sparen aber keinen Kontext – der importierte Inhalt zählt zu Ihrem Token-Budget.

Für Teams: Übergeben Sie die Projekt-CLAUDE.md an die Versionskontrolle. Dadurch wird sichergestellt, dass jede Claude-Sitzung eines Entwicklers – und alle CI-basierten Agentenläufe – mit demselben gemeinsamen Kontext beginnen. Behandeln Sie sie wie .eslintrc oder pyproject.toml.

Was in CLAUDE.md gehört

Die nützlichsten Inhalte sind das, was Sie sonst jede Sitzung neu erklären würden oder was ein neues Teammitglied in der ersten Stunde wissen müsste.

Gute Kandidaten:

• Build- und Testbefehle, die von offensichtlichen Standardeinstellungen abweichen (./scripts/test.sh --ci, nicht nur npm test)
• Code-Konventionen, die nicht vom Linter erfasst werden („Wir verwenden überall benannte Exporte; keine Standard-Exporte in gemeinsam genutzten Dienstprogrammen“)
• Architekturentscheidungen, die nicht offensichtlich aus dem Code hervorgehen („Das lib/-Verzeichnis wird von mehreren Diensten gemeinsam genutzt – fügen Sie dort keine dienstspezifische Logik hinzu“)
• Bekannte Fallstricke („Die config.ts-Datei wird zur Build-Zeit generiert; bearbeiten Sie sie nicht manuell“)
• Workflow-Einschränkungen („Verzweigen Sie immer, bevor Sie Änderungen vornehmen; übertragen Sie auf Remote, bevor Sie einen PR öffnen“)

Dinge, die Sie weglassen sollten:

• Verzeichnislisten und Dateibäume – Claude liest diese aus dem Repository
• Abhängigkeitslisten – verfügbar aus package.json, pyproject.toml und ähnlichen
• Prosa-Beschreibungen dessen, was vorhandener Code tut – Claude liest Quellcode direkt
• Aktuelle Änderungen – Claude verwendet git log und git diff, wenn es den Verlauf benötigt

Halten Sie CLAUDE.md fokussiert auf das, was nicht aus dem Lesen der Codebasis abgeleitet werden kann. Dateien über 200 Zeilen verbrauchen mehr Kontext und verringern die Zuverlässigkeit der Befolgung. Der Befehl /doctor in Claude Code prüft eine eingecheckte CLAUDE.md und schlägt vor, Inhalte zu entfernen, die aus dem Code ableitbar sind – eine nützliche Methode, um eine aufgeblähte Datei zu trimmen.

Effektive Regeln schreiben

Spezifität ist wichtig. Vergleichen Sie:

# Vage – weniger konsistent
Befolgen Sie die Projekt-Codierungsstandards.

# Spezifisch – konsistenter
- Verwenden Sie pnpm, nicht npm oder yarn
- Führen Sie vor jedem Commit pnpm test aus; übergeben Sie nicht, wenn Tests fehlschlagen
- Exportieren Sie alle gemeinsam genutzten Typen aus src/types/index.ts – definieren Sie Typen nicht inline in Komponentendateien
- Das data/-Verzeichnis ist in Tests schreibgeschützt; verwenden Sie Test-Fixtures aus tests/fixtures/

Jede Regel sollte ohne weitere Erklärung umsetzbar sein. Wenn Sie jemandem die Begründung einer Regel erklären müssten, fügen Sie die Begründung inline hinzu – es hilft Claude, die Regel in Grenzfällen korrekt anzuwenden.

Pfadbezogene Regeln mit .claude/rules/

Das Verzeichnis .claude/rules/ ermöglicht es Ihnen, Regeln an bestimmte Dateimuster zu binden, ohne sie in jede Sitzung zu laden. Claude findet Dateien in .claude/rules/ und lädt sie, wenn Sie mit passenden Dateien arbeiten.

Eine typische Struktur für ein TypeScript-Monorepo:

.claude/rules/
  api.md             # Regeln für src/api/** – Anfragevalidierung, Fehlerformate
  components.md      # Regeln für src/components/** – Prop-Typen, Styling-Konventionen
  tests.md           # Regeln für tests/** – Fixture-Muster, Mock-Setup
  database.md        # Regeln für migrations/ und models/ – Migrationsbenennung, Abfragemuster

Jede Regeldatei verwendet YAML-Frontmatter mit einem paths-Feld, um zu steuern, wann sie geladen wird:

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

# API-Entwicklungsregeln

- Alle Route-Handler müssen Eingaben mit zod validieren, bevor Geschäftslogik ausgeführt wird
- Fehler als `{ error: string; code: string }` zurückgeben – niemals als einfache Zeichenketten
- Ratenbegrenzung wird am Gateway angewendet; fügen Sie sie nicht innerhalb von Handlern hinzu

Regeln ohne paths-Feld werden zu Beginn der Sitzung bedingungslos geladen, genau wie Inhalte in der Projekt-CLAUDE.md. Regeln mit paths werden nur geladen, wenn Claude Dateien öffnet, die diesen Mustern entsprechen.

Dies hält die Projektstamm-CLAUDE.md prägnant und stellt sicher, dass detaillierte Konventionen für eine Ebene des Stacks den Kontext nicht während Sitzungen füllen, die sich auf einen anderen Bereich konzentrieren.

settings.json vs. CLAUDE.md

CLAUDE.md steuert, was Claude weiß und zu tun beabsichtigt. settings.json steuert, was Claude tatsächlich tun darf.

	CLAUDE.md	settings.json
Zweck	Anweisungen und Kontext	Berechtigungen und Konfiguration
Erzwungen?	Nein – Claude handelt danach als Leitfaden	Ja – deny-Regeln blockieren Tool-Aufrufe bedingungslos
Format	Freiform-Markdown	Strukturiertes JSON
Lebt unter	./CLAUDE.md, ~/.claude/CLAUDE.md	.claude/settings.json, ~/.claude/settings.json

Eine Projekt-settings.json unter .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(pnpm test)",
      "Bash(pnpm build)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)"
    ]
  }
}

Die allow-Liste genehmigt bestimmte Befehle vorab, sodass Claude sie ohne Eingabeaufforderung ausführen kann. Dies beschleunigt interaktive Sitzungen für Operationen, denen Sie vertrauen. Die deny-Liste blockiert Befehle bedingungslos – unabhängig davon, was Claude zu tun beschließt, unabhängig davon, was CLAUDE.md sagt. Verwenden Sie deny für irreversible Operationen auf Produktionsdaten oder Infrastruktur.

Benutzerebene-Einstellungen unter ~/.claude/settings.json gelten für alle Projekte. Projekteinstellungen unter .claude/settings.json gelten nur in diesem Repository. Projekteinstellungen haben Vorrang vor Benutzereinstellungen, wenn sie sich überschneiden.

Auto Memory: Claudes Notizen

Auto Memory ist das Gegenstück zu CLAUDE.md. Während CLAUDE.md Anweisungen sind, die Sie schreiben, sind Auto Memory Notizen, die Claude selbst schreibt, basierend auf dem, was es während Ihrer Sitzungen lernt.

Wenn Sie Claude während einer Sitzung korrigieren – „Wir verwenden Vitest, nicht Jest in diesem Projekt“ – kann es dies als Notiz in ~/.claude/projects/<repo>/memory/ speichern. In der nächsten Sitzung liest Claude diese Notiz zurück und wendet die Korrektur an, ohne dass es ihm erneut gesagt werden muss.

Das Speicherverzeichnis enthält:

~/.claude/projects/<repo>/memory/
  MEMORY.md          # Index, den Claude verwendet, um andere Dateien zu finden; die ersten 200 Zeilen werden jede Sitzung geladen
  debugging.md       # Muster, die Claude bei der Lösung von Problemen in diesem Repository entdeckt hat
  conventions.md     # Konventionen, die Claude aus Ihren Korrekturen gelernt hat

Dies ist maschinenlokal und pro Repository. Auto Memory ergänzt CLAUDE.md, anstatt es zu ersetzen: CLAUDE.md ist für teamweit geteilte Projektregeln; Auto Memory ist für persönliche Muster, die Claude aus der Zusammenarbeit mit Ihnen gelernt hat.

Auto Memory ist lesbares Markdown, das Sie jederzeit bearbeiten oder löschen können. Führen Sie /memory innerhalb einer Sitzung aus, um die Dateien zu durchsuchen und zu bearbeiten. Wenn etwas veraltet oder falsch ist, löschen Sie es – Claude wird die veraltete Regel nicht mehr anwenden.

Best Practices für agentisches Codieren

Wenn Claude Code autonom ausgeführt wird – über claude -p, das Agent SDK oder CI-Pipelines – steigen die Anforderungen an Ihre Regelkonfiguration. Der Agent kann dutzende Tool-Aufrufe ohne Pause ausführen, und es gibt kein interaktives Hin und Her, um Missverständnisse während des Laufs aufzufangen.

Schreiben Sie explizite Einschränkungen, nicht nur Präferenzen. Interaktives Claude kann Sie um Klärung bitten. Ein autonomer Lauf arbeitet mit dem, was er im Kontext vorfindet. Wenn „Migrationsdateien niemals ändern, ohne vorher einen Datenbank-Snapshot zu erstellen“ wichtig ist, muss es in CLAUDE.md stehen. Gehen Sie nicht davon aus, dass Claude die Einschränkung aus der Codebasis-Struktur ableitet.

Verwenden Sie deny-Regeln für alles, was schwer rückgängig zu machen ist. Die Vorabgenehmigung von Bash(pnpm build) beschleunigt interaktive Sitzungen und ist mit geringem Risiko verbunden. Aber für autonome Läufe ist die deny-Liste Ihr Sicherheitsnetz für Operationen, die Produktionsinfrastruktur berühren, dauerhaft in der Git-Historie committen oder Daten löschen.

Halten Sie die Projekt-CLAUDE.md in der Versionskontrolle. Eine eingecheckte CLAUDE.md im Repository-Stammverzeichnis gilt konsistent für interaktive Sitzungen, CI-Läufe und lokale Agenten jedes Teammitglieds. Dies ist der richtige Ort für die Regeln, die definieren, was „korrekt“ für Ihre Codebasis bedeutet.

Verwenden Sie .claude/rules/ für domänenspezifische Inhalte. Wenn Ihr Projekt unterschiedliche Ebenen hat – Frontend-Komponenten, Backend-API, Datenbankschema, Infrastruktur-Skripte – legen Sie die Regeln für jede Ebene in .claude/rules/ mit Pfadbereichen ab. Eine einzelne 400-zeilige CLAUDE.md mit allem darin ist für Claude schwerer zu navigieren und kostet mehr Kontext pro Sitzung.

Verschieben Sie Referenzmaterial in Skills. Skills (.claude/skills/) werden bei Bedarf geladen, nicht zu Beginn der Sitzung. Lange API-Dokumentationen, mehrstufige Bereitstellungsverfahren und Fehlerbehebungs-Playbooks gehören in Skills, die Sie mit /deploy oder /debug aufrufen – nicht in CLAUDE.md, wo sie Kontext verbrauchen, selbst wenn sie irrelevant sind.

Überprüfen Sie Auto Memory regelmäßig. Auto Memory sammelt sich im Laufe der Zeit an. Build-Befehle ändern sich, Konventionen werden umgestaltet, Testmuster verschieben sich. Eine veraltete Speichernote, die besagt „verwenden Sie den v1-API-Client“, wenn Sie auf v2 migriert haben, wird in autonomen Läufen subtile Fehler verursachen. Überprüfen Sie ~/.claude/projects/<repo>/memory/, wenn Sie wesentliche Änderungen an der Projektstruktur vornehmen.

Open-Source-Modelle mit Ihrer Regelkonfiguration verwenden

Der CLAUDE.md-Kontext und die .claude/rules/, die Sie erstellt haben, funktionieren unabhängig davon, welches Modell die Inferenz übernimmt. Sobald Ihre Regeln geschrieben sind, bleibt beim Wechsel des Modell-Backends alles erhalten – und Open-Source-Modelle über Novita AIs LLM-API sind eine praktische Option für agentische Arbeit mit hohem Volumen.

Die Konfiguration erfolgt über eine Umgebungsvariable:

export ANTHROPIC_BASE_URL="https://api.novita.ai/anthropic"
export ANTHROPIC_AUTH_TOKEN="<your-novita-api-key>"
export ANTHROPIC_MODEL="qwen/qwen3-coder-480b-a35b-instruct"

Mit ANTHROPIC_BASE_URL, das auf Novita AI zeigt, sendet Claude Code alle Inferenzanfragen an Novitas Anthropic-kompatiblen Endpunkt anstelle von api.anthropic.com. Ihre CLAUDE.md, pfadbezogenen Regeln und settings.json gelten genau wie zuvor – die Regelschicht liegt upstream der Modellauswahl.

Novita AI hostet codierungsfokussierte Open-Weight-Modelle, darunter Qwen3-Coder, GLM-4.7, MiniMax M2.5 und DeepSeek V4. Diese Modelle sind für mehrstufige Tool-Nutzung und Funktionsaufrufe optimiert, was gut zu den Tool-Calling-Mustern passt, die Claude Code intern für Dateibearbeitungen, Shell-Befehle und Repository-Navigation verwendet.

Für Teams, die agentische Aufgaben in großem Maßstab ausführen – Code-Review-Pipelines, automatisiertes Refactoring über große Repositories, Testgenerierung – kosten Open-Weight-Modelle auf Novita in der Regel deutlich weniger pro Million Tokens als Closed-Source-Alternativen, während sie Ihre Projektregeln dennoch effektiv lesen und anwenden.

Wenn Sie Agenten gegen eine Produktionscodebasis ausführen und eine zusätzliche Sicherheitsebene über deny-Regeln hinaus wünschen, sollten Sie die Kombination von Novitas LLM-API mit Novitas Agent Sandbox in Betracht ziehen. Die Sandbox bietet dem Agenten eine vollständige Linux-Umgebung für Dateioperationen und Befehlsausführung, isoliert von Ihrem Host-System. Ihr CLAUDE.md-Kontext reist mit der Aufgabe; das Ausführungsrisiko bleibt eingeschlossen.

FAQ

Was ist CLAUDE.md in Claude Code?

CLAUDE.md ist eine Markdown-Datei, die Claude Code dauerhafte Anweisungen über Sitzungen hinweg gibt. Sie wird zu Beginn der Sitzung geladen, sodass Claude Ihre Projektkonventionen nicht jedes Mal neu lernen muss. Sie können CLAUDE.md-Dateien auf mehreren Ebenen haben: auf Benutzerebene (~/.claude/CLAUDE.md) für persönliche Präferenzen, die überall gelten, auf Projektebene (Repository-Stammverzeichnis) für teamweit geteilte Regeln, die in der Versionskontrolle eingecheckt sind, und auf Unterverzeichnisebene für modulspezifische Regeln.

Was sollte ich in claude rules md-Dateien schreiben?

Schreiben Sie das, was Sie sonst jede Sitzung neu erklären würden: Build- und Testbefehle, Codierungskonventionen, die von Framework-Standards abweichen, Architektureinschränkungen und bekannte Fallstricke der Codebasis. Lassen Sie Inhalte weg, die Claude aus der Codebasis selbst ableiten kann – Dateibäume, Abhängigkeitslisten und Beschreibungen dessen, was vorhandener Code tut. Halten Sie Dateien unter 200 Zeilen für eine konsistente Befolgung.

Was ist der Unterschied zwischen CLAUDE.md und settings.json in Claude Code?

CLAUDE.md sind Anweisungen, denen Claude als Leitfaden folgt. settings.json ist eine Konfiguration, die Claude Code auf Systemebene durchsetzt. Eine Regel in CLAUDE.md formt, was Claude zu tun beabsichtigt; ein deny-Eintrag in settings.json blockiert einen Tool-Aufruf bedingungslos. Für alles, was nicht passieren darf, unabhängig davon, was Claude entscheidet – irreversible Löschungen, Force-Pushes, Produktionsumgebungsoperationen – verwenden Sie settings.json, nicht CLAUDE.md.

Was ist das .claude/rules/-Verzeichnis?

.claude/rules/ enthält pfadbezogene Regeldateien, die nur geladen werden, wenn Claude mit Dateien arbeitet, die dem Gültigkeitsbereich der Regel entsprechen. Dies ermöglicht es Ihnen, detaillierte, domänenspezifische Regeln zu schreiben, ohne sie in jede Sitzung zu laden. Regeln sind Markdown-Dateien mit optionalem YAML-Frontmatter, das paths-Glob-Muster angibt. Regeln ohne paths-Frontmatter werden zu Beginn der Sitzung bedingungslos geladen, wie zusätzliche CLAUDE.md-Inhalte.

Funktioniert CLAUDE.md in CI und bei automatisierten Claude Code Aufgaben?

Ja. Jeder claude -p-Aufruf, Agent SDK-Aufruf oder CI-Pipeline, der in einem Repository-Verzeichnis ausgeführt wird, lädt die Projekt-CLAUDE.md. Dies macht CLAUDE.md effektiv für die Durchsetzung konsistenten Verhaltens sowohl in interaktiven als auch in automatisierten Kontexten. Das Einchecken in die Versionskontrolle stellt sicher, dass jeder Lauf – lokal und in CI – mit demselben gemeinsamen Kontext beginnt.

Wie funktioniert der Claude Code Kontext und wie verwalte ich ihn?

Kontext ist das Token-Budget für die aktuelle Sitzung. CLAUDE.md-Dateien, importierte Referenzen, Auto Memory und der Gesprächsverlauf zählen alle dazu. Verwalten Sie ihn, indem Sie CLAUDE.md prägnant halten, .claude/rules/ verwenden, um Domain-Inhalte nur bei Bedarf zu laden, und /compact verwenden, um lange Sitzungen zusammenzufassen, ohne die Kontinuität zu verlieren. Nach /compact liest Claude die Projektstamm-CLAUDE.md erneut von der Festplatte und injiziert sie automatisch wieder in die Sitzung.

Wie verwende ich Claude Code Best Practices für agentisches Codieren in einem Team?

Übergeben Sie die Projekt-CLAUDE.md an Ihr Repository, sodass alle Teammitglieder und CI-Agenten dieselben Regeln teilen. Verwenden Sie .claude/rules/ mit Pfadbereichen für domänenspezifische Inhalte. Fügen Sie deny-Regeln zu .claude/settings.json für Operationen hinzu, die niemals in automatisierten Kontexten ausgeführt werden sollten. Halten Sie Auto Memory aus CI heraus – es ist maschinenlokal und pro Entwickler; die eingecheckte CLAUDE.md ist die Quelle der Wahrheit für gemeinsames Verhalten.

Novita AI ist eine KI-Cloud-Plattform, die Entwicklern eine einfache Möglichkeit bietet, KI-Modelle über unsere einfache API bereitzustellen, und gleichzeitig erschwingliche und zuverlässige GPU-Cloud für den Aufbau und die Skalierung bereitstellt.

Empfohlene Artikel

• Claude Code CLI Dokumentation: Einrichtung, Slash-Befehle und LLM-API-Integration
• Claude Code SDK: Autonome Agenten mit Python & TypeScript erstellen
• Einen Codierungsagenten mit Novitas Agent Sandbox erstellen

---

Quellen geprüft am 21. Juli 2026: Claude Code Memory Dokumentation, Claude Code Funktionsübersicht, Novita AI LLM-API