devmuse

Use when code changes need review, verification, and integration - covers review dispatch, feedback handling, verification gates, and merge/PR workflow

Use before any creative engineering work to design technical architecture — components, interfaces, data flow, error handling. For product/UX requirements (user flows, feature specs), use mu-prd first.

Use when user wants to generate or maintain project-level architecture documentation. Two modes: generate (full wiki creation from codebase analysis) and update (incremental maintenance via git diff). On-demand only — never auto-routed by mu-route.

Use at the start of any unprefixed user message within DevMuse's domain (dev or product work) to route to the right skill. Confidence-based: high confidence invokes silently, medium gives a one-line proposal, low gives full proposal with override options. Bypassed by direct slash invocations (`/mu-<skill>`).

Use when creating new skills, editing existing skills, or verifying skills work before deployment

Use when validating a business premise or defining product strategy (market, BMC, VPC, personas, MVP scope). Two modes: quick (4 forcing questions) or full (comprehensive analysis).

Use when you have an implementation plan ready to execute - supports subagent-driven and inline execution modes with TDD, worktree isolation, and review gates

Use when user needs to understand unfamiliar code before acting — onboarding a new repo, taking over a project, evaluating a dependency, pre-change exploration of an unfamiliar subsystem, or pre-debug exploration around a bug. Produces a persistent mental-model artifact, not a chat summary.

Use when you have a spec or requirements for a multi-step task, before touching code

Use when defining product requirements — user flows, screens, per-feature specs, tiering rules. For technical architecture use mu-arch. For business strategy use mu-biz first.

Use for weekly or periodic retrospective — gather git metrics, review patterns, capture learnings to Claude Code memory.

Use before mu-arch to scope work — enumerate use cases, detect conflicts, assess impact on existing code.

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes