wlsdks
UserLocal-first ontology workbench for teams and AI agents: map business meaning, code structure, and MCP/CLI proof from one markdown graph.
Categories
Indexed Skills (8)
firebase-deploy
Deploy the ontology-atlas static site to Firebase Hosting from this repo. Use when the user asks to deploy, redeploy, publish the site, update Firebase Hosting, or verify the live web.app URL. The workflow must read `.env.prod`, build the static export, deploy only Hosting, and verify the live URL. Never commit `.env.prod` or introduce Firebase backend services.
ontology-bootstrap
Bootstrap an empty (or near-empty) ontology-atlas vault from the surrounding codebase — call analyze_repo_structure once, show the proposed candidates, and selectively land the accepted ones via add_concepts / add_relations (batch writers). Use when the user says "이 codebase 분석해줘" / "bootstrap the ontology" / "fill the vault from the code", or when you notice the vault has only the 5 starter nodes and the user has asked you to do anything ontology-related. Skip when the vault already has 20+ user-curated nodes — bootstrap is for the cold-start case only.
ontology-extract
User gave you prose — a meeting note, a PR description, an RFC draft, a chat log, a paragraph from a Notion page — and asks "extract ontology from this" or similar. Read the prose, cross-check the existing vault with `similar_nodes` / `find_evidence`, then propose a small set of candidate nodes/edges, ask the user to pick which to land, and only then call `add_concept` / `add_relation` / `patch_concept`. Skip when the prose is just a personal note with no ontology-shaped concepts.
ontology-sync
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.
ontology-bootstrap
Bootstrap an empty (or near-empty) oh-my-ontology vault from the surrounding codebase — call analyze_repo_structure once, show the proposed candidates, and selectively land the accepted ones via add_concepts / add_relations (batch writers). Use when the user says "이 codebase 분석해줘" / "bootstrap the ontology" / "fill the vault from the code", or when you notice the vault has only the 5 starter nodes and the user has asked you to do anything ontology-related. Skip when the vault already has 20+ user-curated nodes — bootstrap is for the cold-start case only.
firebase-deploy
Deploy the oh-my-ontology static site to Firebase Hosting from this repo. Use when the user asks to deploy, redeploy, publish the site, update Firebase Hosting, or verify the live web.app URL. The workflow must read `.env.prod`, build the static export, deploy only Hosting, and verify the live URL. Never commit `.env.prod` or introduce Firebase backend services.
ontology-extract
User gave you prose — a meeting note, a PR description, an RFC draft, a chat log, a paragraph from a Notion page — and asks "extract ontology from this" or similar. Read the prose, cross-check the existing vault with `similar_nodes` / `find_evidence`, then propose a small set of candidate nodes/edges, ask the user to pick which to land, and only then call `add_concept` / `add_relation` / `patch_concept`. Skip when the prose is just a personal note with no ontology-shaped concepts.
ontology-sync
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.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.