Das Teuerste an der Arbeit mit einem Agenten ist die erneute Erklärung des Kontexts. Jeden Morgen erklärst du die Entscheidungen von gestern erneut, fügst die letzte Commit-Nachricht ein, legst erneut fest, welcher Fehler den Deploy blockiert. Multipliziert mit jeder Sitzung betragen die versteckten Kosten Stunden pro Woche, nicht Minuten.
STATE.md eliminiert diese Belastung. Eine Datei, am Ende jeder Sitzung aktualisiert, zu Beginn der nächsten geladen. Die Disziplin: Bevor du eine Sitzung schließt, verbringe drei Minuten damit, die Datei zu aktualisieren. Morgen sparen diese drei Minuten zwanzig.
STATE.md enthält drei Dinge, nichts mehr.
Entscheidungen: was du beschlossen hast und warum. Ohne das Warum öffnet dein zukünftiges Ich die Entscheidung erneut. „Postgres-Trigger statt Cron für den täglichen Digest: Trigger sind transaktional, Cron überholt den Schreibpfad.“
In Bearbeitung: was halb fertig ist, spezifisch genug, um es zu übergeben. „Migration 014 geschrieben unter /migrations/014_add_subscription_columns.sql, aber nicht angewendet. Muss vor dem Live-Gang des Webhook-Handlers ausgeführt werden.“
Blocker: was den Fortschritt aufhält, einschließlich dessen, was du versucht hast. „Stripe-Webhook-Signatur schlägt in der Testumgebung fehl. Rohen Body-Parser versucht, immer noch 400. Nächstes: Umgebungsvariable in Vercel-Vorschau prüfen.“
Begrenze es auf 60-80 Zeilen. Wenn etwas gelöst ist, entferne es. Wenn etwas ausgeliefert wird, archiviere es.
Die Update-Disziplin. Füge einen Stop-Hook hinzu, um dich zu erinnern:
{
"hooks": {
"Stop": [
{
"command": "echo 'Bevor du schließt: aktualisiere STATE.md mit Entscheidungen, laufenden Aufgaben und Blockern aus dieser Sitzung.'"
}
]
}
}Die Erinnerung allein reicht nicht aus; die Gewohnheit muss automatisch werden. Der schnellste Weg: mache es fünf aufeinanderfolgende Sitzungen lang. Bis zur sechsten Sitzung wirst du dich falsch fühlen, wenn du schließt, ohne zu aktualisieren. Das Unbehagen ist das Signal, dass sich die Gewohnheit gebildet hat.
MEMORY.md ist der Index für alles Dauerhafte. Jeder Eintrag ist eine Zeile, die auf eine separate Datei verweist. Vier Typen:
user_*: dauerhafte Fakten über dich: Zeitzone, Karrierekontext, Präferenzen. user_location.md
feedback_*: aus Fehlern gelernte Regeln, mit einem Konfidenzfeld. Beginne bei 0.3, erhöhe auf 0.5, wenn das Muster wiederkehrt, befördere zu CLAUDE.md bei 0.9+. feedback_public_endpoints_need_rate_limits.md
project_*: datierter Zustand und Entscheidungen für ein Projekt. Archiviere, wenn es ausgeliefert wird. project_stripe_integration_2026_05.md
reference_*: Nachschlagetabellen für Personen, Tools, APIs. reference_neon_db_config.md
Halte jede Indexzeile unter 200 Zeichen und den Index unter 200 Zeilen. Darüber hinaus werden Einträge abgeschnitten und Claude kann sie nicht sehen.
STATE.md ist für jetzt. MEMORY.md ist für immer. Die Faustregel: Wenn du es in einem Standup sagen würdest, gehört es in STATE.md. Wenn du es in einem Wiki oder Onboarding-Dokument schreiben würdest, gehört es in eine Speicherdatei. Standups sind vergänglich; Wikis sind dauerhaft.
Wenn ein Projekt ausgeliefert wird und STATE.md immer noch fünf Zeilen darüber enthält, verschiebe diese Zeilen in eine datierte project_*-Speicherdatei und lösche sie. Das Projekt hat nicht aufgehört, wichtig zu sein; es ist nicht mehr aktuell. Diese Unterscheidung hält STATE.md nützlich.
Zustand schreiben, kein Tagebuch. Ein Tagebucheintrag: „Habe an der Stripe-Integration gearbeitet. Es war knifflig.“ Ein Zustandseintrag: „Webhook-Endpunkt unter app/api/webhooks/stripe/route.ts. Signaturprüfung funktioniert lokal, schlägt in Vercel-Vorschau fehl (falsches Rohdatenformat). Nächstes: rawBody-Middleware-Konfiguration prüfen.“ Einer gibt der nächsten Sitzung einen Startpunkt; der andere gibt ihr eine Memoiren.
Zwei weitere Anti-Muster: In-flight-Einträge ohne eine konkrete nächste Aktion, die eine neue Sitzung ausführen könnte, und doppelte Einträge für dasselbe Thema über Sitzungen hinweg. Duplikate zusammenführen: ein Thema, ein Eintrag, nur der aktuelle Zustand.
Ein gutes Sitzungsupdate besteht aus neun bis zwölf Zeilen: eine Entscheidung mit Begründung, ein in Bearbeitung befindliches Element mit nächstem Schritt, ein Blocker mit dem, was du versucht hast.
Skalierung über 50 Speicherdateien hinaus: die Digest-Ebene. Jede MEMORY.md-Pointer-Zeile kostet ungefähr 100-150 Tokens. Bei 200 Zeilen sind das 20-30K Tokens reiner Pointer. Die Lösung: STRATEGY-DIGEST.md, eine 2-3-Satz-Zusammenfassung jedes wichtigen Dokuments plus ein „Verwenden wenn:“-Feld:
## q2-positioning.md
Q2-Positionierung zielt auf KI-Aktivierung in mittelständischen Vertriebsorganisationen ab.
Verwenden wenn: Diskussion über Zielkunden, Preise oder Lead-Qualifizierung.Claude liest den Digest (ca. 3K Tokens) und lädt ein vollständiges Dokument nur, wenn es relevant ist. Bei 25 Strategiedokumenten sind das 3K Tokens statt 50K. Das Feld „Verwenden wenn:“ ist der Routing-Mechanismus: schreibe es als spezifische Triggerbedingung, nicht als Beschreibung der Datei.
STATE.md erfasst den aktuellen Zustand (Entscheidungen, laufende Aufgaben, Blocker) unter 80 Zeilen; aktualisiere es am Sitzungsende und archiviere die Historie umgehend. MEMORY.md indiziert dauerhaftes Wissen in vier Typen (Benutzer, Feedback, Projekt, Referenz), begrenzt auf 200 Zeilen. Beginne heute Abend mit drei Zeilen: eine Entscheidung, eine laufende Aufgabe, ein Blocker. Drei Zeilen sind besser als null, während sich die Gewohnheit bildet.