code-review-and-quality

Code Review and Quality

This is a process skill, not a line-by-line checklist — see code-reviewer for the mechanical category scan and security-review for the security-priority walkthrough. This skill governs the surrounding decisions: how big should this change be, how should feedback be labeled, when do you approve versus block, and how do disagreements get resolved. It is grounded in Google's public Code Review Developer Guide and Engineering Practices documentation, adapted to be model-agnostic.

The approval standard

Approve a change when it definitely improves overall code health, even if it isn't perfect. Perfect code doesn't exist. Don't block a change because it isn't exactly how you'd have written it — if it improves the codebase and follows project conventions, approve it. This standard exists specifically to stop reviews from becoming a venue for imposing personal style.

Change sizing — decide before reviewing content

~100 lines changed   → Good, reviewable in one sitting
~300 lines changed   → Acceptable if it is a single logical change
~1000 lines changed  → Too large — ask the author to split it

Watch the file's total size too, not just the diff: a change that pushes an already-large file past roughly 1000 total lines is a signal to extract helpers or modules first, then add the new logic — decompose, then add, not the reverse.

What counts as "one change": a self-contained modification addressing one thing, with its own tests, that leaves the system working. Refactoring and feature work in the same diff is two changes — split them (small renames can stay at reviewer discretion).

Splitting strategies: