Agents can open ten PRs before lunch. You still have one brain. The fix is not reading faster; it is deciding where to read. Here is the routine I use.
Look at the shape of the diff against the merge base, not your local main:
BASE=$(git merge-base origin/main HEAD)
git diff --stat $BASE...HEAD
git diff --name-status $BASE...HEAD
# GitHub
gh pr view 123 --json files,additions,deletions,title,body
Then pick a depth and write it down:
| Depth | When |
|---|---|
| Skim | Docs, renames, generated code, tests only |
| Standard | Feature code inside one module, covered by tests |
| Deep | Auth, payments, migrations, public API, config, concurrency |
A 600-line rename is a skim. A 12-line change to a permission check is deep. Size is not risk.
CONCURRENTLY, on a big table.# does any test fail without the change?
git checkout $BASE -- src/ # old code, new tests
npm test
git checkout HEAD -- src/ # restore the PR
If nothing goes red, the tests are decoration. That is one comment, not twenty.
Agents (and people) fix concrete requests. Use a fixed shape:
[blocking] src/auth/session.ts:42
What: token expiry compared in local time
Why: users in UTC+ get logged out early
Do: compare Date.now() against exp * 1000
Label each one blocking, should or nit. Stop at three nits. If the PR needs more than five blocking comments, ask for a smaller PR instead.
Done means: depth matched the risk, the five checks are answered, and every comment is actionable. Not “I read every line.”
If you want to see how these checklists look as an agent skill, there is a free SKILL.md you can drop into Cursor, Claude Code or Codex: free sample skill.
The full routine above – risk triage, security diff review, breaking-change detection, migration safety, test-gap audit and comment writing – is packaged as 6 skills plus a PDF guide in PR Gatekeeper, $17.