Claude Code merkt sich nichts? Doch — du musst ihm nur sagen wo

Du hast Claude Code installiert, in dein Projekt gestartet, ein paar Sachen ausprobiert. Funktioniert. Am nächsten Tag öffnest du die Session wieder und Claude fragt dich: „Welcher Linter läuft hier eigentlich?" Du hast ihm das gestern erklärt. Drei Tage später, dieselbe Frage. Eine Woche später, dieselbe Frage plus „läuft das mit Vite oder Webpack?"

Das nervt nicht nur — es ist auch der Moment, an dem Claude Code für viele wieder in der Schublade landet. „Wenn ich jeden Tag bei Null anfange, kann ich's auch lassen."

Stimmt aber nicht. Claude Code merkt sich tatsächlich was — nur an drei verschiedenen Stellen, mit drei verschiedenen Zwecken. Und wenn du die richtige Stelle nicht kennst, schreibst du ständig in die falsche, und nichts davon wirkt. Hier sind die drei Stellen, wann welche dran ist, und ein Mindest-Setup für Hobby-Projekte, das in zehn Zeilen Markdown 80 % des Wiederholungs-Frusts auflöst.

Der Mindest-Setup für alle, die gerade angefangen haben

Wenn du Claude Code seit ein paar Tagen ausprobierst und gerade nicht in einer riesigen Codebase steckst, brauchst du genau eine Datei: CLAUDE.md im Root deines Projekts. Lege sie an, schreib für drei Minuten alles rein, was Claude bei jeder Session wissen sollte, ohne dass er fragen muss:

# Über dieses Projekt

Side-Projekt: ein kleiner Habit-Tracker mit Next.js 15 + SQLite.

## Setup
- Node 22, npm
- `npm run dev` für lokal, läuft auf :3000
- Tests: gibt's keine, ich verifiziere im Browser

## Konventionen
- TypeScript strict
- Prettier + ESLint sind drin (`npm run lint --fix`)
- Datenbank-Migrations liegen in `db/migrations/`, eine pro Datei
- Komponenten kommen in `app/components/`, kleinkram in `app/utils/`

## Was ich oft frage
- Bitte vor jedem Schreibvorgang in `db/`-Files erklären, was passiert
- Keine neuen Libraries installieren ohne kurze Begründung

Speichern, committen. Beim nächsten claude startet die Session und Claude weiß, wer du bist und wie das Projekt tickt. Diese eine Datei spart dir ungefähr 70 % der „bei jeder Session bei Null"-Wiederholung. Wirklich.

Wer mehr wissen will, liest weiter. Wer hier zufrieden ist — alles gut, der Rest ist Optimierung für Leute, die täglich mit Claude Code arbeiten.

Die drei Stellen, wo Claude Code Wissen ablegt

Stelle 1 ist genau die CLAUDE.md von oben. Liegt im Repo, wird committed, jeder im Team sieht sie, Claude lädt sie automatisch in jede Session.

Stelle 2 heißt AGENTS.md, liegt ebenfalls im Repo-Root, wird auch automatisch geladen. Der Unterschied zu CLAUDE.md ist subtil aber wichtig: CLAUDE.md ist „so ist das Projekt" — Fakten. AGENTS.md ist „so verhältst du dich hier" — Anweisungen ans Modell. Faktisch beziehungsweise prozedural. Klingt akademisch, hat aber praktischen Effekt: wenn du beides mischst, wachsen beide Dateien, beide veralten, beide werden unklar. Trennt man sie, bleibt jede für sich kurz und nützlich.

In AGENTS.md schreibst du Sachen wie:

- Bevor du eine Migration schreibst, lies erst die letzte Migration und die zugehörige Schema-Datei
- Niemals `--no-verify` beim Commit benutzen
- Bei UI-Änderungen den Dev-Server starten und im Browser checken — ich habe kein Test-Framework

Solche Anweisungen sind reines Verhalten — sie ändern nichts an dem, was das Projekt ist, nur daran, wie der Agent darin arbeitet. Wer das in CLAUDE.md mischt, wird die Datei in drei Wochen nicht mehr durchlesen können, weil sie ein Mischmasch aus Architektur und Verhaltensregeln ist.

Stelle 3 ist persönlich. Claude Code legt unter deinem Home-Verzeichnis einen Memory-Ordner an, in den der Agent selbst kleine Notizen schreiben kann — basierend darauf, was du ihm beibringst. Wenn du Claude einmal sagst „nein, mach das anders", merkt er sich das, schreibt eine kleine Memory-Datei, und beim nächsten Session-Start ist die Korrektur da. Die Datei ist nur für deinen Computer, niemand im Team sieht sie, und sie ist persönlich gefärbt — was du bevorzugst, was du gerade erst hingebogen hast, welche Drift-Stellen du selbst beobachtest.

Du musst diese Stelle nicht aktiv pflegen. Sie wächst, wenn du mit Claude arbeitest und ihn korrigierst. Die einzige Pflege-Geste, die sich lohnt: gelegentlich „merk dir bitte, dass …" sagen, wenn dir auffällt, dass eine Korrektur nicht beim ersten Mal hängengeblieben ist.

Was wohin gehört — eine kurze Heuristik

Drei Fragen, die meistens reichen:

1. „Würde der nächste Mensch, der das Projekt cloned, das wissen wollen?" Wenn ja: CLAUDE.md (Faktwissen) oder AGENTS.md (Verhaltensregel). Wenn nein: persönlicher Memory-Ordner.

2. „Ist das ein Fakt über das Projekt oder eine Anweisung an den Agent?" Fakt: CLAUDE.md. Anweisung: AGENTS.md.

