Code Review Patterns

Quick Guide: A review is worth what the author can act on. Start from the diff's purpose and the file the change is about — a design problem there leads the review. Must Fix blocks approval, Should Fix is strongly recommended, Nice to Have is optional, and a finding that earns none of them is not written. Approve once the diff meets its success criteria and leaves the code healthier, even where you would have written it differently; a clean diff gets a short approval, not manufactured findings.

Detailed Resources:

• examples/core.md — worked findings, labelled and unlabelled reviews, scope findings, the verdict's evidence, praise, a complete clean review
• reference.md — inline comment prefixes, and how verdicts map to platform review states

<critical_requirements>

Before writing a review

Read the specification or description, then every changed file in full, before writing a finding. The purpose is the yardstick for every judgement, and a finding written from a partial read is about code you have not seen — the check it calls missing may sit below where you stopped.

Judge the diff against its purpose, not against an ideal codebase. The author can act on what the diff changed; a finding about code it never touched, or a refactor its specification never asked for, is work with nothing to weigh it against.