SKILL.md
---
name: code-review
description: Perform a deep, full review of a codebase, module, or pull request. Use this skill when the user says "review all my code", "full code review", "audit my codebase", "review this PR", "revue de code complète", "check the whole project", or wants a thorough quality assessment beyond a quick pre-commit check.
---
# Code Review (Full)
A deep review of an entire codebase/module/PR. Broader than `self-review` (fast pre-commit pass): this one assesses architecture and systemic quality, not just the current diff.
## Scope first
Ask or infer: whole repo, one module, or a diff/PR? Then size it up:
```bash
git log --oneline -20 # recent history
git diff main...HEAD --stat # PR scope
```
For a whole repo, review in this order: config → data layer → business logic → API → UI → tests. Prioritize files by risk (auth, payments, data mutations) and churn (most-edited files).
## Review dimensions
### 1. Architecture & structure
- Clear layering (UI ↔ logic ↔ data), or is business logic scattered in components/route handlers?
- Duplication: same logic implemented 3 times (grep for repeated patterns) → extract.
- Coupling: does changing one thing force edits in five files? Circular imports?
- Consistency: one way to do each thing (one fetch pattern, one error pattern, one form pattern), not four.
- File size/complexity: files > ~400 lines or functions > ~50 lines usually hide multiple responsibilities.
### 2. Correctness & robustness
- Error handling: every `await` in a path that can fail is handled; no empty `catch {}`; no swallowed errors.
- Edge cases: null/undefined, empty collections, concurrent updates, partial failures.
- Type safety: `any`, `as` casts, `@ts-ignore`, non-null `!` assertions — each is a potential runtime crash. Are types inferred from a single source of truth?
- Async correctness: sequential awaits that should be `Promise.all`, missing cleanup/abort, race conditions.
### 3. Security (delegate the deep pass to `security-review`)
Flag the obvious: unvalidated input, missing authorization, secrets in code, raw SQL, `dangerouslySetInnerHTML`.
### 4. Performance (deep pass: `performance-audit`)
N+1 queries, missing pagination, unnecessary re-renders, heavy work on the main thread, unbounded loops over remote data.
### 5. Maintainability
- Naming: does the name say what it does? Any lies (`getUser` that also writes)?
- Dead code, unused exports/deps, commented-out blocks, leftover `console.log`, stale TODOs.
- Comments explain WHY where non-obvious; no comments narrating the obvious.
- Tests: do critical paths have coverage? Are tests meaningful or tautological?
### 6. Project hygiene
Scripts work (`dev`/`build`/`lint`/`typecheck`/`test`), `.env.example` complete, README accurate, CI gates real, dependencies current and not duplicated.
## Verify, don't guess
Run the objective checks before opining:
```bash
npm run typecheck && npm run lint && npm run test && npm run build
npm audit --production
```
Report actual output — a review that misses a failing build is worthless.
## Output format
1. **Verdict**: healthy / needs work / at risk, in one paragraph.
2. **Top 5 issues** — the highest-leverage fixes, each with file:line, impact, and concrete fix.
3. **Full findings** grouped by severity: 🔴 must fix / 🟡 should fix / 🟢 nit, and by dimension.
4. **Strengths** — what's genuinely good (so the user keeps doing it).
5. **Action plan** — ordered, realistic: quick wins first, then structural work.
Then offer to apply the fixes; when fixing, do it in small verified batches (typecheck/test between batches), not one giant unreviewable rewrite.
## Rules
- Every claim must be grounded in a file you actually read — cite file:line, no generic advice.
- Distinguish "wrong" from "not my preference"; don't impose style the repo hasn't chosen.
- Don't rewrite working code for elegance alone — justify each change by risk, bug, or cost.