3. „Steht das schon im Code?" Wenn ja: garnicht aufschreiben. Lies, statt zu duplizieren.

Die dritte Frage ist die wichtigste, wird aber am häufigsten vergessen. Es ist verlockend, in CLAUDE.md zu schreiben „die Datenbank ist SQLite, liegt in data/app.db". Aber das steht im Code — in der package.json als Dependency, in der Connection-String-Variable, im Migrations-Folder. Jede Doppelung ist eine zukünftige Drift-Quelle. Wenn du in zwei Monaten von SQLite auf Postgres wechselst, vergisst du die CLAUDE.md-Zeile, und plötzlich hat dein Agent zwei Wahrheiten.

Faustregel: schreibe nur auf, was nicht im Code ist. Architektur-Entscheidungen mit Begründung („wir nutzen Drizzle statt Prisma, weil…"), Konventionen mit Subtilität („Komponenten in app/components/ sind alle Server Components, die *Client.tsx-Suffix-Variante ist Client") — solche Sachen liest niemand aus der Codebase ab, die müssen explizit gemacht werden.

Warum die Trennung sich lohnt

Es klingt nach Bürokratie, drei Memory-Stellen zu unterscheiden, wenn doch alle „Notizen für Claude" sind. Der Effekt zeigt sich erst nach ein paar Wochen.

Wenn alles in einer Datei landet, wächst die Datei mit jeder neuen Erkenntnis. Nach zwei Monaten hast du 400 Zeilen Mischmasch — Faktwissen, Verhaltensregeln, persönliche Vorlieben, alte Korrekturen, die längst nicht mehr stimmen. Claude lädt das alles in den Context, der Context ist halbvoll bevor du eine einzige Frage gestellt hast, und nichts darin ist mehr scharf priorisiert. Drift schleicht ein: einzelne Punkte stimmen nicht mehr, weil sich der Code geändert hat, aber niemand merkt's, weil 400 Zeilen niemand prüft.

Mit der Trennung passiert das nicht. CLAUDE.md bleibt kurz, weil sie nur Architektur-Fakten trägt — vielleicht 40 Zeilen, die alle paar Wochen mal überarbeitet werden. AGENTS.md ebenfalls kurz, oft nur 10-15 Zeilen. Persönlicher Memory wächst zwar, aber lokal und nur bei dir, und Claude verwaltet ihn größtenteils selbst.

Wann updaten — und woran man Drift erkennt

Drei Signale, dass deine Memory-Setup angefasst werden sollte:

Erstes Signal: Claude fragt zum dritten Mal dieselbe Frage. Dann ist die Antwort entweder noch nicht in CLAUDE.md, oder sie ist drin, aber so versteckt zwischen anderem Zeug, dass das Modell sie nicht beachtet. Antwort kürzer und prominenter platzieren.

Zweites Signal: Du korrigierst Claude bei einer Sache, die er „eigentlich wissen sollte". Wenn du gerade irgendwas in CLAUDE.md stehen hast, das dem widerspricht, was Claude gemacht hat — Drift. Die Datei lügt. Aktualisieren oder löschen.

Drittes Signal: Eine Session schlägt nichts vor, was du erwartet hättest. Beispiel: du arbeitest an einem Feature, das normalerweise einen bestimmten Pattern erfordert (z.B. „neue API-Routen brauchen unsere zentrale Error-Wrapper-Funktion"), und Claude macht das nicht. Wenn die Convention nicht in AGENTS.md steht, gehört sie da rein. Wenn sie drin steht und trotzdem ignoriert wird, ist die Formulierung zu vage.

Faustregel für die Pflege: alle 4-6 Wochen einmal 10 Minuten in beide Dateien schauen, gegen die aktuelle Realität abgleichen. Lieber kürzen als ergänzen.

Was du heute machen kannst — fünf Minuten

Wenn du Claude Code nutzt und noch keine CLAUDE.md hast: leg eine an, schreib rein, was dein Projekt ist, was die Tooling-Basics sind, was du bei der Zusammenarbeit erwartest. Drei Minuten. Committe sie.

Wenn du schon eine CLAUDE.md hast und sie länger als 200 Zeilen ist: lies sie einmal durch, sortier mit zwei Spalten — links „Fakt", rechts „Anweisung an den Agent". Anweisungen wandern in eine neue AGENTS.md. Was weder das eine noch das andere ist (Vorlieben, persönliche Tics), kann raus — Claude merkt sich das selbst, sobald du's korrigierst.

Wenn du noch nie was korrigiert hast und Claude einfach machen lässt: fang an, ihn zu korrigieren. „Nein, mach das mit X statt Y." Beim nächsten Session-Start wird die Korrektur in einem persönlichen Memory-Eintrag liegen und automatisch angewendet. Das ist der einfachste Weg, Memory zu nutzen, ohne überhaupt eine Datei anzufassen.

Im nächsten Teil

Memory ist passiv — es dokumentiert, was sein soll. Manchmal reicht das nicht: wenn der Agent eine Anweisung trotz AGENTS.md ignoriert, brauchst du etwas, das nicht verhandelbar ist. Im nächsten Teil dieser Series geht's um Hooks — der Mechanismus, mit dem du Verhalten erzwingst, statt nur darauf zu hoffen. Beispiel: ein Hook, der einfach kein git commit durchlässt, solange der Type-Check rot ist. Egal was im Context steht.

Wenn du den ersten Teil dieser Series noch nicht kennst — der liegt unter „So nutzt du mehrere Claude Code Accounts gleichzeitig" und ist die natürliche Vorstufe. Memory funktioniert besser, wenn der Account-Setup auch sauber ist.