CLAUDE.md meistern: Claude Code optimal konfigurieren 2026

Claude Code liest beim Start automatisch eine Datei: CLAUDE.md. Was simpel klingt, ist in der Praxis der mächtigste Hebel den du hast, um Claude Code in deinem Projekt konsistent, sicher und produktiv einzusetzen. Dieses Handbuch zeigt dir alles — von der Grundstruktur bis zu erweiterten Hooks und Memory-Systemen.

Warum CLAUDE.md so wichtig ist

Ohne CLAUDE.md arbeitet Claude Code im Default-Modus: kein Projektkontext, keine Regeln, keine Einschränkungen. Mit einer gut geschriebenen CLAUDE.md dagegen verhält sich Claude Code wie ein eingespielter Senior-Entwickler der genau dein Projekt kennt.

1. Was ist CLAUDE.md? Automatisches Laden und Hierarchie

Claude Code sucht beim Start nach CLAUDE.md-Dateien und lädt sie automatisch in den Kontext — noch bevor du irgendeine Eingabe machst. Das System arbeitet mit einer dreistufigen Hierarchie:

~/.claude/CLAUDE.md → Global: gilt für ALLE Projekte auf deiner Maschine

↓ überschreibbar durch

./CLAUDE.md → Projekt-Root: gilt für das aktuelle Projekt

↓ überschreibbar durch

./src/CLAUDE.md → Subfolder: gilt nur für dieses Verzeichnis

Die Hierarchie erlaubt es, globale Regeln (z.B. Sicherheitsrichtlinien, bevorzugter Codestil) zu setzen und diese auf Projektebene zu verfeinern oder zu erweitern. Subfolder-Dateien kommen noch spezifischer — perfekt für Monorepos mit verschiedenen Teams.

Automatisches Laden — was genau passiert

Wenn du claude im Terminal startest, lädt Claude Code alle relevanten CLAUDE.md-Dateien in dieser Reihenfolge und hängt sie an den System-Prompt. Das bedeutet: alles was darin steht, ist immer im Kontext — kein explizites "vergiss nicht, du bist..."-Prompt nötig.

# So sieht ein minimales CLAUDE.md aus
# Datei: /home/user/meinprojekt/CLAUDE.md

# MeinProjekt CLAUDE.md

## Projekt-Überblick
MeinProjekt ist ein FastAPI-Backend für Kundendatenverwaltung.
Stack: Python 3.12, FastAPI, PostgreSQL 16, Redis, Docker.

## Wichtige Befehle
- Tests: pytest tests/ -v
- Dev-Server: uvicorn main:app --reload
- Linting: ruff check . && mypy .
- Migrations: alembic upgrade head

Memory-System und Imports

Ab Claude Code 1.x können CLAUDE.md-Dateien andere Dateien importieren. Das ist nützlich um lange Konfigurationen auf mehrere Dateien aufzuteilen:

# CLAUDE.md mit Imports (neuere Syntax)

## Pflichtlektüre (in dieser Reihenfolge)
1. @FOUNDATION.md  — Grundregeln und Autonomie-Level
2. @COMPANY_RULES.md  — Coding-Standards und Qualitäts-Gates
3. @.claude/rules/security.md  — Sicherheitsrichtlinien

## Unterverzeichnis-Regeln
# Dateien in .claude/rules/ werden automatisch geladen
# wenn du sie in .claude/rules/ ablegst

Tipp CLAUDE.md für Teams

Committe CLAUDE.md ins Git-Repository. So haben alle Entwickler automatisch denselben Kontext und dieselben Regeln. Neue Teammitglieder profitieren sofort vom gespeicherten Projektwissen.

2. Projektkontext und Stack beschreiben

Der erste und wichtigste Abschnitt jeder CLAUDE.md ist der Projektkontext. Claude Code muss verstehen, womit es arbeitet, bevor es sinnvoll helfen kann. Ein guter Kontext beantwortet diese Fragen:

Was ist das Projekt? (Zweck, Domäne, Zielgruppe)
Welche Technologien werden verwendet?
Wie ist die Architektur aufgebaut?
Welche Dateipfade sind kritisch?
Welche Befehle werden häufig gebraucht?

# Projektkontext — Beispiel: SaaS-Plattform

## Projekt: CustomerHub SaaS
CustomerHub ist eine B2B-SaaS-Plattform für CRM und Kundenkommunikation.
Zielgruppe: Mittelständische Unternehmen mit 10-500 Mitarbeitern.
Status: Production (v2.4.1) | ~3.200 aktive Nutzer | EU-Hosting

## Technologie-Stack
# Frontend
- Framework: Next.js 15 (App Router, Server Components)
- Styling: Tailwind CSS v3 + shadcn/ui
- State: Zustand + React Query (TanStack Query v5)
- Auth: NextAuth.js v5

# Backend
- API: FastAPI (Python 3.12) — REST + WebSocket
- Datenbank: PostgreSQL 16 (Supabase) + Redis 7 (Cache)
- Queue: Celery + Redis als Broker
- Storage: S3-kompatibel (Hetzner Object Storage)

# Infrastruktur
- Container: Docker + docker-compose
- CI/CD: GitHub Actions → Kamal Deploy
- Monitoring: Sentry + Prometheus/Grafana

## Wichtige Dateipfade
- API-Routes: src/app/api/
- Datenbank-Models: backend/models/
- Migrations: backend/migrations/ (Alembic)
- E2E-Tests: tests/e2e/ (Playwright)
- Umgebungsvariablen: .env.local (lokal), .env.production (nie committen!)

## Häufig gebrauchte Befehle
```bash
# Entwicklung
npm run dev                    # Next.js Dev-Server (Port 3000)
uvicorn backend.main:app --reload  # FastAPI (Port 8000)
docker-compose up -d           # PostgreSQL + Redis starten

# Tests
npm run test                   # Vitest Unit-Tests
npx playwright test            # E2E-Tests
pytest backend/tests/ -v       # Python-Tests

# Code-Qualität
npm run lint && npm run type-check
ruff check backend/ && mypy backend/
```

Architektur-Überblick in CLAUDE.md

Ein kurzer Architektur-Überblick spart Claude Code viele Suchanfragen und macht Vorschläge direkt passender:

## Architektur-Überblick

```
Browser → Next.js (Vercel Edge) → FastAPI Backend → PostgreSQL
                                       ↓
                                   Celery Worker → Redis Queue
                                       ↓
                               External APIs (Stripe, SendGrid)
```

### Datenfluss
1. User-Requests kommen über Next.js API Routes (Server-Side)
2. Authentifizierung via NextAuth.js JWT → Backend validiert Token
3. Schwere Tasks (Emails, Reports, Exports) → Celery Queue
4. Realtime (Chat, Notifications) → WebSocket über FastAPI

### Multi-Tenancy
- Row-Level Security (RLS) in PostgreSQL
- Tenant-ID in JEDEM Query Pflicht — NIEMALS vergessen!
- Schema: public.tenants, public.users, tenant-spezifische Tabellen

Regel SSOT-Prinzip für Projektkontext

Halte CLAUDE.md als Single Source of Truth für den Projektkontext. Wenn sich der Stack ändert, aktualisiere zuerst CLAUDE.md. So bleibt Claude Code immer auf dem aktuellen Stand — und neue Entwickler wissen sofort wo sie stehen.

3. Coding Standards und verbotene Patterns

Dieser Abschnitt ist der Game-Changer für Teams. Statt Coding-Standards in einem Wiki zu begraben das niemand liest, schreibst du sie direkt in CLAUDE.md — und Claude Code hält sich automatisch daran.

Stil-Regeln explizit definieren

## Coding Standards

### Python (Backend)
- Typ-Annotierungen: IMMER — kein untypisierter Code
- Docstrings: Google-Style für alle öffentlichen Funktionen/Klassen
- Imports: isort-Reihenfolge (stdlib → third-party → local)
- Fehlerbehandlung: spezifische Exceptions, KEIN blankes except:
- Async: async/await durchgängig — keine sync DB-Calls in async Context

