---

1) Was ist die CLAUDE.md?

Die CLAUDE.md ist eine reine Markdown-Datei, die Claude Code automatisch liest, sobald eine Session startet. Der Inhalt landet im Systemkontext — Claude weiß also vor dem ersten Prompt schon, wer du bist, womit du arbeitest und welche Regeln gelten.

Es gibt zwei Speicherorte:

Ebene	Pfad	Zweck
User	~/.claude/CLAUDE.md	Globale Präferenzen — gelten in jedem Projekt
Project	./CLAUDE.md im Projekt-Root	Projektspezifische Regeln — gelten nur hier

Beide werden geladen. Project überschreibt nicht — es ergänzt User.

2) User CLAUDE.md — Wer bist du?

Die User-Memory beantwortet drei Kernfragen:

• Wer bin ich? (Rolle, Stack, Sprache)
• Wie arbeite ich? (Workflow, Tooling, Präferenzen)
• Wie soll Claude mit mir umgehen? (Tonalität, Output-Format, Pushback-Regeln)

Was rein gehört

• Name, Rolle, primäre Programmiersprache
• Standard-Tools (Editor, Terminal, Package Manager)
• Allgemeine Code-Style-Präferenzen
• Antwort-Format (kurz vs. ausführlich, Sprache, Emojis)
• Persönliche Arbeitsweise (Deep-Work-Zeiten, ADHS-Hinweise, Pushback-Wünsche)

Was NICHT rein gehört

• Firmen-Geheimnisse, API-Keys, Credentials
• Projektspezifische Architektur
• Kundennamen oder vertrauliche Mandanten-Infos

3) Project CLAUDE.md — Was ist das hier?

Die Project-Memory beantwortet die Fragen, die für diese Codebase gelten:

• Was ist das hier für ein Projekt?
• Wie ist es aufgebaut?
• Welche Konventionen gelten?
• Welche Befehle braucht man?

Was rein gehört

• Projektname, Zweck, Tech-Stack
• Ordnerstruktur (kurz erklärt)
• Build-/Test-/Deploy-Commands
• Naming Conventions, Code-Style-Regeln
• Verbotene Patterns (z. B. „kein any in TypeScript")
• Verweise auf wichtige Files

Was NICHT rein gehört

• Persönliche Vorlieben (gehören in User-Memory)
• Sensitive Konfiguration (gehört in .env)
• Lange Architektur-Dokumente (Verweis auf /docs/ reicht)

4) Beispiel: User CLAUDE.md

Hypothetisches Beispiel für eine Freelance-Entwicklerin namens Mira:

# User Memory — Mira Lindqvist

## Wer ich bin
Freelance Fullstack-Entwicklerin, Stockholm.
Sprache: Deutsch oder Englisch je nach Kunde — Default Englisch.
Schwerpunkt: Next.js, TypeScript, Supabase.

## Tooling
- Editor: Cursor / VS Code
- Terminal: Ghostty + zsh
- Package Manager: pnpm (immer, nie npm)
- Git: Conventional Commits

## Code-Style (global)
- TypeScript strict, **kein** `any`
- Functional Components, keine Class Components
- Tailwind statt CSS-Modules
- Lieber drei kleine Files als ein 500-Zeilen-Monster

## Wie ich arbeite
- Morgens 9–13 Uhr Deep Work, keine Meetings
- Tasks lieber in 30-Minuten-Häppchen
- Lieber **kleiner PR** als großer Drop

## Wie du mit mir reden sollst
- Kurze Antworten, keine Floskeln
- Bei Architektur-Fragen: **zwei** Optionen, nicht fünf
- Bei Unsicherheit lieber **nachfragen** als raten
- Push back, wenn du eine Idee schlecht findest
- Keine Emojis im Code, in Antworten okay

5) Beispiel: Project CLAUDE.md

Hypothetisches Beispiel für ein SaaS-Projekt namens „TaskFlow":

# Project Memory — TaskFlow

## Projekt
TaskFlow ist eine B2B-SaaS für Projektmanagement in kleinen Agenturen.
Stack: Next.js 15 (App Router), TypeScript, Supabase, Vercel.

## Architektur
- `src/app/` — Routes (App Router)
- `src/components/` — UI Components (shadcn/ui Basis)
- `src/lib/` — Business Logic, Supabase-Client, Utils
- `src/server/` — Server Actions, niemals direkt im Client importieren
- `tests/` — Vitest + Playwright

## Commands
| Aktion | Command |
|---|---|
| Dev-Server | `pnpm dev` |
| Tests | `pnpm test` |
| E2E | `pnpm test:e2e` |
| Lint | `pnpm lint` |
| Build | `pnpm build` |
| DB Migration | `pnpm db:migrate` |

## Konventionen
- Komponenten in PascalCase, Files in kebab-case
- Server Actions immer mit `"use server"` als erste Zeile
- Supabase-Queries **immer** typed (`Database` Generic)
- Kein `fetch()` im Client — nutze Server Components oder Server Actions
- Tailwind-Klassen via `cn()` aus `lib/utils.ts`

## Verbotene Patterns
- ❌ `useState` für Server-Daten — nutze `useQuery` oder Server Components
- ❌ `console.log` in Production-Code — `logger.info()`
- ❌ Direkte DB-Calls aus Client-Components
- ❌ Inline-Styles, immer Tailwind

## Wichtige Files
- `src/lib/supabase/types.ts` — Generierte DB-Types
- `src/middleware.ts` — Auth-Gate
- `docs/architecture.md` — High-Level Architektur

## Test-Strategie
Unit-Tests für `lib/`, Integration für Server Actions, E2E nur für kritische Flows (Signup, Checkout, Onboarding).

6) Best Practices

Kurz halten

Die CLAUDE.md ist kein Wiki. Sie steht in jedem Prompt mit drin — also kostet jedes Wort Tokens. Faustregel: unter 200 Zeilen pro Datei. Was länger ist, gehört in /docs/ und wird nur verlinkt.

Konkret statt schwammig

❌ „Schreib sauberen Code" ✅ „Funktionen unter 30 Zeilen, max. 3 Argumente, immer Return-Type."

❌ „Antworte freundlich" ✅ „Default: 3 Sätze. Bei Code: ohne Vorrede. Bei Architektur: zwei Optionen."

Versionieren

Project-CLAUDE.md gehört ins Git. Sie ist Teil der Codebase und sollte mit dem Team gepflegt werden. User-CLAUDE.md bleibt lokal — nicht committen, nicht teilen.

Trennen

Wenn du dich beim Schreiben dabei erwischst, persönliche Vorlieben in die Project-Memory zu schreiben — stopp. Das gehört in die User-Memory. Andersrum: projektspezifische Commands haben nichts in der User-Memory zu suchen.

Pflegen

Die CLAUDE.md ist lebendig. Wenn Claude dauernd denselben Fehler macht oder die gleiche Frage stellt → das ist ein Memory-Update. Direkt eintragen, nicht beim nächsten Mal wieder erklären.

7) Quick Reference

Frage	Antwort
Wo liegt die User-CLAUDE.md?	~/.claude/CLAUDE.md
Wo liegt die Project-CLAUDE.md?	./CLAUDE.md im Projekt-Root
Wird beides gleichzeitig geladen?	Ja — Project ergänzt User
Wie lang darf sie sein?	Möglichst unter 200 Zeilen
Soll ich sie committen?	Project: ja. User: nein.
Was tun, wenn Claude was vergisst?	Eintrag ergänzen, Session neu starten