moicle 2.3.0 → 2.3.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/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
|
+
- **22 Skills** - Auto-triggered workflows for the full SDLC (feature, bug, review, release, ops, content)
|
|
20
20
|
- **9 Architecture References** - DDD + Hexagonal + stack-specific patterns
|
|
21
21
|
|
|
22
22
|
|
|
@@ -124,7 +124,7 @@ 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 (22)
|
|
128
128
|
|
|
129
129
|
Skills are grouped by a `<group>-` prefix. Type `/<group>-` then `Tab` in Claude Code to see all skills in a group.
|
|
130
130
|
|
|
@@ -136,6 +136,7 @@ Skills are grouped by a `<group>-` prefix. Type `/<group>-` then `Tab` in Claude
|
|
|
136
136
|
| `/feature-refactor` | Restructure existing module to DDD or improve internals |
|
|
137
137
|
| `/feature-api` | Add a new endpoint or integrate an external API |
|
|
138
138
|
| `/feature-deprecate` | Safely sunset a feature, API, or module |
|
|
139
|
+
| `/feature-track` | Plan + approve, then run a tracked loop: branch → checklist → per-item test/implement/verify/commit |
|
|
139
140
|
|
|
140
141
|
**`/fix-*` — Bugs & Incidents**
|
|
141
142
|
|
|
@@ -192,6 +193,7 @@ When more than one skill could fit, use this matrix:
|
|
|
192
193
|
| Want to verify DDD compliance only | `/review-architect` | `/review-pr` (broader scope) |
|
|
193
194
|
| Don't know the right solution yet | `/research-web` | `/research-spike` (skip if you can decide from docs) |
|
|
194
195
|
| Need to validate an idea by building | `/research-spike` | `/feature-new` (commit only after spike) |
|
|
196
|
+
| 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) |
|
|
195
197
|
| Writing README / API docs by hand | `/docs-write` | `/docs-sync` (overkill for single file) |
|
|
196
198
|
| Generating full docs site from codebase | `/docs-sync` | `/docs-write` (manual is slower) |
|
|
197
199
|
|
|
@@ -0,0 +1,157 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: feature-track
|
|
3
|
+
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".
|
|
4
|
+
args: "[TASK_DESCRIPTION]"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Tracked Development Loop
|
|
8
|
+
|
|
9
|
+
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**.
|
|
10
|
+
|
|
11
|
+
**ARGUMENTS:** `<task description>` — e.g., `wallet savings account`, `add rate limiting to auth`, `migrate orders module to events`
|
|
12
|
+
|
|
13
|
+
## When to use this skill
|
|
14
|
+
|
|
15
|
+
- ✅ A task that splits into several verifiable steps you want to drive as a checklist
|
|
16
|
+
- ✅ You want a clean history — one commit per completed step, easy to revert
|
|
17
|
+
- ✅ You want test-first discipline on each step, on a dedicated branch
|
|
18
|
+
- ❌ One-line / obvious change → just do it
|
|
19
|
+
- ❌ Urgent production bug → use `/fix-hotfix`
|
|
20
|
+
- ❌ Single full DDD feature across all layers → use `/feature-new`
|
|
21
|
+
- ❌ Driving ONE unit test-first with no branch/checklist → use `/review-tdd`
|
|
22
|
+
|
|
23
|
+
## Read Architecture First
|
|
24
|
+
|
|
25
|
+
Detect stack via `~/.claude/architecture/_shared/stack-detection.md`. The stack doc tells you:
|
|
26
|
+
- Test command + test file location convention
|
|
27
|
+
- Build + lint commands (for the VERIFY step)
|
|
28
|
+
- Mocking pattern for ports / dependencies
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
## Workflow
|
|
33
|
+
|
|
34
|
+
```
|
|
35
|
+
0 BRAINSTORM & PLAN ─▶ [USER APPROVES] ─▶ 1 SETUP ─▶ ┌─ 2 LOOP per item ──────────────────────┐ ─▶ 3 REPORT
|
|
36
|
+
(understand, /brainstorm,(last step of (branch + │ TEST → IMPLEMENT → VERIFY → FIX → │
|
|
37
|
+
plan + draft checklist) planning) checklist) │ MARK DONE → COMMIT │
|
|
38
|
+
│ └ fail ─▶ FIX ─▶ VERIFY (to pass) │
|
|
39
|
+
└─────────── next pending item ──────────┘
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
> Core rule: **brainstorm and plan, the LAST planning step is user approval, THEN start the loop.** Never jump straight to branch/checklist.
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
## Phase 0: BRAINSTORM & PLAN
|
|
47
|
+
|
|
48
|
+
**Goal:** understand the task, pick the simplest viable approach, draft the checklist — and get the user to approve before touching anything.
|
|
49
|
+
|
|
50
|
+
### Steps
|
|
51
|
+
1. **Detect stack** — load the matching architecture doc for test/build/lint commands and conventions.
|
|
52
|
+
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.
|
|
53
|
+
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.
|
|
54
|
+
4. **Draft the plan** — settle:
|
|
55
|
+
- the chosen approach,
|
|
56
|
+
- a proposed branch name (`feat/<slug>`),
|
|
57
|
+
- the **draft checklist** — each item = one verifiable unit = one test passing + one commit,
|
|
58
|
+
- files affected + how each item is tested.
|
|
59
|
+
5. **Present the plan and WAIT for approval.** This is the last step of planning. No branch, no code, no `TaskCreate` yet.
|
|
60
|
+
|
|
61
|
+
### Gate
|
|
62
|
+
- [ ] Stack detected
|
|
63
|
+
- [ ] Requirements clear (clarified if they weren't)
|
|
64
|
+
- [ ] Approach brainstormed via `/brainstorm` (simplest viable picked)
|
|
65
|
+
- [ ] Plan + draft checklist presented
|
|
66
|
+
- [ ] **User APPROVED the plan**
|
|
67
|
+
|
|
68
|
+
---
|
|
69
|
+
|
|
70
|
+
## Phase 1: SETUP
|
|
71
|
+
|
|
72
|
+
**Goal:** turn the approved plan into a branch + a live checklist. Runs only AFTER approval.
|
|
73
|
+
|
|
74
|
+
### Steps
|
|
75
|
+
1. **Checkout a new branch** with the approved name (`feat/<slug>`) off the current base. Never run the loop on `master` / `main`.
|
|
76
|
+
2. **Create the checklist** with `TaskCreate` — one task per checklist item, in order, matching the approved plan.
|
|
77
|
+
|
|
78
|
+
### Gate
|
|
79
|
+
- [ ] New branch created and checked out
|
|
80
|
+
- [ ] Checklist created via `TaskCreate`, matching the approved plan
|
|
81
|
+
|
|
82
|
+
---
|
|
83
|
+
|
|
84
|
+
## Phase 2: LOOP (per item)
|
|
85
|
+
|
|
86
|
+
Take the next `pending` item from the task list and run it through the full cycle. Repeat until no `pending` items remain.
|
|
87
|
+
|
|
88
|
+
1. **MARK IN_PROGRESS** — `TaskUpdate` the item → `in_progress`.
|
|
89
|
+
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.
|
|
90
|
+
3. **IMPLEMENT (GREEN)** — write the minimal code to make the test pass. Follow an existing reference module so it matches the codebase style.
|
|
91
|
+
4. **VERIFY** — actually run it: the item's test + build + lint (commands per stack). Never claim pass without running.
|
|
92
|
+
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.
|
|
93
|
+
6. **MARK DONE** — `TaskUpdate` the item → `completed`.
|
|
94
|
+
7. **COMMIT** — commit just this item with a conventional message (`feat:` / `fix:` / `test:` / `refactor:` …). Commit only — **do not push automatically**.
|
|
95
|
+
|
|
96
|
+
### Gate (per item, before moving on)
|
|
97
|
+
- [ ] Test green
|
|
98
|
+
- [ ] Build + lint green
|
|
99
|
+
- [ ] Task marked `completed`
|
|
100
|
+
- [ ] Item committed (one commit)
|
|
101
|
+
|
|
102
|
+
---
|
|
103
|
+
|
|
104
|
+
## Phase 3: Final Report
|
|
105
|
+
|
|
106
|
+
```markdown
|
|
107
|
+
## Track Complete: {task}
|
|
108
|
+
|
|
109
|
+
Branch: `feat/{slug}`
|
|
110
|
+
|
|
111
|
+
| # | Item | Test(s) | Commit | Status |
|
|
112
|
+
|---|------|---------|--------|--------|
|
|
113
|
+
| 1 | {item} | {test name} | {hash} `feat: …` | ✅ |
|
|
114
|
+
| 2 | {item} | {test name} | {hash} `feat: …` | ✅ |
|
|
115
|
+
|
|
116
|
+
### Totals
|
|
117
|
+
- Items: {N} done / {N}
|
|
118
|
+
- Commits: {N}
|
|
119
|
+
- Tests added: {N}, all green
|
|
120
|
+
|
|
121
|
+
### Next
|
|
122
|
+
- Push + open PR, or run `/review-branch` first
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
---
|
|
126
|
+
|
|
127
|
+
## Hard Rules
|
|
128
|
+
|
|
129
|
+
- **Plan + user approval FIRST** — no branch, no code until the plan is approved.
|
|
130
|
+
- **Branch first** — never run the loop on `master` / `main`.
|
|
131
|
+
- **RED before GREEN** — no production code that a failing test didn't drive.
|
|
132
|
+
- **Verify by running real commands** — never assert pass from inspection alone.
|
|
133
|
+
- **Never swallow errors** in FIX — handle exceptions explicitly, fix the root cause.
|
|
134
|
+
- **One commit per item** — don't squash steps together, don't push automatically.
|
|
135
|
+
- **DB operations (migrate / seed / drop)** inside any item: **CONFIRM with the user before running — every time, even if a previous item was already confirmed.**
|
|
136
|
+
- **Simple first** — don't overengineer an item.
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
## Related Skills
|
|
141
|
+
|
|
142
|
+
| When | Use |
|
|
143
|
+
|------|-----|
|
|
144
|
+
| Need idea frameworks for Phase 0 | `/brainstorm` |
|
|
145
|
+
| Drive ONE unit deeper test-first | `/review-tdd` |
|
|
146
|
+
| Full DDD feature across all layers | `/feature-new` |
|
|
147
|
+
| Self-review the branch after the loop | `/review-branch` |
|
|
148
|
+
| Urgent prod bug, no checklist | `/fix-hotfix` |
|
|
149
|
+
|
|
150
|
+
## Recommended Agents
|
|
151
|
+
|
|
152
|
+
| Phase | Agent | Purpose |
|
|
153
|
+
|-------|-------|---------|
|
|
154
|
+
| BRAINSTORM / PLAN | `@clean-architect` | Approach + decomposition |
|
|
155
|
+
| TEST | `@test-writer` | Failing test per item |
|
|
156
|
+
| IMPLEMENT | Stack-specific dev agent | Minimal implementation |
|
|
157
|
+
| VERIFY / FIX | `@code-reviewer` | Catch issues before commit |
|
|
@@ -36,7 +36,7 @@ const printSkillEditorUsage = (target) => {
|
|
|
36
36
|
const home = target === 'codex' ? '~/.codex' : '~/.gemini';
|
|
37
37
|
const local = target === 'codex' ? './.codex' : './.gemini';
|
|
38
38
|
console.log(chalk.bold(` ${name}:`));
|
|
39
|
-
console.log(chalk.gray(` MoiCle's 16 agents, 4 commands &
|
|
39
|
+
console.log(chalk.gray(` MoiCle's 16 agents, 4 commands & 22 skills installed as SKILL.md files`));
|
|
40
40
|
console.log(chalk.gray(` Skills under ${home}/skills or ${local}/skills`));
|
|
41
41
|
console.log(chalk.gray(` Architecture docs under ${home}/architecture or ${local}/architecture`));
|
|
42
42
|
if (target === 'codex') {
|
|
@@ -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 (22) ~/.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('');
|