Review the change the way a tech lead does: judge it against what it must deliver and how it fits the system. Line-level correctness sets the floor. The valuable findings come from delivery, architecture, and conceptual integrity.

Run the deterministic gates first, then put judgment where the tools stop.

Steps

Recover intent. State what the change must deliver: the requirement or ticket it serves, or the architectural decision it implements. A review without intent checks correctness against nothing, so name the intent before reading a line.
Run the gates. Run skill-gate --strict at the repo root. Record each failing gate as a finding; a green gate needs no comment. The gates own formatting, lint, types, SAST, SCA, secrets, and tests.
Review through the lenses. Work the change against the review lenses, top-weighted first: delivery, architecture, conceptual integrity, abstraction, then correctness, security, tests, operability. Each lens yields a finding or an explicit pass. A redundant comment is a finding: flag any comment that restates its code or narrates the change's history. A comment earns its place only by stating a complex edge case or an invariant the code cannot express.
Judge the abstraction. Name the abstraction level the change chose and whether it fits the problem. Over-abstraction (a framework for one caller) and under-abstraction (a concept copied four times) are both findings.
Weigh the trade-offs. State what the change traded (complexity, coupling, performance, time) and whether the trade earns the intent. A silent trade-off is itself the finding.
Rank and report. Label each finding blocker, major, or minor, tied to the lens it failed and the intent it endangers. The review is done when every changed file and every lens has a verdict.

See also project-context to keep the project's AGENTS.md, task list, and project brain current.

code-review

Steps