moicle 2.2.2 → 2.3.0

package/README.md

@@ -25,9 +25,11 @@ A toolkit to bootstrap and accelerate project development with Claude Code throu
 - [x] Claude
 - [x] Codex CLI
 - [x] Antigravity
-- [ ] Cursor
+- [x] Cursor
 - [ ] Windsurf
 
+Older MoiCle versions merged agents into `~/.cursor/AGENTS.md`. Re-run `moicle install --target cursor` for native `.cursor/rules/*.mdc` layout; you may delete legacy `AGENTS.md` manually.
+
 ## Installation
 
 ```bash
@@ -46,6 +48,10 @@ moicle install --target codex --global
 # Install for Antigravity
 moicle install --target antigravity --global
 
+# Install for Cursor (rules, commands, skills, architecture)
+moicle install --target cursor --global
+moicle install --target cursor --project
+
 # Choose:
 # 1. Pick Claude Code, Codex CLI, or Antigravity
 # 2. Pick global or project scope
@@ -60,7 +66,9 @@ moicle install --target antigravity --global
 | `moicle install --project` | Install to ./.claude/ (copies) |
 | `moicle install --target codex --global` | Install Codex skills + architecture to ~/.codex/ |
 | `moicle install --target codex --project` | Install Codex skills + architecture to ./.codex/ |
-| `moicle list` | List all installed items |
+| `moicle install --target cursor --global` | Install Cursor rules, commands, skills to ~/.cursor/ |
+| `moicle install --target cursor --project` | Install Cursor assets to ./.cursor/ |
+| `moicle list --target cursor` | List Cursor rules, commands, and skills |
 | `moicle status` | Show enabled/disabled status |
 | `moicle enable <item>` | Enable an agent/command/skill |
 | `moicle disable <item>` | Disable an agent/command/skill |
@@ -118,58 +126,58 @@ moicle install --target antigravity --global
 
 ### Skills (21)
 
-Skills are grouped into 6 namespaces. Type `/<group>:<tab>` in Claude Code to see all skills in a group.
+Skills are grouped by a `<group>-` prefix. Type `/<group>-` then `Tab` in Claude Code to see all skills in a group.
 
-**`/feature:*` — Build & Change**
+**`/feature-*` — Build & Change**
 
 | Skill | When to use |
 |-------|-------------|
-| `/feature:new` | Build a new feature end-to-end following DDD |
-| `/feature:refactor` | Restructure existing module to DDD or improve internals |
-| `/feature:api` | Add a new endpoint or integrate an external API |
-| `/feature:deprecate` | Safely sunset a feature, API, or module |
+| `/feature-new` | Build a new feature end-to-end following DDD |
+| `/feature-refactor` | Restructure existing module to DDD or improve internals |
+| `/feature-api` | Add a new endpoint or integrate an external API |
+| `/feature-deprecate` | Safely sunset a feature, API, or module |
 
-**`/fix:*` — Bugs & Incidents**
+**`/fix-*` — Bugs & Incidents**
 
 | Skill | When to use |
 |-------|-------------|
-| `/fix:hotfix` | Fix a bug fast with a rollback plan |
-| `/fix:root-cause` | Hard-to-trace bug that has been "fixed" multiple times |
-| `/fix:incident` | Production outage / on-call workflow |
-| `/fix:pr-comment` | Address review comments on an existing PR |
+| `/fix-hotfix` | Fix a bug fast with a rollback plan |
+| `/fix-root-cause` | Hard-to-trace bug that has been "fixed" multiple times |
+| `/fix-incident` | Production outage / on-call workflow |
+| `/fix-pr-comment` | Address review comments on an existing PR |
 
-**`/review:*` — Review & Quality**
+**`/review-*` — Review & Quality**
 
 | Skill | When to use |
 |-------|-------------|
-| `/review:branch` | Self-review your branch BEFORE pushing / opening PR |
-| `/review:pr` | Review someone else's open PR |
-| `/review:architect` | DDD compliance check (called by `/feature:new` / `/feature:refactor`) |
-| `/review:tdd` | Drive implementation with test-first discipline |
+| `/review-branch` | Self-review your branch BEFORE pushing / opening PR |
+| `/review-pr` | Review someone else's open PR |
+| `/review-architect` | DDD compliance check (called by `/feature-new` / `/feature-refactor`) |
+| `/review-tdd` | Drive implementation with test-first discipline |
 
-**`/research:*` — Explore & Learn**
+**`/research-*` — Explore & Learn**
 
 | Skill | When to use |
 |-------|-------------|
-| `/research:web` | Search the web for solutions / best practices |
-| `/research:spike` | Time-boxed prototype to learn / decide |
-| `/research:onboarding` | Get up to speed on a new codebase |
+| `/research-web` | Search the web for solutions / best practices |
+| `/research-spike` | Time-boxed prototype to learn / decide |
+| `/research-onboarding` | Get up to speed on a new codebase |
 
-**`/docs:*` — Project Documentation**
+**`/docs-*` — Project Documentation**
 
 | Skill | When to use |
 |-------|-------------|
-| `/docs:write` | Author docs manually (README / API / ARCH / CONTRIB) |
-| `/docs:sync` | Auto-generate structured docs from codebase with review loop |
+| `/docs-write` | Author docs manually (README / API / ARCH / CONTRIB) |
+| `/docs-sync` | Auto-generate structured docs from codebase with review loop |
 
-**`/marketing:*` — Brand & Content** (wrapped by the `/marketing` command)
+**`/marketing-*` — Brand & Content** (wrapped by the `/marketing` command)
 
 | Skill | When to use |
 |-------|-------------|
-| `/marketing:content` | Multi-post content strategy (pillars, calendar, channels) |
-| `/marketing:seo-blog` | Write ONE evergreen blog post optimized for Search + AI tools |
-| `/marketing:logo` | Logo + brand identity specification |
-| `/marketing:video` | Video script, storyboard, production plan |
+| `/marketing-content` | Multi-post content strategy (pillars, calendar, channels) |
+| `/marketing-seo-blog` | Write ONE evergreen blog post optimized for Search + AI tools |
+| `/marketing-logo` | Logo + brand identity specification |
+| `/marketing-video` | Video script, storyboard, production plan |
 
 ### Skill decision matrix
 
@@ -177,19 +185,19 @@ When more than one skill could fit, use this matrix:
 
 | Situation | Use | Not |
 |-----------|-----|-----|
-| Bug just happened in prod, need fix in <1h | `/fix:hotfix` | `/fix:root-cause` (too slow) |
-| Bug keeps coming back after "fixes" | `/fix:root-cause` | `/fix:hotfix` (will repeat) |
-| About to push / open PR | `/review:branch` | `/review:pr` (that's for others') |
-| Reviewing teammate's PR | `/review:pr` | `/review:branch` (that's for own branch) |
-| Want to verify DDD compliance only | `/review:architect` | `/review:pr` (broader scope) |
-| Don't know the right solution yet | `/research:web` | `/research:spike` (skip if you can decide from docs) |
-| Need to validate an idea by building | `/research:spike` | `/feature:new` (commit only after spike) |
-| Writing README / API docs by hand | `/docs:write` | `/docs:sync` (overkill for single file) |
-| Generating full docs site from codebase | `/docs:sync` | `/docs:write` (manual is slower) |
+| Bug just happened in prod, need fix in <1h | `/fix-hotfix` | `/fix-root-cause` (too slow) |
+| Bug keeps coming back after "fixes" | `/fix-root-cause` | `/fix-hotfix` (will repeat) |
+| About to push / open PR | `/review-branch` | `/review-pr` (that's for others') |
+| Reviewing teammate's PR | `/review-pr` | `/review-branch` (that's for own branch) |
+| Want to verify DDD compliance only | `/review-architect` | `/review-pr` (broader scope) |
+| Don't know the right solution yet | `/research-web` | `/research-spike` (skip if you can decide from docs) |
+| Need to validate an idea by building | `/research-spike` | `/feature-new` (commit only after spike) |
+| Writing README / API docs by hand | `/docs-write` | `/docs-sync` (overkill for single file) |
+| Generating full docs site from codebase | `/docs-sync` | `/docs-write` (manual is slower) |
 
 ### Backward compatibility
 
-Old trigger phrases still work — they're kept in the skill `description` so Claude auto-invokes the right skill when the user says e.g. "deep debug", "hotfix", "review changes". The namespace `/group:action` is the new explicit invocation form.
+Old trigger phrases still work — they're kept in the skill `description` so Claude auto-invokes the right skill when the user says e.g. "deep debug", "hotfix", "review changes". The flattened name `/group-action` is the explicit invocation form.
 
 ## Architecture-First Approach
 

package/assets/commands/marketing.md

@@ -30,13 +30,13 @@ Let the user choose which areas to focus on:
 Which marketing areas do you want to plan?
 
 1. Logo & Brand Identity     — Design logo, colors, typography, brand guidelines
-                               Triggers skill: /marketing:logo
+                               Triggers skill: /marketing-logo
 
 2. Video Content Strategy    — Plan video series, scripts, production, publishing
-                               Triggers skill: /marketing:video
+                               Triggers skill: /marketing-video
 
 3. Content Writing Strategy  — Blog posts, social media, SEO, newsletter
-                               Triggers skill: /marketing:content
+                               Triggers skill: /marketing-content
 
 4. All of the Above          — Complete marketing plan (Recommended)
 
@@ -55,19 +55,19 @@ MARKETING PLAN WORKFLOW
 
 Phase 1: Brand Foundation
 │
-├── Execute: /marketing:logo skill
+├── Execute: /marketing-logo skill
 │   └── Output: Brand guidelines, color palette, typography
 │
 ▼
 Phase 2: Content Strategy
 │
-├── Execute: /marketing:content skill
+├── Execute: /marketing-content skill
 │   └── Output: Content pillars, blog plan, social media plan, newsletter
 │
 ▼
 Phase 3: Video Content
 │
-├── Execute: /marketing:video skill
+├── Execute: /marketing-video skill
 │   └── Output: Video series, scripts, production specs, calendar
 │
 ▼
@@ -85,7 +85,7 @@ Phase 5: Launch Plan
 
 ### Execution Notes:
 - Run skills sequentially — brand identity informs content and video decisions
-- Pass brand guidelines (colors, voice, tone) from /marketing:logo into /marketing:content and /marketing:video
+- Pass brand guidelines (colors, voice, tone) from /marketing-logo into /marketing-content and /marketing-video
 - Ensure consistency across all outputs
 
 ## Step 4: Create Unified Calendar

package/assets/skills/docs/sync/SKILL.md

@@ -12,9 +12,9 @@ Generate a complete `docs/` site (business overview, architecture, use cases wit
 - ✅ Re-generate the whole `docs/` site from current code
 - ✅ Existing docs have drifted; want batch sync with review loop
 - ✅ Project has no structured docs at all
-- ❌ Authoring a single doc by hand (README / API.md only) → use `/docs:write`
-- ❌ Understand the codebase, not document it → use `/research:onboarding`
-- ❌ Adding doc for one endpoint → use `/feature:api` Phase 4
+- ❌ Authoring a single doc by hand (README / API.md only) → use `/docs-write`
+- ❌ Understand the codebase, not document it → use `/research-onboarding`
+- ❌ Adding doc for one endpoint → use `/feature-api` Phase 4
 
 ## Read Architecture First
 
@@ -229,10 +229,10 @@ For each iteration:
 
 | When | Use |
 |------|-----|
-| Author single doc by hand | `/docs:write` |
-| Onboard self / new dev | `/research:onboarding` |
-| Doc only one new endpoint | `/feature:api` Phase 4 |
-| Architecture itself needs review | `/review:architect` |
+| Author single doc by hand | `/docs-write` |
+| Onboard self / new dev | `/research-onboarding` |
+| Doc only one new endpoint | `/feature-api` Phase 4 |
+| Architecture itself needs review | `/review-architect` |
 
 ## Recommended Agents
 

package/assets/skills/docs/write/SKILL.md

@@ -5,15 +5,15 @@ description: Documentation workflow for authoring project documentation manually
 
 # Documentation Workflow
 
-Hand-author project docs (README, API.md, ARCHITECTURE.md, CONTRIBUTING.md) with full control over voice and structure. For automated batch generation of a whole `docs/` tree with a review loop, use `/docs:sync` instead.
+Hand-author project docs (README, API.md, ARCHITECTURE.md, CONTRIBUTING.md) with full control over voice and structure. For automated batch generation of a whole `docs/` tree with a review loop, use `/docs-sync` instead.
 
 ## When to use this skill
 
 - ✅ Authoring or updating a specific document
 - ✅ Need opinionated prose, not just structure
 - ✅ Doc is small / scoped — a single file or section
-- ❌ Want automated multi-doc generation → use `/docs:sync`
-- ❌ Just need API reference from OpenAPI → use `/feature:api` Phase 4
+- ❌ Want automated multi-doc generation → use `/docs-sync`
+- ❌ Just need API reference from OpenAPI → use `/feature-api` Phase 4
 
 ## Read Architecture First
 
@@ -108,7 +108,7 @@ For each doc define:
 
 ### Minimal skeletons
 
-Use these as starting points. For full templates, see `/docs:sync` (which generates the full set).
+Use these as starting points. For full templates, see `/docs-sync` (which generates the full set).
 
 **README.md** (≤80 lines for most projects)
 ```markdown
