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 that tools handle. - **Understand intent first** — read the PR description, linked ticket, and commit messages before looking at code. - **Check the full picture** — a change in a service may require changes in tests, migrations, docs. - **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 and pick the review depth (below). 3. **Architecture** — does the approach make sense? Right layer? Right pattern? 4. **Correctness** — does it actually work? Edge cases? Error handling? 5. **Quality** — types, naming, readability, SOLID? 6. **Redundancy** — see below; a verdict, not a "this looks duplicated". 7. **Propagation** — did a changed concept reach every occurrence? see below. 8. **Security** — input validation, authorization, injection? 9. **Performance** — N+1 queries, missing indexes, unbounded queries? 10. **Tests** — are new paths covered? Are existing tests still valid? 11. **Conventions** — does it follow project standards? ## The redundancy dimension ...