moicle 1.7.0 → 2.1.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/README.md +76 -27
- package/assets/architecture/_shared/severity-levels.md +34 -0
- package/assets/architecture/_shared/stack-detection.md +34 -0
- package/assets/commands/marketing.md +7 -7
- package/assets/skills/docs/sync/SKILL.md +245 -0
- package/assets/skills/docs/write/SKILL.md +274 -0
- package/assets/skills/feature/api/SKILL.md +277 -0
- package/assets/skills/feature/deprecate/SKILL.md +276 -0
- package/assets/skills/feature/new/SKILL.md +273 -0
- package/assets/skills/feature/refactor/SKILL.md +269 -0
- package/assets/skills/fix/hotfix/SKILL.md +233 -0
- package/assets/skills/fix/incident/SKILL.md +360 -0
- package/assets/skills/fix/pr-comment/SKILL.md +186 -0
- package/assets/skills/fix/root-cause/SKILL.md +276 -0
- package/assets/skills/marketing/content/SKILL.md +269 -0
- package/assets/skills/marketing/logo/SKILL.md +252 -0
- package/assets/skills/marketing/seo-blog/SKILL.md +367 -0
- package/assets/skills/marketing/video/SKILL.md +258 -0
- package/assets/skills/research/onboarding/SKILL.md +225 -0
- package/assets/skills/research/spike/SKILL.md +228 -0
- package/assets/skills/research/web/SKILL.md +204 -0
- package/assets/skills/review/architect/SKILL.md +274 -0
- package/assets/skills/review/branch/SKILL.md +277 -0
- package/assets/skills/review/pr/SKILL.md +231 -0
- package/assets/skills/review/tdd/SKILL.md +245 -0
- package/dist/commands/list.d.ts.map +1 -1
- package/dist/commands/list.js +2 -2
- package/dist/commands/list.js.map +1 -1
- package/dist/utils/symlink.d.ts +7 -0
- package/dist/utils/symlink.d.ts.map +1 -1
- package/dist/utils/symlink.js +82 -0
- package/dist/utils/symlink.js.map +1 -1
- package/package.json +1 -1
- package/assets/skills/api-integration/SKILL.md +0 -883
- package/assets/skills/architect-review/SKILL.md +0 -393
- package/assets/skills/content-writer/SKILL.md +0 -721
- package/assets/skills/deep-debug/SKILL.md +0 -114
- package/assets/skills/deprecation/SKILL.md +0 -923
- package/assets/skills/documentation/SKILL.md +0 -1333
- package/assets/skills/fix-pr-comment/SKILL.md +0 -283
- package/assets/skills/hotfix/SKILL.md +0 -397
- package/assets/skills/incident-response/SKILL.md +0 -946
- package/assets/skills/logo-design/SKILL.md +0 -477
- package/assets/skills/new-feature/SKILL.md +0 -297
- package/assets/skills/onboarding/SKILL.md +0 -607
- package/assets/skills/pr-review/SKILL.md +0 -620
- package/assets/skills/refactor/SKILL.md +0 -338
- package/assets/skills/research/SKILL.md +0 -124
- package/assets/skills/review-changes/SKILL.md +0 -312
- package/assets/skills/spike/SKILL.md +0 -535
- package/assets/skills/sync-docs/SKILL.md +0 -575
- package/assets/skills/tdd/SKILL.md +0 -828
- package/assets/skills/video-content/SKILL.md +0 -651
|
@@ -0,0 +1,277 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-branch
|
|
3
|
+
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".
|
|
4
|
+
args: "[BASE_BRANCH]"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Review Local Branch Changes
|
|
8
|
+
|
|
9
|
+
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.
|
|
10
|
+
|
|
11
|
+
**ARGUMENTS:** (optional) base branch. Default: `main` (fallback to `master`).
|
|
12
|
+
|
|
13
|
+
## When to use this skill
|
|
14
|
+
|
|
15
|
+
- ✅ Before pushing your branch / opening a PR
|
|
16
|
+
- ✅ Before asking a teammate to review (catch easy issues first)
|
|
17
|
+
- ✅ Quick sanity check on a feature you've been working on
|
|
18
|
+
- ❌ Reviewing someone else's PR → use `/review:pr`
|
|
19
|
+
- ❌ Only checking DDD architecture → use `/review:architect`
|
|
20
|
+
- ❌ Security-only sweep → use `@security-audit` agent
|
|
21
|
+
|
|
22
|
+
## Read Architecture First
|
|
23
|
+
|
|
24
|
+
Detect stack via `~/.claude/architecture/_shared/stack-detection.md`. Load `ddd-architecture.md` + the stack doc — extract forbidden imports + conventions before reviewing.
|
|
25
|
+
|
|
26
|
+
Severity definitions: `~/.claude/architecture/_shared/severity-levels.md` (code severity table).
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## Workflow
|
|
31
|
+
|
|
32
|
+
```
|
|
33
|
+
0 DETECT → 1 COLLECT → 2 BUILD+LINT → 3 ARCH → 4 CONVENTIONS → 5 QUALITY → 6 TESTS → 7 REPORT → 8 FIX
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
---
|
|
37
|
+
|
|
38
|
+
## Phase 0: DETECT
|
|
39
|
+
|
|
40
|
+
- [ ] Stack detected (ask user if ambiguous, e.g., monorepo)
|
|
41
|
+
- [ ] Architecture doc loaded
|
|
42
|
+
- [ ] Forbidden-imports list extracted
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
## Phase 1: COLLECT
|
|
47
|
+
|
|
48
|
+
```bash
|
|
49
|
+
BASE=${1:-main}
|
|
50
|
+
git rev-parse --verify "$BASE" >/dev/null 2>&1 || BASE=master
|
|
51
|
+
|
|
52
|
+
git log "$BASE"..HEAD --oneline
|
|
53
|
+
git diff "$BASE"...HEAD --stat
|
|
54
|
+
git diff "$BASE"...HEAD --name-only --diff-filter=ACMR
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
Categorize changed files by layer:
|
|
58
|
+
|
|
59
|
+
| Layer | Typical paths |
|
|
60
|
+
|-------|---------------|
|
|
61
|
+
| Domain | `domain/`, `internal/domain/`, `src/domain/`, `lib/domain/` |
|
|
62
|
+
| Application | `application/`, `internal/application/`, `src/application/` |
|
|
63
|
+
| Infrastructure | `infrastructure/`, `internal/infrastructure/`, `src/infrastructure/` |
|
|
64
|
+
| Presentation / UI | `controllers/`, `pages/`, `components/`, `views/`, `ports/http/` |
|
|
65
|
+
| Persistence | `models/`, `entities/` (ORM), `prisma/`, `migrations/` |
|
|
66
|
+
| Config / Bootstrap | `config/`, `bootstrap/`, `cmd/`, `main.*` |
|
|
67
|
+
|
|
68
|
+
Read **all** changed files before reviewing — never skim.
|
|
69
|
+
|
|
70
|
+
---
|
|
71
|
+
|
|
72
|
+
## Phase 2: BUILD + LINT
|
|
73
|
+
|
|
74
|
+
Run the stack's build + typecheck + lint commands. If any fail → mark **CRITICAL** and stop further review until they pass.
|
|
75
|
+
|
|
76
|
+
```bash
|
|
77
|
+
# Go: go build ./... && go vet ./...
|
|
78
|
+
# NestJS: pnpm typecheck && pnpm lint
|
|
79
|
+
# Laravel: composer dump-autoload && ./vendor/bin/phpstan analyse
|
|
80
|
+
# Flutter: dart analyze
|
|
81
|
+
# React/Remix: pnpm typecheck && pnpm lint
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## Phase 3: ARCHITECTURE (changed files only)
|
|
87
|
+
|
|
88
|
+
Apply the stack's rules. Common checks per layer:
|
|
89
|
+
|
|
90
|
+
### 3.1 Domain (if changed)
|
|
91
|
+
| # | Rule |
|
|
92
|
+
|---|------|
|
|
93
|
+
| D1 | Domain purity — no forbidden imports (ORM, HTTP, cache, queue, auth SDK) |
|
|
94
|
+
| D2 | No cross-domain imports (only shared kernel allowed) |
|
|
95
|
+
| D3 | No persistence-model imports in domain |
|
|
96
|
+
| D4 | Entities have behavior (not anemic data bags) |
|
|
97
|
+
| D5 | Entities raise events on state change (if architecture uses events) |
|
|
98
|
+
| D6 | Ports in `ports/` dir (not inline in usecases) |
|
|
99
|
+
| D7 | One port per file |
|
|
100
|
+
| D8 | Ports return domain types, not primitives |
|
|
101
|
+
| D9 | Value objects stdlib-only |
|
|
102
|
+
| D10 | Usecases have no infra imports |
|
|
103
|
+
|
|
104
|
+
Quick check:
|
|
105
|
+
```bash
|
|
106
|
+
CHANGED_DOMAIN=$(git diff "$BASE"...HEAD --name-only --diff-filter=ACMR \
|
|
107
|
+
| grep -E '^(src|internal|lib)/domain/')
|
|
108
|
+
[ -n "$CHANGED_DOMAIN" ] && echo "$CHANGED_DOMAIN" \
|
|
109
|
+
| xargs grep -lEn '<STACK_FORBIDDEN_REGEX>' 2>/dev/null \
|
|
110
|
+
&& echo FAIL || echo PASS
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
### 3.2 Application (if changed)
|
|
114
|
+
| # | Rule |
|
|
115
|
+
|---|------|
|
|
116
|
+
| A1 | Handler is thin (parse → service → respond, no business logic) |
|
|
117
|
+
| A2 | Service justified only when ≥2 usecases orchestrated |
|
|
118
|
+
| A3 | Listener is side-effect only (no business logic) |
|
|
119
|
+
| A4 | Listener registered in event bus |
|
|
120
|
+
| A5 | Event name string matches registry |
|
|
121
|
+
| A6 | DTOs validated at boundary |
|
|
122
|
+
| A7 | Composition root only — no inline wiring in handlers |
|
|
123
|
+
|
|
124
|
+
### 3.3 Infrastructure (if changed)
|
|
125
|
+
| # | Rule |
|
|
126
|
+
|---|------|
|
|
127
|
+
| I1 | Repository has no business logic |
|
|
128
|
+
| I2 | Mappers exist (domain ↔ ORM model) |
|
|
129
|
+
| I3 | Implements port interface (returns domain types) |
|
|
130
|
+
| I4 | Context / transaction propagation correct |
|
|
131
|
+
|
|
132
|
+
### 3.4 Persistence models (if changed)
|
|
133
|
+
| # | Rule |
|
|
134
|
+
|---|------|
|
|
135
|
+
| M1 | ORM models in infrastructure, NOT domain |
|
|
136
|
+
| M2 | Schema change → matching migration |
|
|
137
|
+
| M3 | Nullable columns use nullable types |
|
|
138
|
+
|
|
139
|
+
---
|
|
140
|
+
|
|
141
|
+
## Phase 4: CONVENTIONS (cross-stack)
|
|
142
|
+
|
|
143
|
+
| # | Rule |
|
|
144
|
+
|---|------|
|
|
145
|
+
| G1 | No swallowed errors (no empty catch / `if err != nil {}`) |
|
|
146
|
+
| G2 | Async work uses background context, NOT request context |
|
|
147
|
+
| G3 | API-facing types have serialization tags (`json:`, decorators, etc.) |
|
|
148
|
+
| G4 | No hardcoded secrets / tokens / keys |
|
|
149
|
+
| G5 | Parameterized queries only — no string-interpolated SQL |
|
|
150
|
+
| G6 | Input validation at boundary before reaching domain |
|
|
151
|
+
|
|
152
|
+
Plus any stack-specific Hard Rules from the architecture doc.
|
|
153
|
+
|
|
154
|
+
---
|
|
155
|
+
|
|
156
|
+
## Phase 5: QUALITY (manual)
|
|
157
|
+
|
|
158
|
+
Read the diff. Look for:
|
|
159
|
+
|
|
160
|
+
| # | Area | What to look for |
|
|
161
|
+
|---|------|------------------|
|
|
162
|
+
| Q1 | Logic correctness | Off-by-one, nil deref, wrong condition, missed edge case |
|
|
163
|
+
| Q2 | Error handling | Errors propagated/wrapped, not silently ignored |
|
|
164
|
+
| Q3 | Concurrency | Race conditions, shared mutable state, async leaks |
|
|
165
|
+
| Q4 | Resource leaks | Unclosed connections, HTTP bodies, file handles |
|
|
166
|
+
| Q5 | Naming | Reveals intent (no `data`, `info`, `manager`, `helper`) |
|
|
167
|
+
| Q6 | Dead code | Unreachable, unused, commented-out |
|
|
168
|
+
| Q7 | Duplication | Real duplication across changed files (not coincidental) |
|
|
169
|
+
| Q8 | Breaking change | API contract change, removed field, behavior change |
|
|
170
|
+
| Q9 | Over-engineering | Abstraction not justified by the change |
|
|
171
|
+
| Q10 | Test coverage | New logic has tests; bug fixes have regression tests |
|
|
172
|
+
|
|
173
|
+
---
|
|
174
|
+
|
|
175
|
+
## Phase 6: TESTS
|
|
176
|
+
|
|
177
|
+
```bash
|
|
178
|
+
# Tests for changed domains only
|
|
179
|
+
CHANGED_DOMAINS=$(git diff "$BASE"...HEAD --name-only --diff-filter=ACMR \
|
|
180
|
+
| grep -E '/(domain|modules|features)/' \
|
|
181
|
+
| sed -E 's|.*(domain\|modules\|features)/([^/]+)/.*|\2|' | sort -u)
|
|
182
|
+
|
|
183
|
+
for d in $CHANGED_DOMAINS; do
|
|
184
|
+
# Go: go test ./internal/domain/$d/... -v
|
|
185
|
+
# NestJS: npx jest src/domain/$d
|
|
186
|
+
# Laravel: ./vendor/bin/phpunit --filter $d
|
|
187
|
+
# Flutter: flutter test test/domain/$d
|
|
188
|
+
echo "Test $d"
|
|
189
|
+
done
|
|
190
|
+
|
|
191
|
+
# Full suite
|
|
192
|
+
{full_test_command}
|
|
193
|
+
```
|
|
194
|
+
|
|
195
|
+
---
|
|
196
|
+
|
|
197
|
+
## Phase 7: REPORT
|
|
198
|
+
|
|
199
|
+
```markdown
|
|
200
|
+
## Code Review: {branch} → {base}
|
|
201
|
+
|
|
202
|
+
**Stack:** {stack} · **Commits:** {N} · **Files:** {N} (+{add} / -{del})
|
|
203
|
+
|
|
204
|
+
### Build / Lint / Types
|
|
205
|
+
| Check | Status |
|
|
206
|
+
|-------|--------|
|
|
207
|
+
| Build | PASS/FAIL |
|
|
208
|
+
| Lint | PASS/FAIL |
|
|
209
|
+
| Types | PASS/FAIL |
|
|
210
|
+
|
|
211
|
+
### Architecture / Conventions / Quality
|
|
212
|
+
| # | Rule | Status | File:line |
|
|
213
|
+
|---|------|--------|-----------|
|
|
214
|
+
| D1 | Domain purity | PASS | — |
|
|
215
|
+
| G4 | No secrets | FAIL | `config/db.ts:42` hardcoded token |
|
|
216
|
+
| Q1 | Logic correctness | OK | — |
|
|
217
|
+
|
|
218
|
+
### Tests
|
|
219
|
+
| Check | Status |
|
|
220
|
+
|-------|--------|
|
|
221
|
+
| Changed area tests | PASS/FAIL |
|
|
222
|
+
| Full suite | PASS/FAIL |
|
|
223
|
+
|
|
224
|
+
### Issues (sorted by severity)
|
|
225
|
+
| # | Severity | File:line | Issue | Suggested fix |
|
|
226
|
+
|---|----------|-----------|-------|---------------|
|
|
227
|
+
| 1 | CRITICAL | config/db.ts:42 | hardcoded token | move to env |
|
|
228
|
+
| 2 | HIGH | handlers/user.ts:88 | business logic in handler | extract to usecase |
|
|
229
|
+
|
|
230
|
+
### Verdict
|
|
231
|
+
{APPROVED / CHANGES REQUESTED}
|
|
232
|
+
```
|
|
233
|
+
|
|
234
|
+
### Verdict rules
|
|
235
|
+
- **CRITICAL or HIGH found** → CHANGES REQUESTED
|
|
236
|
+
- **MEDIUM only** → CHANGES REQUESTED (should fix)
|
|
237
|
+
- **LOW only or nothing** → APPROVED (with suggestions if any)
|
|
238
|
+
|
|
239
|
+
---
|
|
240
|
+
|
|
241
|
+
## Phase 8: FIX (if user confirms)
|
|
242
|
+
|
|
243
|
+
1. Fix in order: CRITICAL → HIGH → MEDIUM → LOW
|
|
244
|
+
2. Re-run build + lint + tests after each batch
|
|
245
|
+
3. Re-run full review when all fixed
|
|
246
|
+
4. Report final status
|
|
247
|
+
|
|
248
|
+
---
|
|
249
|
+
|
|
250
|
+
## Hard Rules
|
|
251
|
+
|
|
252
|
+
- **Changed files only** — don't expand scope to drive-by reviews
|
|
253
|
+
- **Stop on CRITICAL** — fix build / lint / type errors before everything else
|
|
254
|
+
- **File:line for every issue** — no vague "somewhere in handlers"
|
|
255
|
+
- **Match severity honestly** — don't grade-inflate
|
|
256
|
+
- **Test changed areas** — don't only rely on global test run
|
|
257
|
+
|
|
258
|
+
---
|
|
259
|
+
|
|
260
|
+
## Related Skills
|
|
261
|
+
|
|
262
|
+
| When | Use |
|
|
263
|
+
|------|-----|
|
|
264
|
+
| Reviewing teammate's PR | `/review:pr` |
|
|
265
|
+
| Deep DDD audit of a domain | `/review:architect` |
|
|
266
|
+
| Fixing review comments on your PR | `/fix:pr-comment` |
|
|
267
|
+
| Fixing bugs surfaced here | `/fix:hotfix` |
|
|
268
|
+
|
|
269
|
+
## Recommended Agents
|
|
270
|
+
|
|
271
|
+
| Phase | Agent | Purpose |
|
|
272
|
+
|-------|-------|---------|
|
|
273
|
+
| 3 Architecture | `@clean-architect` | DDD compliance |
|
|
274
|
+
| 4 Conventions | `@security-audit` | Vulnerability sweep |
|
|
275
|
+
| 5 Quality | `@code-reviewer` | Code smells |
|
|
276
|
+
| 6 Tests | `@test-writer` | Coverage check |
|
|
277
|
+
| 8 Fix | Stack-specific dev agent | Apply fixes |
|
|
@@ -0,0 +1,231 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-pr
|
|
3
|
+
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".
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Pull Request Review Workflow
|
|
7
|
+
|
|
8
|
+
Review someone else's PR across 5 dimensions and post structured feedback to GitHub.
|
|
9
|
+
|
|
10
|
+
## When to use this skill
|
|
11
|
+
|
|
12
|
+
- ✅ Reviewing someone else's open PR (`gh pr view <number>` accessible)
|
|
13
|
+
- ✅ Need to post structured feedback (APPROVE / REQUEST CHANGES / COMMENT)
|
|
14
|
+
- ✅ Want a multi-dimensional review (architecture + security + perf + tests)
|
|
15
|
+
- ❌ Self-review of own branch before push → use `/review:branch`
|
|
16
|
+
- ❌ Only checking DDD compliance → use `/review:architect`
|
|
17
|
+
- ❌ Addressing comments on your own PR → use `/fix:pr-comment`
|
|
18
|
+
|
|
19
|
+
## Read Architecture First
|
|
20
|
+
|
|
21
|
+
Load `~/.claude/architecture/ddd-architecture.md` + the stack-specific doc. Detect stack via `~/.claude/architecture/_shared/stack-detection.md`.
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## Workflow
|
|
26
|
+
|
|
27
|
+
```
|
|
28
|
+
FETCH → ANALYZE → REVIEW (5 dims) → FEEDBACK → POST
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
## Phase 1: FETCH
|
|
34
|
+
|
|
35
|
+
**Goal:** load PR + diff + context in one pass.
|
|
36
|
+
|
|
37
|
+
```bash
|
|
38
|
+
PR={number}
|
|
39
|
+
gh pr view $PR --json number,title,body,author,state,headRefName,baseRefName,commits,files
|
|
40
|
+
gh pr diff $PR
|
|
41
|
+
gh pr checks $PR
|
|
42
|
+
gh pr view $PR --comments
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
### Gate
|
|
46
|
+
- [ ] PR metadata + diff + CI status loaded
|
|
47
|
+
- [ ] PR description explains "what / why" — if missing, ask author before deep review
|
|
48
|
+
- [ ] CI status known (don't review red builds — ask author to fix first)
|
|
49
|
+
|
|
50
|
+
---
|
|
51
|
+
|
|
52
|
+
## Phase 2: ANALYZE
|
|
53
|
+
|
|
54
|
+
**Goal:** understand scope before going line-by-line.
|
|
55
|
+
|
|
56
|
+
1. **Scope check**: does the diff match the PR title / description? Mixed-scope PRs (e.g., feature + drive-by refactor) → ask author to split.
|
|
57
|
+
2. **Risk profile**: which files? domain logic, infra config, migrations, auth — high risk vs UI tweak — low risk.
|
|
58
|
+
3. **Test delta**: are new tests in the diff? coverage % up or down?
|
|
59
|
+
4. **Reference module**: open 1 existing similar module to compare conventions.
|
|
60
|
+
|
|
61
|
+
### Gate
|
|
62
|
+
- [ ] PR scope is single-purpose (or split requested)
|
|
63
|
+
- [ ] Risk level identified (low / medium / high)
|
|
64
|
+
- [ ] Test delta noted
|
|
65
|
+
|
|
66
|
+
---
|
|
67
|
+
|
|
68
|
+
## Phase 3: REVIEW — 5 dimensions
|
|
69
|
+
|
|
70
|
+
Severity definitions: `~/.claude/architecture/_shared/severity-levels.md` (code severity table).
|
|
71
|
+
|
|
72
|
+
### 3.1 Architecture (CRITICAL / HIGH)
|
|
73
|
+
|
|
74
|
+
For DDD-aware code, check against architecture doc:
|
|
75
|
+
- Domain has zero framework imports
|
|
76
|
+
- No cross-domain imports
|
|
77
|
+
- Business logic in usecases, not handlers / stores
|
|
78
|
+
- Ports in `ports/` dir (not inline interfaces)
|
|
79
|
+
- Entities raise events on state changes
|
|
80
|
+
- Listeners use background context, not request context
|
|
81
|
+
|
|
82
|
+
**For deep DDD audit:** call `/review:architect` instead and link result.
|
|
83
|
+
|
|
84
|
+
### 3.2 Security (CRITICAL / HIGH)
|
|
85
|
+
|
|
86
|
+
- Input validation at trust boundary (handler / DTO)
|
|
87
|
+
- AuthN + AuthZ checked before sensitive ops
|
|
88
|
+
- No secrets / tokens in code or logs
|
|
89
|
+
- SQL via parameterized queries / ORM — no string concatenation
|
|
90
|
+
- File paths / shell commands sanitized
|
|
91
|
+
- Rate limiting + idempotency on state-mutating endpoints
|
|
92
|
+
- Crypto: standard library, no roll-your-own
|
|
93
|
+
|
|
94
|
+
### 3.3 Performance (HIGH / MEDIUM)
|
|
95
|
+
|
|
96
|
+
- No N+1 queries (eager-load relations the handler uses)
|
|
97
|
+
- Indexes match new query patterns (check `EXPLAIN`)
|
|
98
|
+
- Pagination on list endpoints (cursor preferred)
|
|
99
|
+
- Background work for slow operations (don't block request)
|
|
100
|
+
- Caching where appropriate, invalidation thought through
|
|
101
|
+
- Synchronous external API calls have timeouts
|
|
102
|
+
|
|
103
|
+
### 3.4 Testing (HIGH / MEDIUM)
|
|
104
|
+
|
|
105
|
+
- New business logic has unit tests (usecases, entities, value objects)
|
|
106
|
+
- New endpoints have at least 1 integration test (happy + error)
|
|
107
|
+
- Tests assert on behavior, not implementation
|
|
108
|
+
- Tests don't depend on order, time, or env
|
|
109
|
+
- Coverage didn't drop for touched files
|
|
110
|
+
|
|
111
|
+
### 3.5 Code quality (MEDIUM / LOW)
|
|
112
|
+
|
|
113
|
+
- Names reveal intent (no `data`, `info`, `manager`, `helper`)
|
|
114
|
+
- Functions do one thing
|
|
115
|
+
- No dead branches or commented-out code
|
|
116
|
+
- DRY only where the duplication is real (not coincidental)
|
|
117
|
+
- Errors handled at boundary, not swallowed mid-flow
|
|
118
|
+
|
|
119
|
+
---
|
|
120
|
+
|
|
121
|
+
## Phase 4: FEEDBACK
|
|
122
|
+
|
|
123
|
+
**Goal:** turn findings into actionable comments at the right place.
|
|
124
|
+
|
|
125
|
+
### Decision (pick one)
|
|
126
|
+
|
|
127
|
+
| Decision | When |
|
|
128
|
+
|----------|------|
|
|
129
|
+
| **APPROVE** | 0 CRITICAL / HIGH; LOW only |
|
|
130
|
+
| **REQUEST CHANGES** | Any CRITICAL or HIGH; or multiple MEDIUM in same area |
|
|
131
|
+
| **COMMENT** | Only style / nit comments; or asking questions before final review |
|
|
132
|
+
|
|
133
|
+
### Inline comment format
|
|
134
|
+
|
|
135
|
+
Be specific. File + line + rationale + suggested fix:
|
|
136
|
+
|
|
137
|
+
```
|
|
138
|
+
file: internal/wallet/usecases/withdraw.go:42
|
|
139
|
+
severity: HIGH
|
|
140
|
+
issue: Business logic in handler — `if wallet.Balance < amount` should live in
|
|
141
|
+
the Withdraw usecase, not here. The handler should just call usecase and
|
|
142
|
+
return the error.
|
|
143
|
+
suggest:
|
|
144
|
+
// handler
|
|
145
|
+
result, err := s.WithdrawUsecase.Execute(ctx, req)
|
|
146
|
+
|
|
147
|
+
// usecase
|
|
148
|
+
func (u *WithdrawUsecase) Execute(ctx, req) (Result, error) {
|
|
149
|
+
if !wallet.HasSufficientBalance(amount) { return ErrInsufficient }
|
|
150
|
+
// ...
|
|
151
|
+
}
|
|
152
|
+
```
|
|
153
|
+
|
|
154
|
+
### Summary comment (top of PR)
|
|
155
|
+
|
|
156
|
+
```markdown
|
|
157
|
+
## Review Summary
|
|
158
|
+
**Decision:** REQUEST CHANGES
|
|
159
|
+
|
|
160
|
+
**Must fix (HIGH):**
|
|
161
|
+
- [ ] `withdraw.go:42` — business logic moved out of handler
|
|
162
|
+
- [ ] `withdraw.go:88` — missing input validation on `amount`
|
|
163
|
+
|
|
164
|
+
**Should fix (MEDIUM):**
|
|
165
|
+
- [ ] `withdraw_test.go` — only happy path tested, add insufficient-balance case
|
|
166
|
+
- [ ] `wallet_store.go:120` — N+1 query loading transactions
|
|
167
|
+
|
|
168
|
+
**Nits (LOW):**
|
|
169
|
+
- [ ] `helper.go:5` — rename `helper` to something specific
|
|
170
|
+
|
|
171
|
+
**What looked great:**
|
|
172
|
+
- Clean port interface, good test naming, clear PR description.
|
|
173
|
+
```
|
|
174
|
+
|
|
175
|
+
### Gate
|
|
176
|
+
- [ ] Decision matches severity rules
|
|
177
|
+
- [ ] Every HIGH+ has file:line + suggested fix
|
|
178
|
+
- [ ] Summary lists must-fix vs should-fix vs nits
|
|
179
|
+
- [ ] Acknowledged what's good (not just criticism)
|
|
180
|
+
|
|
181
|
+
---
|
|
182
|
+
|
|
183
|
+
## Phase 5: POST
|
|
184
|
+
|
|
185
|
+
```bash
|
|
186
|
+
# Inline comments (one per finding)
|
|
187
|
+
gh pr review $PR --request-changes --body "$(cat summary.md)"
|
|
188
|
+
# or
|
|
189
|
+
gh pr review $PR --approve --body "LGTM, see one nit"
|
|
190
|
+
# or
|
|
191
|
+
gh pr review $PR --comment --body "Questions before final review"
|
|
192
|
+
|
|
193
|
+
# Optional: label
|
|
194
|
+
gh pr edit $PR --add-label "needs-changes"
|
|
195
|
+
```
|
|
196
|
+
|
|
197
|
+
### Gate
|
|
198
|
+
- [ ] Review posted to GitHub
|
|
199
|
+
- [ ] Author has clear next-step list
|
|
200
|
+
|
|
201
|
+
---
|
|
202
|
+
|
|
203
|
+
## Hard Rules
|
|
204
|
+
|
|
205
|
+
- **Don't review red CI** — ask author to fix tests / lint first
|
|
206
|
+
- **Don't bikeshed style** when the team has a linter — let the tool flag it
|
|
207
|
+
- **Always include "what went well"** — pure-criticism reviews demoralize
|
|
208
|
+
- **One severity per finding** — don't grade-inflate to push for a fix
|
|
209
|
+
- **File:line for every HIGH+** — author shouldn't have to grep for what you mean
|
|
210
|
+
|
|
211
|
+
---
|
|
212
|
+
|
|
213
|
+
## Related Skills
|
|
214
|
+
|
|
215
|
+
| When | Use |
|
|
216
|
+
|------|-----|
|
|
217
|
+
| Reviewing own branch before push | `/review:branch` |
|
|
218
|
+
| Only checking DDD architecture | `/review:architect` |
|
|
219
|
+
| Fixing comments on your own PR | `/fix:pr-comment` |
|
|
220
|
+
| Bug surfaced by review | `/fix:hotfix` |
|
|
221
|
+
|
|
222
|
+
## Recommended Agents
|
|
223
|
+
|
|
224
|
+
| Phase | Agent | Purpose |
|
|
225
|
+
|-------|-------|---------|
|
|
226
|
+
| ANALYZE | `@clean-architect` | Architecture context |
|
|
227
|
+
| REVIEW 3.1 | `@clean-architect` | Architecture compliance |
|
|
228
|
+
| REVIEW 3.2 | `@security-audit` | Security findings |
|
|
229
|
+
| REVIEW 3.3 | `@perf-optimizer` | N+1, indexes, slow paths |
|
|
230
|
+
| REVIEW 3.4 | `@test-writer` | Coverage + test quality |
|
|
231
|
+
| REVIEW 3.5 | `@code-reviewer` | Naming + quality |
|