Es gibt eine einzige Datei, die den Unterschied macht zwischen einem Claude Code, der ständig nachfragt, falsche Konventionen benutzt und Architekturentscheidungen ignoriert — und einem Claude Code, der sich anfühlt wie ein Senior-Entwickler, der das Projekt seit Monaten kennt. Diese Datei heißt CLAUDE.md.
In diesem Guide zeigen wir dir alles, was du wissen musst: von der grundlegenden Struktur bis zu fortgeschrittenen Multi-Package-Patterns, Memory-Integration und versionierten Regelwerken für größere Teams.
Inhalt
Basics 1. CLAUDE.md Grundlagen & automatisches Laden
CLAUDE.md ist eine Markdown-Datei, die Claude Code beim Start automatisch in seinen Kontext lädt — ohne dass du jedes Mal manuell Anweisungen geben musst. Sie funktioniert als persistente Wissensbasis über dein Projekt, dein Team und deine Regeln.
Wo wird CLAUDE.md gelesen?
Claude Code lädt CLAUDE.md-Dateien aus mehreren Verzeichnissen gleichzeitig. Dabei gilt eine klare Hierarchie:
📁 Lade-Hierarchie (von allgemein zu spezifisch)
- ~/.claude/CLAUDE.md — Globale User-Regeln (gilt für ALLE Projekte)
- /projekt-root/CLAUDE.md — Projekt-weite Regeln (wird am häufigsten genutzt)
- /projekt-root/src/CLAUDE.md — Verzeichnis-spezifische Regeln
- /projekt-root/packages/ui/CLAUDE.md — Package-spezifische Regeln (Monorepos)
Spezifischere Regeln überschreiben allgemeinere — aber alle aktiven CLAUDE.md-Dateien werden zusammengeführt. Das bedeutet: Globale Grundregeln bleiben erhalten, während pakettspezifische Details nur dort gelten, wo sie relevant sind.
Tipp
Claude Code lädt CLAUDE.md beim Start der Session sowie automatisch wenn du in ein neues Verzeichnis navigierst, das eine CLAUDE.md enthält.
Wann wird CLAUDE.md wirklich gelesen?
Die Datei wird in folgenden Situationen aktiv genutzt:
- Beim Start jeder Claude Code Session im Projektverzeichnis
- Wenn Claude Code eine Frage zu Konventionen oder Architektur bekommt
- Wenn Code-Generierung stattfindet (Naming, Struktur, Imports)
- Wenn Claude Code eigenständig Entscheidungen trifft (welche Bibliothek? welches Pattern?)
- Beim Navigieren in Unterverzeichnisse mit eigener CLAUDE.md
# Minimales CLAUDE.md Skeleton — ein guter Startpunkt
# Projektname
## Tech-Stack
- Node.js 20 + TypeScript 5.4
- React 18 mit Vite
- PostgreSQL 16 via Prisma ORM
- Deployment: Docker + Hetzner Cloud
## Build & Run
```bash
npm run dev # Entwicklung (Port 3000)
npm run build # Produktions-Build
npm test # Vitest Unit-Tests
npm run e2e # Playwright E2E
```
## Wichtige Dateipfade
- src/ — Quellcode
- src/api/ — REST API Routen
- prisma/schema.prisma — Datenbank-Schema
- tests/ — Unit + E2E Tests
Context 2. Projekt-Kontext richtig dokumentieren
Der Projekt-Kontext ist das Herzstück deiner CLAUDE.md. Hier entscheidest du, welche Informationen Claude Code braucht, um sofort produktiv zu sein — ohne ellenlange Einführungen zu benötigen oder falsche Annahmen zu treffen.
Was gehört in den Projekt-Kontext?
✅ Pflicht-Informationen
- Tech-Stack mit genauen Versionen (nicht "React" sondern "React 18.3")
- Architektur-Übersicht in 3-5 Sätzen (was macht das System?)
- Wichtige Dateipfade & Verzeichnisstruktur
- Build, Test und Run Befehle
- Deployment-Umgebungen (Dev/Staging/Prod)
# MeinProjekt CLAUDE.md
## Architektur-Übersicht
MeinProjekt ist ein B2B SaaS für Lagerlogistik. Kernkomponenten:
- Frontend: React 18 SPA mit Zustand (state management) + TanStack Query
- Backend: Fastify API (Node.js 20), vollständig typisiert mit Zod
- Datenbank: PostgreSQL 16 — Prisma als ORM, NIEMALS raw SQL
- Auth: JWT via better-auth Library (nicht NextAuth, nicht Supabase Auth)
- Infrastruktur: Docker Compose lokal, Kubernetes in Prod (Hetzner)
## Verzeichnisstruktur
```
src/
api/ # Fastify Routen (eine Datei pro Domain)
services/ # Business Logic (keine DB-Calls hier!)
repositories/ # Alle Prisma-Queries hier zentralisiert
schemas/ # Zod Schemas (shared zwischen Frontend + Backend)
components/ # React Komponenten (Atomic Design)
hooks/ # Custom React Hooks
tests/
unit/ # Vitest — isolierte Unit-Tests
integration/ # Vitest — echte DB (test container)
e2e/ # Playwright
```
## Environment Variables
Alle Secrets in .env.local (NIEMALS hardcoden).
Schema in src/config/env.ts via Zod validiert — dort zuerst schauen.
Architektur-Entscheidungen erklären
Besonders wertvoll: Erkläre warum bestimmte Entscheidungen getroffen wurden. Das verhindert, dass Claude Code besserwisserisch andere Patterns vorschlägt.
## Architektur-Entscheidungen (ADRs)
# Warum Fastify statt Express?
Fastify wegen 2x Performance bei JSON-Serialisierung + nativer TypeScript-Support.
Nicht zu Express wechseln, auch wenn Snippets aus dem Internet Express nutzen.
# Warum Prisma statt Drizzle/Kysely?
Prisma wurde 2024 eingeführt wegen besserer Schema-Migration-Tooling.
Drizzle wurde evaluiert aber abgelehnt — kein Rollback für bestehenden Prisma-Code.
# Warum kein Redux?
Zustand ist ausreichend für unsere Complexity. Redux = overkill, wird NICHT eingeführt.
Häufiger Fehler
Vage Beschreibungen wie "wir nutzen React und Node.js" helfen Claude Code kaum. Sei präzise: Versionen, konkrete Libraries, Deployment-Targets. Je spezifischer, desto besser.
Wichtige Dateipfade als Orientierung
Gib Claude Code eine Karte des Projekts. Welche Dateien sind Einstiegspunkte? Wo liegt die Business-Logik? Was sollte auf keinen Fall geändert werden?
## Wichtige Dateipfade
# Einstiegspunkte
- src/main.ts — App-Bootstrap, Plugin-Registration
- src/router.ts — API-Routing-Übersicht (alle Routen hier registriert)
- src/app.tsx — React Root, Provider-Stack
# Konfiguration
- prisma/schema.prisma — Datenbank-Schema (SSOT!)
- src/config/env.ts — Alle ENV-Variablen mit Typen
- vite.config.ts — Build-Konfiguration
# NICHT anfassen ohne Rücksprache
- src/auth/ — Auth-Logik ist legacy, komplex, hat Quirks
- migrations/ — NIEMALS manuell editieren, nur via prisma migrate
Standards 3. Coding Standards & verbotene Patterns
Coding Standards in CLAUDE.md sind anders als in einem ESLint-Config-File: Du kannst hier nicht nur Regeln definieren, sondern auch den Kontext dahinter erklären. Das führt zu deutlich besserem Code als reine Linter-Konfiguration.
Naming Conventions
## Naming Conventions
# TypeScript / JavaScript
- Variablen/Funktionen: camelCase
- Klassen/Interfaces/Types: PascalCase
- Konstanten: SCREAMING_SNAKE_CASE
- Private Methoden: _leadingUnderscore (nur in Klassen)
- Dateien: kebab-case.ts (NICHT PascalCase für Dateien!)
# React Komponenten
- Komponenten-Dateien: PascalCase.tsx
- Custom Hooks: use Prefix, camelCase (z.B. useOrderStatus)
- Context Provider: XyzProvider + useXyz Hook
- Props Interfaces: ComponentNameProps (NICHT "Props" standalone)
# API Routes
- Routen: kebab-case, Plural für Collections (/orders, nicht /order)
- Query-Parameter: camelCase im Code, aber snake_case in der URL
- NIEMALS PascalCase in URLs
Import-Reihenfolge
Konsistente Import-Reihenfolge verhindert Merge-Konflikte und macht Dateien schneller parsbar:
## Import-Reihenfolge (Pflicht)
# Immer in dieser Reihenfolge, getrennt durch Leerzeile:
1. Node.js Built-ins (node:path, node:fs etc.)
2. Externe Pakete (react, fastify, prisma...)
3. Interne Absolute Imports (@/services, @/schemas...)
4. Relative Imports (../utils, ./helper)
5. Type-only Imports (import type { ... })
# Beispiel:
import { readFile } from 'node:fs/promises'
import { z } from 'zod'
import Fastify from 'fastify'
import { OrderService } from '@/services/order'
import { orderSchema } from '@/schemas/order'
import { formatDate } from '../utils/date'
import type { Order, OrderStatus } from '@/types'
Verbotene Patterns — explizit und mit Begründung
Der wichtigste Abschnitt: Was Claude Code nicht tun soll. Mit Begründung, damit es nicht als willkürlich ignoriert wird.
## Verbotene Patterns (NIEMALS verwenden)
### 1. any in TypeScript
VERBOTEN: const data: any = fetchSomething()
KORREKT: const data: Order = fetchSomething()
Warum: any untergräbt das gesamte Typsystem. Lieber unknown + type guard.
### 2. Direkte DB-Queries in Route-Handlern
VERBOTEN: await prisma.order.findMany() // direkt in der Route
KORREKT: await orderRepository.findAll() // über Repository-Layer
Warum: Testbarkeit, Separation of Concerns, kein Prisma-Lock in der Route.
### 3. console.log für Logging
VERBOTEN: console.log('User created:', userId)
KORREKT: logger.info({ userId }, 'User created')
Warum: Wir nutzen Pino Logger mit strukturiertem JSON-Output für Log-Aggregation.
### 4. Inline Styles in React
VERBOTEN: <div style={{ color: 'red' }}>
KORREKT: Tailwind CSS Klassen oder CSS Modules
Warum: Design-System-Konsistenz, Tailwind ist bereits konfiguriert.
### 5. Synchrone File-Operationen
VERBOTEN: fs.readFileSync(), fs.writeFileSync()
KORREKT: await fs.readFile(), await fs.writeFile()
Warum: Blockiert den Node.js Event-Loop, Performance-Killer in Production.
### 6. Default Exports (außer für React Komponenten)
VERBOTEN: export default function processOrder() {}
KORREKT: export function processOrder() {}
Warum: Named Exports sind refactoring-freundlicher, bessere IDE-Unterstützung.
Anti-Pattern Tabelle
| Anti-Pattern | Problem | Korrekte Alternative |
|---|---|---|
| Promise.all ohne Error-Handling | Ein Fehler bricht alle Promises | Promise.allSettled + Fehlerprüfung |
| Mutations in useState direkt | React erkennt Änderungen nicht | Immutable Updates via Spread / immer |
| env vars direkt lesen (process.env.X) | Kein Typ, kein Fallback, kein Validation | Import aus src/config/env.ts |
| Hardcodierte URLs / IPs | Bricht in anderen Environments | Config-Variablen aus env.ts |
| catch(e) ohne Logging | Fehler verschwinden still | logger.error({ err: e }, 'context') |
Workflow 4. Workflows, Commits & Review-Prozesse
Claude Code kann aktiv in deinen Entwicklungs-Workflow integriert werden. Definiere klare Prozesse — von Branch-Naming bis zum Deploy — damit Claude Code keine Annahmen trifft.
Branch-Naming & Commit-Format
## Git Workflow
### Branch-Naming
Schema: type/JIRA-ID-kurze-beschreibung
Types: feat, fix, chore, refactor, docs, test
Beispiele:
- feat/OM-142-batch-order-export
- fix/OM-156-null-pointer-in-shipment
- chore/OM-160-upgrade-fastify-v5
### Commit-Format (Conventional Commits)
type(scope): kurze Beschreibung (max 72 Zeichen)
Gültige Types: feat, fix, docs, style, refactor, test, chore, perf, ci
Gültige Scopes: api, ui, db, auth, infra, config
Beispiele:
feat(api): add batch order export endpoint
fix(auth): prevent token refresh race condition
perf(db): add index on orders.created_at
test(api): add integration tests for shipment route
### NIEMALS in einem Commit:
- Mehrere unzusammenhängende Änderungen (atomic commits!)
- "WIP", "fixfix", "asdf" als Commit-Message
- Direkt auf main pushen (außer Hotfixes mit Rücksprache)
PR-Prozess & Review-Checkliste
## Pull Request Prozess
### Vor dem PR erstellen:
- [ ] npm test lokal grün
- [ ] npm run lint ohne Errors
- [ ] TypeScript: npm run typecheck fehlerfrei
- [ ] Neue Funktionalität hat Unit-Tests
- [ ] DB-Änderungen haben Migration (prisma migrate dev)
- [ ] CLAUDE.md aktualisiert falls neue Patterns eingeführt
### PR-Beschreibung muss enthalten:
- Was wurde geändert? (1-3 Sätze)
- Warum? (Business-Kontext oder Bug-Referenz)
- Wie testen? (Schritte für Reviewer)
- Screenshots bei UI-Änderungen
### Merge-Kriterien:
- Mindestens 1 Reviewer-Approval (bei kritischen Pfaden: 2)
- Alle CI-Jobs grün (Tests + Lint + TypeCheck + E2E)
- Keine ungelösten Review-Kommentare
- NIEMALS mit "--no-verify" pushen
### Branch-Cleanup:
Nach Merge: Branch löschen (GitHub macht das automatisch)
Deploy-Prozess
## Deployment
### Environments
- Development: Lokal via docker-compose up
- Staging: Auto-Deploy bei merge in develop Branch
- Production: Manueller Trigger via GitHub Actions (nur main)
### Deploy-Checkliste für Production:
1. Staging 24h stabil (keine Fehler in Sentry)
2. DB-Migrations: prisma migrate deploy VOR App-Deploy
3. Feature-Flags aktivieren nach Deploy, nicht davor
4. Health-Check: /health Endpoint muss 200 zurückgeben
5. Rollback-Plan: kubectl rollout undo deployment/api
### NIEMALS:
- Direkt in Production deployen ohne Staging-Test
- Migrations und App-Code gleichzeitig deployen
- Deploy Freitag nach 15:00 Uhr
Best Practice
Integriere deine CLAUDE.md in deinen Onboarding-Prozess. Neue Entwickler, die CLAUDE.md lesen, verstehen das Projekt genauso schnell wie Claude Code selbst.
Team 5. Team-spezifische Regeln & Domänen-Glossar
Jedes Team entwickelt im Laufe der Zeit sein eigenes Vokabular, seine eigenen Abkürzungen und seine eigene Interpretation von Business-Konzepten. CLAUDE.md ist der perfekte Ort, um dieses Wissen zu externalisieren.
Domänen-Glossar
Erkläre fachliche Begriffe, die im Code auftauchen. Das verhindert, dass Claude Code allgemeine Definitionen anwendet statt projektspezifische.
## Domänen-Glossar
### Kernbegriffe (NICHT mit allgemeiner Bedeutung verwechseln!)
Order:
Ein Kundenauftrag im System. NICHT verwechseln mit "Bestellung" (das ist ein Einkauf).
Orders haben Status: DRAFT → CONFIRMED → PROCESSING → SHIPPED → DELIVERED | CANCELLED
Technisch: Tabelle orders, immer via OrderRepository laden.
Shipment:
Eine physische Liefereinheit für eine oder mehrere Orders.
Eine Order kann mehrere Shipments haben (Teillieferungen).
WICHTIG: Shipment !== Order. API-Pfade: /shipments, nicht /orders/:id/delivery
SKU:
Stock Keeping Unit — eindeutige Produktkennung.
Format: CAT-SUBCAT-NUMMER (z.B. EL-KB-00142 = Elektronik, Keyboard, Nr. 142)
NIEMALS numerische IDs für SKUs verwenden!
Carrier:
Logistikdienstleister (DHL, UPS, Hermes...).
In der DB: carriers Tabelle mit Code (z.B. DHL_DE).
KEIN direkter API-Call an Carrier — immer über CarrierService abstrahieren.
Backorder:
Order-Position die nicht sofort verfügbar ist.
Spezialfall: hat eigene State Machine, NICHT wie normale Orders behandeln.
Technisch: orders.type = 'BACKORDER'
Business-Logik-Kontext
## Business-Logik Besonderheiten
### Preisberechnung (KRITISCH)
Preise sind IMMER in Cent (Integer), NIEMALS Floats!
VERBOTEN: price: 19.99
KORREKT: priceInCents: 1999
Steuerberechnung: Steuer wird IMMER separat gespeichert (taxInCents).
Brutto = netto + tax. NIEMALS Brutto aus Netto berechnen und runden!
### Bestandsverwaltung
Lagerbestand kann negativ werden (Backorder-Mechanismus).
KEINE Validierung auf >= 0 einbauen ohne Rücksprache!
Reservierungen laufen über StockReservation (optimistic locking).
### Multi-Mandantenfähigkeit
JEDE Datenbankabfrage MUSS tenantId im WHERE-Clause haben.
Das Repository-Layer handhabt das automatisch via BaseRepository.
NIEMALS direkte Prisma-Calls ohne tenantId-Filter!
Bekannte Fallstricke & Legacy-Erklärungen
## Bekannte Fallstricke
### Legacy: OrderV1 vs OrderV2
Historisch: Bis 2024 hatten wir zwei Order-Systeme parallel.
OrderV1: legacy, nur noch READ-Zugriff, NICHT mehr schreiben!
OrderV2: aktuelles System, alle neuen Features hier
Erkennbar an: orders.version Feld (1 oder 2)
Code: src/legacy/ = V1, src/services/ = V2
### Timezone-Gotcha
Alle Timestamps in der DB sind UTC.
Frontend zeigt lokale Zeit des Browsers.
NIEMALS new Date() direkt für DB-Writes — immer toUTC() Helper nutzen.
Bug-History: 2023 haben wir 3 Stunden Timezone-Probleme gehabt. Bitte nicht wiederholen.
### Prisma Client Singleton
NICHT new PrismaClient() in Funktionen aufrufen!
Es gibt einen zentralen Singleton in src/db/client.ts.
Mehrere PrismaClient-Instanzen = Connection-Pool-Probleme in Production.
### Test-Fixtures vs. Factories
Unit-Tests: src/tests/factories/ (TypeScript Factories, kein DB-Call)
Integration-Tests: src/tests/fixtures/ (echte DB-Einträge via Seeder)
NIEMALS Fixtures in Unit-Tests — zu langsam, zu fragil.
Advanced 6. Fortgeschrittene Patterns & Skalierung
Wenn ein einfaches CLAUDE.md an seine Grenzen stößt — wegen Monorepo-Komplexität, verschiedenen Teams oder langen Dokumenten — gibt es fortgeschrittene Patterns, die die Konfiguration skalierbar machen.
Sub-CLAUDE.md in Packages (Monorepo)
In Monorepos macht es Sinn, separate CLAUDE.md-Dateien pro Package zu pflegen. Das Root-CLAUDE.md enthält globale Regeln, die Sub-Dateien paket-spezifische Ergänzungen.
# Monorepo Struktur
/
├── CLAUDE.md # Globale Regeln (Tech-Stack, Konventionen)
├── packages/
│ ├── ui/
│ │ └── CLAUDE.md # UI-spezifisch: Storybook, Design Tokens
│ ├── api/
│ │ └── CLAUDE.md # API-spezifisch: Fastify-Plugins, Middleware
│ └── shared/
│ └── CLAUDE.md # Shared-Lib: was hier liegen darf/nicht
└── apps/
├── web/
│ └── CLAUDE.md # Web-App: Next.js Konventionen, Routing
└── admin/
└── CLAUDE.md # Admin-App: andere Zielgruppe, andere Patterns
# packages/ui/CLAUDE.md — Beispiel
# UI Package
## Globale Regeln gelten — zusätzlich:
## Design System
Alle Komponenten folgen Atomic Design:
- atoms/: Button, Input, Badge (keine Logik, nur Darstellung)
- molecules/: FormField, SearchBar (kombinierte Atoms)
- organisms/: DataTable, OrderCard (komplexe UI-Einheiten)
- templates/: PageLayout, DashboardLayout
## Storybook
JEDE neue Komponente braucht eine Story-Datei (ComponentName.stories.tsx).
Stories müssen alle relevanten States zeigen (loading, error, empty, populated).
npm run storybook zum Testen.
## Design Tokens
Farben NIEMALS hardcoden — nur Tokens aus tokens.css verwenden!
VERBOTEN: color: #6366f1
KORREKT: color: var(--color-primary)
Imports für lange Dokumentation
Für sehr umfangreiche Regelwerke können externe Markdown-Dateien referenziert werden. So bleibt CLAUDE.md übersichtlich, während Details in separaten Dateien leben.
# In CLAUDE.md referenzieren:
## Detailregeln
Für ausführliche Dokumentation zu spezifischen Themen:
- Security-Regeln: Siehe .claude/rules/security.md
- API-Konventionen: Siehe .claude/rules/api-standards.md
- Test-Strategie: Siehe .claude/rules/testing.md
- DB-Guidelines: Siehe .claude/rules/database.md
# Claude Code liest Dateien die in CLAUDE.md referenziert werden
# automatisch mit — nutze @filepath Syntax:
Detailregeln: @.claude/rules/security.md
Memory-Integration
Für agentic Workflows lässt sich CLAUDE.md mit einem Memory-System kombinieren. Langzeit-Wissen wird persistent gespeichert und bei Bedarf abgerufen — besonders nützlich für Agents, die 24/7 laufen.
## Memory & Wissens-Management
### Kurzzeitgedächtnis (Session)
CLAUDE.md wird bei jeder Session geladen — ideal für unveränderliche Regeln.
### Langzeitgedächtnis (Persistent)
Für Wissen das sich ändert oder angesammelt wird:
- memory recall "suchbegriff" — Wissen aus Qdrant abrufen
- memory save "content" — Neues Wissen persistent speichern
### Was gehört wo?
CLAUDE.md: Unveränderliche Projektregeln, Tech-Stack, Standards
Memory: Lessons Learned, Debugging-Notizen, Team-Entscheidungen, Erfahrungswerte
### MEMORY.md (Fallback)
Falls kein Qdrant verfügbar:
MEMORY.md im Projektroot als file-basiertes Gedächtnis nutzen.
Format: ### [Datum] Thema + kurze Notiz (max 1 Zeile im Index)
Versionierung & Changelog für CLAUDE.md
## CLAUDE.md Changelog
### Warum CLAUDE.md versionieren?
Bei größeren Teams ändern sich Regeln. Ein Changelog hilft:
- Nachvollziehen wann/warum eine Regel eingeführt wurde
- Onboarding: neues Teammitglied sieht Kontext hinter Regeln
- AI-Agent: versteht Priorität und Stabilität von Regeln
# Beispiel-Changelog am Ende der CLAUDE.md:
## Änderungshistorie
- 2026-05-06: Repository-Pattern für DB-Queries als Pflicht eingeführt (PR #234)
- 2026-04-20: Prisma Singleton-Regel nach Production-Incident (Ticket OM-891)
- 2026-03-15: Cent-Regel für Preise dokumentiert (war implizit, jetzt explizit)
- 2026-02-01: OrderV1 als deprecated markiert, nur noch READ erlaubt
CLAUDE.md Qualitätscheckliste
✓ Dein CLAUDE.md ist vollständig wenn...
- Ein neuer Entwickler (oder Agent) in 5 Minuten weiß, wie das Projekt aufgebaut ist
- Alle verbotenen Patterns mit Begründung dokumentiert sind
- Build, Test und Run-Befehle sofort auffindbar sind
- Domänen-spezifische Begriffe erklärt sind
- Deployment-Prozess klar beschrieben ist
- Bekannte Fallstricke und Legacy-Bereiche markiert sind
- Ein Changelog vorhanden ist (bei Teams mit mehr als 3 Personen)
- Sub-CLAUDE.md Dateien existieren wenn Package-spezifische Regeln nötig sind
Fazit: CLAUDE.md ist dein persistentes Team-Gehirn
CLAUDE.md ist keine Dokumentation die niemand liest — es ist eine lebendige Konfiguration, die direkten Einfluss auf die Qualität jeder Zeile Code hat, die Claude Code generiert. Die Zeit, die du in eine gute CLAUDE.md investierst, zahlt sich hundertfach aus durch weniger Nachfragen, bessere Code-Qualität und einen AI-Assistenten, der sich wie ein eingearbeitetes Teammitglied anfühlt.
Die wichtigsten Prinzipien zusammengefasst:
- Sei spezifisch — Versionen, Dateipfade, konkrete Beispiele statt vager Beschreibungen
- Erkläre das Warum — Regeln ohne Kontext werden ignoriert oder umgangen
- Verbotene Patterns explizit nennen — was nicht in CLAUDE.md steht, gilt als erlaubt
- Hierarchisch denken — Global/Projekt/Package, von allgemein zu spezifisch
- Aktuell halten — Eine veraltete CLAUDE.md ist schlimmer als keine
- Memory ergänzen — Statische Regeln in CLAUDE.md, dynamisches Wissen in Memory
Claude Code noch effizienter nutzen?
Teste SpockyMagicAI kostenlos — unsere Plattform kombiniert Claude Code mit Team-Koordination, Memory-System und automatischen Workflows. CLAUDE.md wird zur Basis eines ganzen Agent-Teams.
Kostenlos starten →Kein Kreditkarte erforderlich · In 5 Minuten eingerichtet