code-review

When this skill is invoked:

1. **Read the target file(s)** in full.

2. **Read the CLAUDE.md** for project coding standards.

3. **Identify the system category** (api, service, repository, component, utility, infrastructure)
   and apply category-specific standards.

4. **Evaluate against coding standards**:
   - [ ] Public methods and classes have doc comments
   - [ ] Cyclomatic complexity under 10 per method
   - [ ] No method exceeds 40 lines (excluding data declarations)
   - [ ] Dependencies are injected (no singletons for business state)
   - [ ] Configuration values loaded from external config, not hardcoded
   - [ ] Systems expose interfaces (not concrete class dependencies)

5. **Check architectural compliance**:
   - [ ] Correct dependency direction (infrastructure ← domain ← application)
   - [ ] No circular dependencies between modules
   - [ ] Proper layer separation (UI does not own business logic)
   - [ ] Events/messages used for cross-service communication
   - [ ] Consistent with established patterns in the codebase
   - [ ] Interfaces are earning their complexity: prefer deep modules over thin pass-through wrappers
   - [ ] Suspected abstractions survive the deletion test: deleting them would reintroduce complexity across callers, not simplify the system

6. **Check SOLID compliance**:
   - [ ] Single Responsibility: Each class has one reason to change
   - [ ] Open/Closed: Extendable without modification
   - [ ] Liskov Substitution: Subtypes substitutable for base types
   - [ ] Interface Segregation: No fat interfaces
   - [ ] Dependency Inversion: Depends on abstractions, not concretions

7. **Check for common web/software issues**:
   - [ ] No N+1 query patterns (use eager loading or joins)
   - [ ] Proper async/await usage (no unhandled promises, no floating async)
   - [ ] Input validation at system boundaries (user input, external APIs)
   - [ ] Proper error handling with meaningful, safe messages (no stack traces exposed)
   - [ ] No secrets or sensitive data hardcoded (API keys, passwords, tokens)
   - [ ] Resource cleanup (DB connections, streams, subscriptions, event listeners)
   - [ ] Thread/concurrency safety where required

8. **Output the review** in this format:

```
## Code Review: [File/System Name]

### Standards Compliance: [X/6 passing]
[List failures with line references]

### Architecture: [CLEAN / MINOR ISSUES / VIOLATIONS FOUND]
[List specific architectural concerns]

### SOLID: [COMPLIANT / ISSUES FOUND]
[List specific violations]

### Web/Software Concerns
[List web and software-specific issues found]

### Positive Observations
[What is done well — always include this section]

### Required Changes
[Must-fix items before approval]

### Suggestions
[Nice-to-have improvements]

### Verdict: [APPROVED / APPROVED WITH SUGGESTIONS / CHANGES REQUIRED]
```

## Protocol

Architecture vocabulary to use when it helps clarify a finding:

- **Module** — unit with an interface and implementation
- **Deep module** — small interface, high leverage behind it
- **Shallow module** — interface nearly as complex as implementation
- **Deletion test** — if deleting a wrapper mostly removes indirection instead of
  reintroducing complexity in callers, the abstraction may be shallow

Use this vocabulary to sharpen architectural findings, not to force jargon into
every review.

- **Question**: Auto-starts from argument (file or directory path); no clarification needed
- **Options**: Skip — single review path
- **Decision**: Skip — verdict is advisory
- **Draft**: Full review shown in conversation only
- **Approval**: Skip — read-only; no files written

## Output

Deliver exactly:

- **Risk Tier** (Low / Medium / High) with one-sentence justification
- **Standards & Architecture compliance** score (X/6, X/5)
- **Blocking issues** — must fix before merge (or "None")
- **Suggestions** — optional improvements, max 3
- **Verdict**: `APPROVED` / `APPROVED WITH SUGGESTIONS` / `CHANGES REQUIRED`