moicle 2.3.0 → 3.0.0

package/assets/skills/review/architect/SKILL.md

@@ -1,274 +0,0 @@
----
-name: review-architect
-description: DDD architecture compliance review with automated checks and review loop. Use when user says "architect-review", "architecture review", "review architecture", "check architecture", "review ddd", "ddd review".
-args: "[ARCHITECTURE_NAME] [DOMAIN]"
----
-
-# DDD Architecture Review
-
-Audit a codebase (or a single domain) against DDD rules with automated checks, manual review, and a fix loop until score ≥ B.
-
-## When to use this skill
-
-- ✅ Verify DDD compliance after `/feature-new` or `/feature-refactor`
-- ✅ Periodic audit of an existing codebase
-- ✅ Quality gate before merging architectural changes
-- ❌ Full PR review (arch + code + security + tests) → use `/review-pr`
-- ❌ Self-review own branch before push → use `/review-branch`
-- ❌ Security-only audit → use `@security-audit` agent
-
-## Usage
-
-```
-/review-architect <architecture> [domain]
-/review-architect              # auto-detect stack
-```
-
-Examples: `/review-architect go-backend wallet`, `/review-architect react-frontend`.
-
-## Supported architectures
-
-Aliases: `ddd → ddd-architecture`, `go → go-backend`, `react → react-frontend`, `flutter → flutter-mobile`, `laravel → laravel-backend`, `remix → remix-fullstack`, `nestjs → nodejs-nestjs`, `mono → monorepo`.
-
-Files live at `.claude/architecture/{name}.md` (project) → `~/.claude/architecture/{name}.md` (global).
-
----
-
-## Workflow
-
-```
-RESOLVE → LOAD RULES → AUTOMATED CHECKS → MANUAL REVIEW → REPORT → FIX LOOP
-```
-
----
-
-## Phase 0: RESOLVE ARCHITECTURE
-
-### Argument provided
-1. Normalize via alias table → search project then global
-2. Found → Phase 1. Not found → reject with available list, STOP.
-
-### No argument
-1. Detect stack via `~/.claude/architecture/_shared/stack-detection.md`
-2. Detected → confirm with user. Not detected → list options, ask.
-
-### Gate
-- [ ] Architecture file loaded
-- [ ] Domain identified (if scoped)
-
----
-
-## Phase 1: LOAD RULES
-
-Read `ddd-architecture.md` (core) + the stack doc. Extract:
-- DDD directory layout
-- Layer import rules + forbidden imports
-- Hard rules (HR1-HR15)
-- Stack-specific check scripts
-- Wiring + test patterns
-
-### Gate
-- [ ] Core + stack rules loaded
-- [ ] Check scripts extracted
-- [ ] Review checklist prepared
-
----
-
-## Phase 2: AUTOMATED CHECKS
-
-Run the stack-specific check scripts from the architecture doc. They follow this universal pattern (adapt per stack):
-
-```bash
-echo "R1: Build"        ; {build}        && echo PASS || echo FAIL
-echo "R2: Lint/Vet"     ; {lint}         && echo PASS || echo FAIL
-echo "R3: Domain pure"  ; {grep_forbidden in domain/} && echo FAIL || echo PASS
-echo "R4: No cross-dom" ; {grep_domain_A in domain_B} && echo FAIL || echo PASS
-echo "R5: No cycles"    ; {cycle_check}  && echo FAIL || echo PASS
-echo "R6: Tests exist"  ; {find_tests_in_domain} | wc -l
-echo "R7: Tests pass"   ; {test}         && echo PASS || echo FAIL
-echo "R8: Wiring reg"   ; {check_routes_registered}
-echo "R9: Event names"  ; {check_event_consistency}
-echo "R10: Async ctx"   ; {check_no_request_context_in_goroutines}
-```
-
-Record PASS/FAIL per check. Continue to Phase 3 either way — manual review catches what automated misses.
-
-### Gate
-- [ ] All 10 automated checks run
-- [ ] PASS/FAIL recorded
-
----
-
-## Phase 3: MANUAL REVIEW
-
-Focus on **architecture structure**, not business correctness. 10 areas:
-
-### D — Directory Structure
-- D1 `domain/{domain}/` exists with proper subdirs
-- D2 Has `entities/`, `ports/`, `usecases/` at minimum
-- D3 `valueobjects/` separate (not mixed in entities)
-- D4 `events/` separate, 1 file per event
-- D5 Application layer: `ports/{transport}/`, `services/`, `listeners/`
-- D6 Infrastructure implements ports
-- D7 No legacy dirs (`modules/`, flat structure)
-
-### E — Entities
-- E1 Has constructor (`New{Entity}` / `create()`)
-- E2 Has behavior methods (NOT anemic)
-- E3 Raises domain events on state change
-- E4 No framework imports
-- E5 Has mappers (if persisted)
-
-### VO — Value Objects
-- VO1 In `valueobjects/`, not entities
-- VO2 Only stdlib imports
-- VO3 Immutable with behavior methods
-- VO4 Used by entities + ports (not raw strings)
-
-### P — Ports
-- P1 `ports/` dir exists (no inline interfaces in usecases)
-- P2 One file per port
-- P3 Each file has interface + related DTOs
-- P4 Domain types in signatures (not primitives)
-- P5 Platform-agnostic naming (`URLParser` not `ShopeeURLParser`)
-- P6 No infrastructure imports
-
-### EV — Events
-- EV1 One file per event
-- EV2 Extends base event type
-- EV3 Carries data for listeners
-- EV4 Name matches registry
-
-### U — UseCases
-- U1 Uses port interfaces (not inline)
-- U2 Split by concern (≤200 lines/file)
-- U3 Business logic lives here (not in handler / store / service)
-- U4 No infrastructure imports
-- U5 Dispatches events after persistence
-- U6 No `deps.go` inline interfaces
-
-### SVC — Services
-- SVC1 Thin wrapper, delegates to usecases
-- SVC2 No infrastructure imports
-
-### H — Handlers / Controllers
-- H1 Has registration function
-- H2 Thin (parse → service → respond)
-- H3 No business logic
-- H4 DTOs in separate file
-
-### L — Listeners
-- L1 One per event (`on_{event}` naming)
-- L2 Side-effects only
-- L3 Registered in event bus
-- L4 Background context (not request ctx)
-
-### I — Infrastructure
-- I1 Implements port interface
-- I2 Has mappers (domain ↔ persistence)
-- I3 No business logic
-- I4 Compile-time interface check (where possible)
-
-### Gate
-- [ ] All 10 areas reviewed
-- [ ] Findings categorized by severity (see `~/.claude/architecture/_shared/severity-levels.md`)
-
----
-
-## Phase 4: REPORT
-
-```markdown
-## Architecture Review: {architecture} / {domain}
-
-### Automated (R1-R10)
-| # | Check | Status |
-|---|-------|--------|
-| R1 | Build | PASS/FAIL |
-| ... | ... | ... |
-
-### Manual review
-| Area | Status | Violations |
-|------|--------|------------|
-| Directory (D1-D7) | OK / ISSUE | ... |
-| Entities (E1-E5) | OK / ISSUE | ... |
-| ... | ... | ... |
-
-### Violations
-1. [SEVERITY] code:file:line — description
-2. ...
-
-### Recommended fixes
-1. ...
-
-### Overall Score: {A/B/C/D/F}
-```
-
-### Scoring
-
-| Score | Criteria |
-|-------|----------|
-| **A** | 0 violations, all R1-R10 PASS |
-| **B** | 0 CRITICAL/HIGH, max 3 MEDIUM |
-| **C** | 0 CRITICAL, max 2 HIGH |
-| **D** | Has CRITICAL or 3+ HIGH |
-| **F** | Multiple CRITICAL — architecture broken |
-
-### Gate
-- [ ] Report generated
-- [ ] Score calculated
-- [ ] All violations have file:line
-
----
-
-## Phase 5: FIX LOOP (if user confirms)
-
-```
-LOOP:
-  1. Fix all violations
-  2. Re-run automated checks (Phase 2)
-  3. Re-run manual review (Phase 3)
-  4. IF violations severity ≥ MEDIUM → GOTO 1
-  5. IF only LOW or none → BREAK, final report
-```
-
-Verify after each iteration: build passes, tests pass, domain purity holds.
-
----
-
-## Calling from other skills
-
-`/feature-new` and `/feature-refactor` call this skill at the end of their workflows. When called from another skill:
-- Skip Phase 0 (architecture already known)
-- Skip user confirmation for fixes (auto-fix in loop)
-- Report final score back to caller
-
----
-
-## Hard Rules
-
-- **All CRITICAL/HIGH must be fixed** before merge
-- **MEDIUM allowed with waiver** (explicit decision + comment)
-- **Don't grade-inflate** — if it's a HIGH, mark HIGH
-- **Don't skip Phase 3** — automated checks miss structural issues
-- **File:line for every violation** — author shouldn't have to grep
-
----
-
-## Related Skills
-
-| When | Use |
-|------|-----|
-| Full PR review (arch + code + security + tests) | `/review-pr` |
-| Self-review own branch before push | `/review-branch` |
-| Refactor to fix violations | `/feature-refactor` |
-| Add tests if missing | `/review-tdd` |
-| Called from `/feature-new` / `/feature-refactor` | automatic |
-
-## Recommended Agents
-
-| Phase | Agent | Purpose |
-|-------|-------|---------|
-| LOAD | `@clean-architect` | Interpret architecture rules |
-| AUTOMATED | `@devops` | Build / lint / test scripts |
-| MANUAL | `@code-reviewer` | Spot violations |
-| FIX | Stack-specific dev agent | Apply fixes |