@@ -258,10 +258,10 @@ If any issue → return to Phase 3 for that doc, fix, re-review.
 
 | When | Use |
 |------|-----|
-| Generate full doc site from codebase | `/docs:sync` |
-| Document a newly added API endpoint | `/feature:api` Phase 4 |
-| Onboard self / new dev | `/research:onboarding` |
-| Write blog / social content | `/marketing:content` |
+| Generate full doc site from codebase | `/docs-sync` |
+| Document a newly added API endpoint | `/feature-api` Phase 4 |
+| Onboard self / new dev | `/research-onboarding` |
+| Write blog / social content | `/marketing-content` |
 
 ## Recommended Agents
 

package/assets/skills/feature/api/SKILL.md

@@ -13,8 +13,8 @@ End-to-end workflow for designing, implementing, testing, and documenting APIs
 - ✅ Integrating a third-party API (Stripe, OpenAI, etc.) into the system
 - ✅ Replacing or upgrading an existing API integration
 - ❌ Just need a one-off HTTP call in a script → use Bash directly
-- ❌ Need to research which API to use → use `/research:web` first
-- ❌ Building a whole new domain → use `/feature:new` (which calls this skill internally for the API surface)
+- ❌ Need to research which API to use → use `/research-web` first
+- ❌ Building a whole new domain → use `/feature-new` (which calls this skill internally for the API surface)
 
 ---
 
@@ -160,7 +160,7 @@ GET /resource?cursor=<opaque>&limit=<int 1..100, default 20>
 
 ### What to update
 1. **OpenAPI spec** committed to repo (`openapi.yaml` or per-resource files)
-2. **API.md** — append the new endpoint(s) (or refer to `/docs:write` skill for full re-author)
+2. **API.md** — append the new endpoint(s) (or refer to `/docs-write` skill for full re-author)
 3. **CHANGELOG.md** — note breaking / additive changes
 4. **README.md** — if this changes quick-start
 
@@ -201,11 +201,11 @@ Create a resource. Idempotent via `Idempotency-Key` header.
 
 ## Phase 5: REVIEW LOOP
 
-Run `/review:architect` for the touched domain. Loop until score ≥ B.
+Run `/review-architect` for the touched domain. Loop until score ≥ B.
 
 ```
 LOOP:
-  1. Run /review:architect {stack} {domain}
+  1. Run /review-architect {stack} {domain}
   2. Fix violations
   3. Re-run tests + build
   4. GOTO 1 (until score ≥ B)
@@ -257,10 +257,10 @@ LOOP:
 | When | Use |
 |------|-----|
 | Designing the API contract from scratch | `@api-designer` agent |
-| Adding the endpoint as part of a larger feature | `/feature:new` (calls this internally) |
-| Writing tests for the endpoint | `/review:tdd` |
-| Documenting the full API surface | `/docs:write` |
-| Reviewing architecture compliance | `/review:architect` |
+| Adding the endpoint as part of a larger feature | `/feature-new` (calls this internally) |
+| Writing tests for the endpoint | `/review-tdd` |
+| Documenting the full API surface | `/docs-write` |
+| Reviewing architecture compliance | `/review-architect` |
 
 ---
 

package/assets/skills/feature/deprecate/SKILL.md

@@ -255,10 +255,10 @@ class OldWidget { ... }
 
 | When | Use |
 |------|-----|
-| Adding the replacement first | `/feature:new` |
+| Adding the replacement first | `/feature-new` |
 | Restructuring the code that uses the deprecated thing | `refactor` |
-| Documenting the migration guide | `/docs:write` |
-| Reviewing the removal PR | `/review:pr` |
+| Documenting the migration guide | `/docs-write` |
+| Reviewing the removal PR | `/review-pr` |
 
 ---
 

package/assets/skills/feature/new/SKILL.md

@@ -15,9 +15,9 @@ Build a new feature following DDD layers with rule checks per phase and a final
 - ✅ Feature spans multiple DDD layers (domain + app + infra)
 - ✅ The approach is well-understood (no major research / prototype needed)
 - ✅ You want automated architecture review at the end
-- ❌ Quick bug fix → use `/fix:hotfix`
-- ❌ Don't know the right approach yet → `/research:web` or `/research:spike` first
-- ❌ Restructuring existing code → use `/feature:refactor`
+- ❌ Quick bug fix → use `/fix-hotfix`
+- ❌ Don't know the right approach yet → `/research-web` or `/research-spike` first
+- ❌ Restructuring existing code → use `/feature-refactor`
 
 ## Read Architecture First
 
@@ -205,7 +205,7 @@ Build in order: **value objects → entities → events → ports → usecases**
 
 ```
 LOOP:
-  1. /review:architect {stack} {domain}
+  1. /review-architect {stack} {domain}
   2. IF violations severity ≥ MEDIUM:
        fix all → build → tests → GOTO 1
   3. IF score ≥ B → BREAK
@@ -253,12 +253,12 @@ LOOP:
 
 | When | Use |
 |------|-----|
-| Don't know approach yet | `/research:web` → then this skill |
-| Want to validate by prototyping | `/research:spike` → then this skill |
-| Adding only an endpoint | `/feature:api` |
-| Restructuring existing module | `/feature:refactor` |
-| Architecture check (called automatically in Phase 7) | `/review:architect` |
-| Write tests inline (TDD style) | `/review:tdd` |
+| Don't know approach yet | `/research-web` → then this skill |
+| Want to validate by prototyping | `/research-spike` → then this skill |
+| Adding only an endpoint | `/feature-api` |
+| Restructuring existing module | `/feature-refactor` |
+| Architecture check (called automatically in Phase 7) | `/review-architect` |
+| Write tests inline (TDD style) | `/review-tdd` |
 
 ## Recommended Agents
 

package/assets/skills/feature/refactor/SKILL.md

@@ -15,9 +15,9 @@ Restructure existing code into DDD layers, or fix drift in an existing DDD modul
 - ✅ Migrating a legacy module into DDD layers
 - ✅ Existing DDD module has drifted (fat controller, anemic entity, mixed concerns)
 - ✅ Splitting one domain into multiple bounded contexts
-- ❌ Building a brand-new feature → use `/feature:new`
+- ❌ Building a brand-new feature → use `/feature-new`
 - ❌ Just renaming files / variables → just do it
-- ❌ Fixing a bug → use `/fix:hotfix` or `/fix:root-cause`
+- ❌ Fixing a bug → use `/fix-hotfix` or `/fix-root-cause`
 
 ## Read Architecture First
 
@@ -196,11 +196,11 @@ grep -r "{old_import_path}" --include="*.{ext}" . && echo "FAIL: stale imports"
 
 ## Review Loop
 
-After Phase 6, call `/review:architect {stack} {domain}`. Loop until score ≥ B.
+After Phase 6, call `/review-architect {stack} {domain}`. Loop until score ≥ B.
 
 ```
 LOOP:
-  1. /review:architect {stack} {domain}
+  1. /review-architect {stack} {domain}
   2. IF violations severity ≥ MEDIUM:
        fix all → full build → all tests → GOTO 1
   3. IF score ≥ B → BREAK
@@ -252,10 +252,10 @@ LOOP:
 
 | When | Use |
 |------|-----|
-| Building from scratch (no existing code) | `/feature:new` |
-| Just adding tests to untested code | `/review:tdd` |
-| Reviewing the refactor before merging | `/review:branch` |
-| Final architecture check (called automatically in review loop) | `/review:architect` |
+| Building from scratch (no existing code) | `/feature-new` |
+| Just adding tests to untested code | `/review-tdd` |
+| Reviewing the refactor before merging | `/review-branch` |
+| Final architecture check (called automatically in review loop) | `/review-architect` |
 
 ## Recommended Agents
 

package/assets/skills/fix/hotfix/SKILL.md

@@ -12,9 +12,9 @@ Fast-track bug fix with a rollback plan. Use when the cause is identifiable in u
 - ✅ Bug is reproducible and root cause is clear (or quickly identifiable)
 - ✅ Need a fix shipped fast with a rollback plan
 - ✅ Severity ranges from low (minor UI) to high (feature broken)
-- ❌ Production is down right now → use `/fix:incident` first
-- ❌ Bug has been "fixed" multiple times and keeps returning → use `/fix:root-cause`
-- ❌ Building a new feature → use `/feature:new`
+- ❌ Production is down right now → use `/fix-incident` first
+- ❌ Bug has been "fixed" multiple times and keeps returning → use `/fix-root-cause`
+- ❌ Building a new feature → use `/feature-new`
 
 ## Read Architecture First
 
@@ -22,7 +22,7 @@ Read `ddd-architecture.md` + stack-specific doc — the fix must land in the rig
 
 ## Severity
 
-Use `~/.claude/architecture/_shared/severity-levels.md` (incident table). Hotfix typically covers P2-P4. P1 → start with `/fix:incident` for triage / comms.
+Use `~/.claude/architecture/_shared/severity-levels.md` (incident table). Hotfix typically covers P2-P4. P1 → start with `/fix-incident` for triage / comms.
 
 ---
 
@@ -61,7 +61,7 @@ IDENTIFY → REPRODUCE → FIX → VERIFY → DEPLOY
 - [ ] Error captured verbatim
 - [ ] Reproduction steps known (or "intermittent" noted)
 - [ ] Severity assigned (P2 / P3 / P4)
-- [ ] Root cause identified (use `/fix:root-cause` if 5 Whys doesn't converge)
+- [ ] Root cause identified (use `/fix-root-cause` if 5 Whys doesn't converge)
 
 ---
 
@@ -91,7 +91,7 @@ IDENTIFY → REPRODUCE → FIX → VERIFY → DEPLOY
 ### Rules
 - Fix at the **root cause**, not the symptom
 - Land the fix in the right layer (boundary validation → handler/DTO; business rule → usecase; data shape → infra mapper)
-- **Add a regression test first** (RED), then make it pass (GREEN). See `/review:tdd`.
+- **Add a regression test first** (RED), then make it pass (GREEN). See `/review-tdd`.
 - Don't refactor on the fix — separate PR
 - If the fix requires schema migration, plan it as 2 deploys (compatible code first, then migration)
 
@@ -131,7 +131,7 @@ For data-shape bugs (null where not expected, type mismatch from external API):
 ## Phase 5: DEPLOY
 
 ### Pre-deploy checklist
-- [ ] PR reviewed (`/review:branch` self + `/review:pr` from teammate)
+- [ ] PR reviewed (`/review-branch` self + `/review-pr` from teammate)
 - [ ] Rollback plan documented (see below)
 - [ ] On-call notified
 - [ ] CHANGELOG entry
@@ -215,11 +215,11 @@ Document **before** deploying:
 
 | When | Use |
 |------|-----|
-| Production is down right now | `/fix:incident` first, then hotfix |
-| Bug keeps coming back after fixes | `/fix:root-cause` |
-| Need to write regression test first | `/review:tdd` |
-| Bug is on an open PR | `/fix:pr-comment` |
-| Self-review before opening PR | `/review:branch` |
+| Production is down right now | `/fix-incident` first, then hotfix |
+| Bug keeps coming back after fixes | `/fix-root-cause` |
+| Need to write regression test first | `/review-tdd` |
+| Bug is on an open PR | `/fix-pr-comment` |
+| Self-review before opening PR | `/review-branch` |
 
 ## Recommended Agents
 

package/assets/skills/fix/incident/SKILL.md

@@ -12,8 +12,8 @@ Structured workflow for handling production incidents from triage to postmortem.
 - ✅ Production is down or degraded right now
 - ✅ Users are impacted, on-call has been paged
 - ✅ Need to coordinate response, mitigation, comms, and postmortem
-- ❌ Bug is reported but no users impacted → use `/fix:hotfix`
-- ❌ Already mitigated, need to find root cause → use `/fix:root-cause`
+- ❌ Bug is reported but no users impacted → use `/fix-hotfix`
+- ❌ Already mitigated, need to find root cause → use `/fix-root-cause`
 - ❌ Postmortem only, no active incident → jump to Phase 5
 
 ---
@@ -205,7 +205,7 @@ Live walkthrough (5-10 min): outgoing IC walks incoming IC through the timeline
 **Goal:** apply the permanent fix and verify.
 
 ### Actions
-1. Confirm root cause (use `/fix:root-cause` workflow if not obvious)
+1. Confirm root cause (use `/fix-root-cause` workflow if not obvious)
 2. Implement permanent fix following stack architecture
 3. Add test that would have caught this
 4. Deploy fix through normal pipeline (don't skip CI even under pressure — unless explicitly authorized)
@@ -340,10 +340,10 @@ Postmortem: {date} — link to come
 
 | When | Use |
 |------|-----|
-| Bug reported but no active incident | `/fix:hotfix` |
-| Root cause unclear, need deep investigation | `/fix:root-cause` |
+| Bug reported but no active incident | `/fix-hotfix` |
+| Root cause unclear, need deep investigation | `/fix-root-cause` |
 | Need to roll back deployment | (use ops runbook, not a skill) |
-| Documenting postmortem as a doc | `/docs:write` |
+| Documenting postmortem as a doc | `/docs-write` |
 
 ---
 

package/assets/skills/fix/pr-comment/SKILL.md

@@ -15,9 +15,9 @@ Fetch all review comments on an open PR, address each, push, and respond back to
 - ✅ Reviewer left comments and you need to address each one
 - ✅ Want to track which comments are resolved vs still open
 - ✅ Need structured responses posted back to GitHub
-- ❌ You are the reviewer → use `/review:pr`
-- ❌ No PR yet → use `/review:branch`
-- ❌ Fix is a brand-new bug surfaced by reviewer → `/fix:hotfix` first, then this skill
+- ❌ You are the reviewer → use `/review-pr`
+- ❌ No PR yet → use `/review-branch`
+- ❌ Fix is a brand-new bug surfaced by reviewer → `/fix-hotfix` first, then this skill
 
 ---
 
@@ -86,15 +86,15 @@ Build a triage table:
 - Fix in order: must-fix → should-fix → discussion outcomes
 - One concern per commit (`fix(handler): validate input in DTO per #pr-comment-1`)
 - After each batch: run build + lint + tests locally
