code-reviewlisted

# Code Review Review as one reviewer, in one pass. No sub-agents. The goal is not to list everything that could be better. It is to find the things that will actually hurt, prove them, and say them plainly. Five verified findings beat fifty plausible ones — a reviewer who cries wolf gets ignored, and an ignored reviewer catches nothing. ## Pin the diff ```bash git log <base>..HEAD --oneline # what's under review git diff <base>...HEAD # three dots: compare against the merge-base ``` `<base>` is whatever the user named, or the merge-base with the tracking branch (usually `main`) — say which you picked. For uncommitted work use `git diff` / `git diff --staged`. For a PR, use `gh pr view <n> --json title,body,files` and `gh pr checkout <n>`. Then read the intent — the PR body, commit messages, and any issue they reference (`gh issue view`). And read the repo's rules: `CONTRIBUTING.md`, `CLAUDE.md`, `AGENTS.md`, `.cursor/rules/`, lint and formatter config. **A documented repo standard beats anything in this skill.** Anything the linter, formatter, or type-checker already reports is off the table — CI says it sooner and better. Do **not** read existing review comments on the PR yet. That comes at the end, and reading them now costs you every finding only fresh eyes get. ## What to look at, in order **Design first.** Does this change belong here at all? Is it in the right layer, the right module, the right package? Does it integrate with what already exists