wlsdks
UserUnderstand what your codebase builds, why it is structured that way, and what a change could affect. One shared Markdown ontology for humans and coding agents—visualized for people, accessible to agents through MCP, and reviewed with Git. Local-first. Open source.
Categories
Indexed Skills (29)
ontology-bootstrap
Build a trustworthy first ontology from an empty or near-empty ontology-atlas vault using only Atlas MCP evidence. Use when the user asks to analyze a codebase, bootstrap/fill its ontology, extract product meaning from a repository, or when a requested ontology task finds only starter nodes. Separate observed implementation facts from proposed meanings, define and cite every domain/capability, answer competency questions, obtain independent source-hidden qualification and user approval, then write only the exact released plan with batch tools. Route mature vaults with 20+ curated nodes to ontology-sync instead; this is a workflow threshold, never a vault or project node limit.
ontology-extract
Extract a small, evidence-bound set of ontology candidates from prose, check the existing vault for duplicates, obtain user approval, and land only the approved nodes and relations.
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.
design-audit
Audit a finished frontend change by measuring rendered rects and computed styles before using screenshots as human-checkable evidence.
design-build
Build UI from this repository's primitives and ramps in a deterministic order, then prove the rendered result with the matching instruments and gates.
design-council
Review only the Atlas structural commitments selected by design routing, using relevant seats, built evidence, optional conflict rebuttal, and one accountable guardian.
design-directions
When Atlas design routing finds a structural commitment, sketch three different directions in text before code, including the status quo, and let the owner choose one.
gate-probe
Prove a gate before trusting it. Inventory violations, plant a defect, verify RED, restore GREEN, prevent idle scans, and confirm automatic wiring.
map-perf
Measure topology-map drag, pan, and zoom with a deterministic harness that proves it grabbed a real node instead of silently panning the background.
motion-verify
Verify canvas and UI motion with a real macOS recording, uniform 30fps frames, a visual phase strip, and frame-to-frame pixel-diff statistics.
ontology-absorb-confluence
Read a wiki page through a user-registered third-party MCP, classify it with absorb_document dry-run, obtain approval, and land only approved candidates with the source URL cited.
ontology-field-trial
Measure Atlas ontology quality on an unfamiliar repository with a source-hidden handoff and four baseline measurements. Use for changes to meaning-construction rules or MCP read/write behavior that can change vault contents, or an explicit ontology-quality field trial. Skip UI work and wording-only clarifications that preserve the evidence, approval, and write contracts.
parallel-brief
Write a subagent brief that isolates ports, files, worktrees, scratch output, baselines, and primary evidence before parallel work begins.
po-council
Review a hard-to-reverse Atlas product decision with Evidence plus one risk specialist, testing whether it restores a named human ability.
po-pass
Route Atlas product work from observable change facts and one human-recovery outcome; use a compact solo pass for reversible work.
responsive-sweep
Live-verify layout across tablet, laptop, and wide breakpoints by measuring rects, elementFromPoint occlusion, bottom-tab reserve, and screenshots.
user-walkthrough
Walk one complete journey against the running build with a declared knowledge state, name observable UX failure patterns, and refuse to invent whether a person would want the product.
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.
atlas-absorb
글에서 개념 뽑기. 회의록·기획서·PR 설명에서 개념 후보를 뽑되 중복부터 먼저 확인한다. 사람이 고르기 전에는 쓰지 않는다. "이 글에서 뽑아줘" · "이 문서 반영해줘" 일 때 쓴다.
atlas-grow
다음 한 걸음. 이 볼트에 무엇을 더하면 값이 가장 큰지 후보를 근거와 함께 뽑아 보여 준다. 사람이 고르기 전에는 한 글자도 쓰지 않는다. "다음에 뭐 채워" · "빈 곳 찾아줘" · "더 넣을 거 있어" 일 때 쓴다.
atlas-review
Review this vault. Find what is broken or disconnected, report it in plain language, and give the exact call that fixes each one. Writes nothing. Use for "what's wrong here" · "check the vault" · "is this healthy".
codex
OpenAI Codex CLI — delegate coding tasks (build features, refactor, review) to a backgrounded agent. Requires OPENAI_API_KEY.
gh
GitHub CLI — read PR status, CI logs, issues, releases, and run arbitrary `gh api` queries.
loop-creator
Use when 진안 wants to start (register) an autonomous improvement loop on the Muse repo — "루프 돌려줘", "loop 등록", "X를 계속 강화하는 루프", or just a theme to iterate on. Generates a principle-compliant recurring loop prompt from its bundled loop-engineering.md contract AND registers the cron itself, then reports the prompt + cron id + how to stop. The autonomous successor to hand-written ad-hoc loop prompts.
release
Use when 진안 wants to cut/tag a Muse release or asks anything about the next version — "릴리스 찍어줘", "release 만들자", "버전 올려줘", "v0.2 내자", "patch 올려줘", "다음 버전 뭐야", "changelog/릴리스 노트 만들어줘", "GitHub release 올려줘", "이번엔 minor야 patch야". Reads the full commit history since the last tag, AUTO-DECIDES patch vs minor vs major (patch climbs by default, minor only on a breaking public-surface change or an explicit milestone — per docs/VERSIONING.md), writes curated user-facing release notes from those commits, then bumps + changelogs + commits + tags + pushes + creates the GitHub Release (pre-release while 0.x). Muse-specific.
grow-muse
Use when deciding what NEW user-facing capability to build next for Muse — the owner asked for growth, a daily flow dead-ends because a capability doesn't exist, or a growth-loop fire. For defects, debt, or dead code in what already exists, use improve-muse instead.
improve-muse
Use when deciding what internal/hardening work to do next on the Muse repo — at the start of a maintenance pass, after a regression or real failure surfaces, or as the per-fire entrypoint of a hardening loop. Covers defects, silent failures, debt, dead code. For a NEW user-facing capability, use grow-muse instead.
muse-dev-patterns
The distilled per-slice engineering discipline of the Muse repo — how to triage a failing gate, probe the live path, prove a test isn't vacuous, calibrate a constant from measurement, and land a slice with the right writeback. Use this whenever working on Muse code — especially when a gate/test/battery fails and you must decide "my bug, stale expectation, or pre-existing rot?", when adding or tuning any threshold constant, when writing a test for a fix, when creating a live eval battery, or when landing/committing a slice. Also use it when a claim like "X works" needs verification — it says which proof is the cheapest sufficient one.
scout-rivals
Use when the owner wants to know how Muse compares to the open-source agent landscape RIGHT NOW — what openclaw, hermes-agent, and other notable open-source agents shipped recently, what Muse lacks, or when the parity reservoir feels stale; also as the per-fire entrypoint of a rival-watch loop. Produces judged intelligence only — building belongs to grow-muse/improve-muse.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.