wlsdks

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.

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.