moicle 2.2.3 → 2.3.1

package/README.md

@@ -16,7 +16,7 @@ A toolkit to bootstrap and accelerate project development with Claude Code throu
 
 - **16 AI Agents** - 6 developer agents + 10 utility agents
 - **4 Commands** - Wizards for bootstrap, brainstorm, documentation, and marketing
-- **21 Skills** - Auto-triggered workflows for the full SDLC (feature, bug, review, release, ops, content)
+- **22 Skills** - Auto-triggered workflows for the full SDLC (feature, bug, review, release, ops, content)
 - **9 Architecture References** - DDD + Hexagonal + stack-specific patterns
 
 
@@ -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 |
@@ -116,7 +124,7 @@ moicle install --target antigravity --global
 | `/brainstorm` | Brainstorm ideas with 6 frameworks |
 | `/doc` | Scan project and generate documentation |
 
-### Skills (21)
+### Skills (22)
 
 Skills are grouped by a `<group>-` prefix. Type `/<group>-` then `Tab` in Claude Code to see all skills in a group.
 
@@ -128,6 +136,7 @@ Skills are grouped by a `<group>-` prefix. Type `/<group>-` then `Tab` in Claude
 | `/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-track` | Plan + approve, then run a tracked loop: branch → checklist → per-item test/implement/verify/commit |
 
 **`/fix-*` — Bugs & Incidents**
 
@@ -184,6 +193,7 @@ When more than one skill could fit, use this matrix:
 | 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) |
