moicle 2.3.1 → 3.0.0

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

@@ -1,231 +0,0 @@
----
-name: review-pr
-description: Thorough pull request review workflow with architecture compliance checks. Use when reviewing pull requests, checking code changes, or when user says "review pr", "check pr", "review code", "pr review", "review pull request".
----
-
-# Pull Request Review Workflow
-
-Review someone else's PR across 5 dimensions and post structured feedback to GitHub.
-
-## When to use this skill
-
-- ✅ Reviewing someone else's open PR (`gh pr view <number>` accessible)
-- ✅ Need to post structured feedback (APPROVE / REQUEST CHANGES / COMMENT)
-- ✅ Want a multi-dimensional review (architecture + security + perf + tests)
-- ❌ Self-review of own branch before push → use `/review-branch`
-- ❌ Only checking DDD compliance → use `/review-architect`
-- ❌ Addressing comments on your own PR → use `/fix-pr-comment`
-
-## Read Architecture First
-
-Load `~/.claude/architecture/ddd-architecture.md` + the stack-specific doc. Detect stack via `~/.claude/architecture/_shared/stack-detection.md`.
-
----
-
-## Workflow
-
-```
-FETCH → ANALYZE → REVIEW (5 dims) → FEEDBACK → POST
-```
-
----
-
-## Phase 1: FETCH
-
-**Goal:** load PR + diff + context in one pass.
-
-```bash
-PR={number}
-gh pr view $PR --json number,title,body,author,state,headRefName,baseRefName,commits,files
-gh pr diff $PR
-gh pr checks $PR
-gh pr view $PR --comments
-```
-
-### Gate
-- [ ] PR metadata + diff + CI status loaded
-- [ ] PR description explains "what / why" — if missing, ask author before deep review
-- [ ] CI status known (don't review red builds — ask author to fix first)
-
----
-
-## Phase 2: ANALYZE
-
-**Goal:** understand scope before going line-by-line.
-
-1. **Scope check**: does the diff match the PR title / description? Mixed-scope PRs (e.g., feature + drive-by refactor) → ask author to split.
-2. **Risk profile**: which files? domain logic, infra config, migrations, auth — high risk vs UI tweak — low risk.
-3. **Test delta**: are new tests in the diff? coverage % up or down?
-4. **Reference module**: open 1 existing similar module to compare conventions.
-
-### Gate
-- [ ] PR scope is single-purpose (or split requested)
-- [ ] Risk level identified (low / medium / high)
-- [ ] Test delta noted
-
----
-
-## Phase 3: REVIEW — 5 dimensions
-
-Severity definitions: `~/.claude/architecture/_shared/severity-levels.md` (code severity table).
-
-### 3.1 Architecture (CRITICAL / HIGH)
-
-For DDD-aware code, check against architecture doc:
-- Domain has zero framework imports
-- No cross-domain imports
-- Business logic in usecases, not handlers / stores
-- Ports in `ports/` dir (not inline interfaces)
-- Entities raise events on state changes
-- Listeners use background context, not request context
-
-**For deep DDD audit:** call `/review-architect` instead and link result.
-
-### 3.2 Security (CRITICAL / HIGH)
-
-- Input validation at trust boundary (handler / DTO)
-- AuthN + AuthZ checked before sensitive ops
-- No secrets / tokens in code or logs
-- SQL via parameterized queries / ORM — no string concatenation
-- File paths / shell commands sanitized
-- Rate limiting + idempotency on state-mutating endpoints
-- Crypto: standard library, no roll-your-own
-
-### 3.3 Performance (HIGH / MEDIUM)
-
-- No N+1 queries (eager-load relations the handler uses)
-- Indexes match new query patterns (check `EXPLAIN`)
-- Pagination on list endpoints (cursor preferred)
-- Background work for slow operations (don't block request)
-- Caching where appropriate, invalidation thought through
-- Synchronous external API calls have timeouts
-
-### 3.4 Testing (HIGH / MEDIUM)
-
-- New business logic has unit tests (usecases, entities, value objects)
-- New endpoints have at least 1 integration test (happy + error)
-- Tests assert on behavior, not implementation
-- Tests don't depend on order, time, or env
-- Coverage didn't drop for touched files
-
-### 3.5 Code quality (MEDIUM / LOW)
-
-- Names reveal intent (no `data`, `info`, `manager`, `helper`)
-- Functions do one thing
-- No dead branches or commented-out code
-- DRY only where the duplication is real (not coincidental)
-- Errors handled at boundary, not swallowed mid-flow
-
----
-
-## Phase 4: FEEDBACK
-
-**Goal:** turn findings into actionable comments at the right place.
-
-### Decision (pick one)
-
-| Decision | When |
-|----------|------|
-| **APPROVE** | 0 CRITICAL / HIGH; LOW only |
-| **REQUEST CHANGES** | Any CRITICAL or HIGH; or multiple MEDIUM in same area |
-| **COMMENT** | Only style / nit comments; or asking questions before final review |
-
-### Inline comment format
-
-Be specific. File + line + rationale + suggested fix:
-
-```
-file: internal/wallet/usecases/withdraw.go:42
-severity: HIGH
-issue: Business logic in handler — `if wallet.Balance < amount` should live in
-the Withdraw usecase, not here. The handler should just call usecase and
-return the error.
-suggest:
-  // handler
-  result, err := s.WithdrawUsecase.Execute(ctx, req)
-
-  // usecase
-  func (u *WithdrawUsecase) Execute(ctx, req) (Result, error) {
-      if !wallet.HasSufficientBalance(amount) { return ErrInsufficient }
-      // ...
-  }
-```
-
-### Summary comment (top of PR)
-
-```markdown
-## Review Summary
-**Decision:** REQUEST CHANGES
-
-**Must fix (HIGH):**
-- [ ] `withdraw.go:42` — business logic moved out of handler
-- [ ] `withdraw.go:88` — missing input validation on `amount`
-
-**Should fix (MEDIUM):**
-- [ ] `withdraw_test.go` — only happy path tested, add insufficient-balance case
-- [ ] `wallet_store.go:120` — N+1 query loading transactions
-
-**Nits (LOW):**
-- [ ] `helper.go:5` — rename `helper` to something specific
-
-**What looked great:**
-- Clean port interface, good test naming, clear PR description.
-```
-
-### Gate
-- [ ] Decision matches severity rules
-- [ ] Every HIGH+ has file:line + suggested fix
-- [ ] Summary lists must-fix vs should-fix vs nits
-- [ ] Acknowledged what's good (not just criticism)
-
----
-
-## Phase 5: POST
-
-```bash
-# Inline comments (one per finding)
-gh pr review $PR --request-changes --body "$(cat summary.md)"
-# or
-gh pr review $PR --approve --body "LGTM, see one nit"
-# or
-gh pr review $PR --comment --body "Questions before final review"
-
-# Optional: label
-gh pr edit $PR --add-label "needs-changes"
-```
-
-### Gate
-- [ ] Review posted to GitHub
-- [ ] Author has clear next-step list
-
----
-
-## Hard Rules
-
-- **Don't review red CI** — ask author to fix tests / lint first
-- **Don't bikeshed style** when the team has a linter — let the tool flag it
-- **Always include "what went well"** — pure-criticism reviews demoralize
-- **One severity per finding** — don't grade-inflate to push for a fix
-- **File:line for every HIGH+** — author shouldn't have to grep for what you mean
-
----
-
-## Related Skills
-
-| When | Use |
-|------|-----|
-| Reviewing own branch before push | `/review-branch` |
-| Only checking DDD architecture | `/review-architect` |
-| Fixing comments on your own PR | `/fix-pr-comment` |
-| Bug surfaced by review | `/fix-hotfix` |
-
-## Recommended Agents
-
-| Phase | Agent | Purpose |
-|-------|-------|---------|
-| ANALYZE | `@clean-architect` | Architecture context |
-| REVIEW 3.1 | `@clean-architect` | Architecture compliance |
-| REVIEW 3.2 | `@security-audit` | Security findings |
-| REVIEW 3.3 | `@perf-optimizer` | N+1, indexes, slow paths |
-| REVIEW 3.4 | `@test-writer` | Coverage + test quality |
-| REVIEW 3.5 | `@code-reviewer` | Naming + quality |

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

@@ -1,245 +0,0 @@
----
-name: review-tdd
-description: Test-Driven Development workflow. Use when doing TDD, writing tests first, or when user says "tdd", "test first", "test driven", "red green refactor".
----
-
-# Test-Driven Development (TDD) Workflow
-
-Red-Green-Refactor cycle: write failing test → write minimal code to pass → refactor while green.
-
-## When to use this skill
-
-- ✅ Logic with clear input → output behavior (parsers, validators, business rules, usecases)
-- ✅ Fixing a bug — failing test first, then fix (regression guard)
-- ✅ Refactoring critical code where you need a safety net
-- ❌ UI prototyping / visual tweaks → manual is faster
-- ❌ Exploratory spike → use `/research-spike` (throwaway, no tests)
-- ❌ One-line config change → just change it
-
-## Read Architecture First
-
-Detect stack via `~/.claude/architecture/_shared/stack-detection.md`. Architecture doc tells you:
-- Test file location convention (`_test.go` next to source, `__tests__/`, `tests/Feature/`, etc.)
-- Test framework (Go `testing`, Jest, Pest, `flutter_test`)
-- Mocking pattern for ports
-- AAA layout convention
-
----
-
-## The TDD Cycle
-
-```
-       ┌──────┐    ┌───────┐    ┌──────────┐
-   ┌──▶│ RED  │───▶│ GREEN │───▶│ REFACTOR │──┐
-   │   └──────┘    └───────┘    └──────────┘  │
-   │   (fail)      (minimal)    (cleanup)     │
-   └──────────────────────────────────────────┘
-              next requirement
-```
-
----
-
-## Phase 1: RED — failing test
-
-**Goal:** describe wanted behavior with a test that fails because the code doesn't exist yet.
-
-### Steps
-1. Pick ONE small requirement (smallest verifiable behavior)
-2. Name the test as a sentence describing behavior
-3. Arrange: inputs + mocks
-4. Act: call the method
-5. Assert: verify output / state / interaction
-6. Run — it MUST fail (compile error or assertion fail). If it passes, the test is wrong.
-
-### Test naming
-- `should_<behavior>_when_<condition>` (snake_case for Go / Python)
-- `it("returns X when Y", ...)` (Jest / Mocha)
-- `test_<behavior>_<condition>` (PHPUnit / Pest)
-
-### AAA pattern
-```
-// Arrange — set up inputs and mocks
-// Act     — call function under test
-// Assert  — verify result / state / interactions
-```
-
-### Gate
-- [ ] Test fails for the RIGHT reason (not a typo / missing import)
-- [ ] Name describes behavior, not implementation
-- [ ] One behavior per test
-
----
-
-## Phase 2: GREEN — minimal code to pass
-
-**Goal:** smallest amount of code to pass. **Resist** "doing it properly" — refactor is next.
-
-### Rules
-- **Minimal** means: hardcode return values if the test allows it; triangulate with more tests
-- Don't add code not required by a test
-- Don't add error handling unless a test requires it
-- Don't generalize until 3+ tests force it
-
-### Steps
-1. Confirm RED
-2. Write just enough code to pass
-3. Run all tests — all must stay green
-4. If others broke, you're not minimal — revert + try smaller
-
-### Gate
-- [ ] New test passes
-- [ ] All previous tests still pass
-- [ ] No untested behavior added
-
----
-
-## Phase 3: REFACTOR — clean up while green
-
-**Goal:** improve structure without changing behavior. Tests stay green throughout.
-
-### What to refactor
-- **Duplication** — extract function / method / class
-- **Long methods** — split when one does multiple things
-- **Bad names** — rename to reveal intent (the most underrated refactor)
-- **Dead branches** — remove code no test exercises
-- **Coupling** — break dependencies that make tests painful
-
-### Rules
-- **Run tests after every change** — green is your safety net
-- **One refactor at a time** — extract method, run tests, rename, run tests, …
-- **No new behavior** — if a refactor needs a new test, go back to RED
-
-### When NOT to refactor
-- Tests are flaky → fix flakiness first
-- Under time pressure → skip, leave a `// TODO: refactor` linked to a follow-up
-- Code about to be deleted → don't polish trash
-
-### Gate
-- [ ] All tests still green
-- [ ] No new public API added
-- [ ] Code easier to read than before
-
----
-
-## Test patterns per layer (DDD)
-
-| Layer | Test type | Dependencies | Example |
-|-------|-----------|--------------|---------|
-| Value Object | Unit (pure) | None | `Money.add()` |
-| Entity | Unit (pure) | None | `Order.cancel()` raises event |
-| UseCase | Unit | Mock ports | `CreateOrder` calls `OrderStore.save()` |
-| Service | Unit | Mock usecase | Delegates correctly |
-| Handler / Controller | Integration | Real router, mock service | `POST /orders` returns 201 |
-| Infrastructure | Integration | Real DB / testcontainers | `OrderRepository.save()` persists |
-| Listener | Unit | Mock infra | `on_order_created` sends email |
-| API contract (cross-service) | Contract test | Real / sandboxed external | OpenAPI / Pact / Wiremock |
-
-### Mock vs real — decision table
-
-| Dependency type | Use real | Use stub / fake | Use mock |
-|-----------------|----------|-----------------|----------|
-| Value objects, entities (pure) | ✅ always | — | never (brittle) |
-| Stdlib (time, fs, env) | mostly — use clock / fs abstraction in domain | for determinism | rarely |
-| Repository / port | testcontainers in infra tests | in-memory fake for usecase tests | only when verifying call args |
-| External HTTP API | sandbox URL in integration | wiremock / msw for predictable cases | for failure-mode tests |
-| Auth / session | real in integration | fake user in unit | rarely |
-| Time | clock abstraction | fixed clock in tests | rarely |
-
-**Stub vs fake vs mock:**
-- **Stub** — returns canned values (`returnsBalance(100)`)
-- **Fake** — working in-memory implementation (`InMemoryOrderStore`)
-- **Mock** — records calls + verifies them (`expect(store.save).toHaveBeenCalledWith(...)`)
-
-Prefer **fake** for repository tests (closest to real behavior). Use **mock** only when call args are the assertion.
-
-### Property-based testing
-
-For pure logic with many edge cases (parsers, math, encoders), use property-based tests:
-
-- Go: `testing/quick`, `gopter`
-- TS / JS: `fast-check`
-- Python: `hypothesis`
-- Dart: `glados`
-
-Pattern: "for all valid input X, property P holds." Generates 100s of cases including edge cases you wouldn't think of.
-
-Example (TS, fast-check):
-```ts
-test("reverse twice = identity", () => {
-  fc.assert(fc.property(fc.array(fc.string()), (arr) => {
-    expect(reverse(reverse(arr))).toEqual(arr);
-  }));
-});
-```
-
-Use it for: serializers, parsers, math, sorting, encoding/decoding. Not for: business workflows.
-
----
-
-## Common Mistakes
-
-| Mistake | Why it's bad | Fix |
-|---------|--------------|-----|
-| Writing tests AFTER the code | Tests what's written, not what's needed | Always RED first |
-| Testing implementation, not behavior | Refactor breaks tests | Assert outputs / observable state |
-| One test, many behaviors | Failure message unclear | One behavior per test |
-| Mocking value objects | Brittle, no benefit | Use real — they're pure |
-| Skipping REFACTOR | Tech debt accumulates | It's a phase, not optional |
-| Test depends on order | Flaky | Each test sets up its own state |
-| Slow tests (>1s each) | People stop running them | Move to integration tier; keep unit <100ms |
-| 100% coverage chase | Forces tests for trivial code | Aim for high-value coverage on domain |
-
----
-
-## Final Report
-
-```markdown
-## TDD Cycle Complete: {feature}
-
-### Cycles
-| # | RED (behavior) | GREEN (code added) | REFACTOR |
-|---|----------------|--------------------|----------|
-| 1 | rejects negative amount | guard in constructor | extracted validator |
-| 2 | transitions PENDING → ACTIVE | added transition method | — |
-
-### Test Coverage
-- {N} tests, all passing
-- Domain coverage: {%} (target ≥80%)
-
-### Files
-- Tests: {paths}
-- Code:  {paths}
-```
-
----
-
-## Hard Rules
-
-- **RED first, always** — no production code without a failing test driving it
-- **Minimal GREEN** — hardcode if test allows; triangulate later
-- **REFACTOR is a phase, not optional**
-- **All tests green at all times** (except briefly during RED)
-- **One behavior per test**, named after the behavior
-- **Unit tests <100ms each** — slow tests don't get run
-- **Test behavior, not implementation** — refactor must not break tests
-
----
-
-## Related Skills
-
-| When | Use |
-|------|-----|
-| Building feature from scratch (with TDD inside) | `/feature-new` + this skill |
-| Adding regression test for a bug | `/fix-hotfix` or `/fix-root-cause` → then this skill |
-| Refactoring untested legacy code | `/feature-refactor` (add tests first) |
-| Reviewing test quality on a PR | `/review-pr` |
-
-## Recommended Agents
-
-| Phase | Agent | Purpose |
-|-------|-------|---------|
-| RED | `@test-writer` | Failing tests first |
-| GREEN | Stack-specific dev agent | Minimal implementation |
-| REFACTOR | `@refactor` | Patterns + cleanup |
-| REFACTOR | `@code-reviewer` | Review refactored code |
-| REFACTOR | `@perf-optimizer` | Perf tweaks (only with benchmarks) |