On my team most pull requests are written with Claude Code, and a lot of them touch 40 to 70 files. If you start at the top of GitHub's file list and scroll, you run out of attention around the middle, and the middle is often where the logic is.
This is the order I work in now. Most of it needs no tool at all. I'll say where I use Hyperpowers, which I built, and where it doesn't help.
1. Before the diff, write down what was asked
Find the request behind the pull request: the issue, the description, or the prompt the author gave the agent. A pasted prompt is a perfectly good description.
Then write two short things:
- What the pull request does, in one or two sentences.
- What a correct version has to do. For an export feature that might be "only people who can see a report can export it" and "large reports don't time out".
The second one matters most. A diff can't show what the code should have done and didn't, so you bring that with you.
Where Hyperpowers helps: the start page gives a short summary and the flow in numbered steps. I treat it as a first draft of my two sentences. The "what correct looks like" list still comes from me.
2. Sort the files before you open any
Look at the file list for five minutes without reading code. Put each file in a rough pile:
- data: migrations, schemas, models
- logic: services, jobs, helpers
- edges: routes, API handlers, CLI commands
- interface: components, templates, styles
- tests
- noise: lockfiles, generated clients and types, snapshots, pure renames and formatting
On our 70-file pull requests, a good part of the list is usually noise. Mark it so you can skip it later. Give a lockfile one look to see which packages moved.
Where Hyperpowers helps: it puts each file in an area for you (database, backend, frontend, tests, setup, docs or other) and leaves generated files out of Claude's review. The area is a guess from the path that the model then corrects, so glance at it.
3. Decide which part you're on the hook for
On a full-stack change, two people can split the review. If you're the backend person, read the backend fully and say you didn't review the page components. That beats two people each skimming all 70 files.
Where Hyperpowers helps: pick one area on the start page and the review keeps to it.
4. Read in the order the code runs
Start with the data, then the logic that uses it, then the edges that call the logic, then the interface, with tests next to the code they test. By the time you reach the component, you already know what the API returns, and you can review the component for its own job.
Read in your editor if you can. Go-to-definition and find-references matter, because some bugs sit in lines the pull request didn't touch, like a caller that now passes the wrong thing.
Where Hyperpowers helps: this is the main thing it does. It takes you through one change at a time in that order, with the diff open in the editor and a note on what changed and why.
5. For every change, ask why it's there
Agents add things nobody asked for, like a renamed helper or a timeout that went from 30 seconds to 10. Each needs a reason that traces back to the request. If there isn't one, ask for it to be reverted or moved to its own pull request.
Where Hyperpowers helps: if the code was written with Claude Code on the machine that created the walkthrough, the why next to each change comes from the request in that session. That makes a change nobody asked for easier to spot. Without sessions, the why is the model's reading of the diff, which is less useful for this step.
6. Look for what isn't there
The bugs that are hardest to catch in review have no lines. Go back to your "what correct looks like" list and check each item. Then ask the questions a diff never prompts:
- What happens when the network call fails, or the input is empty?
- Does every new endpoint check permissions?
- Does the migration handle existing rows?
- Is there a test for the case this change exists to fix, and does it fail if you break the code?
Where Hyperpowers doesn't help much: this step is still mostly you. Review with Claude can draft findings, and it sometimes catches a missing check, but it can also miss one or flag something that's fine. It doesn't run your tests or type checker, so run those yourself.
7. Check the bot comments yourself
Read existing AI review comments as suggestions to check. When two disagree, pick one and say why. When another agent resolved a thread, look at the fix yourself.
8. Split it across sittings
A 70-file review usually doesn't fit in one sitting. Stop at a natural boundary, such as the end of the data layer, and write down where you stopped. If new commits land in between, review only what changed.
Where Hyperpowers helps: it keeps your place per pull request. When new commits come in, Update explains only the changed files and keeps your comments.
9. Finish honestly
When you submit, write two or three sentences at the top:
- what you think the change does, in your own words
- which comments block the merge
- what you didn't review
That last line is the one people skip. "I didn't review the generated client or the snapshot updates" tells the next person exactly where to look.
Where Hyperpowers helps: Finish the review shows how much you read, such as "You read 4 of 11 changes", and lists the files you haven't opened. It never blocks you from submitting. Nothing posts to GitHub until you press Submit review.
What this costs
More time than a skim. I don't have a clean number, but reading in run order with a reason next to each change is less tiring than scrolling, so I get further before I need a break.
The Claude part runs on your own Claude Code plan. On a small sample pull request, explaining took about a minute and $0.21, and Review with Claude on all of it took 43 seconds and $0.37. A 70-file pull request will cost more than that.
You can do all of this by hand. The shorter version of this method is in how to review a pull request that AI wrote, and tracing AI-written code back to the prompt explains where the why in step 5 comes from.
If you want to try it with Hyperpowers on an example pull request, open it in your browser with nothing to install, or install the extension for your own pull requests.
Common questions
What order should I read a large pull request in?
The order the code runs: data first, then the logic that uses it, then the edges that call the logic, then the interface, with tests next to the code they test. By the time you reach a component, you know what the API returns.
Which files in a big pull request can I skip?
Lockfiles, generated clients and types, snapshots, and pure renames and formatting. Give a lockfile one look to see which packages moved, and say in your review what you skipped.
How do I review a pull request that is too big for one sitting?
Stop at a natural boundary, such as the end of the data layer, and write down where you stopped. If new commits land in between, review only what changed.