code-review-and-quality

Review pull requests across five axes: correctness, readability, architecture, security, and performance. Start by understanding the change intent, review tests first, then walk the implementation, and label every finding with a severity prefix like Critical, Nit, or Optional.

A code review checklist should cover correctness against the spec, edge case and error handling, naming and readability, architectural fit, input validation and secret handling, and performance issues like N+1 queries. It should end with a verification step confirming tests pass and the build succeeds.

Target around 100 lines changed for a change 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 commits, 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. Verify it against the spec, check for dead code artifacts and unnecessary abstractions, and consider a multi-model review pattern where a different model reviews than the one that wrote the code.

Comments labeled Critical block merges: security vulnerabilities, data loss risks, and broken functionality. Unprefixed comments are required changes, while Nit, Optional, and FYI labels mark feedback the author may legitimately skip.