ontology-synclisted

After a code change, sync the project's ontology vault — read what's already there, identify new capabilities / elements / domains introduced by the change, and write them back via the MCP server (or fall back to the CLI). Use this at the end of any task that introduces a new feature, refactors a module, or renames a unit. Skip when the change is purely a typo, style nudge, or test fixture tweak.
wlsdks/oh-my-ontology · ★ 1 · AI & Automation · score 67

Install: claude install-skill wlsdks/oh-my-ontology

# /ontology-sync — keep the vault in step with the code The vault under `docs/ontology/` (this repo's dogfood) — or the user's own vault when one is selected — is the **shared mental model** between the developer and the AI agent. When code grows or shifts, the vault has to follow, otherwise the graph drifts and stops being a useful map. This skill runs after a unit of code work (new feature, refactor, rename, notable cleanup) and produces the corresponding ontology updates so the human sees the change appear in their workbench. ## When to run **Run when**: - a new user-visible capability landed (login flow, checkout flow, …) - a new concrete element landed (jwt-token, indexeddb-adapter, sigma-canvas, …) - a domain was reshaped (auth → split into auth + session, …) - a slug-level rename happened in code that should mirror in the graph **Skip when**: - the change is a typo, comment tweak, or single-line style nudge - the change is purely test fixture / lint config / docs prose - the change reverts something already in the graph ## Workflow The MCP server `oh-my-ontology-local` (or the published `oh-my-ontology-mcp`) is the primary path. Fall back to the `cli/` binary (`oh-my-ontology add` / `import` / `validate`) if MCP is unavailable in the current session. ### 1. Read what's already there (cheap) ``` list_kinds # how many of each kind list_concepts # full node table (paginated) get_concept(slug)