-- Re-run `/review:branch` before pushing
+- Re-run `/review-branch` before pushing
 
 ### When the fix changes architecture
-If a comment requests something structural (move logic between layers, add a port), use `/feature:refactor` for that subtree, then come back here to respond.
+If a comment requests something structural (move logic between layers, add a port), use `/feature-refactor` for that subtree, then come back here to respond.
 
 ### Gate
 - [ ] All must-fix items addressed
 - [ ] Build + lint + tests green
-- [ ] Self-review with `/review:branch` clean
+- [ ] Self-review with `/review-branch` clean
 
 ---
 
@@ -162,7 +162,7 @@ gh pr edit $PR --add-reviewer {original_reviewer}
 - **Reply to every comment** — silence reads as ignoring
 - **Push back politely** when you have a real reason; never just close threads
 - **One concern per commit** — easier for reviewer to verify
-- **Run `/review:branch` before pushing** — catch easy issues before reviewer round 2
+- **Run `/review-branch` before pushing** — catch easy issues before reviewer round 2
 - **Don't argue style** when the team has a linter — let the tool decide
 
 ---
@@ -171,10 +171,10 @@ gh pr edit $PR --add-reviewer {original_reviewer}
 
 | When | Use |
 |------|-----|
-| You are the reviewer | `/review:pr` |
-| Self-review before pushing again | `/review:branch` |
-| Reviewer asked for architectural refactor | `/feature:refactor` |
-| Reviewer surfaced a bug needing investigation | `/fix:root-cause` |
+| You are the reviewer | `/review-pr` |
+| Self-review before pushing again | `/review-branch` |
+| Reviewer asked for architectural refactor | `/feature-refactor` |
+| Reviewer surfaced a bug needing investigation | `/fix-root-cause` |
 
 ## Recommended Agents
 

