code-review

When this skill is invoked:

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

1. Read the CLAUDE.md for project coding standards.

1. Identify the system category (api, service, repository, component, utility, infrastructure)

and apply category-specific standards.

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

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

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

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

1. 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