Table of Contents

knowledge-curator

Architektur
Die vier Subagents (read-only)
Commands
Change-Set-Format
Sicherheitsmodell
Kosten

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

knowledge-curator

Orchestrator-Worker-Setup zum Auditieren und Restrukturieren des MCP-Memory-Hubs (Knowledge Graph). Read-only per Default — Mutationen laufen ausschließlich über einen separaten, explizit aufgerufenen Apply-Schritt mit Backup und Bestätigung.

Architektur

/kg-curate ──► skill: knowledge-curator        (Main-Thread, orchestriert)
                  │  dispatcht parallel via Task-Tool:
                  ├─► kg-graph-auditor          (Struktur-Integrität)      read-only / sonnet
                  ├─► kg-entity-deduplicator    (Überschneidungen/Merges)  read-only / opus
                  ├─► kg-relation-miner          (fehlende Verknüpfungen)  read-only / opus
                  └─► kg-taxonomy-architect     (Kategorien/Ontologie)     read-only / opus
                  │
                  ├─► Deutscher Audit-Report
                  └─► kg-changeset.json (Vorschlag, KEINE Mutation)

/kg-apply ───► liest kg-changeset.json, Backup → Diff → Bestätigung → schreibt

Der Orchestrator ist ein Skill, weil Subagents vom Main-Thread per Task gestartet werden und nicht weiter verschachteln. Jeder Worker arbeitet in eigenem Kontextfenster, zieht den read_graph-Dump dorthin und gibt nur kompaktes JSON zurück — der Hauptkontext bleibt schlank.

Die vier Subagents (read-only)

Agent	Aufgabe	Modell
`kg-graph-auditor`	Orphans, Dangling Relations, leere Entities, Naming-Inkonsistenzen, Typ-Wildwuchs	sonnet
`kg-entity-deduplicator`	Merge-Cluster gleicher realer Dinge, mit Confidence	opus
`kg-relation-miner`	semantisch verwandte, aber unverbundene Entities → neue Relations mit Evidenz	opus
`kg-taxonomy-architect`	saubere Typ-Hierarchie + Naming-Regeln + Migrations-Map	opus

Alle vier haben in ihrer tools:-Whitelist nur read_graph, search_nodes, open_nodes — keine Write-Tools. Sie können den Graph technisch nicht verändern.

Commands

/kg-curate — startet das read-only Audit: dispatcht die vier Worker parallel, synthetisiert einen deutschen Audit-Report (Zusammenfassung, Statistik, Strukturbefunde, Dubletten, vorgeschlagene Verknüpfungen, Taxonomie-Vorschlag, empfohlenes Vorgehen) und schreibt den Vorschlag nach ./kg-changeset.json. Keine Mutation — endet in der Plan-Phase zur Review.
/kg-apply — der einzige Writer. Liest ein freigegebenes kg-changeset.json und wendet es an.

Change-Set-Format

/kg-curate schreibt kg-changeset.json mit den Gruppen merges, new_relations, deletions, type_migrations, rename_suggestions (jeweils mit Confidence bzw. Begründung).

Sicherheitsmodell

Audit ist strikt read-only (Whitelist ohne Write-Tools).
/kg-apply macht zuerst ein Voll-Backup (kg-backup-<timestamp>.json), zeigt dann einen nach Operationstyp gruppierten Diff und verlangt Bestätigung pro destruktiver Gruppe (Merges/Deletes sind unwiderruflich).
Apply-Reihenfolge: additiv (neue Entities/Relations) → Observations → Merges (Relations auf Canonical umhängen, Observations kopieren, redundante Member löschen) → Typ-Migrationen/Renames → Standalone-Deletes zuletzt. Nach jeder Gruppe Re-Read zur Verifikation.
Backup-Hook als zweite Verteidigungslinie: hooks/hooks.json matcht mcp__memory__(create|add|delete)_.* und feuert backup-memory.sh vor jedem Memory-Write — debounced (ein Apply-Lauf = ein Backup), gepruned auf KG_BACKUP_KEEP, blockiert nie (Exit 0). Greift auch bei manuellen Writes außerhalb von /kg-apply. Konfiguration siehe Installation.

Kosten

Vier parallele Opus-Subagents ≈ ~7× Tokens vs. Single-Thread. Für Routine-Re-Audits die drei semantischen Worker auf model: sonnet setzen — der Auditor läuft bereits auf sonnet.