moicle 2.3.1 → 3.0.1

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Quyền
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

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
-- **22 Skills** - Auto-triggered workflows for the full SDLC (feature, bug, review, release, ops, content)
+- **10 Skills** - Mode-based, auto-triggered workflows for the full SDLC (feature, bug, review, research, docs, marketing) plus a `/challenge` self-critique nudge
 - **9 Architecture References** - DDD + Hexagonal + stack-specific patterns
 
 
@@ -124,82 +124,76 @@ moicle install --target cursor --project
 | `/brainstorm` | Brainstorm ideas with 6 frameworks |
 | `/doc` | Scan project and generate documentation |
 
-### Skills (22)
+### Skills (10)
 
-Skills are grouped by a `<group>-` prefix. Type `/<group>-` then `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. Each skill bundles several related workflows into **modes** chosen at the top of the file — pick a mode (or let Claude pick it from your natural-language phrasing). One skill — `/challenge` — is intentionally standalone (no group, no modes).
 
 **`/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-track` | Plan + approve, then run a tracked loop: branch → checklist → per-item test/implement/verify/commit |
+| Skill | Modes | When to use |
+|-------|-------|-------------|
+| `/feature-build` | NEW · REFACTOR · API · DEPRECATE | Build a new DDD feature, restructure existing code, add/integrate an API, or safely sunset a feature |
+| `/feature-track` | — | Plan + approve, then run a tracked loop: branch → checklist → per-item test/implement/verify/commit |
 
 **`/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 |
+| Skill | Modes | When to use |
+|-------|-------|-------------|
+| `/fix-bug` | QUICK · DEEP | QUICK: fix fast with rollback plan · DEEP: trace a hard / recurring / intermittent bug |
+| `/fix-incident` | — | Production outage / on-call workflow |
 
 **`/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 |
+| Skill | Modes | When to use |
+|-------|-------|-------------|
+| `/review-code` | SELF · PR · ARCHITECT · TDD · ADDRESS | Self-review a branch, review a teammate's PR, deep DDD audit, test-first development, or address PR comments |
 
 **`/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 |
+| Skill | Modes | When to use |
+|-------|-------|-------------|
+| `/research-explore` | WEB · SPIKE · ONBOARDING | Research solutions via docs, validate by building a prototype, or ramp up on a new codebase |
 
 **`/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 |
+| Skill | Modes | When to use |
+|-------|-------|-------------|
+| `/docs-sync` | SINGLE · FULL | SINGLE: hand-author one doc · FULL: auto-generate the whole docs site with review loop |
 
 **`/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 |
+| Skill | Modes | When to use |
+|-------|-------|-------------|
+| `/marketing-content` | STRATEGY · POST | Multi-post content strategy, or write ONE evergreen post optimized for Search + AI |
+| `/marketing-brand` | LOGO · VIDEO | Logo + brand identity spec, or video script/storyboard/production plan |
+
+**`/challenge` — Self-Critique** (standalone, no group)
+
+| Skill | Modes | When to use |
+|-------|-------|-------------|
+| `/challenge` | — | A quick skeptical re-examination of what you just did (or selected code): simpler? duplicated? optimal? edge cases? — reports honest findings without self-congratulating. Lighter than `/review-code` SELF. |
 
 ### Skill decision matrix
 
-When more than one skill could fit, use this matrix:
+When more than one skill / mode 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) |
-| 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) |
+| Bug just happened in prod, need fix in <1h | `/fix-bug` (QUICK) | `/fix-bug` DEEP (too slow) |
+| Bug keeps coming back after "fixes" | `/fix-bug` (DEEP) | `/fix-bug` QUICK (will repeat) |
+| About to push / open PR | `/review-code` (SELF) | `/review-code` PR (that's for others') |
+| Reviewing teammate's PR | `/review-code` (PR) | `/review-code` SELF (that's for own branch) |
+| Want to verify DDD compliance only | `/review-code` (ARCHITECT) | `/review-code` PR (broader scope) |
+| Don't know the right solution yet | `/research-explore` (WEB) | SPIKE (skip if you can decide from docs) |
+| Need to validate an idea by building | `/research-explore` (SPIKE) | `/feature-build` NEW (commit only after spike) |
+| Driving a multi-step task as a checklist with commit-per-step | `/feature-track` | `/feature-build` NEW (single full DDD feature), `/review-code` TDD (one unit, no branch/commit) |
+| Writing README / API docs by hand | `/docs-sync` (SINGLE) | `/docs-sync` FULL (overkill for single file) |
+| Generating full docs site from codebase | `/docs-sync` (FULL) | `/docs-sync` SINGLE (manual is slower) |
+| Quick "did I overcomplicate this?" gut-check on fresh code | `/challenge` | `/review-code` ARCHITECT (heavier, scored audit) |
 
 ### 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 flattened name `/group-action` is the explicit invocation form.
