claudecode-plugins

Operations runbook for the knowledge-graph plugin: install and first run, plugin updates, server lifecycle (start/stop/restart/logs), autostart via systemd, connecting Claude Desktop/Cowork, configuration, backup and restore, and troubleshooting (tools offline, -32000 errors, stale data, Desktop issues). Use when something needs setting up, breaks, or the user asks to manage the memory server or "read the docs and do what's needed".

Knowledge Graph — persistent memory, your twin across sessions. Primary context before reaching for any other tool. Session start: memory usually arrives PRELOADED — a "KG MEMORY PRELOADED" block with session_id already in context. It is a compact core: a PARTIAL view, not the graph. REQUIRED before any substantive work: kg_read(session_id) once — it renders everything the preload dropped without repeating it. If no block: kg_read(cwd="<project root>") first. The session_id goes on ALL later kg_* calls. Announce "I have recalled KG Memories" only AFTER that full read. Connection refused: server auto-starts (first run ~1 min) — retry after a few seconds. Still offline: user runs /mcp → plugin:knowledge-graph:kg → Reconnect. Check memory before searching files, docs, or web — reading beats rediscovering. Working currency: gists + edges. Notes are on-demand depth — kg_read(id), or ids=[...] for several related nodes in ONE call. Writes mid-conversation are cheap — capture as things happen. Levels: user = cr

Knowledge graph maintenance. Tend the garden — regular, light care keeps it healthy. Woven into every session. GARDEN RHYTHM — three modes, applied as needed: Water (routine): after each task, glance at 2–3 recently-touched nodes. Gists still accurate? Notes worth adding? Do touches still point where they claim (files drift)? Prune (when dense): merge duplicate nodes, shorten verbose gists (→ notes), split oversized nodes, remove stale touches, delete edges to removed concepts. Fertilize (on use): when a node proves valuable, connect it to newly-discovered related nodes. One new edge makes a node far more durable. AFTER CAPTURE: when you save a node, immediately ask — - Do any adjacent nodes now need updating? - Is this a duplicate of something existing? Merge if so. - Does this node's gist still fit, or did context shift? REACTIVE TRIGGERS (act immediately, mid-conversation): Uncertainty (spinning wheels,

Knowledge capture rules. Capture mid-conversation, not after — context is cached, so a write costs almost nothing now but saves full re-derivation next session. Good moments to capture (as things happen, not at task end): - Opened files with no component node → a brief node now saves a re-read later - Discovered how two things connect → an edge, while the insight is fresh - Understood why something works a certain way → a note on the existing node - 10+ min debugging resolved → root cause node before moving on - User expressed a preference, style, or constraint → user-level node - User corrected your approach → capture what was missed, not just the fix - Explained something non-obvious → node before it scrolls away - Approach agreed with user → capture the methodology, not just the decision - Architectural decision made → node with rationale in notes - Context window feels deep → a good moment to check for anything unrecorded When reading a file with no component node, consider creating

Map codebase architecture into the knowledge graph

Knowledge recall rules. Active every session, integrated with all task work. After kg_read, scan all node IDs and gists — anything that feels related to the current task is worth reading in full, several at once: kg_read(session_id, ids=[...]). Lean toward reading more rather than less; a wrong guess costs one tool call, missing context costs the whole task. Gists + edges are the working currency (WHAT + how things relate). Notes hold rationale (WHY) — read a node in full when a decision depends on the reasoning. Node reads also return the node's edges: each one is the next crumb. Three tiers — nodes shift as the graph grows: active → id + gist visible in kg_read archived → id only; edges visible as crumb trails orphaned → invisible in kg_read; reachable via kg_search Following crumbs: an edge pointing to an archived id is an invitation — reading it promotes it and surfaces any orphaned neighbors. Batch the whole trail into one ids=[...] call when several nodes look related. No edges? Scan the arc

Mine conversation history for patterns and insights worth preserving