Der letzte Post argumentierte, CLAUDE.md sei nur für Invarianten da. Was gehört dann ins memory? Ich habe alle 5 memory-Dateien geöffnet, die in diesem Projekt laufen, und sie einzeln auditiert — was bleibt, was gelöscht werden sollte und wo die Grenze zwischen CLAUDE.md und memory wirklich verläuft.
Der vorige Artikel argumentierte, dass CLAUDE.md nur das enthalten sollte, was Claude nicht aus dem Code lesen kann. Ein Leser fragte sofort: und was ist mit memory? Memory ist auch Kontext — wo liegt der wirkliche Unterschied?
Viele behandeln memory mit der Zeit wie eine „Backup-Erweiterung" von CLAUDE.md — sie stopfen alles rein, was ihnen einfällt. Nach und nach wird memory aufgebläht, Claude liest es in jeder Session, und Entscheidungen werden auf Basis veralteter Informationen getroffen.
Dieser Artikel überspringt die abstrakten Definitionen. Ich habe alle 5 memory-Dateien geöffnet, die gerade in diesem Projekt laufen, und sie einzeln auditiert — welche bleiben, welche müssen raus, welche hätten nie geschrieben werden sollen. Dabei beantwortet sich die CLAUDE.md-vs-memory-Frage von selbst.
Die nützliche Frage ist nicht „wohin damit?" — sondern „wie lange lebt diese Information, und wer aktualisiert sie?"
feedback_commits — warten, bis ich "commit" sage, bevor committed wird
feedback_article_authenticity — Praxisartikel dürfen nicht erfunden werden
project_i18n_strategy — die Entscheidung „alle Sprachen gleichzeitig launchen"
project_howdev_plan — unvollendeter Plan für how2claude.dev
project_article_workflow — die Pipeline zur Artikelveröffentlichung
Nach Typ gruppiert.
Der Rumpf ist kurz: "don't auto-commit, wait for user to confirm."
Das ist der memory-Typ mit dem höchsten ROI. Eine Korrektur → permanent in allen zukünftigen Sessions.
Warum nicht in CLAUDE.md? Es ist keine Projektregel — es ist meine persönliche Arbeitsgewohnheit. Wenn ein anderer Mitwirkender dem Projekt beitritt, müsste er nicht zwingend derselben Regel folgen. CLAUDE.md ist Team-Ebene. Memory ist „zwischen Claude und mir".
Warum nicht am Anfang jedes Gesprächs wiederholen? Weil memory sessionübergreifend bleibt. Wenn Claude mir nächste Woche hilft, erinnert er sich noch daran.
Der Auslöser ist klar: Ich habe einmal korrigiert und will, dass die Korrektur ewig gilt.
Der Rumpf dieses memory ist ungewöhnlich konkret:
Am 2026-04-16, während ich den Abschlussartikel der multi-agent-Serie schrieb, erfand ich eine Geschichte über „drei Agents, die ein Webhook-Feature bauen"… alles erfunden. Der User fragte „ist das echt oder erfunden" — ein anderer Maßstab als in den zwei vorherigen (methodischen) Artikeln…
Der Punkt: Das Why-Feld ist kein abstraktes Prinzip — es ist ein konkretes Ereignis + Datum + was passiert ist.
Warum so schreiben? In sechs Monaten wird mich „Praxisartikel brauchen echtes Material" als abstrakte Regel verwirren — wann wurde das festgelegt, warum? Aber „4-16, ich habe eine Agent-Geschichte erfunden und wurde erwischt" löst sofort Erinnerung aus und erlaubt mir, direkt zu beurteilen, ob die Regel noch gilt.
Das ist der „schwerste" Eintrag meiner 5. Es ist nicht bloß eine Regel — es ist eine Vorfallsakte, die sowohl Claude als auch ich abfragen können.
Der Inhalt: Warum dieses Projekt aggressiv alle Sprachen gleichzeitig startete — Übersetzungskosten über Claude ~0 €, englischsprachige Offizialdocs als zentrales Gelegenheitsfenster.
Das sieht man nicht am Code. Der Code zeigt nur 19 Locale-Dateien. Warum 19, warum alle gleichzeitig, warum Japanisch und Koreanisch priorisiert — all das lebt in meinem Kopf.
Memory destilliert diese „Kopf-Entscheidung" in etwas Beständiges, damit Claude, wenn er später ein Feature vorschlägt, fragen kann: kollidiert das mit der i18n-Strategie?
Keine operative Regel (gehört nicht in CLAUDE.md). Strategischer Hintergrund (gehört in memory).
Das zeitlich flüchtigste der Gruppe: ein Umsetzungsplan mit 9 Dateien für die Entwicklerseite how2claude.dev, endet mit „wird in der nächsten Session fortgesetzt."
Der gefährlichste memory-Typ — er wird leicht zu Zombie-memory. Du beendest die Arbeit und vergisst zu löschen; beim nächsten Mal behandelt Claude es als noch aktiv und berät auf Basis eines veralteten Plans („du hast Step 3 noch nicht gemacht").
Diese memories brauchen einen expliziten Ausstiegsmechanismus: in dem Moment, in dem how2claude.dev live geht, muss ich diesen Eintrag manuell löschen.
Dieses Memory hat die höchste Informationsdichte. Zunächst hielt ich es für das nützlichste — bis ich es gründlich las:
/write-article und /publish-article → .claude/commands/ angucken, fertigdocs/drafts/ macht es offensichtlich.claude/publish-config.jsonClaude kann all das durch Lesen des Codes ableiten.
Das Einzige, was memory tatsächlich beiträgt, ist der letzte Block: "Accounts (production): zh → @how2claude, en → @howtoclaude" — und das ist bereits veraltet. Die letzte Session hat gezeigt, dass Produktion tatsächlich zh=@howtoclaude ist. Memory hat einen Schnappschuss von vor ein paar Tagen festgehalten; er ist schon abgedriftet.
Fazit: 90 % dieses memory sollten weg. Der erhaltenswerte Teil ("kamal verwenden, um Live-Accounts abzufragen") passt besser in CLAUDE.md — oder besser noch, nirgendwohin, denn in memory hartcodierte Accounts werden wieder driften.
1. Die eigentliche Aufgabe von memory ist, Räume zu öffnen, in die Claude nicht hineinkommt.
2. Wenn Claude es aus dem Code lesen kann, gehört es nicht ins memory.
Dasselbe Prinzip wie im vorigen CLAUDE.md-Artikel. Dateipfade, API-URLs, Verzeichnisstruktur — alles Fragen, die der Code beantworten kann. Das ins memory zu stopfen, weil man keine Lust auf ein grep hat, ist eine Wette darauf, dass sich nie etwas ändert.
3. Memory verfällt.
project_article_workflow ist der Beweis — vor Tagen geschrieben, Account-Info schon falsch. Je älter memory, desto weniger vertrauenswürdig. Regelmäßig auditieren > endlos hinzufügen.
4. Das Why-Feld rettet dich.
Vergleich meiner beiden Feedback-Einträge:
feedback_article_authenticity: „4-16, ich habe im multi-agent-Artikel eine Geschichte erfunden" → sechs Monate später kann ich sofort beurteilen, ob es noch gilt.feedback_commits: nur „user wants to review" → sechs Monate später bin ich mir nicht sicher, welche konkrete Korrektur es hervorgebracht hat.Zweiteres ist deutlich schwächer. Abstrakte Prinzipien überleben nicht — niemand erinnert sich, warum sie verhängt wurden.
Wenn neue Information auftaucht, stelle drei Fragen:
Frage drei ist die Falle. Die meisten „unveränderlichen" Dinge, die du notieren willst, lassen sich tatsächlich aus dem Code ableiten — du willst nur nicht, dass Claude nochmal greppen muss.
Nach einem Durchgang stechen einige Dinge heraus:
project_article_workflow lassen sich aus dem Code ableiten. Der braucht am meisten Operation.project_howdev_plan ist eine temporäre Übergabe — theoretisch sollte es einen Ausstiegsmechanismus haben.project_i18n_strategy ist eine strategische Entscheidung — in ein paar Monaten lohnt sich ein erneutes Nachsehen.feedback_commits ist schwach; ein konkretes Ereignis anzuhängen würde es robuster machen.Nebenbeobachtung: meine Typverteilung ist feedback×2 + project×3, null user- oder reference-Typen. Das heißt, ich habe Claude noch nicht gesagt, „wer ich bin" oder „aus welchen externen Systemen ich Zustand lese". Wahrscheinlich das nächste zu schreibende Bündel.
Die größte Falle bei memory ist nicht „was ich hätte schreiben sollen und nicht geschrieben habe." Es ist „was ich geschrieben habe und jetzt veraltet ist." Bei 5 Einträgen reicht eine einzige Abdrift — Claude nutzt stillschweigend veraltete Informationen, um zu entscheiden, und er wird die Abdrift nicht melden.
In meinen 5 sehe ich schon ein paar Dinge, die angefasst werden wollen. Und bei deinen?