code-review-and-quality

Follow a five-step process: understand the change's intent, review the tests first, walk the implementation across five axes (correctness, readability, architecture, security, performance), 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, test coverage), readability (naming, simplicity), architecture (patterns, coupling, abstraction level), security (input validation, secrets, injection), and performance (N+1 queries, unbounded operations, pagination), plus a verification section confirming tests and builds pass.

Around 100 changed lines is ideal and reviewable in one sitting; 300 lines is acceptable for a single logical change; 1000 lines is too large and should be split. Split oversized changes by stacking, file groups, horizontal layers, or vertical feature slices.

Read the changelog rather than trusting semver, upgrade one dependency per change so failures are attributable, require a green test suite before and after, and review the lockfile diff since a single direct bump can pull in many transitive changes. Never hand-edit the lockfile.

Request changes when Critical issues exist (security vulnerabilities, data loss, broken functionality) or Required findings are unresolved. Approve when the change improves overall code health even if imperfect, and never accept promises to clean up later since deferred cleanup rarely happens.