Was macht Memory Engine?
Erweiterungsschicht für das manuelle Gedächtnissystem. Dieses Skill ersetzt nicht das bestehende automatische Gedächtnisverhalten — es fügt Struktur, Budgetbewusstsein und einen Checkpoint am Sitzungsende hinzu.
Kernphilosophie: Vorschlagen, niemals automatisch speichern. Der Mensch entscheidet, was erhaltenswert ist.
Speicherverzeichnis
Alle Speicherdateien leben in ~/.claude/projects/-Users-coni/memory/.
Indexdatei: MEMORY.md (immer geladen, reine Verweise, kein Inhalt).
Phase 1: Speichererfassung
Beim Speichern eines beliebigen Gedächtniseintrags (ob von dir oder vom Sitzungs-Checkpoint ausgelöst), führe jedes Mal diesen Ablauf durch:
Schritt 1 — Klassifizieren
Fünf Typen. Wähle den passenden:
| Typ | Erfasst | Signale |
|---|---|---|
user | Identität, Präferenzen, Werte, Wissen | "Ich bin ein...", "Ich bevorzuge...", Persönlichkeitswechsel |
feedback | Wie man mit dem Benutzer arbeitet — Korrekturen UND Bestätigungen | "Nicht so", "Ja, genau so", Ansatz bestätigt |
project | Aktueller Arbeitskontext, Fristen, Ziele | "Wir machen X bis Donnerstag", Meilenstein erreicht |
reference | Externes Wissen, Tool-Konfigurationen, Verweise | Neues Tool entdeckt, API konfiguriert |
decision | Warum X statt Y gewählt wurde | "X statt Y gewählt", Abwägung von Kompromissen, Architekturentscheidungen |
Für den Typ decision: Lies references/decision-type-spec.md für das Frontmatter-Schema und die Körperstruktur (Kontext → Optionen → Entscheidung → Wann erneut prüfen).
Schritt 2 — Deduplizieren
Vor dem Schreiben scannen der MEMORY.md-Index nach überlappenden Einträgen:
- Gleiches Thema bereits abgedeckt? → Aktualisiere die vorhandene Datei, erstelle keine neue
- Überschneidung mit einer CLAUDE.md-Regel? → Nicht speichern (die Regel ist maßgeblich)
- Flüchtiges Aufgabendetail? → Nicht speichern (Git-Log / Code ist die Quelle der Wahrheit)
Wende alle Regeln aus feedback-memory-hygiene.md an — sie bleiben maßgeblich.
Schritt 3 — Token-Kosten schätzen
Berechne: datei_bytes / 3,2 (ganze Zahl, abgerundet). Dies liefert eine vernünftige Näherung für gemischte CJK/englische Inhalte ohne externe Abhängigkeiten.
Schritt 4 — Schreiben
- Erstelle die Speicherdatei mit YAML-Frontmatter (Name, Beschreibung, Typ)
- Aktualisiere den MEMORY.md-Index — füge Eintrag unter der richtigen Abschnittsüberschrift hinzu
- Füge die Token-Schätzung an:
`~NNNNtk`am Ende der Indexzeile
Beispiel für eine Indexzeile:
- [decision-deploy-cloudflare.md](decision-deploy-cloudflare.md) — Inlandseinsatz wählt CF Pages statt Vercel `~280tk`
Was NICHT gespeichert werden soll
Diese Regeln sind nicht verhandelbar (aus memory-hygiene + automatischem Gedächtnissystem):
- Codemuster, Architektur, Dateipfade — aus dem Code ableitbar
- Git-Verlauf, letzte Änderungen —
git logist maßgeblich - Debug-Lösungen — die Korrektur befindet sich im Code
- Alles, was bereits in CLAUDE.md oder
~/cc-personal/rules/steht - Flüchtiger Aufgabenstatus — nur in der aktuellen Sitzung nützlich
- Projektstatus-Schnappschüsse — aus Code und Git lesen
Phase 2: Speicherwartung
/memory-check
Führe das Audit-Skript aus und präsentiere die Ergebnisse:
bash ~/.claude/skills/memory-engine/scripts/memory-health-check.sh
Das Skript gibt einen strukturierten Bericht aus, der Folgendes abdeckt:
- Budget: Gesamt-Tokens vs. 40.000tk-Grenze (20 % des 200K-Kontexts)
- Typenverteilung: Anzahl und Tokens pro Typ
- Top 5 nach Größe: größte Dateien, die das meiste Budget verbrauchen
- Probleme: veraltete Dateien (>30 Tage), Waisen, defekte Links, leere Typen, Budgetwarnungen
Nach der Präsentation des Berichts, schlage spezifische Aktionen für jedes gefundene Problem vor:
| Problem | Aktion |
|---|---|
| VERALTET | "Prüfen oder archivieren: {Datei} — noch relevant?" |
| WAISE | "Zum MEMORY.md-Index hinzufügen oder löschen, falls veraltet" |
| DEFEKTER LINK | "Aus MEMORY.md entfernen oder Datei neu erstellen" |
| KEINE EINTRÄGE | Informativ — nicht alle Typen müssen jederzeit Einträge haben |
| BUDGETWARNUNG | "Größte Dateien: … — Komprimieren oder Aufteilen in Betracht ziehen" |
Nach der Behebung von Problemen aktualisiere den MEMORY.md-Budgetkommentar:
<!-- budget: ~NNNNtk / 40000tk (NN%) | aktualisiert: YYYY-MM-DD -->
Token-Annotation-Format
Jeder MEMORY.md-Indexeintrag trägt ein Token-Schätzungssuffix:
- [dateiname.md](dateiname.md) — Beschreibung `~NNNNtk`
Der Budgetkommentar steht ganz oben in MEMORY.md (vor der Überschrift). Es ist ein HTML-Kommentar — unsichtbar im gerenderten Markdown, aber von Skripten lesbar.
Phase 3: Siebendimensionale Konsolidierungs-Checkpoint
Auslöser (doppelte Absicherung)
Primärer Auslöser — Prompt-basiert (CLAUDE.md-Regeln): Erkenne folgende Signale im Dialog und führe dann aktiv den Sieben-Dimensionen-Scan durch:
- Dichte Tool-Aufrufe (>15 Tool-Aufrufe)
- Ein substanzielles Ergebnis wurde abgeschlossen (Code, Analyse, Lösung)
- Großer Themenwechsel
- Benutzer sagt explizit "festhalten", "zusammenfassen", "rückblick"
Fallback-Auslöser — Stop-Hook (settings.json):
consolidation-trigger.sh läuft bei jedem Agent-Stopp und verfolgt die Anzahl der Stopps und das Zeitintervall.
Wenn die Stopp-Anzahl ≥ 20 und das Intervall seit dem letzten Auslöser ≥ 30 Minuten beträgt, gib den Sieben-Dimensionen-Scan-Hinweis aus.
Zustandsdatei: ~/.claude/projects/-Users-coni/memory/.consolidate-state
Sieben-Dimensionen-Scan
Scanne das aktuelle Gespräch Zeile für Zeile und beurteile, ob ein Treffer vorliegt:
| # | Dimension | Treffersignal | Entsprechender Speichertyp |
|---|---|---|---|
| 1 | Aufgabenabschluss | Eine vollständige Aufgabe von der Anforderung bis zur Lieferung abgeschlossen | project (Meilenstein) |
| 2 | CLAUDE.md-Aktualisierung | Neue allgemeine Verhaltensregel entdeckt | Direkt in CLAUDE.md schreiben |
| 3 | Regeln festhalten | Domänen-/Tool-/Dateityp-bezogene Regeln entdeckt | In ~/cc-personal/rules/ schreiben |
| 4 | Architekturentscheidung | Tool-Auswahl, technische Lösung, Bereitstellungsstrategie usw. getroffen (nicht offensichtliche Wahl) | decision |
| 5 | Projektmeilenstein | Projektstatus hat substanziellen Fortschritt gemacht (Release, Livegang, Schlüsselfunktion abgeschlossen) | project |
| 6 | Zusammenarbeitskalibrierung | Benutzer hat Vorgehensweise korrigiert oder nicht offensichtliche Vorgehensweise bestätigt | feedback |
| 7 | Hochwertige Analyse | Analyse-Rahmenwerk, Einsichten oder Modelle erstellt, die sitzungsübergreifend wiederverwendbar sind | reference oder user |
Ausführungsablauf
Scan 7 Dimensionen → Treffer zählen
Treffer 0-1 → stillschweigend überspringen
Treffer 2+ → Checkpoint-Vorschlag ausgeben
Regeln
- Wende die Liste "Was NICHT gespeichert werden soll" strikt an — keine Ausnahmen zum Checkpoint-Zeitpunkt
- Überprüfe vorhandene MEMORY.md-Einträge, bevor du Vorschläge machst — keine Duplikate
- Maximal 3 Kandidaten pro Checkpoint — Qualität vor Quantität
- Wenn nichts qualifiziert ist, gib nichts aus (stillschweigend überspringen, keine erzwungenen Vorschläge)
- Schreibe während des Checkpoints niemals Dateien — präsentiere nur Kandidaten zur Benutzerfreigabe
- Jeder Kandidat muss die getroffene Dimensionsnummer angeben
Ausgabeformat
[Speicher-Checkpoint] Dieses Gespräch hat 3/7 Dimensionen getroffen (④⑥⑦), Vorschlag zum Festhalten:
1. [decision] ④ Wahl des dualen Auslösers Stop-Hook + Prompt anstelle von reinem Hook — Hook kann Dialogsemantik nicht erfassen
2. [feedback] ⑥ Benutzer bestätigt: Kern des Schwungrads ist automatische Auslösung, nicht Speicherklassifizierung
3. [reference] ⑦ Rahmenwerk der Subjektvitalität: Zeit-/Energieverteilungsmodell für Mensch/Unternehmen/KI
Welche speichern? Antworte mit Nummern (z. B. 1,2) oder "skip" zum Überspringen.
Wenn der Benutzer Nummern bestätigt, führe den Speichervorgang aus Phase 1 für jedes ausgewählte Element aus. Wenn der Benutzer "skip" oder Ähnliches sagt, tue nichts.
Fallstricke
- Aktualisiere den MEMORY.md-Budgetkommentar nicht bei jedem Speichern — nur während
/memory-check. Häufige Aktualisierungen unterbrechen den Cache und fügen Rauschen in Git-Diffs hinzu. - Token-Schätzungen sind Näherungswerte — behandle sie nicht als exakt. Die /3,2-Methode ist ~90 % genau für gemischte CJK/EN-Inhalte, was für das Budgetbewusstsein gut genug ist.
- Der Typ decision ist für nicht-triviale Entscheidungen — "Ich habe vim anstelle von nano verwendet" ist keine erhaltenswerte Entscheidung. Hebe ihn für Entscheidungen auf, die zukünftige Sitzungen beeinflussen.
- Der Stop-Hook ist ein Fallback, kein Primärauslöser — wenn der Benutzer mit Strg+C beendet, wird der Hook nicht ausgelöst. Der aktive Scan ist der Motor des Schwungrads.
- Der aktive Scan soll den Flow des Benutzers nicht unterbrechen — löse ihn in Aufgabenpausen (Phasenabschluss, Themenwechsel) aus, nicht während der Ausführung.