reviewing-codelisted

# Reviewing Code ## Overview A code review answers two questions: is the implementation correct, and is it consistent with the rest of the codebase. The reviewer's job is to catch what the author could not — the blind spots that come from having written the code yourself. This skill applies two mechanisms for consistency across a team: a checklist, so every category gets checked every time regardless of who reviews, and severity ratings, so the author can distinguish a blocking defect (Blocker: "this cannot merge") from a style preference (Nit: "your call entirely"). It covers the review process, severity calibration, output format, reviewing AI-assisted code, and handling disagreements. ## Process ### Pre-Review Before reading a single line of code, establish context. Reviewing code you do not understand the purpose of is a waste of both your time and the author's. 1. **Check for a plan.** If this work had a plan or design document, invoke `exloom:auditing-plan-fidelity` first. Plan fidelity answers "did the implementation match what was agreed?" Code review answers "is the implementation correct and consistent?" These are different questions. Running fidelity first means you already know whether deviations are intentional when you start reading code. 2. **Read the PR body.** If the PR description is empty, says "fixed the thing," or contains only a ticket number with no explanation, stop. Request a proper description before reviewing code. You cannot review what you