### TypeScript (Frontend)
- strict: true in tsconfig — keine Ausnahmen
- Kein any — stattdessen unknown mit Type Guard
- Komponenten: Functional + Arrow Function (KEIN class-based)
- CSS: NUR Tailwind-Klassen — kein inline style, kein CSS-in-JS
- Server Components bevorzugen — Client Components NUR wenn nötig

### Allgemein
- Commit-Format: [type] scope: kurze Beschreibung
  Beispiele: feat(auth): add OAuth2 Google login
             fix(api): handle null tenant_id in middleware
             docs(readme): update deployment steps
- Maximale Zeilenlänge: 100 Zeichen
- Keine magischen Zahlen — immer benannte Konstanten

Verbotene Patterns klar benennen

Das ist der wichtigste Teil vieler CLAUDE.md-Dateien. Explizite Verbote verhindern Fehler bevor sie passieren:

## Verbotene Patterns — NIEMALS verwenden

### Sicherheit
- NIEMALS SQL-Queries mit String-Interpolation (f"SELECT * WHERE id={id}")
  → IMMER parametrisierte Queries oder ORM nutzen
- NIEMALS Secrets/API-Keys hardcoden
  → IMMER aus os.getenv() / process.env. lesen
- NIEMALS eval() oder exec() auf User-Input
- NIEMALS XSS-vulnerable dangerouslySetInnerHTML ohne Sanitization

### Datenbank
- NIEMALS N+1-Queries — IMMER eager loading / joins verwenden
- NIEMALS DB-Calls außerhalb von Repository-Klassen (DDD-Prinzip!)
- NIEMALS SELECT * — IMMER explizite Spalten angeben
- NIEMALS Transactions ohne Rollback-Handling

### Anti-Patterns im Code
- KEINE God-Klassen über 300 Zeilen
- KEINE Funktionen über 50 Zeilen (Ausnahme: gut begründet + Kommentar)
- KEINE Dummy/Placeholder-Implementierungen ohne NotImplementedError
- KEIN auskommentierter Code im Main-Branch
- KEINE Quick-Fixes ohne Root-Cause-Analyse

### Deployment
- NIEMALS direkt auf main pushen — IMMER Pull Request
- NIEMALS CI-Pipeline rot mergen
- NIEMALS --force push auf main oder production

Anti-Quickfix-Regel

Die wichtigste Regel für produktive KI-gestützte Entwicklung: NIEMALS Quick-Fixes, Workarounds oder Hacks. IMMER Root-Cause-Analyse. Claude Code neigt dazu, das Symptom zu beheben — dein CLAUDE.md muss es zwingen, die eigentliche Ursache zu finden.

Test-Anforderungen definieren

## Test-Anforderungen

### Was IMMER getestet werden muss
- Neue API-Endpunkte: Unit-Test + Integration-Test (Pflicht)
- Datenbank-Migrations: Up + Down Migration testen
- Auth-Flows: Happy Path + Edge Cases (expired token, wrong role)
- Externe Integrationen: Mock in Tests, echte Calls nur in E2E

### Test-Struktur
```
tests/
  unit/          # Isolierte Funktionen, keine externen Abhängigkeiten
  integration/   # DB + Services zusammen (echte DB in Testcontainer)
  e2e/           # Browser-Tests (Playwright), nur für kritische User-Flows
```

### Coverage-Ziele
- Backend Unit-Tests: mindestens 80% (gemessen mit pytest-cov)
- Frontend: kritische Komponenten (Auth, Payment, Data-Tables)
- E2E: 5 kritische User Journeys (Login, Onboarding, Core-Feature, Payment, Logout)

### NIEMALS
- Tests auskommentieren mit "temporär deaktiviert"
- Mock-Daten die echte Produktionsdaten imitieren (DSGVO!)
- Tests die von externer Netzwerkverbindung abhängen (außer E2E)

4. Team-Regeln und Workflows

CLAUDE.md ist besonders wertvoll für Teams. Statt Confluence-Seiten die niemand kennt, landen die wichtigsten Workflow-Regeln direkt im Kontext von Claude Code — und damit in jeder Entwicklungssession.

Branch-Strategie

