moicle 3.0.0 → 3.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +10 -3
- package/assets/skills/challenge/SKILL.md +57 -0
- package/dist/commands/install/usage.js +1 -1
- package/package.json +1 -1
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Quyền
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
CHANGED
|
@@ -16,7 +16,7 @@ A toolkit to bootstrap and accelerate project development with Claude Code throu
|
|
|
16
16
|
|
|
17
17
|
- **16 AI Agents** - 6 developer agents + 10 utility agents
|
|
18
18
|
- **4 Commands** - Wizards for bootstrap, brainstorm, documentation, and marketing
|
|
19
|
-
- **
|
|
19
|
+
- **10 Skills** - Mode-based, auto-triggered workflows for the full SDLC (feature, bug, review, research, docs, marketing) plus a `/challenge` self-critique nudge
|
|
20
20
|
- **9 Architecture References** - DDD + Hexagonal + stack-specific patterns
|
|
21
21
|
|
|
22
22
|
|
|
@@ -124,9 +124,9 @@ moicle install --target cursor --project
|
|
|
124
124
|
| `/brainstorm` | Brainstorm ideas with 6 frameworks |
|
|
125
125
|
| `/doc` | Scan project and generate documentation |
|
|
126
126
|
|
|
127
|
-
### Skills (
|
|
127
|
+
### Skills (10)
|
|
128
128
|
|
|
129
|
-
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).
|
|
129
|
+
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).
|
|
130
130
|
|
|
131
131
|
**`/feature-*` — Build & Change**
|
|
132
132
|
|
|
@@ -167,6 +167,12 @@ Skills are grouped by a `<group>-` prefix. Type `/<group>-` then `Tab` in Claude
|
|
|
167
167
|
| `/marketing-content` | STRATEGY · POST | Multi-post content strategy, or write ONE evergreen post optimized for Search + AI |
|
|
168
168
|
| `/marketing-brand` | LOGO · VIDEO | Logo + brand identity spec, or video script/storyboard/production plan |
|
|
169
169
|
|
|
170
|
+
**`/challenge` — Self-Critique** (standalone, no group)
|
|
171
|
+
|
|
172
|
+
| Skill | Modes | When to use |
|
|
173
|
+
|-------|-------|-------------|
|
|
174
|
+
| `/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. |
|
|
175
|
+
|
|
170
176
|
### Skill decision matrix
|
|
171
177
|
|
|
172
178
|
When more than one skill / mode could fit, use this matrix:
|
|
@@ -183,6 +189,7 @@ When more than one skill / mode could fit, use this matrix:
|
|
|
183
189
|
| 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) |
|
|
184
190
|
| Writing README / API docs by hand | `/docs-sync` (SINGLE) | `/docs-sync` FULL (overkill for single file) |
|
|
185
191
|
| Generating full docs site from codebase | `/docs-sync` (FULL) | `/docs-sync` SINGLE (manual is slower) |
|
|
192
|
+
| Quick "did I overcomplicate this?" gut-check on fresh code | `/challenge` | `/review-code` ARCHITECT (heavier, scored audit) |
|
|
186
193
|
|
|
187
194
|
### Backward compatibility
|
|
188
195
|
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: challenge
|
|
3
|
+
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".
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Challenge — Self-Critique Pass
|
|
7
|
+
|
|
8
|
+
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.
|
|
9
|
+
|
|
10
|
+
## What's in scope
|
|
11
|
+
|
|
12
|
+
Pick the target in this order:
|
|
13
|
+
|
|
14
|
+
1. **Selected / named code** — if the user selected lines or named a file/function/change, critique exactly that.
|
|
15
|
+
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).
|
|
16
|
+
|
|
17
|
+
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.
|
|
18
|
+
|
|
19
|
+
## The one rule
|
|
20
|
+
|
|
21
|
+
> **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.
|
|
22
|
+
|
|
23
|
+
No sycophancy. No "great job, but…". Just: here is what I'd change and why.
|
|
24
|
+
|
|
25
|
+
## Pass — run every lens, keep only real hits
|
|
26
|
+
|
|
27
|
+
Go through each lens on the in-scope code. For each, either cite a concrete spot or move on silently.
|
|
28
|
+
|
|
29
|
+
| Lens | Ask |
|
|
30
|
+
|------|-----|
|
|
31
|
+
| **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? |
|
|
32
|
+
| **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".) |
|
|
33
|
+
| **Optimal** | Redundant work, N+1, re-fetch, re-compute in a loop, unnecessary allocation? Is the data structure the right one? |
|
|
34
|
+
| **Correctness edges** | Null / empty / boundary / large input / concurrent access / partial failure — which path did I not handle? |
|
|
35
|
+
| **Error handling** | Any swallowed error (empty catch, ignored return)? Failures must surface clearly and be logged, not muffled. |
|
|
36
|
+
| **Naming & footprint** | Misleading names? Did I rename/move things I didn't need to? Is any file getting too big / doing too much? |
|
|
37
|
+
| **Tests** | Is the risky path actually covered, or just the happy one? |
|
|
38
|
+
|
|
39
|
+
## Output
|
|
40
|
+
|
|
41
|
+
Keep it tight. For each real finding:
|
|
42
|
+
|
|
43
|
+
```
|
|
44
|
+
⚠️ <one-line problem> · <file:line>
|
|
45
|
+
→ <concrete fix>
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
Then end with exactly one of:
|
|
49
|
+
|
|
50
|
+
- **Findings exist** → list them worst-first, then ask: "Áp dụng mấy cái này không?" (do not auto-edit).
|
|
51
|
+
- **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.
|
|
52
|
+
|
|
53
|
+
## Boundaries
|
|
54
|
+
|
|
55
|
+
- ❌ Full architecture / DDD audit with scoring → use `/review-code` (ARCHITECT mode).
|
|
56
|
+
- ❌ Reviewing a whole PR / branch to post to GitHub → use `/review-code` (PR mode).
|
|
57
|
+
- ❌ Actually implementing the fixes now → this skill *proposes*; apply only after the user says go.
|
|
@@ -48,7 +48,7 @@ const printCursorUsage = () => {
|
|
|
48
48
|
console.log(chalk.bold(' Cursor:'));
|
|
49
49
|
console.log(chalk.gray(' Rules (16 agents) ~/.cursor/rules/ or ./.cursor/rules/'));
|
|
50
50
|
console.log(chalk.gray(' Commands (4) ~/.cursor/commands/ or ./.cursor/commands/'));
|
|
51
|
-
console.log(chalk.gray(' Skills (
|
|
51
|
+
console.log(chalk.gray(' Skills (10) ~/.cursor/skills/ or ./.cursor/skills/'));
|
|
52
52
|
console.log(chalk.gray(' Architecture (11) ~/.cursor/architecture/ or ./.cursor/architecture/'));
|
|
53
53
|
console.log(chalk.gray(' Use @agent-name in chat or slash commands from the command palette'));
|
|
54
54
|
console.log('');
|