code-review
code-review
State the problem the code solves in one sentence before reviewing anything. If you cannot, ask — a review of code whose purpose you have guessed at is worse than no review.
Then pick one lens and read only that file. They are different methods, not different vocabularies for the same method; running two produces findings that contradict each other on priority.
| The question in front of you | Lens | Read |
|---|---|---|
| Should this exist at all? Is it at the right layer? Does the diff/package/dependency earn its maintenance cost? Asked to "audit", "polish", or "refactor" something | Russ Cox | RUSS-COX.md |
| Will it behave as advertised? Can it panic, silently truncate, or cost more than it looks? Are the defaults and error contracts honest? Reviewing a library API or a patch that changes complexity | BurntSushi | BURNTSUSHI.md |
| Is this being held to the right standard? Should the dumb version ship, or does this need to stay stable for years? Reviewing a public interface, a breaking change, or product code that looks over-engineered | Mitsuhiko | MITSUHIKO.md |
Default to Russ Cox for an unqualified "review this diff." Reach for the others when the code is a library boundary (BurntSushi) or when the product/library call is itself in question (Mitsuhiko).
In an established codebase, search for existing primitives before judging anything new — under any lens, the most common real finding is that a helper, interface, or package already does this.
Not this skill: writing the commit or PR message (use write-docs), gauging complexity against value before you edit (use complexity-budget), or reviewing for what a newcomer would not understand (use newcomer-lens-review).