# Skill: Code Review

This skill provides a systematic checklist and standards for reviewing code.

## Review Order

Always review in this order — from broad to specific:

1. **Architecture** — does the overall structure make sense? Are responsibilities well-separated?
2. **Correctness** — does the code do what it claims? Are edge cases handled?
3. **Security** — are there injection risks, exposed secrets, missing auth checks, or unsafe operations?
4. **Performance** — are there obvious bottlenecks, N+1 queries, blocking calls in async code, or unnecessary re-computation?
5. **Readability** — are names clear? Is logic obvious? Are comments present where needed?
6. **Tests** — are tests present? Do they cover the important cases?

## Checklist Per File

When reviewing a single file, check:

- [ ] Functions have a single, clear responsibility
- [ ] Error cases are handled (not just the happy path)
- [ ] No hardcoded secrets, credentials, or environment-specific paths
- [ ] Async operations are awaited; promises are not silently dropped
- [ ] Input validation is present for untrusted data
- [ ] No commented-out dead code left in
- [ ] Variable and function names accurately describe their purpose
- [ ] No obvious performance issue (large loops, redundant I/O, etc.)

## Severity Levels

Use these labels when reporting issues:

| Level | Meaning |
|-------|---------|
| `CRITICAL` | Must fix before shipping — security issue or data loss risk |
| `HIGH` | Likely bug or serious design flaw |
| `MEDIUM` | Correctness concern or maintainability issue |
| `LOW` | Style, naming, or minor improvement suggestion |
| `NIT` | Tiny stylistic preference — optional |

## Output Format

Structure your code review report as:

```
## Summary
Brief overall assessment (2–3 sentences).

## Issues

### CRITICAL
- [file.js:42] Description of the critical issue and why it matters

### HIGH
- [file.js:88] Description...

### MEDIUM / LOW / NIT
- ...

## Positive Observations
What the code does well — this is not optional.

## Recommendations
3–5 concrete, prioritised next steps.
```

## Rules

- Always include "Positive Observations" — finding only problems is incomplete feedback
- Cite file path and line number for every issue
- Explain *why* something is a problem, not just *what* is wrong
- Do not rewrite the code in your review — describe the issue and suggest an approach