+| Driving a multi-step task as a checklist with commit-per-step | `/feature-track` | `/feature-new` (single full DDD feature), `/review-tdd` (one unit, no branch/commit) |
 | 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) |
 

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/feature/track/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: feature-track
+description: Tracked development loop — first brainstorm + plan and get user approval, THEN checkout a branch, build a task checklist, and loop each item through test → implement → verify → fix → mark done → commit (one commit per item). Use when user says "bắt đầu loop", "làm track này", "tracked loop", "checklist driven dev", "run the loop", "checkout branch and start track", "brainstorm rồi làm track", "implement with checklist and commit per task".
+args: "[TASK_DESCRIPTION]"
+---
+
+# Tracked Development Loop
+
+Run a multi-step task as a controlled loop: **brainstorm + plan first, get approval, THEN** checkout a branch, turn the plan into a task checklist, and drive each item through test → implement → verify → fix → mark done → commit — **one commit per item**.
+
+**ARGUMENTS:** `<task description>` — e.g., `wallet savings account`, `add rate limiting to auth`, `migrate orders module to events`
+
+## When to use this skill
+
+- ✅ A task that splits into several verifiable steps you want to drive as a checklist
+- ✅ You want a clean history — one commit per completed step, easy to revert
+- ✅ You want test-first discipline on each step, on a dedicated branch
+- ❌ One-line / obvious change → just do it
+- ❌ Urgent production bug → use `/fix-hotfix`
+- ❌ Single full DDD feature across all layers → use `/feature-new`
+- ❌ Driving ONE unit test-first with no branch/checklist → use `/review-tdd`
+
+## Read Architecture First
+
+Detect stack via `~/.claude/architecture/_shared/stack-detection.md`. The stack doc tells you:
+- Test command + test file location convention
+- Build + lint commands (for the VERIFY step)
+- Mocking pattern for ports / dependencies
+
+---
+
+## Workflow
+
+```
+0 BRAINSTORM & PLAN ─▶ [USER APPROVES] ─▶ 1 SETUP ─▶ ┌─ 2 LOOP per item ──────────────────────┐ ─▶ 3 REPORT
+(understand, /brainstorm,(last step of      (branch +  │ TEST → IMPLEMENT → VERIFY → FIX →       │
+ plan + draft checklist)  planning)          checklist) │ MARK DONE → COMMIT                      │
+                                                        │      └ fail ─▶ FIX ─▶ VERIFY (to pass) │
+                                                        └─────────── next pending item ──────────┘
+```
+
+> Core rule: **brainstorm and plan, the LAST planning step is user approval, THEN start the loop.** Never jump straight to branch/checklist.
+
+---
+
+## Phase 0: BRAINSTORM & PLAN
+
+**Goal:** understand the task, pick the simplest viable approach, draft the checklist — and get the user to approve before touching anything.
+
+### Steps
+1. **Detect stack** — load the matching architecture doc for test/build/lint commands and conventions.
+2. **Understand the task** — read the relevant code/context. If `[TASK_DESCRIPTION]` is ambiguous (scope, acceptance criteria, edge cases), ask to clarify (AskUserQuestion). Don't assume.
+3. **Brainstorm the approach — invoke `/brainstorm`** to generate and compare options for the task (First Principles, SCAMPER, Working Backwards, 5 Whys…), then pick the simplest that works. For a trivial/obvious task a quick single-framework pass is enough — don't overengineer, but don't skip the step.
+4. **Draft the plan** — settle:
+   - the chosen approach,
+   - a proposed branch name (`feat/<slug>`),
+   - the **draft checklist** — each item = one verifiable unit = one test passing + one commit,
+   - files affected + how each item is tested.
+5. **Present the plan and WAIT for approval.** This is the last step of planning. No branch, no code, no `TaskCreate` yet.
+
+### Gate
+- [ ] Stack detected
+- [ ] Requirements clear (clarified if they weren't)
+- [ ] Approach brainstormed via `/brainstorm` (simplest viable picked)
+- [ ] Plan + draft checklist presented
+- [ ] **User APPROVED the plan**
+
+---
+
+## Phase 1: SETUP
+
+**Goal:** turn the approved plan into a branch + a live checklist. Runs only AFTER approval.
+
+### Steps
+1. **Checkout a new branch** with the approved name (`feat/<slug>`) off the current base. Never run the loop on `master` / `main`.
+2. **Create the checklist** with `TaskCreate` — one task per checklist item, in order, matching the approved plan.
+
+### Gate
+- [ ] New branch created and checked out
+- [ ] Checklist created via `TaskCreate`, matching the approved plan
+
+---
+
+## Phase 2: LOOP (per item)
+
+Take the next `pending` item from the task list and run it through the full cycle. Repeat until no `pending` items remain.
+
+1. **MARK IN_PROGRESS** — `TaskUpdate` the item → `in_progress`.
+2. **TEST (RED)** — write a unit test describing the item's behavior. Run it and confirm it **fails for the right reason** (code missing / assertion fails), not a typo or import error.
+3. **IMPLEMENT (GREEN)** — write the minimal code to make the test pass. Follow an existing reference module so it matches the codebase style.
+4. **VERIFY** — actually run it: the item's test + build + lint (commands per stack). Never claim pass without running.
+5. **FIX** — if anything fails, fix at the **root, never swallow the error** (handle exceptions explicitly — no empty catch). Then go back to VERIFY until green.
+6. **MARK DONE** — `TaskUpdate` the item → `completed`.
+7. **COMMIT** — commit just this item with a conventional message (`feat:` / `fix:` / `test:` / `refactor:` …). Commit only — **do not push automatically**.
+
+### Gate (per item, before moving on)
+- [ ] Test green
+- [ ] Build + lint green
+- [ ] Task marked `completed`
+- [ ] Item committed (one commit)
+
+---
+
+## Phase 3: Final Report
+
+```markdown
+## Track Complete: {task}
+
+Branch: `feat/{slug}`
+
+| # | Item | Test(s) | Commit | Status |
+|---|------|---------|--------|--------|
+| 1 | {item} | {test name} | {hash} `feat: …` | ✅ |
+| 2 | {item} | {test name} | {hash} `feat: …` | ✅ |
+
+### Totals
+- Items: {N} done / {N}
+- Commits: {N}
+- Tests added: {N}, all green
+
+### Next
+- Push + open PR, or run `/review-branch` first
+```
+
+---
+
+## Hard Rules
+
+- **Plan + user approval FIRST** — no branch, no code until the plan is approved.
+- **Branch first** — never run the loop on `master` / `main`.
+- **RED before GREEN** — no production code that a failing test didn't drive.
+- **Verify by running real commands** — never assert pass from inspection alone.
+- **Never swallow errors** in FIX — handle exceptions explicitly, fix the root cause.
+- **One commit per item** — don't squash steps together, don't push automatically.
+- **DB operations (migrate / seed / drop)** inside any item: **CONFIRM with the user before running — every time, even if a previous item was already confirmed.**
+- **Simple first** — don't overengineer an item.
+
+---
+
+## Related Skills
+
+| When | Use |
+|------|-----|
+| Need idea frameworks for Phase 0 | `/brainstorm` |
+| Drive ONE unit deeper test-first | `/review-tdd` |
+| Full DDD feature across all layers | `/feature-new` |
+| Self-review the branch after the loop | `/review-branch` |
+| Urgent prod bug, no checklist | `/fix-hotfix` |
+
+## Recommended Agents
+
+| Phase | Agent | Purpose |
+|-------|-------|---------|
+| BRAINSTORM / PLAN | `@clean-architect` | Approach + decomposition |
+| TEST | `@test-writer` | Failing test per item |
+| IMPLEMENT | Stack-specific dev agent | Minimal implementation |
+| VERIFY / FIX | `@code-reviewer` | Catch issues before commit |

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