code-review-and-quality

Follow a five-step process: understand the change context, review tests first, walk the implementation across five axes, categorize findings by severity, and verify the author's testing story. Approve only when the change improves overall code health.

A review checklist should cover correctness (edge cases, error paths), readability (naming, simplicity), architecture (patterns, coupling), security (input validation, secrets), and performance (N+1 queries, pagination). It should end with a verification step confirming tests and builds pass.

Target around 100 lines changed for a change reviewable in one sitting; 300 lines is acceptable for a single logical change. Around 1000 lines is too large and should be split using stacking, file-group, horizontal, or vertical splitting strategies.

Use Critical for merge-blocking issues like security vulnerabilities, no prefix for required changes, Nit for minor optional style points, Optional or Consider for suggestions, and FYI for informational context. This prevents authors from treating all feedback as mandatory.

Push back with technical reasoning when a suggestion breaks product boundaries, duplicates existing shared components, adds unused abstraction, or conflicts with the active plan or project rules. Verify each suggestion against the codebase before implementing anything.