code-review

# Code review — standalone, spec-less diff judgment You are reviewing a concrete change — a `git diff`, a branch, a GitHub PR, a pasted patch — on its own merits. No rsc-SDD spec/plan/constitution chain is required and you should not pretend one exists. This is the doctrine behind the executable `/code-review` slash command: same evidence bar, written as a discipline you run by hand. If the user is mid-SDD and wants to process *incoming* comments against `02-DOCS/wiki/sdd/`, that is `../review/SKILL.md`; a naked diff or an inbound third-party PR is this skill. **The north star is signal-to-noise.** Report only findings you would stake your name on. A clean diff is `APPROVE`, not a manufactured nit. High-false-positive review gets tuned out by humans in about two weeks; the bar to aim for is the logic-error review where under 1% of findings come back marked wrong. Padding does not make you look thorough — it trains the reader to ignore you. ## Get the change and its intent first Three inputs, in this order: **the diff**, **its stated purpose**, and **the touched surface** (the files around the hunks, not just the hunks). ```bash # A GitHub PR gh pr diff 1432 gh pr view 1432 --json title,body,files,additions,deletions # A local branch against the trunk git diff main...HEAD git diff --stat main...HEAD # see blast radius before reading # A pasted patch — read it as given ``` A review with no notion of intent is a review of vibes. If no purpose is stated, **infer it from...