code-review-and-quality

Review a pull request by first understanding its intent, then checking tests, then walking the implementation across five axes: correctness, readability, architecture, security, and performance. Label every finding by severity and verify the author's testing story before approving.

A code review checklist should cover correctness against the spec, edge case and error handling, clear naming, architectural fit, input validation, secrets hygiene, injection risks, N+1 query patterns, and confirmation that tests and builds pass.

A pull request around 100 changed lines is reviewable in one sitting, 300 lines is acceptable for a single logical change, and 1000 lines should be split. Split oversized changes by stacking, file groups, horizontal layers, or vertical feature slices.

Review dependency upgrades by reading the changelog rather than trusting semver, upgrading one dependency per change, requiring a green test suite before and after, and reviewing the lockfile diff for unexpected transitive changes.

Request changes when Critical issues exist, such as security vulnerabilities, data loss, or broken functionality, or when Required findings are unresolved. Approve when the change improves overall code health even if it is not perfect.

AI-generated code needs more scrutiny, not less, because it is confident and plausible even when wrong. Review it across all five axes, verify tests actually test behavior, and never rubber-stamp with an unexamined approval.