package/assets/skills/review/branch/SKILL.md

@@ -1,277 +0,0 @@
----
-name: review-branch
-description: Review local branch changes for architecture compliance, conventions, and code quality before pushing/PR. Stack-aware — detects the project stack and applies the matching rules. Use when user says "review changes", "review branch", "check branch", "check changes", "review my code", "review before pr".
-args: "[BASE_BRANCH]"
----
-
-# Review Local Branch Changes
-
-Self-review your branch vs a base branch before pushing or opening a PR. Checks architecture compliance, stack conventions, and code quality — on **changed files only**, not the whole codebase.
-
-**ARGUMENTS:** (optional) base branch. Default: `main` (fallback to `master`).
-
-## When to use this skill
-
-- ✅ Before pushing your branch / opening a PR
-- ✅ Before asking a teammate to review (catch easy issues first)
-- ✅ Quick sanity check on a feature you've been working on
-- ❌ Reviewing someone else's PR → use `/review-pr`
-- ❌ Only checking DDD architecture → use `/review-architect`
-- ❌ Security-only sweep → use `@security-audit` agent
-
-## Read Architecture First
-
-Detect stack via `~/.claude/architecture/_shared/stack-detection.md`. Load `ddd-architecture.md` + the stack doc — extract forbidden imports + conventions before reviewing.
-
-Severity definitions: `~/.claude/architecture/_shared/severity-levels.md` (code severity table).
-
----
-
-## Workflow
-
-```
-0 DETECT → 1 COLLECT → 2 BUILD+LINT → 3 ARCH → 4 CONVENTIONS → 5 QUALITY → 6 TESTS → 7 REPORT → 8 FIX
-```
-
----
-
-## Phase 0: DETECT
-
-- [ ] Stack detected (ask user if ambiguous, e.g., monorepo)
-- [ ] Architecture doc loaded
-- [ ] Forbidden-imports list extracted
-
----
-
-## Phase 1: COLLECT
-
-```bash
-BASE=${1:-main}
-git rev-parse --verify "$BASE" >/dev/null 2>&1 || BASE=master
-
-git log "$BASE"..HEAD --oneline
-git diff "$BASE"...HEAD --stat
-git diff "$BASE"...HEAD --name-only --diff-filter=ACMR
-```
-
-Categorize changed files by layer:
-
-| Layer | Typical paths |
-|-------|---------------|
-| Domain | `domain/`, `internal/domain/`, `src/domain/`, `lib/domain/` |
-| Application | `application/`, `internal/application/`, `src/application/` |
-| Infrastructure | `infrastructure/`, `internal/infrastructure/`, `src/infrastructure/` |
-| Presentation / UI | `controllers/`, `pages/`, `components/`, `views/`, `ports/http/` |
-| Persistence | `models/`, `entities/` (ORM), `prisma/`, `migrations/` |
-| Config / Bootstrap | `config/`, `bootstrap/`, `cmd/`, `main.*` |
-
-Read **all** changed files before reviewing — never skim.
-
----
-
-## Phase 2: BUILD + LINT
-
-Run the stack's build + typecheck + lint commands. If any fail → mark **CRITICAL** and stop further review until they pass.
-
-```bash
-# Go:       go build ./... && go vet ./...
-# NestJS:   pnpm typecheck && pnpm lint
-# Laravel:  composer dump-autoload && ./vendor/bin/phpstan analyse
-# Flutter:  dart analyze
-# React/Remix: pnpm typecheck && pnpm lint
-```
-
----
-
-## Phase 3: ARCHITECTURE (changed files only)
-
-Apply the stack's rules. Common checks per layer:
-
-### 3.1 Domain (if changed)
-| # | Rule |
-|---|------|
-| D1 | Domain purity — no forbidden imports (ORM, HTTP, cache, queue, auth SDK) |
-| D2 | No cross-domain imports (only shared kernel allowed) |
-| D3 | No persistence-model imports in domain |
-| D4 | Entities have behavior (not anemic data bags) |
-| D5 | Entities raise events on state change (if architecture uses events) |
-| D6 | Ports in `ports/` dir (not inline in usecases) |
-| D7 | One port per file |
-| D8 | Ports return domain types, not primitives |
-| D9 | Value objects stdlib-only |
-| D10 | Usecases have no infra imports |
-
-Quick check:
-```bash
-CHANGED_DOMAIN=$(git diff "$BASE"...HEAD --name-only --diff-filter=ACMR \
-  | grep -E '^(src|internal|lib)/domain/')
-[ -n "$CHANGED_DOMAIN" ] && echo "$CHANGED_DOMAIN" \
-  | xargs grep -lEn '<STACK_FORBIDDEN_REGEX>' 2>/dev/null \
-  && echo FAIL || echo PASS
-```
-
-### 3.2 Application (if changed)
-| # | Rule |
-|---|------|
-| A1 | Handler is thin (parse → service → respond, no business logic) |
-| A2 | Service justified only when ≥2 usecases orchestrated |
-| A3 | Listener is side-effect only (no business logic) |
-| A4 | Listener registered in event bus |
-| A5 | Event name string matches registry |
-| A6 | DTOs validated at boundary |
-| A7 | Composition root only — no inline wiring in handlers |
-
-### 3.3 Infrastructure (if changed)
-| # | Rule |
-|---|------|
-| I1 | Repository has no business logic |
-| I2 | Mappers exist (domain ↔ ORM model) |
-| I3 | Implements port interface (returns domain types) |
-| I4 | Context / transaction propagation correct |
-
-### 3.4 Persistence models (if changed)
-| # | Rule |
-|---|------|
-| M1 | ORM models in infrastructure, NOT domain |
-| M2 | Schema change → matching migration |
-| M3 | Nullable columns use nullable types |
-
----
-
-## Phase 4: CONVENTIONS (cross-stack)
-
-| # | Rule |
-|---|------|
-| G1 | No swallowed errors (no empty catch / `if err != nil {}`) |
-| G2 | Async work uses background context, NOT request context |
-| G3 | API-facing types have serialization tags (`json:`, decorators, etc.) |
-| G4 | No hardcoded secrets / tokens / keys |
-| G5 | Parameterized queries only — no string-interpolated SQL |
-| G6 | Input validation at boundary before reaching domain |
-
-Plus any stack-specific Hard Rules from the architecture doc.
-
----
-
-## Phase 5: QUALITY (manual)
-
-Read the diff. Look for:
-
-| # | Area | What to look for |
-|---|------|------------------|
-| Q1 | Logic correctness | Off-by-one, nil deref, wrong condition, missed edge case |
-| Q2 | Error handling | Errors propagated/wrapped, not silently ignored |
-| Q3 | Concurrency | Race conditions, shared mutable state, async leaks |
-| Q4 | Resource leaks | Unclosed connections, HTTP bodies, file handles |
-| Q5 | Naming | Reveals intent (no `data`, `info`, `manager`, `helper`) |
-| Q6 | Dead code | Unreachable, unused, commented-out |
-| Q7 | Duplication | Real duplication across changed files (not coincidental) |
-| Q8 | Breaking change | API contract change, removed field, behavior change |
-| Q9 | Over-engineering | Abstraction not justified by the change |
-| Q10 | Test coverage | New logic has tests; bug fixes have regression tests |
-
----
-
-## Phase 6: TESTS
-
-```bash
-# Tests for changed domains only
-CHANGED_DOMAINS=$(git diff "$BASE"...HEAD --name-only --diff-filter=ACMR \
-  | grep -E '/(domain|modules|features)/' \
-  | sed -E 's|.*(domain\|modules\|features)/([^/]+)/.*|\2|' | sort -u)
-
-for d in $CHANGED_DOMAINS; do
-  # Go:      go test ./internal/domain/$d/... -v
-  # NestJS:  npx jest src/domain/$d
-  # Laravel: ./vendor/bin/phpunit --filter $d
-  # Flutter: flutter test test/domain/$d
-  echo "Test $d"
-done
-
-# Full suite
-{full_test_command}
-```
-
----
-
-## Phase 7: REPORT
-
-```markdown
-## Code Review: {branch} → {base}
-
-**Stack:** {stack} · **Commits:** {N} · **Files:** {N} (+{add} / -{del})
-
-### Build / Lint / Types
-| Check | Status |
-|-------|--------|
-| Build | PASS/FAIL |
-| Lint | PASS/FAIL |
-| Types | PASS/FAIL |
-
-### Architecture / Conventions / Quality
-| # | Rule | Status | File:line |
-|---|------|--------|-----------|
-| D1 | Domain purity | PASS | — |
-| G4 | No secrets | FAIL | `config/db.ts:42` hardcoded token |
-| Q1 | Logic correctness | OK | — |
-
-### Tests
-| Check | Status |
-|-------|--------|
-| Changed area tests | PASS/FAIL |
-| Full suite | PASS/FAIL |
-
-### Issues (sorted by severity)
-| # | Severity | File:line | Issue | Suggested fix |
-|---|----------|-----------|-------|---------------|
-| 1 | CRITICAL | config/db.ts:42 | hardcoded token | move to env |
-| 2 | HIGH | handlers/user.ts:88 | business logic in handler | extract to usecase |
-
-### Verdict
-{APPROVED / CHANGES REQUESTED}
-```
-
-### Verdict rules
-- **CRITICAL or HIGH found** → CHANGES REQUESTED
-- **MEDIUM only** → CHANGES REQUESTED (should fix)
-- **LOW only or nothing** → APPROVED (with suggestions if any)
-
----
-
-## Phase 8: FIX (if user confirms)
-
-1. Fix in order: CRITICAL → HIGH → MEDIUM → LOW
-2. Re-run build + lint + tests after each batch
-3. Re-run full review when all fixed
-4. Report final status
-
----
-
-## Hard Rules
-
-- **Changed files only** — don't expand scope to drive-by reviews
-- **Stop on CRITICAL** — fix build / lint / type errors before everything else
-- **File:line for every issue** — no vague "somewhere in handlers"
-- **Match severity honestly** — don't grade-inflate
-- **Test changed areas** — don't only rely on global test run
-
----
-
-## Related Skills
-
-| When | Use |
-|------|-----|
-| Reviewing teammate's PR | `/review-pr` |
-| Deep DDD audit of a domain | `/review-architect` |
-| Fixing review comments on your PR | `/fix-pr-comment` |
-| Fixing bugs surfaced here | `/fix-hotfix` |
-
-## Recommended Agents
-
-| Phase | Agent | Purpose |
-|-------|-------|---------|
-| 3 Architecture | `@clean-architect` | DDD compliance |
-| 4 Conventions | `@security-audit` | Vulnerability sweep |
-| 5 Quality | `@code-reviewer` | Code smells |
-| 6 Tests | `@test-writer` | Coverage check |
-| 8 Fix | Stack-specific dev agent | Apply fixes |