package/assets/skills/fix/root-cause/SKILL.md

@@ -14,8 +14,8 @@ For bugs that have been "fixed" multiple times and keep coming back, intermitten
 - ✅ Error inside vendor / framework internals
 - ✅ Local vs production behavior differs
 - ✅ Race condition / concurrency suspected
-- ❌ Bug is well understood, just needs a fix → `/fix:hotfix`
-- ❌ Production is down with user impact → `/fix:incident` first, then this skill
+- ❌ Bug is well understood, just needs a fix → `/fix-hotfix`
+- ❌ Production is down with user impact → `/fix-incident` first, then this skill
 
 ---
 
@@ -259,10 +259,10 @@ For data-shape bugs from external sources: validate / coerce at the adapter, not
 
 | When | Use |
 |------|-----|
-| Bug is understood, just needs a fix | `/fix:hotfix` |
-| Production is down | `/fix:incident` (then this skill after mitigation) |
-| Write regression test after fix | `/review:tdd` |
-| Research how others solved similar bugs | `/research:web` |
+| Bug is understood, just needs a fix | `/fix-hotfix` |
+| Production is down | `/fix-incident` (then this skill after mitigation) |
+| Write regression test after fix | `/review-tdd` |
+| Research how others solved similar bugs | `/research-web` |
 
 ## Recommended Agents
 

package/assets/skills/marketing/content/SKILL.md

@@ -12,9 +12,9 @@ Workflow for creating content strategy: audience research, content pillars, SEO
 - ✅ Building a content strategy from scratch (pillars, calendar, channels)
 - ✅ Writing one specific piece (blog post, newsletter, social thread)
 - ✅ Repurposing one piece into multi-channel content
-- ❌ Writing API / project documentation → use `/docs:write` or `/docs:sync`
+- ❌ Writing API / project documentation → use `/docs-write` or `/docs-sync`
 - ❌ Writing release notes / changelog → use git history + manual
-- ❌ Designing a video → use `/marketing:video`
+- ❌ Designing a video → use `/marketing-video`
 
 ---
 
@@ -251,10 +251,10 @@ SIGNATURE
 
 | When | Use |
 |------|-----|
-| Building brand identity (logo + colors) | `/marketing:logo` |
-| Creating video scripts / storyboards | `/marketing:video` |
+| Building brand identity (logo + colors) | `/marketing-logo` |
+| Creating video scripts / storyboards | `/marketing-video` |
 | Building a full marketing plan | `/marketing` (combines all three) |
-| Writing project documentation | `/docs:write` |
+| Writing project documentation | `/docs-write` |
 
 ---