mykg
SolidRun mykg knowledge-graph commands inside Claude Code from one slash command `/mykg`. The user describes intent in natural language (extract, append, sync, resume, approve, walkthrough, parse-docs, fetch-web, query); the skill parses intent, builds the right `mykg` CLI command from the live `--help` output, confirms, runs it, and drives the inbox/outbox watch loop for LLM-bearing commands (extract-graph). For read-only queries, prefers MCP tools when the mykg MCP server is online, falling back to reading session files directly, with the `mykg query` CLI as a last-resort fallback. Ensures `.mcp.json` is configured (with user approval). Excludes `mykg init` (interactive shell command) and `mykg merge-graphs` (follow-up planning).
Install
Quality Score: 83/100
Skill Content
Details
- Author
- SenolIsci
- Repository
- SenolIsci/mykg
- Created
- 3 months ago
- Last Updated
- 1 weeks ago
- Language
- Python
- License
- MIT
Integrates with
Similar Skills
Semantically similar based on skill content — not just same category
knowledge-graph
Records and retrieves engineering decisions in the kgai knowledge graph (a small, stable graph of domain ELEMENTS — Invoice, Pricing, Checkout… — shaped by an immutable log of DECISIONS). INVOKE THIS SKILL AUTOMATICALLY, WITHOUT WAITING TO BE ASKED, WHENEVER you make or implement a structural/architectural choice: splitting, merging, or moving a module/feature; renaming a domain element (its canonical name changes — code-level renames of files/functions don't count); changing a dependency, ownership boundary, or how something is exposed/rendered; deprecating or replacing a prior decision; or finishing ANY task in which such a choice was made. The skill then records it for you (no confirmation needed) — capturing the decision is part of completing the task, not optional bookkeeping, so do not end your turn with an uncaptured structural decision. ALSO invoke it BEFORE a non-trivial change to read prior decisions you must respect, and to answer "why is X like this", "how does X relate to Y", "what changed and wh
kg-core
Knowledge Graph — persistent memory, your twin across sessions. Memory usually arrives PRELOADED: a "KG MEMORY PRELOADED" block carrying the session_id — follow its directive (one full kg_read before substantive work). No block? Then the full read is on you: kg_read(cwd="<project root>") comes before substantive work, whatever the task. Then live in the graph while you work: recall before rediscovering — reading beats re-deriving; capture at the moment of learning — whatever cost effort to gain; connect rather than duplicate — an edge beats a new node; search below the surface — the render shows the top of a grown graph, not all of it. In a rich, long-lived graph the fact you need is often buried under fresher work; kg_search reaches every tier. Gauge by the graph's age and size: near-empty means little to find, mature means the answer is likely there, just not on the surface. And a node found when truly needed earns the usefulness credit that keeps it alive. Mechanics live in the kg_* tool descriptions; oper
okf-kg
Builds and queries a SQLite+FTS5 knowledge graph over an OKF markdown vault (a curated knowledge base of frontmattered concept notes joined by standard markdown links). Use when asked to ingest, index, search, query, or traverse an OKF vault or knowledge base - e.g. "ingest this vault", "search the knowledge base for X", "what links to concept Y", "how are A and B connected", "rebuild the knowledge graph" - when answering ANY factual or relationship question from such a vault's contents ("using the vault at <path>, what/how..."; "what does the knowledge base say about X") - or when any agent needs to orient inside a vault of concept notes before answering from it or generating docs. Fully offline and deterministic - no API keys, no network. The graph lives at <vault>/.okf-kg.db and rebuilds idempotently from the markdown.