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 finish with an approve or request-changes verdict.

A code review checklist should cover context understanding, correctness against the spec, edge case and error handling, naming and readability, architectural fit, security checks like input validation and secrets, performance issues like N+1 queries, and verification 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 is too large and should be split. Split oversized changes by stacking, file groups, horizontal layers, or vertical feature slices.

AI-generated code needs more scrutiny, not less, because it is confident and plausible even when wrong. Verify it against the spec, check edge cases and error paths, and never rubber-stamp with LGTM without evidence of actual review.

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. Avoid bulk bump PRs that hide which package broke the build.

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.