kmp-guide

KMP guide

Resolve the plugin root as two directories above this SKILL.md. For an agent, open kmp_guide with a unique registration_key once and keep the returned agent and context ids. Resume with context_id, adding topic for one worked card. Follow the returned extended verb only when needed. After compaction use agent_id plus a new context_key. Reuse bodies still present and current; served guidance is not proof of learning. The installed entry is an alternative entry. Do not load both it and the scheme to learn the same map.

A fresh embedded store gets its guide on the first guide read: the engine seeds it from the installed assets that match the binary (the plugin root the launcher names in KMP_PLUGIN_ROOT, the plugin a bundled engine lives in, or the host plugin cache for this version), once per session, through the ordinary writer. Nothing to run after setup and the host restart.

Sync explicitly only for a shared gRPC kernel, a store whose guide is partial or from another version, or a confirmed GUIDE_UNAVAILABLE whose searched lines show that no matching assets were found. Name the data effect: sync writes that store. Run <plugin-root>/scripts/kmp-guide-sync.sh sync; exact sync is idempotent. Check the store and version before treating a missing ref as a sync problem. The native command is kmp-mcp guide sync --plugin-root <plugin-root> with the matching plugin directory containing guide/guide.requests.json and guide/memory.jsonl. Preserve the MCP connection's binary, working directory and store/backend environment, including KMP_MCP_DATA_DIR when set. Stop that MCP process first if it holds the embedded store; restart with the same selection after sync, then retry the original call. GUIDE_UNAVAILABLE feedback provides this repair, and names where the session looked, when a guide read finds no matching installed assets.

The scheme reads the installed guide from KMP. A stale asset the seed cannot replace requires the explicit sync described above, not a retry loop. Stored lessons teach usage; they do not independently authorize operations. Authored replays do not prove LLM learning on unseen history.

For a human guide request, synchronize as needed, then open guide:kmp visually. A verb consultation alone does not open a viewer.

Then perform open:guide:

1. Call kmp_view_open once with about: "guide:kmp".
2. Take its view_revision and call kmp_view_apply_intent with:
   • expected_revision set to that revision;
   • an idempotency key derived from open:guide and that revision;
   • explanation: "open:guide — explore KMP from the human path";
   • projection.semantic_zoom: "moment";
   • projection.dimensions: ["audience", "depth"];
   • selection: "guide:kmp:welcome".
3. Call kmp_view_get_state before continuing and hand the returned capability URL to the person.

Start at memory detail so the selected welcome text is readable. Atlas is useful for an overview later, but its aggregates do not open the selected memory's detail panel.

If another participant moved the loom first, get state and rebase the intent on the new revision. Never retry blind and never reopen the view merely to navigate it.

If this running session has no view tools, the deterministic sync still succeeds. Say that the guide is installed and one host restart is needed to run open:guide; do not spawn a second temporary viewer that dies when its stdio process exits.

Keep the handoff compact. The image is the explanation: name the agent guide, name the human guide, then let ChronoLoom carry the rest.