/sibyl-save – Sitzungsspeicher-Synchronisation + Skill-Extraktion (Sibyl Memory Plugin)
Teil der offenen Skillsammlung von Sibyl Labs. MIT-lizenziert. Erstellt von Sibyl Labs, LLC.
Ein Begleitskill für das Sibyl Memory Plugin. Er erfasst alles, was in dieser Sitzung passiert ist, und speist es über die eigene Schnittstelle des Plugins in die lokale Speicherdatenbank (~/.sibyl-memory/memory.db) ein. Anschließend extrahiert er wiederverwendbare Muster in neue Skills.
Er schreibt keine rohen Speicherdateien. Der gesamte Speicher durchläuft das Plugin, sodass Tiering, Volltextindizierung und das Free-Tier-Limit eingehalten werden. Da das Plugin auf jeder unterstützten Umgebung (Claude Code, Codex und jeder MCP-Host; Hermes über das Python SDK) dieselben MCP-Tools bereitstellt, ist dieser eine Skill von Natur aus Multi-Harness-fähig.
Voraussetzungen
Das Sibyl Memory Plugin, installiert und verdrahtet:
pip install sibyl-memory-cli
sibyl init # Browser-/Wallet-Aktivierung, schreibt ~/.sibyl-memory/
sibyl setup claude-code # oder: codex | hermes (verdrahtet die Speicherschnittstelle in Ihre Umgebung)
Dieser Skill kommuniziert dann über eine von zwei Oberflächen mit dem Plugin:
- MCP (Claude Code, Codex, Cursor, jeder MCP-Host): die 8
memory_*-Tools unten. - Python SDK (Hermes oder jeder Python-Agent):
sibyl_memory_client.MemoryClient/sibyl_memory_hermes.SibylMemoryProvider.
Die Plugin-Schnittstelle
| Zweck | MCP-Tool | Python SDK |
|---|---|---|
| Ein Faktum / eine Entität speichern | memory_remember(category, name, body) | client.set_entity(category, name, body) |
| Eine Entität abrufen | memory_recall(category, name) | client.get_entity(category, name) |
| Entitäten auflisten | memory_list(category, limit) | client.list_entities(category) |
| Volltextsuche | memory_search(query, limit, tiers) | client.search(query) |
| Ein Zustandsdokument setzen | memory_set_state(key, body) | client.set_state(key, body) |
| Ein Zustandsdokument abrufen | memory_get_state(key) | client.get_state(key) |
| Ein Journalereignis aufzeichnen | memory_record_event(kind, body, category, name) | client.write_event(...) |
| Archivieren / Vergessen | memory_forget(category, name, reason) | client.archive_entity(category, name, reason) |
Die Beispiele unten verwenden die MCP-Namen. Verwenden Sie unter Hermes oder einem Python-Agenten die SDK-Spalte.
Tier-Zuordnung
| Sitzungsinhalt | Tier | Aufruf |
|---|---|---|
| Sitzungszeiger / Zusammenfassung / Weiterleitungselemente | HOT (state) | memory_set_state("session", ...) |
| Rangfolge-Prioritäten | HOT (state) | memory_set_state("priorities", ...) |
| Sitzungslogeintrag | COLD (journal) | memory_record_event("session_save", ...) |
| Projekte / Personen / Produkte | WARM (entities) | memory_remember(category, name, body) |
| Abgeschlossene / tote Elemente | ARCHIVE | memory_forget(category, name, reason) |
| Konfiguration dieses Skills + Delta-Marker | HOT (state) | memory_set_state("sibyl_save:config" / "sibyl_save:last_save", ...) |
Modi
- run (Standard):
/sibyl-save,save session,sync memory. Sitzungskontext in das Plugin einspeisen, dann Skill-Extraktion anbieten. - setup:
/sibyl-save setup,/sibyl-save config. Interaktiv. Konfiguration erstellen oder bearbeiten (im Plugin unter dem State-Keysibyl_save:configgespeichert). Einmal vor der ersten Verwendung ausführen. - preview (Trockenlauf):
/sibyl-save preview,/sibyl-save --dry-run. Vollständige Analyse durchführen und alle geplanten Schreibvorgänge melden. Nichts aufrufen, was die Datenbank verändert. Der Delta-Marker wird nicht aktualisiert.
Modus: setup (dynamische Konfiguration)
Ziel: Die Konfiguration im Plugin unter dem State-Key sibyl_save:config ablegen. Interaktiv und minimal sein. Was möglich ist, ableiten; nur das erfragen, was nicht ableitbar ist.
- Umgebung. Erkennen oder erfragen, um welche Umgebung es sich handelt (claude-code, codex, cursor, hermes, andere). Dies steuert, wo Phase 2 die Skill-Dateien schreibt.
- Skill-Ausgabe. Wohin neue Skills für diese Umgebung geschrieben werden. Standard für Claude Code:
.claude/skills/<name>/SKILL.md. Für andere Umgebungen den Skill-Pfad und das Format bestätigen. Alsskill_output: {dir, format}speichern. - Prioritäten. State-Key für die Rangliste (Standard
priorities) und ein Limit. Standard 15. Obergrenze 30: Niemals einen Wert über 30 akzeptieren. Eine Liste mit mehr als 30 Einträgen ist ein Backlog, keine Menge von Prioritäten. - Entitätskategorien. Welche WARM-Kategorien Sie verfolgen (Standard
project,person,product). Benutzer fügt hinzu oder entfernt. - Zusätzliche Erfassung. Optional zusätzliche State-Keys oder Entitätskategorien benennen, die der Speicher bei jedem Durchlauf befüllen soll (ein Metrik-State-Dokument, eine Kontakt-Kategorie). Dies ist der Erweiterungspunkt.
- Trockenlauf-Standard.
dry_run_defaultumschalten (Standard false). - Konfiguration schreiben über
memory_set_state("sibyl_save:config", {...}). Den Delta-Marker nicht berühren.
Konfigurationsform: siehe examples/sibyl-save-config.example.json. Erneutes Ausführen von setup bearbeitet sie direkt.
Modus: run
Phase 1: Speichersynchronisation (in die Plugin-DB)
Schritt 0 – Konfiguration + Delta laden
memory_get_state("sibyl_save:config"). Falls nicht vorhanden, wechseln zu setup. memory_get_state("sibyl_save:last_save") für den Delta-Anker (was sich seit dem letzten Speichern geändert hat). Wenn dry_run_default true ist und kein Modus angegeben wurde, als Vorschau (preview) ausführen.
Schritt 1 – Aktuellen Zustand lesen
memory_get_state("session")undmemory_get_state(<Prioritäten-Key>)memory_list(category, limit)für die verfolgten Kategorien undmemory_recall/memory_searchfür Entitäten, die in dieser Sitzung berührt wurden- alle zusätzlichen State-Keys oder Kategorien, die in der Konfiguration benannt sind
Schritt 1.5 – Prioritäten prüfen und abgleichen
Das Prioritäten-State-Dokument lesen und direkt abgleichen (mit memory_set_state zurückschreiben). Bedingungen und die jeweils erforderliche Aktion:
- ABGESCHLOSSENES Element noch gelistet: entfernen; den Abschluss über
memory_record_event("priority_closed", {...})aufzeichnen. - RANG_ABWEICHUNG / DOPPELRANG (Ränge nicht fortlaufend 1..N, oder ein Rang wiederholt sich): auf 1..N umnummerieren.
- ÜBER_LIMIT (mehr Elemente als das Limit): die niedrigsten Prioritätselemente in ein Backlog-State-Dokument verschieben, bis das Limit wieder eingehalten wird.
- VERALTETES_ELEMENT (>14 Tage unberührt): dem Benutzer anzeigen.
- TERMINALE Entität (die referenzierte Entität ist archiviert/tot): die Priorität schließen.
- KAPUTTE_Entitätsreferenz (zeigt auf keine reale Entität): auf eine echte
category/namekorrigieren.
Das Limit bei jedem Schreibvorgang durchsetzen (niemals 30 überschreiten).
Schritt 2 – Die Sitzung analysieren
Das Gespräch seit dem Delta-Anker (oder seit Sitzungsbeginn beim ersten Speichern) durchgehen. Extrahieren:
- Berührte Entitäten – Projekte, Personen, Produkte, die erstellt, gelesen oder geändert wurden
- Durchgeführte Aktionen – konkrete Dinge, die passiert sind, mit Bezeichnern
- Getroffene Entscheidungen – strategische Entscheidungen und deren Begründung
- Weiterleitungselemente – Aktionen für die nächste Sitzung, verb-zuerst ("Bereitstellen...", "Nachfassen bei...", "Überprüfen...")
- Warnungen – aktive Risiken, Blockaden, Fristen, Beinaheunfälle
- Erkenntnisse – betriebliche Verbesserungen (diese fließen in Phase 2 ein)
- Zusätzliche Erfassungen – Daten für alle zusätzlichen State-Keys / Kategorien in der Konfiguration
Schritt 3 – In die Plugin-DB einspeisen
Im Vorschau-Modus nichts aufrufen, was die Datenbank verändert. Die geplanten Schreibvorgänge melden (Schritt 4) und anhalten.
- Sitzungszustand –
memory_set_state("session", { last_session, summary, forward, entities_touched, warnings }). Weiterleitungselemente sind nur Aktionsreferenzen, niemals Kontostands-Schnappschüsse oder etwas, das veraltet. - Journalereignis –
memory_record_event("session_save", { evaluated, acted, forward, extra }). Ein Ereignis pro Speicherung (nur anfügen, per Design). - Prioritäten –
memory_set_state(<Prioritäten-Key>, { updated, cap, items }), gedeckelt. Überlauf in ein Backlog-State-Dokument. - Entitäten – für jede geänderte Entität
memory_remember(category, name, body). Neue Entitäten sind einfach neuememory_remember-Aufrufe; das Plugin indiziert sie, daher muss kein separates Register geführt werden. - Geschlossen / tot –
memory_forget(category, name, reason). - Zusätzliche Erfassungen – jeden konfigurierten zusätzlichen State-Key / jede Kategorie anwenden.
- Delta-Marker –
memory_set_state("sibyl_save:last_save", { ts: <jetzt> }). Im Vorschaumodus überspringen.
Schritt 4 – Bericht
Kurze Zusammenfassung: geschriebene Entitäten, aktualisierte State-Dokumente, Journalereignis-ID, hinzugefügte/geschlossene Prioritäten, zusätzliche Erfassungen und Weiterleitungselemente für die nächste Sitzung. Im Vorschaumodus jede Zeile mit "würde" kennzeichnen und bestätigen, dass nichts geschrieben wurde.
Phase 2: Skill-Extraktion (umgebungsnativ)
Skills werden unabhängig von der Umgebung auf die gleiche Weise präsentiert: identifizieren, vorschlagen, dann als native Skill-Datei für die aktuelle Umgebung erstellen.
Schritt 5 – Wiederverwendbare Muster identifizieren
Die Sitzung nach Vorgängen durchsuchen, die IRGENDEINES dieser Kriterien erfüllen: wiederholt (mehr als einmal in dieser Sitzung), wiederkehrend (wahrscheinlich erneut auftretend), mehrschrittig (3+ aufeinanderfolgende Schritte), nicht offensichtlich (ein Workaround, der es wert ist, behalten zu werden), fehleranfällig (benötigt eine Checkliste). Für jeden Kandidaten bewerten: Name (kurzer imperativer Verbausdruck), Auslöser, Parameter, Komplexität (gefährliche Schritte), Häufigkeit.
Schritt 6 – Kandidaten vorschlagen
Jeden als Einzeiler mit Name, Beschreibung und geschätzter Häufigkeit präsentieren. Dann fragen: "Diese erstellen? Oder welche überspringen?"
Schritt 7 – Genehmigte Skills erstellen (umgebungsnativ)
skill_output aus der Konfiguration lesen, um zu erfahren, wo und in welchem Format diese Umgebung Skills erwartet. Standardeinstellungen:
| Umgebung | Skill-Pfad | Format |
|---|---|---|
| claude-code | .claude/skills/<name>/SKILL.md | YAML-Frontmatter (name, description) + Markdown-Textkörper |
| codex | ~/.codex/prompts/<name>.md (in setup bestätigen) | Markdown-Prompt |
| cursor | .cursor/ command/rule (in setup bestätigen) | gemäß Cursor-Konvention |
| andere | von skill_output.dir | von skill_output.format |
Für jeden genehmigten Skill die Datei am konfigurierten Pfad schreiben, mit Auslösephrasen, Schritt-für-Schritt-Anleitung, Parameterbeschreibungen, Sicherheitsprüfungen für jeden gefährlichen Schritt und einem Beispielaufruf. Den Pfad melden.
KEINE Skills erstellen, die: einen vorhandenen Skill duplizieren (zuerst den Skill-Pfad prüfen), zu sitzungsspezifisch sind, um wiederzukehren, einen einzelnen trivialen Befehl umschließen oder das Bearbeiten von Dateien erfordern, die durch Ihre Betriebsregeln geschützt sind (diese anzeigen, nicht selbst bearbeiten).
Regeln (nicht verhandelbar)
- Niemals Live-Daten (Kontostände, Preise, Zählwerte) als dauerhafte Fakten speichern. Referenzen erfassen, keine Schnappschüsse.
- Sitzungs-Weiterleitungselemente sind handlungsorientiert und verb-zuerst.
- Ein Journalereignis pro Speicherung (nur anfügen; niemals die Geschichte umschreiben).
- Prioritäten sind gedeckelt (Standard 15, niemals über 30). Überlauf in ein Backlog-State-Dokument.
- Entitäten werden durch
category+nameangesprochen; das Plugin als Index verwenden. Kein paralleles Register. - Alle Speicherschreibvorgänge erfolgen über die Plugin-Schnittstelle. Niemals
~/.sibyl-memory/-Dateien schreiben odermemory.dbdirekt öffnen: der Client übernimmt das Sperren und das Free-Tier-Limit. - Vorhandene Skills als schreibgeschützt behandeln. Neue erstellen, anstatt direkt zu bearbeiten, es sei denn, es wird ausdrücklich darum gebeten.
Lizenz & Herkunft
MIT (siehe LICENSE). Der Wasserzeichen-Kommentar am Anfang jeder Markdown-Datei dient der Zuschreibung und Herkunftsangabe, nicht als Nutzungseinschränkung. Eine Kopie mit node scripts/watermark.mjs verify überprüfen. Details in WATERMARK.md.