+The 22 original skills were consolidated into 9 mode-based skills. Old trigger phrases still work — they're kept in each skill's `description` so Claude auto-invokes the right skill **and the right mode** when the user says e.g. "deep debug" (→ `/fix-bug` DEEP), "hotfix" (→ `/fix-bug` QUICK), "review changes" (→ `/review-code` SELF). The flattened name `/group-action` is the explicit invocation form.
 
 ## Architecture-First Approach
 

package/assets/commands/marketing.md

@@ -30,10 +30,10 @@ 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-brand (LOGO mode)
 
 2. Video Content Strategy    — Plan video series, scripts, production, publishing
-                               Triggers skill: /marketing-video
+                               Triggers skill: /marketing-brand (VIDEO mode)
 
 3. Content Writing Strategy  — Blog posts, social media, SEO, newsletter
                                Triggers skill: /marketing-content
@@ -55,19 +55,19 @@ MARKETING PLAN WORKFLOW
 
 Phase 1: Brand Foundation
 │
-├── Execute: /marketing-logo skill
+├── Execute: /marketing-brand (LOGO mode)
 │   └── Output: Brand guidelines, color palette, typography
 │
 ▼
 Phase 2: Content Strategy
 │
-├── Execute: /marketing-content skill
+├── Execute: /marketing-content (STRATEGY mode)
 │   └── Output: Content pillars, blog plan, social media plan, newsletter
 │
 ▼
 Phase 3: Video Content
 │
-├── Execute: /marketing-video skill
+├── Execute: /marketing-brand (VIDEO mode)
 │   └── 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-brand (LOGO) into /marketing-content and /marketing-brand (VIDEO)
 - Ensure consistency across all outputs
 
 ## Step 4: Create Unified Calendar

package/assets/skills/challenge/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: challenge
+description: A fast self-critique nudge — re-examine the thing you just did (or the selected/named code) with a skeptical eye and report what could be better, WITHOUT self-congratulating. Lighter than /review-code SELF; it is a single pass, not a full review process. Use when the user says "challenge", "rethink", "check kĩ hơn", "soi lại", "phản biện", "tối ưu chưa", "is this optimal", "double check this", "any duplication", "có lặp code không", "did I overengineer", "second-guess this", "review what you just did".
+---
+
+# Challenge — Self-Critique Pass
+
+A short, honest re-examination of the work in scope. The whole point is to **push back on your own output** instead of accepting it. You are the skeptic reviewing your own code, not the author defending it.
+
+## What's in scope
+
+Pick the target in this order:
+
+1. **Selected / named code** — if the user selected lines or named a file/function/change, critique exactly that.
+2. **The change you just made** — otherwise, critique the code you produced or edited most recently in this session (check the working diff if unsure).
+
+If neither is clear, ask one line: "Soi cái gì — thay đổi vừa rồi hay chỗ nào cụ thể?" — then proceed.
+
+## The one rule
+
+> **Do not conclude "it's fine / already optimal" without evidence.** Assume something can be better and go find it. If after a genuine pass nothing real turns up, say so plainly and state what you checked — do not pad with fake concerns, and do not praise the code.
+
+No sycophancy. No "great job, but…". Just: here is what I'd change and why.
+
+## Pass — run every lens, keep only real hits
+
+Go through each lens on the in-scope code. For each, either cite a concrete spot or move on silently.
+
+| Lens | Ask |
+|------|-----|
+| **Simpler** | Is there a shorter / more direct way? Am I solving a problem I don't have? Any premature abstraction, needless layer, config, or generality? |
+| **Duplication (DRY)** | Is this logic already implemented elsewhere in the codebase? Did I repeat a block that should be one helper? (Search before claiming "no dup".) |
+| **Optimal** | Redundant work, N+1, re-fetch, re-compute in a loop, unnecessary allocation? Is the data structure the right one? |
+| **Correctness edges** | Null / empty / boundary / large input / concurrent access / partial failure — which path did I not handle? |
+| **Error handling** | Any swallowed error (empty catch, ignored return)? Failures must surface clearly and be logged, not muffled. |
+| **Naming & footprint** | Misleading names? Did I rename/move things I didn't need to? Is any file getting too big / doing too much? |
+| **Tests** | Is the risky path actually covered, or just the happy one? |
+
+## Output
+
+Keep it tight. For each real finding:
+
+```
+⚠️ <one-line problem>  ·  <file:line>
+   → <concrete fix>
+```
+
+Then end with exactly one of:
+
+- **Findings exist** → list them worst-first, then ask: "Áp dụng mấy cái này không?" (do not auto-edit).
+- **Genuinely nothing** → "Đã soi <các lens> trên <scope>, không thấy vấn đề thực sự. Điểm cần lưu ý nếu mở rộng sau: <1 dòng, nếu có>." State what you searched so the "clean" verdict is earned, not assumed.
+
+## Boundaries
+
+- ❌ Full architecture / DDD audit with scoring → use `/review-code` (ARCHITECT mode).
+- ❌ Reviewing a whole PR / branch to post to GitHub → use `/review-code` (PR mode).
+- ❌ Actually implementing the fixes now → this skill *proposes*; apply only after the user says go.