moicle 1.3.0 → 1.4.0

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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "moicle",
3
- "version": "1.3.0",
3
+ "version": "1.4.0",
4
4
  "description": "Reusable AI agents, commands, skills, and architecture references for Claude Code",
5
5
  "type": "module",
6
6
  "main": "dist/index.js",
@@ -1,143 +0,0 @@
1
- # Clean Architecture Reference
2
-
3
- > **Optional pattern** - Use when strict layer separation is needed. For simpler projects, consider stack-specific patterns.
4
-
5
- ## Overview
6
-
7
- Clean Architecture separates concerns into independent layers, making code easier to test, maintain and scale.
8
-
9
- ```
10
- ┌─────────────────────────────────────────────────────┐
11
- │ Presentation │
12
- │ (UI, Controllers, Views) │
13
- ├─────────────────────────────────────────────────────┤
14
- │ Application │
15
- │ (Use Cases, App Services) │
16
- ├─────────────────────────────────────────────────────┤
17
- │ Domain │
18
- │ (Entities, Repository Interfaces) │
19
- ├─────────────────────────────────────────────────────┤
20
- │ Infrastructure │
21
- │ (DB, API, External Services, Repos) │
22
- └─────────────────────────────────────────────────────┘
23
- ```
24
-
25
- ## When to Use
26
-
27
- **Use Clean Architecture when:**
28
- - Large, long-term project with multiple developers
29
- - Need to swap infrastructure easily (DB, external APIs)
30
- - Strict testability requirements
31
- - Domain logic is complex and needs isolation
32
-
33
- **Consider simpler patterns when:**
34
- - Small to medium projects
35
- - Rapid prototyping
36
- - Simple CRUD applications
37
- - Framework conventions are sufficient
38
-
39
- ## Dependency Rule
40
-
41
- - Dependencies only point **inward**
42
- - Domain layer **does not depend** on any other layer
43
- - Outer layers depend on inner layers via **interfaces**
44
-
45
- ## Layers
46
-
47
- ### 1. Domain Layer (Core)
48
- ```
49
- domain/
50
- ├── entities/ # Business objects
51
- ├── value_objects/ # Immutable objects
52
- ├── repositories/ # Repository interfaces
53
- ├── services/ # Domain services (interfaces)
54
- └── errors/ # Domain-specific errors
55
- ```
56
-
57
- **Rules:**
58
- - Pure business logic, no framework dependencies
59
- - Entities contain business rules
60
- - Repository interfaces defined here, implemented in Infrastructure
61
-
62
- ### 2. Application Layer (Use Cases)
63
- ```
64
- application/
65
- ├── use_cases/ # Application-specific business rules
66
- ├── dto/ # Data Transfer Objects
67
- ├── mappers/ # Entity <-> DTO mappers
68
- └── interfaces/ # Port interfaces
69
- ```
70
-
71
- **Rules:**
72
- - Orchestrate domain objects
73
- - Contains application-specific business rules
74
- - No direct DB/API access, use repository interfaces
75
-
76
- ### 3. Infrastructure Layer
77
- ```
78
- infrastructure/
79
- ├── repositories/ # Repository implementations
80
- ├── datasources/ # DB, API clients
81
- ├── services/ # External service implementations
82
- └── mappers/ # DB models <-> Entities
83
- ```
84
-
85
- **Rules:**
86
- - Implements repository interfaces from Domain
87
- - Contains all external dependencies (DB, HTTP, etc.)
88
- - Can be swapped without affecting other layers
89
-
90
- ### 4. Presentation Layer
91
- ```
92
- presentation/
93
- ├── controllers/ # HTTP handlers / Controllers
94
- ├── views/ # UI components
95
- ├── view_models/ # Presentation logic
96
- └── routes/ # Route definitions
97
- ```
98
-
99
- **Rules:**
100
- - Handles user input/output
101
- - Calls Use Cases, never Domain directly
102
- - Contains UI-specific logic only
103
-
104
- ## Naming Conventions
105
-
106
- | Layer | Suffix | Example |
107
- |-------|--------|---------|
108
- | Entity | - | `User`, `Order` |
109
- | Use Case | `UseCase` | `CreateUserUseCase` |
110
- | Repository Interface | `Repository` | `UserRepository` |
111
- | Repository Impl | `RepositoryImpl` | `UserRepositoryImpl` |
112
- | Controller | `Controller` | `UserController` |
113
- | DTO | `DTO` / `Request` / `Response` | `CreateUserDTO` |
114
-
115
- ## Data Flow
116
-
117
- ```
118
- Request → Controller → UseCase → Repository(Interface) → RepositoryImpl → DB
119
-
120
- Response ← Controller ← DTO ← Entity
121
- ```
122
-
123
- ## Testing Strategy
124
-
125
- | Layer | Test Type | Mock |
126
- |-------|-----------|------|
127
- | Domain | Unit | None |
128
- | Application | Unit | Repository interfaces |
129
- | Infrastructure | Integration | DB (testcontainers) |
130
- | Presentation | E2E | Full stack |
131
-
132
- ## Alternative Patterns
133
-
134
- If Clean Architecture is overkill for your project:
135
-
136
- | Stack | Simpler Alternative |
137
- |-------|---------------------|
138
- | Laravel | Domain + UseCase pattern (see `laravel-backend.md`) |
139
- | Go | Handler + Service pattern |
140
- | React | Feature-based folders |
141
- | Flutter | BLoC or Provider pattern |
142
-
143
- Choose the pattern that fits your project's complexity.
@@ -1,77 +0,0 @@
1
- ---
2
- name: go-module
3
- description: Generate complete Go module with Clean Architecture. Triggers: "generate go module", "scaffold go", "new go module"
4
- ---
5
-
6
- # Go Module Generator
7
-
8
- Generate complete Go module following Clean Architecture pattern.
9
-
10
- ## Usage
11
-
12
- ```bash
13
- python scripts/module-generator.py --stack go --name <module_name> --fields "<fields>" --project <go_module_path> [--validators]
14
- ```
15
-
16
- ## Examples
17
-
18
- ```bash
19
- # Basic CRUD
20
- python scripts/module-generator.py \
21
- --stack go \
22
- --name product \
23
- --fields "name:string,description:*string,price:int64,status:string" \
24
- --project github.com/user/myapp
25
-
26
- # With validators
27
- python scripts/module-generator.py \
28
- --stack go \
29
- --name bank_account \
30
- --fields "user_id:string,bank_name:string,account_number:string,is_verified:bool" \
31
- --project github.com/user/myapp \
32
- --validators
33
-
34
- # Optional fields (use ?)
35
- python scripts/module-generator.py \
36
- --stack go \
37
- --name order \
38
- --fields "user_id:string,total:int64,status:string,note:string?" \
39
- --project github.com/user/myapp
40
- ```
41
-
42
- ## Field Types
43
-
44
- | Type | Example |
45
- |------|---------|
46
- | `string` | `name:string` |
47
- | `*string` | `description:*string` (nullable) |
48
- | `int64` | `price:int64` |
49
- | `int` | `count:int` |
50
- | `bool` | `is_active:bool` |
51
- | `float64` | `rate:float64` |
52
-
53
- ## Generated Structure
54
-
55
- ```
56
- internal/modules/{module}/
57
- ├── controllers/{module}_controller.go
58
- ├── usecases/{module}_usecase.go
59
- ├── dtos/{module}_dto.go
60
- ├── validators/{module}_validator.go # if --validators
61
- └── init.go
62
-
63
- pkg/database/{module}.go
64
- ```
65
-
66
- ## After Generation
67
-
68
- 1. Register in `cmd/api/router.go`:
69
- ```go
70
- import "project/internal/modules/{module}"
71
- {module}.Init(r, db, authMiddleware)
72
- ```
73
-
74
- 2. Add to `pkg/database/database.go`:
75
- ```go
76
- db.AutoMigrate(&{Entity}{})
77
- ```
@@ -1,297 +0,0 @@
1
- ---
2
- name: ship
3
- description: Ship workflow for versioning, changelog, tagging, and creating PR. Use when releasing, shipping versions, or when user says "release", "ship", "publish", "new version", "cut release", "bump version".
4
- ---
5
-
6
- # Release Workflow
7
-
8
- Workflow for shipping releases with versioning, changelog, tagging, and PR creation.
9
-
10
- ## IMPORTANT: Read Architecture First
11
-
12
- **Before starting any phase, you MUST read the appropriate architecture reference:**
13
-
14
- ### Global Architecture Files
15
- ```
16
- ~/.claude/architecture/
17
- ├── clean-architecture.md # Core principles for all projects
18
- ├── flutter-mobile.md # Flutter + Riverpod
19
- ├── react-frontend.md # React + Vite + TypeScript
20
- ├── go-backend.md # Go + Gin
21
- ├── laravel-backend.md # Laravel + PHP
22
- ├── remix-fullstack.md # Remix fullstack
23
- └── monorepo.md # Monorepo structure
24
- ```
25
-
26
- ### Project-specific (if exists)
27
- ```
28
- .claude/architecture/ # Project overrides
29
- ```
30
-
31
- **Understand the project's release process and conventions before proceeding.**
32
-
33
- ## Recommended Agents
34
-
35
- | Phase | Agent | Purpose |
36
- |-------|-------|---------|
37
- | PRE-CHECK | `@code-reviewer` | Final code review |
38
- | PRE-CHECK | `@test-writer` | Verify test coverage |
39
- | PRE-CHECK | `@security-audit` | Security scan before release |
40
- | CHANGELOG | `@docs-writer` | Generate changelog & release notes |
41
-
42
- ## Workflow Overview
43
-
44
- ```
45
- ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
46
- │1.PRE-CHECK──▶│2.VERSION │──▶│3.CHANGELOG──▶│4.TAG+COMMIT──▶│5.CREATE PR│
47
- └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
48
- ```
49
-
50
- ---
51
-
52
- ## Phase 1: PRE-CHECK
53
-
54
- **Goal**: Ensure codebase is release-ready
55
-
56
- ### Actions
57
- 1. **Identify project stack and read architecture doc**
58
- 2. Verify branch state:
59
- ```bash
60
- git status
61
- git log --oneline -20
62
- git diff main..HEAD --stat # or master
63
- ```
64
-
65
- 3. Run full test suite:
66
- ```bash
67
- flutter test # Flutter
68
- go test ./... # Go
69
- bun test # React/Remix
70
- php artisan test # Laravel
71
- ```
72
-
73
- 4. Check for:
74
- - [ ] All tests passing
75
- - [ ] No uncommitted changes
76
- - [ ] No pending PRs that should be included
77
- - [ ] No known critical bugs
78
-
79
- 5. Review what's being released:
80
- ```bash
81
- git log $(git describe --tags --abbrev=0 2>/dev/null || git rev-list --max-parents=0 HEAD)..HEAD --oneline
82
- ```
83
-
84
- ### Output
85
- ```markdown
86
- ## Pre-Release Check
87
-
88
- **Stack**: [Flutter/React/Go/Laravel/Remix]
89
- **Branch**: [branch name]
90
- **Last Release**: [tag/version]
91
-
92
- ### Tests: [PASS/FAIL]
93
- ### Commits Since Last Release: [count]
94
-
95
- ### Changes Summary
96
- - feat: [list features]
97
- - fix: [list fixes]
98
- - breaking: [list breaking changes]
99
- ```
100
-
101
- ### Gate
102
- - [ ] All tests pass
103
- - [ ] Clean working tree
104
- - [ ] Changes catalogued
105
-
106
- ---
107
-
108
- ## Phase 2: VERSION
109
-
110
- **Goal**: Determine and apply the correct version number
111
-
112
- ### Versioning Strategy
113
-
114
- Follow [Semantic Versioning](https://semver.org/):
115
- ```
116
- MAJOR.MINOR.PATCH
117
-
118
- MAJOR - Breaking changes (incompatible API changes)
119
- MINOR - New features (backwards compatible)
120
- PATCH - Bug fixes (backwards compatible)
121
- ```
122
-
123
- ### Actions
124
- 1. Determine version bump based on commits:
125
- ```
126
- feat!: / BREAKING CHANGE: → MAJOR
127
- feat: → MINOR
128
- fix: / perf: / refactor: → PATCH
129
- ```
130
-
131
- 2. Check current version:
132
- ```bash
133
- # Node.js
134
- node -e "console.log(require('./package.json').version)"
135
-
136
- # Flutter
137
- grep 'version:' pubspec.yaml
138
-
139
- # Go
140
- git describe --tags --abbrev=0
141
-
142
- # Laravel
143
- grep "'version'" config/app.php
144
- ```
145
-
146
- 3. Apply version bump:
147
- ```bash
148
- # Node.js
149
- npm version [major|minor|patch] --no-git-tag-version
150
-
151
- # Flutter - update pubspec.yaml version field
152
-
153
- # Go - version via git tags only
154
-
155
- # Laravel - update config/app.php version
156
- ```
157
-
158
- 4. Ask user to confirm the new version number
159
-
160
- ### Gate
161
- - [ ] Version number confirmed by user
162
- - [ ] Version applied to project files
163
- - [ ] Bump type matches changes
164
-
165
- ---
166
-
167
- ## Phase 3: CHANGELOG
168
-
169
- **Goal**: Generate clear, useful release notes
170
-
171
- ### Actions
172
- 1. Collect commits since last release:
173
- ```bash
174
- git log $(git describe --tags --abbrev=0 2>/dev/null || git rev-list --max-parents=0 HEAD)..HEAD --pretty=format:"- %s (%h)" --reverse
175
- ```
176
-
177
- 2. Categorize changes:
178
- ```markdown
179
- ## [x.y.z] - YYYY-MM-DD
180
-
181
- ### Breaking Changes
182
- - description (#PR)
183
-
184
- ### Features
185
- - description (#PR)
186
-
187
- ### Bug Fixes
188
- - description (#PR)
189
-
190
- ### Performance
191
- - description (#PR)
192
-
193
- ### Other
194
- - description (#PR)
195
- ```
196
-
197
- 3. Update CHANGELOG.md (prepend new version at top)
198
-
199
- ### Gate
200
- - [ ] CHANGELOG.md updated
201
- - [ ] All significant changes documented
202
-
203
- ---
204
-
205
- ## Phase 4: TAG & COMMIT
206
-
207
- **Goal**: Create release commit and tag
208
-
209
- ### Actions
210
- 1. Stage and commit version + changelog:
211
- ```bash
212
- git add -A
213
- git commit -m "chore(release): bump version to [x.y.z]"
214
- ```
215
-
216
- 2. Create annotated tag:
217
- ```bash
218
- git tag -a v[x.y.z] -m "Release v[x.y.z]"
219
- ```
220
-
221
- ### Gate
222
- - [ ] Version commit created
223
- - [ ] Tag created
224
-
225
- ---
226
-
227
- ## Phase 5: CREATE PR
228
-
229
- **Goal**: Push and create PR to master
230
-
231
- ### Actions
232
- 1. Push branch and tag:
233
- ```bash
234
- git push origin [branch] -u
235
- git push origin v[x.y.z]
236
- ```
237
-
238
- 2. Create PR:
239
- ```bash
240
- gh pr create --base master --title "chore(release): v[x.y.z]" --body "$(cat <<'EOF'
241
- ## Release v[x.y.z]
242
-
243
- ### Changes
244
- [paste categorized changelog here]
245
-
246
- ### Checklist
247
- - [ ] Tests passing
248
- - [ ] Version bumped
249
- - [ ] CHANGELOG updated
250
- - [ ] Tag created
251
- EOF
252
- )"
253
- ```
254
-
255
- ### Gate
256
- - [ ] Branch pushed
257
- - [ ] Tag pushed
258
- - [ ] PR created to master
259
-
260
- ---
261
-
262
- ## Quick Reference
263
-
264
- ### Architecture Docs
265
- | Stack | Doc |
266
- |-------|-----|
267
- | All | `clean-architecture.md` |
268
- | Flutter | `flutter-mobile.md` |
269
- | React | `react-frontend.md` |
270
- | Go | `go-backend.md` |
271
- | Laravel | `laravel-backend.md` |
272
- | Remix | `remix-fullstack.md` |
273
- | Monorepo | `monorepo.md` |
274
-
275
- ### Version Bump Decision
276
- | Commit Type | Bump | Example |
277
- |-------------|------|---------|
278
- | `feat!:` / `BREAKING CHANGE:` | MAJOR | API removed |
279
- | `feat:` | MINOR | New endpoint |
280
- | `fix:` / `perf:` | PATCH | Bug fix |
281
-
282
- ### Commit Message Format
283
- ```
284
- chore(release): bump version to x.y.z
285
- ```
286
-
287
- ### Tag Format
288
- ```
289
- v[MAJOR].[MINOR].[PATCH]
290
- ```
291
-
292
- ### Release Checklist
293
- - [ ] Tests pass
294
- - [ ] Version bumped
295
- - [ ] CHANGELOG updated
296
- - [ ] Committed & tagged
297
- - [ ] PR created to master