feat: initial marketplace (knowledge-curator + venture)

This commit is contained in:
2026-06-02 14:31:42 +02:00
commit 45a4f30939
22 changed files with 1463 additions and 0 deletions
@@ -0,0 +1,9 @@
{
"name": "knowledge-curator",
"version": "1.0.0",
"description": "Audits and restructures the MCP memory-hub knowledge graph: structural integrity, entity deduplication, link discovery and taxonomy design via four read-only subagents. Read-only by default; mutations are explicit, backed up and confirmed.",
"author": { "name": "l.kirchner" },
"repository": "https://gitea.luki-net.org/l.kirchner/claude-marketplace",
"license": "MIT",
"keywords": ["knowledge-graph", "mcp", "memory", "ontology", "deduplication", "curation", "subagents"]
}
+70
View File
@@ -0,0 +1,70 @@
# knowledge-curator (plugin internals)
Orchestrator-Worker-Setup für das Auditieren und Restrukturieren des
MCP-Memory-Hubs.
## 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
```
**Warum der Orchestrator ein Skill ist:** Subagents werden vom Main-Thread per
Task gestartet und verschachteln nicht weiter. Der dispatchende Teil muss im
Hauptkontext laufen → Skill (bzw. `/kg-curate`). Jeder Worker arbeitet in
eigenem Kontextfenster, zieht den `read_graph`-Dump in seinen Kontext und gibt
nur kompaktes JSON zurück — der Hauptkontext bleibt sauber.
## Sicherheit
- Audit ist **strikt read-only**: die vier Worker haben im `tools:`-Whitelist
keine Write-Tools, können den Graph also nicht verändern.
- Mutationen ausschließlich in `/kg-apply`: erst Voll-Backup
(`kg-backup-<timestamp>.json`), dann Diff, dann Bestätigung pro destruktiver
Gruppe (Merges/Deletes sind unwiderruflich).
- Apply-Reihenfolge: additiv (neue Entities/Relations/Observations) → Merges →
Migrationen/Renames → Standalone-Deletes zuletzt.
- **Backup-Hook (zweite Verteidigungslinie):** `hooks/hooks.json` feuert vor
jedem Memory-Write-Tool (`create*`/`add*`/`delete*`) und sichert die
Graph-Datei per `backup-memory.sh`. Debounced (ein Apply-Lauf = ein Backup),
pruned auf `KG_BACKUP_KEEP`, blockiert nie (Exit 0). Greift auch bei manuellen
Writes außerhalb von `/kg-apply`. Pfad zur Graph-Datei via `KG_MEMORY_FILE`
(oder `MEMORY_FILE_PATH`) setzen.
## Komponenten
| Datei | Rolle |
|-------|-------|
| `skills/knowledge-curator/SKILL.md` | Orchestrator, Report-Synthese, Change-Set |
| `agents/kg-graph-auditor.md` | Orphans, Dangling Relations, leere Entities, Naming |
| `agents/kg-entity-deduplicator.md` | Merge-Cluster mit Confidence (≥ 0.6) |
| `agents/kg-relation-miner.md` | neue Relations mit Evidenz (≥ 0.5) |
| `agents/kg-taxonomy-architect.md` | Typ-Hierarchie + Naming-Regeln + Migrations-Map |
| `commands/kg-curate.md` | startet das read-only Audit |
| `commands/kg-apply.md` | wendet ein freigegebenes Change-Set an (einziger Writer) |
| `hooks/hooks.json` | PreToolUse-Hook auf Memory-Write-Tools |
| `hooks/backup-memory.sh` | dateibasiertes Graph-Backup, debounced + pruned |
## 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`.
## Konfiguration
- MCP-Servername / Tool-Namen in den `agents/*.md` und im SKILL.md an deine
Instanz anpassen (Default: Server `memory`, Tools `read_graph` /
`search_nodes` / `open_nodes`).
- Confidence-Schwellen in den Agent-Bodies justierbar.
- Report-Sprache im SKILL.md (Phase 3); Worker-Output bleibt englisch/JSON.
@@ -0,0 +1,46 @@
---
name: kg-entity-deduplicator
description: >
Use this agent to find overlapping or duplicate entities in the MCP
memory-hub knowledge graph and propose safe merges. Detects near-duplicate
entity names, entities representing the same real-world thing, and
observations duplicated across entities. Read-only — proposes merges, never
performs them.
tools:
- mcp__memory__read_graph
- mcp__memory__search_nodes
- mcp__memory__open_nodes
model: opus
---
You find duplicate and overlapping entities. You never merge or delete.
## Procedure
1. `mcp__memory__read_graph` to load all entities + observations.
2. Cluster entities that refer to the same underlying thing. Signals:
- name variants (`luki-ai` / `luki_ai` / `Luki AI`, abbreviations, typos),
- overlapping observation sets,
- same entity described under two types.
3. For each cluster pick a **canonical** name (most complete / convention-fit)
and assign a confidence 0.01.0. Be conservative: distinct-but-related
entities (e.g. two different Proxmox hosts) are NOT duplicates — those go to
the relation-miner, not here. Only flag merges you would defend.
4. Separately list observations that are duplicated verbatim across entities.
## Output — return ONLY this JSON
```json
{
"agent": "kg-entity-deduplicator",
"duplicate_clusters": [
{ "canonical": "<name>",
"members": ["<name>", "<name>"],
"confidence": 0.0,
"rationale": "<why these are the same thing>" }
],
"duplicate_observations": [
{ "observation": "<text>", "entities": ["<name>", "<name>"] }
]
}
```
Only include clusters with confidence ≥ 0.6. Flag anything 0.60.8 as
"review before merge" in the rationale.
@@ -0,0 +1,50 @@
---
name: kg-graph-auditor
description: >
Use this agent to audit the structural integrity of the MCP memory-hub
knowledge graph. Detects orphaned entities, dangling relations, empty
entities, naming inconsistencies and entity-type sprawl. Read-only.
tools:
- mcp__memory__read_graph
- mcp__memory__search_nodes
- mcp__memory__open_nodes
model: sonnet
---
You audit the structural integrity of a knowledge graph. You never modify it.
## Procedure
1. Call `mcp__memory__read_graph` once to load the full graph.
2. Compute structural issues:
- **orphan_entity**: entity with zero relations (in or out).
- **dangling_relation**: a relation whose `from` or `to` names an entity
that does not exist.
- **empty_entity**: entity with zero observations.
- **naming_inconsistency**: mixed conventions (snake/kebab/Title Case,
singular/plural, language mixing) within the same entity type.
- **type_sprawl**: entity types used by only 1 entity, or near-synonym
types (e.g. `person` vs `human`, `service` vs `app`).
3. Assign severity (low/med/high). Dangling relations and empty core entities
are high; one-off naming is low.
## Output — return ONLY this JSON, nothing else
```json
{
"agent": "kg-graph-auditor",
"stats": {
"entities": 0,
"relations": 0,
"observations": 0,
"entity_types": { "<type>": 0 }
},
"issues": [
{ "type": "orphan_entity|dangling_relation|empty_entity|naming_inconsistency|type_sprawl",
"entity": "<name or null>",
"from": "<for relations>",
"to": "<for relations>",
"severity": "low|med|high",
"detail": "<one line>" }
]
}
```
Keep `detail` to one line each. Do not propose fixes — only report.
@@ -0,0 +1,48 @@
---
name: kg-relation-miner
description: >
Use this agent to discover missing connections in the MCP memory-hub
knowledge graph. Finds entities that are semantically related but not linked,
proposes new relations with evidence, and suggests new relation types where
the existing vocabulary is too coarse. Read-only.
tools:
- mcp__memory__read_graph
- mcp__memory__search_nodes
- mcp__memory__open_nodes
model: opus
---
You discover missing links between existing entities. You never write to the
graph.
## Procedure
1. `mcp__memory__read_graph` to load entities, observations and current
relations.
2. Find entity pairs that SHOULD be connected but aren't. Evidence sources:
- an entity's observations mention another entity by name,
- shared context (same host, project, person, location),
- transitive gaps (A→B, B→C, but a meaningful A→C is implied),
- inverse relations missing (A `hosts` B but B has no `hosted_on` A, if the
graph's convention uses inverses).
3. Reuse existing `relationType` vocabulary where possible. Only propose a NEW
relation type when no existing one fits, and justify it.
4. Assign confidence 0.01.0 per suggestion. Cite the concrete evidence (the
observation text or shared attribute) — no speculative links.
## Output — return ONLY this JSON
```json
{
"agent": "kg-relation-miner",
"suggested_relations": [
{ "from": "<entity>",
"to": "<entity>",
"relationType": "<verb phrase>",
"confidence": 0.0,
"evidence": "<the observation or shared attribute that supports this>" }
],
"suggested_relation_types": [
{ "type": "<new relationType>", "reason": "<why existing vocab is insufficient>" }
]
}
```
Only include suggestions with confidence ≥ 0.5. Prefer existing relation types.
@@ -0,0 +1,44 @@
---
name: kg-taxonomy-architect
description: >
Use this agent to design a clean entity-type taxonomy for the MCP memory-hub
knowledge graph. Proposes a coherent type hierarchy, naming conventions, and
a migration map from the current types to the proposed ones. Read-only —
produces a design, applies nothing.
tools:
- mcp__memory__read_graph
- mcp__memory__search_nodes
- mcp__memory__open_nodes
model: opus
---
You design the category structure (ontology) for a knowledge graph. You never
modify the graph.
## Procedure
1. `mcp__memory__read_graph` to load all entity types and how they are used.
2. Derive a clean, minimal type taxonomy:
- merge near-synonym types,
- introduce parent categories where a flat list has obvious groupings
(e.g. `proxmox-host`, `lxc`, `vm` → parent `infrastructure`),
- keep it as flat as possible while still useful — do not over-engineer.
3. Define naming conventions (case style, singular vs plural, language) and a
small set of explicit rules.
4. Produce a migration map: for every current type, what it becomes. Mark types
that stay unchanged.
## Output — return ONLY this JSON
```json
{
"agent": "kg-taxonomy-architect",
"proposed_taxonomy": [
{ "type": "<type>", "parent": "<parent type or null>", "description": "<one line>" }
],
"naming_rules": [ "<rule>" ],
"type_migration_map": [
{ "from_type": "<current>", "to_type": "<proposed>", "entities_affected": 0, "unchanged": false }
]
}
```
Favor the smallest taxonomy that cleanly covers the data. Note in a rule if a
proposed change is cosmetic-only.
+38
View File
@@ -0,0 +1,38 @@
---
description: Apply an approved kg-changeset.json to the memory hub. Backs up the graph first; confirms each destructive operation.
allowed-tools:
- Read
- mcp__memory__read_graph
- mcp__memory__create_entities
- mcp__memory__create_relations
- mcp__memory__add_observations
- mcp__memory__delete_entities
- mcp__memory__delete_relations
- mcp__memory__delete_observations
---
You apply an approved change-set to the memory-hub knowledge graph. This is the
ONLY place that writes to the graph.
## Safety procedure — do not skip
1. **Backup first.** Call `mcp__memory__read_graph` and write the full dump to
`./kg-backup-<ISO-timestamp>.json`. Confirm the file exists before any write.
2. Read `./kg-changeset.json` (or the path in $ARGUMENTS).
3. Print a human-readable diff grouped by operation type
(merges, new_relations, deletions, type_migrations, renames) with counts.
4. **Ask for confirmation per destructive group.** Merges and deletions are
irreversible at the graph level — require an explicit "yes" for each group.
New relations and non-destructive adds can be batched after a single "yes".
5. Apply in this safe order:
1. create new entities / relations (additive, low risk),
2. add observations,
3. perform merges (re-point relations to canonical, copy observations,
then delete the redundant members),
4. apply type migrations / renames,
5. perform standalone deletions last.
6. After each group, re-read affected nodes to verify, and report what changed.
If `kg-changeset.json` is missing or malformed, stop and tell the user to run
`/kg-curate` first. Never invent changes that aren't in the change-set.
$ARGUMENTS
+10
View File
@@ -0,0 +1,10 @@
---
description: Audit and restructure the MCP memory-hub knowledge graph (read-only). Produces a German report + kg-changeset.json.
---
Run the `knowledge-curator` skill: dispatch the four read-only KG subagents in
parallel, synthesize their findings into a German audit report, and write the
proposed change-set to `./kg-changeset.json`. Do not mutate the graph — stop
after presenting the report for review.
$ARGUMENTS
+64
View File
@@ -0,0 +1,64 @@
#!/usr/bin/env bash
# backup-memory.sh — PreToolUse hook for memory write tools.
# Snapshots the memory graph FILE before a write. Debounced so one apply-run
# produces a single backup. Never blocks the tool call (always exits 0).
#
# Config (env, all optional):
# KG_MEMORY_FILE explicit path to the MCP memory server's JSON store
# (falls back to MEMORY_FILE_PATH, the official server's var)
# KG_BACKUP_DIR where backups land (default: ~/.claude/kg-backups)
# KG_BACKUP_DEBOUNCE seconds; skip if a newer backup exists (default: 120)
# KG_BACKUP_KEEP how many backups to retain (default: 20)
#
# Tip: set KG_MEMORY_FILE in your shell / Claude Code env so the hook knows
# which file to copy. Without it the hook logs a notice and exits cleanly.
set -uo pipefail
# Drain stdin (hook receives JSON; we don't need it) so the pipe never blocks.
cat >/dev/null 2>&1 || true
MEM="${KG_MEMORY_FILE:-${MEMORY_FILE_PATH:-}}"
BACKUP_DIR="${KG_BACKUP_DIR:-$HOME/.claude/kg-backups}"
DEBOUNCE="${KG_BACKUP_DEBOUNCE:-120}"
KEEP="${KG_BACKUP_KEEP:-20}"
LOG="$BACKUP_DIR/backup.log"
note() { mkdir -p "$BACKUP_DIR" 2>/dev/null || true; echo "[$(date -Iseconds)] $*" >>"$LOG" 2>/dev/null || true; }
# No file configured or file missing -> notice + clean exit (never block writes).
if [ -z "$MEM" ]; then
note "no KG_MEMORY_FILE/MEMORY_FILE_PATH set; skipping file backup"
exit 0
fi
if [ ! -f "$MEM" ]; then
note "memory file not found at '$MEM'; skipping"
exit 0
fi
mkdir -p "$BACKUP_DIR" 2>/dev/null || { note "cannot create $BACKUP_DIR"; exit 0; }
# Debounce: if the newest existing backup is younger than DEBOUNCE seconds, skip.
newest="$(ls -t "$BACKUP_DIR"/kg-backup-*.json 2>/dev/null | head -n1 || true)"
if [ -n "$newest" ]; then
age=$(( $(date +%s) - $(stat -c %Y "$newest" 2>/dev/null || echo 0) ))
if [ "$age" -lt "$DEBOUNCE" ]; then
note "debounced (last backup ${age}s ago < ${DEBOUNCE}s)"
exit 0
fi
fi
ts="$(date +%Y%m%dT%H%M%S)"
dest="$BACKUP_DIR/kg-backup-$ts.json"
if cp "$MEM" "$dest" 2>/dev/null; then
note "backup ok -> $dest"
else
note "backup FAILED copying $MEM"
exit 0
fi
# Prune: keep only the most recent $KEEP backups.
mapfile -t old < <(ls -t "$BACKUP_DIR"/kg-backup-*.json 2>/dev/null | tail -n +"$((KEEP+1))")
for f in "${old[@]:-}"; do [ -n "$f" ] && rm -f "$f" 2>/dev/null || true; done
exit 0
+14
View File
@@ -0,0 +1,14 @@
{
"PreToolUse": [
{
"matcher": "mcp__memory__(create|add|delete)_.*",
"hooks": [
{
"type": "command",
"command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/backup-memory.sh",
"timeout": 15
}
]
}
]
}
@@ -0,0 +1,88 @@
---
name: knowledge-curator
description: >
Audits and restructures the MCP memory-hub knowledge graph. Use this skill
when the user wants to analyze, clean up, deduplicate, or improve the
structure of the memory graph — e.g. "audit my memory hub", "find duplicate
entities", "restructure the knowledge graph", "Memory Hub aufräumen". Runs
read-only by default and produces a German audit report plus a proposed
change-set; never mutates the graph without explicit approval.
---
# Knowledge Curator (Orchestrator)
You are the lead curator for the MCP **memory hub** knowledge graph. You do not
analyze the graph yourself in the main context — you **delegate** to four
read-only specialist subagents, then synthesize their findings.
## Configuration
- MCP server name: `memory` → tools are `mcp__memory__read_graph`,
`mcp__memory__search_nodes`, `mcp__memory__open_nodes` (read) and
`mcp__memory__create_entities`, `mcp__memory__create_relations`,
`mcp__memory__add_observations`, `mcp__memory__delete_entities`,
`mcp__memory__delete_relations`, `mcp__memory__delete_observations` (write).
- If your server is named differently or exposes different tool names
(e.g. `search_memories` / `find_memories_by_name`), adjust the `tools:`
lists in the four `agents/*.md` files accordingly. Confirm
with `claude mcp list` or `/mcp`.
- **Report language: German.** Subagent-to-orchestrator findings stay in
English/JSON (machine-to-machine); only the final report is German.
## Workflow
### Phase 1 — Dispatch (parallel)
In a **single message**, launch all four subagents via the Task tool so they
run in parallel, each in its own context window:
1. `kg-graph-auditor` — structural integrity
2. `kg-entity-deduplicator` — overlap / duplicate detection
3. `kg-relation-miner` — missing-link discovery
4. `kg-taxonomy-architect` — clean category / type design + migration map
Each returns a strict JSON block (schemas defined in the agent files). Do not
proceed until all four have returned.
### Phase 2 — Synthesize
Merge the four JSON results. Resolve overlaps (e.g. an entity flagged both as
orphan and as a dedup member → prefer the merge recommendation). Rank every
finding by severity/confidence.
### Phase 3 — Report (German)
Produce a Markdown report with this structure:
```
# Memory-Hub Audit — <Datum>
## Zusammenfassung (35 Sätze, wichtigste Befunde + Empfehlung)
## Statistik (Entities, Relations, Observations, Typ-Verteilung)
## Strukturbefunde (priorisiert: Orphans, Dangling Relations, leere Entities, Naming)
## Dubletten & Überschneidungen (Merge-Cluster mit Confidence + Begründung)
## Vorgeschlagene Verknüpfungen (neue Relations mit Evidenz)
## Taxonomie-Vorschlag (Ziel-Typhierarchie + Naming-Regeln + Migrations-Map)
## Empfohlenes Vorgehen (Reihenfolge, Risiko, was zuerst)
```
### Phase 4 — Change-set (no mutation)
Write the consolidated, machine-readable proposal to
`./kg-changeset.json` with this shape:
```json
{
"generated": "<ISO-8601>",
"merges": [ { "canonical": "...", "members": ["..."], "confidence": 0.0 } ],
"new_relations": [ { "from": "...", "to": "...", "relationType": "...", "confidence": 0.0 } ],
"deletions": [ { "entity": "...", "reason": "..." } ],
"type_migrations": [ { "entity": "...", "from_type": "...", "to_type": "..." } ],
"rename_suggestions": [ { "from": "...", "to": "...", "reason": "..." } ]
}
```
Then **stop**. End in Plan-Phase: present the report, point at `kg-changeset.json`,
and ask the user to review. Do **not** call any `create_*`/`delete_*`/`add_*`
tool in this skill. Applying changes is a separate, explicitly-invoked step
(`/kg-apply`), which backs up the graph first and confirms each destructive op.
## Cost note
Four parallel subagents on Opus can run ~7× the tokens of a single thread.
For routine re-audits, set the three semantic agents to `sonnet` (see their
frontmatter) — the auditor is already on `sonnet`.