## Git-Workflow und Branch-Strategie

### Branches
- main: Production. Nur via PR mergen. Direkte Pushes VERBOTEN.
- develop: Integration-Branch. Alle Features landen hier zuerst.
- feature/TICKET-123-kurze-beschreibung: Feature-Branches
- fix/TICKET-456-bug-name: Bugfix-Branches
- hotfix/TICKET-789-kritischer-fix: Nur für Production-kritische Fixes

### Branch-Regeln
- Branch IMMER von develop erstellen (nicht von main!)
- Branch-Name MUSS Ticket-Nummer enthalten
- Maximale Branch-Lebensdauer: 2 Wochen (danach eskalieren oder löschen)
- Vor PR-Erstellung: git rebase develop (kein merge-commit Chaos)

### Commit-Konventionen
Format: type(scope): beschreibung
Types: feat | fix | docs | style | refactor | test | chore
- Breaking Changes: feat!: ... mit BREAKING CHANGE im Body
- Commit-Größe: Max 200 geänderte Zeilen (sonst aufteilen)
- Spätestens alle 3-5 Dateiänderungen committen (Crash-Sicherheit!)

Review-Prozess

## Code-Review-Regeln

### PR-Pflichtinhalt
- Beschreibung: Was wurde geändert + Warum
- Testing: Welche Tests wurden hinzugefügt/angepasst
- Screenshots: Bei UI-Änderungen obligatorisch
- Breaking Changes: Explizit markieren + Migrations-Plan

### Review-Standards
- Mindestens 1 Reviewer für alle PRs
- Mindestens 2 Reviewer für: Auth, Payment, Datenbank-Migrationen
- Approval OHNE Kommentar = Rubber-Stamp → NICHT akzeptabel
- Review-Frist: 24h an Werktagen (sonst eskalieren)

### Was Reviewer prüfen
1. Logik korrekt? Edge Cases bedacht?
2. Tests vorhanden und sinnvoll?
3. Keine verbotenen Patterns (siehe oben)?
4. Dokumentation aktualisiert?
5. Performance-Impact bedacht?

### CI muss grün sein BEVOR Review
- Lint + Type-Check: Pflicht
- Unit-Tests: Pflicht
- E2E (Playwright): Pflicht für UI-PRs
- Security-Scan (Dependabot): Pflicht

Deployment-Regeln

## Deployment-Prozess

### Staging-Deploy (automatisch)
1. PR auf develop gemergt → GitHub Action triggert
2. Tests laufen (Unit + Integration + E2E)
3. Bei Grün: Auto-Deploy auf Staging (staging.customerhub.de)
4. Slack-Notification: #deployments

### Production-Deploy (manuell + kontrolliert)
1. Release-Branch: release/vX.Y.Z von develop erstellen
2. CHANGELOG.md updaten (IMMER vor Release!)
3. PR von release → main erstellen (2 Reviewer Pflicht)
4. Nach Merge: GitHub Action deployt via Kamal
5. Smoke-Tests nach Deploy (automatisch + manuell)
6. Rollback-Plan bereit haben (Kamal: kamal app rollback)

### Deployment-Verbote
- KEINE Deploys Freitag nach 15 Uhr (EU-Zeit)
- KEINE Deploys ohne Monitoring-Blick (Sentry + Grafana)
- Bei Zweifel: WARTEN und besprechen

Team Sicherheitsregeln in CLAUDE.md

Sicherheitsregeln gehören in eine separate Datei (.claude/rules/security.md) die von der CLAUDE.md importiert wird. So können Security-Richtlinien unabhängig vom Rest aktualisiert werden — und bleiben trotzdem immer im Kontext.

5. MCP-Server und Tool-Konfiguration

MCP (Model Context Protocol) ist das Erweiterungssystem von Claude Code. Über .claude/settings.json konfigurierst du, welche MCP-Server verfügbar sind, welche Tools erlaubt sind und welche Berechtigungen Claude Code hat.

.claude/settings.json — Grundstruktur

