code-review

# code-review ## When to use Use this skill when: - Reviewing a PR (own or someone else's) - Self-reviewing local changes before creating a PR - Responding to review feedback on your PR - The user asks to "review", "check", or "look at" code changes ## Procedure: Review code ### Mindset - **Be thorough but pragmatic** — catch real bugs, not style nitpicks tools handle. - **Understand intent first** — read PR description, linked ticket, commit messages before code. - **Check the full picture** — a service change may require test / migration / doc changes. - **Assume good intent** — suggest improvements, don't criticize. ### Review order 1. **Understand the goal** — what is this change trying to achieve? 2. **Detect the change-type + depth** — route to the right checklist, pick review depth (below). 3. **Architecture** — approach sound? Right layer? Right pattern? 4. **Correctness** — does it work? Edge cases? Error handling? 5. **Quality** — types, naming, readability, DRY, SOLID? 6. **Security** — input validation, authorization, injection? 7. **Performance** — N+1 queries, missing indexes, unbounded queries? 8. **Tests** — are new paths covered? Are existing tests still valid? 9. **Conventions** — does it follow project standards? ## Change-type routing — load only the checklist the diff needs Per-domain checklists live in `checklists/`, loaded **on demand** — a review carries only the depth the change needs (progressive disclosure; a dependency bump does not pay fo...