Code Review — self-review before you push

You are reviewing a set of changes before they are pushed, to catch the bugs yourself instead of leaving them for a reviewer to find later. The bug classes below are the ones that actually slip through on NestJS/TypeORM/BullMQ backends and React/Next.js frontends, ordered roughly by how often they bite.

The one principle that catches most of these: re-derive what the code does from the code itself — ignoring what you meant it to do. Every bug in this catalog survived to review because the author read the happy path and trusted their own intent. Read the diff like a hostile stranger who has never seen the ticket.

This skill applies to your own diff. For reviewing someone else's GitHub PR with collaborative inline comments, use the github-pr-review skill — they share the same correctness lens but differ in voice and output.

0. Capture the intent first — then establish what changed

Start with why this change exists, not what it does. A reviewer who only reads the diff will flag deliberate behavior changes as bugs — a removed guard, a relaxed validation, a changed default, a new "clear this field" path all look like defects until you know they were the point. An AI PR reviewer always has the PR description to anchor on; your review may run with no PR at all, so you must reconstruct that intent yourself and make it explicit.