// .claude/settings.json
{
  "model": "claude-opus-4-5",
  "maxTokens": 8192,

  // MCP-Server Konfiguration
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem",
               "/home/user/meinprojekt"],
      "description": "Dateisystem-Zugriff für das Projekt"
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "${POSTGRES_URL}"
      }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "brave-search": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-brave-search"],
      "env": {
        "BRAVE_API_KEY": "${BRAVE_API_KEY}"
      }
    }
  },

  // Tool-Berechtigungen
  "permissions": {
    "allow": [
      "Read",
      "Write",
      "Edit",
      "Bash",
      "Glob",
      "Grep",
      "mcp__filesystem__*",
      "mcp__github__*",
      "mcp__brave-search__*"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force)",
      "mcp__postgres__execute_query(DROP*)"
    ]
  }
}

allowedTools in CLAUDE.md

Ergänzend zur settings.json kannst du in CLAUDE.md selbst definieren, welche Tools Claude Code nutzen soll — und vor allem, welche es nicht nutzen soll:

## Tool-Nutzung und Einschränkungen

### Erlaubte Operationen
- Dateien lesen, erstellen, bearbeiten (im Projektverzeichnis)
- Shell-Befehle ausführen (siehe erlaubte Liste unten)
- GitHub API nutzen (lesen + schreiben, nur unser Repo)
- Datenbankabfragen (SELECT, INSERT, UPDATE — KEIN DROP/TRUNCATE)
- Web-Suche für aktuelle Dokumentation

### Shell-Befehle — NUR diese sind erlaubt
npm run *           # Alle npm-Scripts
npx playwright *    # E2E-Tests
pytest *            # Python-Tests
ruff * && mypy *    # Linting
git status/log/diff # Git-Info (KEIN force push!)
docker-compose *    # Container-Management

### NIEMALS ausführen
- rm -rf ohne explizite Bestätigung
- git push --force auf main/production
- DROP TABLE / TRUNCATE (Produktionsdaten!)
- curl | bash (Supply-Chain-Angriffe)
- Befehle die Ports nach außen öffnen (ufw allow etc.)

MCP-Server	Zweck	Wann nützlich
`@mcp/server-filesystem`	Dateisystem-Zugriff mit Pfad-Beschränkung	Immer — Grundausstattung
`@mcp/server-postgres`	Direkte DB-Abfragen und Schema-Inspektion	Backend-Projekte mit PostgreSQL
`@mcp/server-github`	Issues, PRs, Commits, CI-Status	GitHub-basierte Workflows
`@mcp/server-brave-search`	Web-Suche für aktuelle Doku	Research-intensive Projekte
`@mcp/server-slack`	Team-Kommunikation lesen/schreiben	Ops-Automatisierung

MCP Umgebungsvariablen in MCP-Config

Schreibe niemals echte API-Keys direkt in settings.json. Nutze stattdessen ${ENV_VAR_NAME}-Syntax — Claude Code liest die Werte aus der Shell-Umgebung. So bleiben Secrets aus dem Repository heraus.

6. Advanced: Hooks, Memory und Slash-Commands

Für Power User bietet Claude Code erweiterte Mechanismen: Hooks die vor oder nach Tool-Aufrufen ausgeführt werden, ein persistentes Memory-System und eigene Slash-Commands.

PreToolUse und PostToolUse Hooks

Hooks ermöglichen es, bestimmte Aktionen automatisch vor oder nach Tool-Aufrufen auszulösen. Sie werden in .claude/settings.json konfiguriert:

// .claude/settings.json — Hooks-Konfiguration
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"[HOOK] Bash-Befehl: $CLAUDE_TOOL_INPUT\" >> /tmp/claude-audit.log"
          }
        ]
      },
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command",
            "command": "/scripts/pre-write-check.sh"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run lint --silent 2>/dev/null || true"
          }
        ]
      },
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"[$(date -u +%H:%M:%S)] Tool done\" >> /tmp/claude-audit.log"
          }
        ]
      }
    ]
  }
}

Typische Anwendungsfälle für Hooks:

