Checks

Code review checklist

Five steps I run on every pull request, plus extra checks for ones an AI agent wrote. Short enough to keep open during a real review.

Read the story

Before any code. If you cannot say what this change is for, the diff will not tell you.

I read the ticket and the PR description, not just the title.
I can say in one sentence what problem this solves and for whom.
The size of the PR matches the size of the problem.
Anything unclear goes back to the author now, before I spend time on the code.

Map the blast radius

Work out what this change can break, including the parts it never touches.

I looked at the list of changed files and know which areas they sit in.
If a shared component, helper or type changed, I checked who else uses it.
Public APIs, schemas, routes, config and environment variables are either untouched or deliberately changed.
I know how this ships, and how to turn it off or roll it back.

Check behavior before code

Run it first. A green CI badge tells you the tests passed, not that the feature works.

I ran the branch or the preview and did the thing the PR claims to do.
I tried an empty state, an error, and one input the author probably did not.
For UI changes: keyboard only, a narrow screen, and light and dark.
CI is green on the latest commit, and I read what it ran.

Review only the core

Every diff has a small part that carries the logic. Spend your attention there.

I found the few files or functions where the real decisions are made.
I skimmed renames, lockfiles, snapshots and generated files instead of reading them line by line.
In the core, I checked conditions, error paths, data ownership and naming.
I left style nits to the formatter and the linter.

Write comments that get acted on

A review only helps if the author knows what to do next.

Each comment makes one point and says what, why, and what I would do instead.
I marked what blocks the merge and what is optional.
Real questions are written as questions, and requests are written as requests.
I said what is good, specifically, at least once.

Extra checks when an AI agent wrote the PR

Agent-written code reads clean and sounds sure of itself. These are the four ways it tends to go wrong anyway.

Every import, helper, API and package in the diff exists. Check the lockfile and the installed version, not just the call site.
The tests check what the ticket asked for. When the same agent writes the code and the tests, both can share one misunderstanding, so break the code on purpose and see if a test fails.
I looked for what is not in the diff: error handling, accessibility, migrations, docs, and old code that should have been removed.
Nothing was added that nobody asked for: extra abstractions, options, files, or a rewrite around the actual fix.

Your sign-off is your accountability

When you approve a PR, your name is on it next to the author's. It does not matter whether a person or an agent typed the code. If it breaks production, "the AI wrote it" is not an answer, and neither is "CI was green". Approve only what you would be willing to explain.

If you review with Claude Code, angular-engineer is the review skill I use alongside this list.

Inspired by the review workflow in this video and the checklist idea at codenbird.com. The wording here is my own.

1Read the story

2Map the blast radius

3Check behavior before code

4Review only the core

5Write comments that get acted on