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 with a severity such as Critical, Nit, or Optional so the author knows what must be addressed.

A code review checklist should cover correctness against the spec, edge case and error handling, test adequacy, naming and readability, architectural fit, security checks like input validation and secret handling, and performance concerns such as N+1 queries and missing pagination.

A pull request around 100 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 dependent changes, grouping by file, or slicing horizontally or vertically.

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.

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