Audit-Logging: Jeder Bash-Befehl wird protokolliert — wichtig für Compliance und Debugging
Auto-Lint: Nach jedem Write-Aufruf automatisch Linting laufen lassen
Pre-Write-Guard: Vor dem Schreiben prüfen ob eine Datei schreibgeschützt ist
Notification: Bei bestimmten Tool-Calls eine Slack-Nachricht senden

Memory-Dateien und Persistenz

Claude Code vergisst zwischen Sessions. Um wichtiges Wissen zu persistieren, gibt es das Memory-System. In CLAUDE.md definierst du, was Claude Code nach bestimmten Ereignissen speichern soll:

## Memory und Persistenz

### Was gespeichert werden soll
Nach jedem erfolgreichen Task IMMER updaten:
- MEMORY.md: Was funktioniert hat, was nicht, wichtige Entscheidungen
- CHECKPOINT.md: Aktueller Aufgaben-Status vor Session-Ende

### Memory-Struktur
```
.claude/
  memory/
    MEMORY.md      # Persistente Erkenntnisse (manuell pflegen)
    learnings/     # Spezifische Learnings pro Thema
  CHECKPOINT.md    # Aktueller Status (wird überschrieben)
```

### /compact — Kontext-Komprimierung
Bei langen Sessions (>60% Context-Window) IMMER /compact nutzen:
1. Wichtige Punkte vor /compact als Checkpoint sichern
2. /compact ausführen → Claude komprimiert den Kontext
3. Nach /compact: MEMORY.md und CHECKPOINT.md neu laden

### Wann Checkpoint erstellen
- Nach jedem git commit
- Vor jedem Deploy
- Bei >50% Context-Window
- Bei Session-Ende

Eigene Slash-Commands definieren

Slash-Commands sind wiederverwendbare Prompts die du mit /name aufrufen kannst. Sie werden in .claude/commands/ als Markdown-Dateien gespeichert:

# .claude/commands/review.md
# Aufruf: /review

Führe ein Code-Review des aktuell geöffneten/geänderten Codes durch.

Prüfe folgende Punkte:
1. Werden verbotene Patterns aus CLAUDE.md verletzt?
2. Gibt es potenzielle Security-Issues (OWASP Top 10)?
3. Fehlen Tests für neuen/geänderten Code?
4. Ist die Fehlerbehandlung vollständig?
5. Sind Typen korrekt annotiert?

Ausgabe-Format:
- ✅ Was gut ist (kurz)
- ⚠️ Was verbessert werden sollte (mit Code-Beispiel)
- ❌ Was MUSS gefixt werden bevor Merge (mit Begründung)

# .claude/commands/deploy-check.md
# Aufruf: /deploy-check

Deployment-Readiness-Check durchführen:

1. Laufen alle Tests? (npm test && pytest tests/)
2. Ist CHANGELOG.md aktualisiert?
3. Gibt es uncommittete Änderungen? (git status)
4. Ist die Version in package.json bumped?
5. Sind alle Umgebungsvariablen in .env.production gesetzt?

Nur bei ALLEN Checks grün:
"Deployment kann starten. Führe aus: npm run deploy:staging"

Bei Problemen:
Liste alle offenen Punkte mit Anweisungen zur Behebung.

# .claude/commands/debug.md
# Aufruf: /debug $BESCHREIBUNG

Root-Cause-Analyse für: $BESCHREIBUNG

Vorgehen (IMMER in dieser Reihenfolge):
1. Symptome beschreiben (was sehen wir genau?)
2. Hypothesen aufstellen (mindestens 3 mögliche Ursachen)
3. Jede Hypothese systematisch prüfen
4. Root Cause identifizieren
5. Fix implementieren (keine Workarounds!)
6. Fix verifizieren (BEIDE Code-Pfade testen)
7. Learnings in MEMORY.md dokumentieren

NIEMALS:
- Timeout erhöhen statt den echten Fehler zu finden
- Code auskommentieren als "temporären" Fix
- "Funktioniert" melden wenn nur 1 von 2 Pfaden läuft

CLAUDE.md für Multi-Agent-Systeme

Wenn du mehrere Claude Code Instanzen parallel nutzt — zum Beispiel für ein Agenten-Team das verschiedene Aspekte eines Projekts bearbeitet — wird CLAUDE.md noch kritischer:

