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 so the author knows what blocks merge.

A code review checklist should cover correctness against the spec, edge case and error handling, test coverage, naming and simplicity, architectural fit, input validation and secrets handling, and performance issues like N+1 queries or missing pagination.

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, verifying a green test suite before and after, and reviewing the lockfile diff for unexpected transitive changes.

Request changes when Critical or Required findings exist, such as security vulnerabilities, broken functionality, or missing regression tests. Approve when the change improves overall code health even if imperfect, and never accept deferred cleanup promises.