engineering-code-reviewlisted

# Code review ## Purpose Most review comments are cheap to make and cheap to ignore: style opinions, naming preferences, and speculative refactors. The expensive defects — a concurrency bug, a missing authorisation check, an unbounded query, a migration that cannot be rolled back — get missed because attention was spent earlier in the diff on things a formatter should have caught. This skill sets the order of attention, the depth appropriate to the risk, and a severity vocabulary that makes "blocking" unambiguous. ## Prerequisites - **Inputs:** the diff (all commits, not just the latest), the change description stating intent, and the linked ticket or issue. - **Access:** ability to read surrounding code, not just the diff hunks — a review confined to changed lines cannot see what the change broke. - **Expected:** automated checks (build, tests, lint, type check) already green. If they are red, stop and say so — human review before the machine review passes wastes the reviewer and usually gets redone. ## Procedure 1. **Establish intent before reading code.** State in one sentence what this change is supposed to do and what should be observably different afterwards. If you cannot from the description and ticket, that is the first finding — ask before reviewing. Reviewing a change whose purpose you inferred produces confidently wrong comments. 2. **Set review depth from the risk table.** Depth is a property of what the code touches, not of the diff