## Multi-Agent-Koordination

### Rollen in diesem Projekt
- CEO-Agent: Koordiniert, delegiert, trifft Entscheidungen — schreibt KEINEN Code
- Coder-Agent: Implementiert Features, schreibt Tests, macht Code-Reviews
- Research-Agent: Recherchiert, analysiert, erstellt Berichte
- Runner-Agent: Führt Tests aus, deployt, überwacht CI

### Kommunikationsregeln
- Jede Agent-Nachricht: [Agent-Name → Agent-Name] Inhalt
- Ergebnisse SOFORT melden — nicht sammeln
- Bottom-Up-Reporting: Worker → Lead → Manager → CEO

### Spawn-Regeln
- Manager-Agents spawnen Sub-Agents via Agent()-Tool
- NIEMALS direkt auf externen Maschinen spawnen
- bypassPermissions IMMER für Worker-Agents setzen

Praxis-Tipp: CLAUDE.md iterativ aufbauen

Starte mit einem Minimal-CLAUDE.md (Stack + 3 wichtigste Regeln). Füge nach jeder Session hinzu, was Claude Code falsch gemacht oder nicht gewusst hat. Nach 2 Wochen hast du eine CLAUDE.md die genau auf dein Projekt zugeschnitten ist.

Die vollständige CLAUDE.md-Vorlage

Hier ist eine produktionsreife Grundstruktur die du für eigene Projekte nutzen kannst:

# CLAUDE.md — [Projektname]
# Automatisch geladen von Claude Code bei jedem Start

## Pflichtlektüre (diese Dateien VOR der Arbeit lesen)
1. @.claude/rules/security.md  — Sicherheitsregeln (ABSOLUT BINDEND)
2. @.claude/rules/coding-standards.md  — Code-Qualität

## Projekt-Überblick
[Projektname + Zweck + Stack + Status]

## Wichtige Befehle
- Dev: ...
- Test: ...
- Lint: ...
- Deploy: ...

## Architektur
[ASCII-Diagramm + kurze Erklärung]

## Coding Standards
[Sprachenspezifische Regeln + allgemeine Prinzipien]

## Verbotene Patterns — NIEMALS
[Explizite Liste was Claude Code NICHT tun darf]

## Test-Anforderungen
[Was getestet werden muss + Coverage-Ziele]

## Git-Workflow
[Branch-Strategie + Commit-Format + Review-Prozess]

## Memory-Regeln
[Wann/Was in MEMORY.md speichern]

## Eskalationsregeln
[Bei welchen Problemen warten und nachfragen]

Claude Code in deinem Team einsetzen?

Starte deinen kostenlosen Trial und entdecke wie du mit konfigurierten Agenten echte Entwicklungsarbeit automatisieren kannst — mit CLAUDE.md genau auf dein Projekt abgestimmt.

Kostenlos ausprobieren →

Fazit: CLAUDE.md als Investment

Eine gut geschriebene CLAUDE.md ist kein Overhead — sie ist ein Multiplikator. Jede Stunde die du investierst um CLAUDE.md zu verbessern, spart dir Dutzende Stunden falsch generiertem Code, Debugging von AI-Fehlern und erklärenden Gesprächen die bei null anfangen.

Die wichtigsten Punkte zusammengefasst:

Hierarchie nutzen: Global → Projekt → Subfolder — je spezifischer desto hilfreicher
Verbote explizit machen: Was Claude Code nicht tun soll, muss explizit verboten werden
Standards-First: Coding Standards in CLAUDE.md statt in einem Wiki das niemand liest
MCP konfigurieren: Die richtigen Tools aktivieren und sichern via settings.json
Hooks für Automation: Pre/PostToolUse für Linting, Logging, Validierung
Memory aufbauen: MEMORY.md + Checkpoints für Persistenz über Sessions hinweg
Iterativ verbessern: Nach jeder Session updaten was Claude Code nicht wusste

Claude Code ist so gut wie der Kontext den du ihm gibst. CLAUDE.md ist dieser Kontext.

← Alle Artikel | KI-Agenten mit Claude Code →