moicle 2.2.3 → 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 |

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` |
 
 ---
 

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

@@ -14,7 +14,7 @@ Produce a logo + brand identity **specification** that a designer can execute (o
 - ✅ Need a deliverable spec for a designer to execute
 - ❌ Just need a quick icon variation → use a design tool directly
 - ❌ Full marketing plan (logo + content + video) → use `/marketing`
-- ❌ Video-specific visuals → use `/marketing:video`
+- ❌ Video-specific visuals → use `/marketing-video`
 
 ---
 
@@ -238,9 +238,9 @@ Pick 1 display + 1 body font (or 1 font in 2 weights). Note:
 | When | Use |
 |------|-----|
 | Full marketing plan (logo + content + video) | `/marketing` |
-| Write content with the brand | `/marketing:content` |
-| Create video with the brand | `/marketing:video` |
-| Document brand guidelines as a doc | `/docs:write` |
+| Write content with the brand | `/marketing-content` |
+| Create video with the brand | `/marketing-video` |
+| Document brand guidelines as a doc | `/docs-write` |
 
 ## Recommended Agents
 

package/assets/skills/marketing/seo-blog/SKILL.md

@@ -12,7 +12,7 @@ Write **one** evergreen blog post that ranks on traditional search AND is easy f
 - ✅ Writing a single evergreen blog post (entity / trust / compare / glossary / use-case / FAQ)
 - ✅ Updating an existing evergreen post that has drifted
 - ✅ Replacing a thin / outdated post with a stronger version on the same intent
-- ❌ Multi-post content plan / calendar / strategy → use `/marketing:content`
+- ❌ Multi-post content plan / calendar / strategy → use `/marketing-content`
 - ❌ Changelog / feature launch / release announcement → write manually or use a feature-blog template
 - ❌ Time-sensitive news / event post → not evergreen, different rules
 
@@ -350,11 +350,11 @@ head -30 {blog_dir}/{slug}.md
 
 | When | Use |
 |------|-----|
-| Multi-post content plan / calendar / strategy | `/marketing:content` |
-| Brand voice / visual identity setup first | `/marketing:logo` |
-| Video / shorts version of the post | `/marketing:video` |
+| Multi-post content plan / calendar / strategy | `/marketing-content` |
+| Brand voice / visual identity setup first | `/marketing-logo` |
+| Video / shorts version of the post | `/marketing-video` |
 | Full go-to-market plan (logo + content + video) | `/marketing` command |
-| Writing technical project docs (not blog) | `/docs:write` |
+| Writing technical project docs (not blog) | `/docs-write` |
 
 ## Recommended Agents
 

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

@@ -14,7 +14,7 @@ Plan video content end-to-end: strategy, script, storyboard, production spec, pu
 - ✅ Repurposing existing long-form into shorts / clips
 - ❌ Just need ideas, not a plan → use `brainstorm`
 - ❌ Want full marketing plan (logo + content + video) → use `/marketing`
-- ❌ Writing a blog post or thread → use `/marketing:content`
+- ❌ Writing a blog post or thread → use `/marketing-content`
 
 ---
 
@@ -241,8 +241,8 @@ CTA (≤10 sec)
 | When | Use |
 |------|-----|
 | Full marketing plan (logo + content + video) | `/marketing` |
-| Need brand visuals first | `/marketing:logo` |
-| Repurpose video → blog / threads | `/marketing:content` |
+| Need brand visuals first | `/marketing-logo` |
+| Repurpose video → blog / threads | `/marketing-content` |
 | Brainstorm video topics | `brainstorm` |
 
 ---

package/assets/skills/research/onboarding/SKILL.md

@@ -12,8 +12,8 @@ Ramp up on a new codebase quickly: structure, conventions, where things live, ho
 - ✅ Just joined a project / repo and need to ramp up
 - ✅ Returning to a codebase you haven't touched in months
 - ✅ Need to give a teammate a structured walkthrough
-- ❌ Want to generate full docs site → use `/docs:sync`
-- ❌ Need to fix a specific bug → use `/fix:hotfix` / `/fix:root-cause`
+- ❌ Want to generate full docs site → use `/docs-sync`
+- ❌ Need to fix a specific bug → use `/fix-hotfix` / `/fix-root-cause`
 - ❌ Only want a quick file lookup → just use `grep` / `find`
 
 ## Read Architecture First
@@ -158,7 +158,7 @@ git shortlog -sn --since=3months | head -10
 - [ ] Followed naming + error-handling conventions
 - [ ] Commit message matches project style (`git log --oneline`)
 - [ ] PR description follows template (check `.github/PULL_REQUEST_TEMPLATE.md`)
-- [ ] Self-reviewed with `/review:branch` before opening PR
+- [ ] Self-reviewed with `/review-branch` before opening PR
 
 ### Who to ask
 - Architecture / "why is it like this": {tech lead from git shortlog}
@@ -208,10 +208,10 @@ git shortlog -sn --since=3months | head -10
 
 | When | Use |
 |------|-----|
-| Generate full doc site after onboarding | `/docs:sync` |
-| Build first real feature after onboarding | `/feature:new` |
-| First bug fix to learn the codebase | `/fix:hotfix` |
-| Author / update the onboarding doc itself | `/docs:write` |
+| Generate full doc site after onboarding | `/docs-sync` |
+| Build first real feature after onboarding | `/feature-new` |
+| First bug fix to learn the codebase | `/fix-hotfix` |
+| Author / update the onboarding doc itself | `/docs-write` |
 
 ## Recommended Agents