To review a large GitHub pull request in VS Code, install the free Hyperpowers extension, paste the pull request's link into Create Walkthrough, and press Start the review. Your own Claude Code explains the pull request first, the review takes you through each change in the order the code runs, and your comments go to GitHub as one review when you press Submit review.
GitHub's Files changed tab lists diffs alphabetically. That works for five files and breaks down at fifty. Here's how to do the review in VS Code with Hyperpowers. To see it before installing anything, try it in your browser on an example pull request. It needs a desktop browser.
What do you need?
- VS Code, or an editor built on it, such as Cursor, Windsurf or Antigravity.
- Claude Code, to create a walkthrough. The extension uses your own Claude Code to read and explain the pull request. You don't need the hyperpowers plugin.
- A GitHub repository, to post your review. Reading works with any git repository. Submitting comments as a review needs GitHub.
Someone who only reads a walkthrough you send them needs just the extension.
How do you install the extension?
You install it from a .vsix file:
- Download it from the install section of the home page.
- In VS Code, open Extensions, click the ... menu and choose Install from VSIX.
- Pick the downloaded file.
The same section has a one-line terminal command that downloads the file and runs code --install-extension. In Cursor, use cursor instead of code.
After that it keeps itself up to date. Each time VS Code starts, it asks hyperpowers.dev whether a newer version is out, and shows an update button when there is one. The download is checked against its published checksum before it is installed. Turn the check off with the hyperpowers.walkthrough.checkForUpdates setting.
How do you create a walkthrough from a pull request?
- Open the repository in VS Code.
- Click the Hyperpowers icon in the left bar.
- At the top of Code Reviews, click + (Create Walkthrough).
- Paste the pull request's link, or type its number.
The extension fetches the pull request with git and asks your Claude Code to explain it. A small pull request takes about a minute and a big one a few, with progress as it goes. The walkthrough is saved in your checkout, where git ignores it. Nothing is posted to the pull request.
If you made the change yourself with Claude Code on this machine, the extension also reads those sessions, so the why for each change comes from what you asked. Passwords and keys are removed first. Turn this off with the hyperpowers.walkthrough.useClaudeSessions setting. Tracing AI-written code back to the prompt that asked for it has the details.
If the extension can't find claude, set hyperpowers.walkthrough.claudePath to its full path. By default it looks it up through your login shell.
How does it handle a pull request too big for one call?
A small change is explained in one call. A bigger one is split into parts of up to eight files, about 20,000 characters of diff and 40 changed blocks each, and the parts run six at a time. A file whose diff is too long for one part is cut into slices where its changed blocks begin and end, so the biggest files are read too.
By default the parts run on claude-sonnet-5 at low effort, and a final call on claude-opus-5 writes the summary and the flow from the parts' notes. The hyperpowers.walkthrough.explainModel setting picks one model for every call instead. A part that fails twice is left out and named, so you know which files have no notes. Finished parts are kept on disk, so running it again asks only for what is missing.
How do you split a large pull request into areas?
Each changed file is put in an area: frontend, backend, database, setup, tests, docs or other. Areas show where the weight of the change is and let you review one part at a time. If you are the frontend reviewer on a full-stack change, you can read the frontend and leave the migration to someone else.
On the start page, above Start the review, pick All files or one area, such as Frontend 2. The review then keeps to that area.
Which languages does it understand?
The explanation works on any language Claude can read. The area is a first guess from the file's path, then the model that explains the change corrects it where the code says otherwise.
The path guess knows, for example:
- test files by folder (
tests/,__tests__/,e2e/,fixtures/) and by name, such as*.test.ts,test_*.py,*_test.go,*_test.rbandFooTest.java, - lockfiles and project files for npm, Yarn, pnpm, Bun, Cargo, Go, Bundler, Composer, Poetry, uv, Pipenv, Gradle and Maven, which go in setup,
- migrations,
.sqland Prisma schema files, which go in database, .tsx,.jsx,.vue,.svelte,.astro, stylesheets and templates as frontend, and.py,.go,.rb,.java,.rs,.php,.cs,.ex,.scalaas backend,- folder names such as
web,client,componentsorserver,api,handlers. The outermost one wins, so in a monorepoweb/src/apistill counts as the web app, whilepages/apiandapp/apiin a Next.js app count as backend.
A file the guess can't place goes in other until the model says where it belongs.
What order should you read the files in?
Read in the order the code runs: database first, then backend, then frontend, then tests. Inside an area, read a file after the files it uses. You meet each piece of data before the code that depends on it, so by the time you reach a component you already know what the API returns.
The review uses that order. Setup and docs go last, or first when the change is mostly setup. The start page also shows how the change flows, in numbered steps, before you read any code.
How do you read one change at a time?
The review opens in the right side bar, and the first change opens in the editor as a diff. It shows one change at a time, such as Change 3 of 11, with its area, what changed in two or three points, and why. Next change and Previous move through them, or press → and ←.
In the editor, each changed section carries a note above it with which change it is, what it does, and ‹ Prev, Next › and Comment. Click a note to move the review there.
Files in This Change, on the left, lists the files under their folders with what each one is for. A file shows A or M until you have read it, then a tick. Click a file to open it on its own, and Back to change 3 returns you to where you were.
If a change is unclear, type a question under it in Ask Claude about this change. Claude reads the change and answers in a few sentences. The notes are written by a model reading the diff, and they say so. Check them against the code.
How do you get a second opinion from Claude?
Press Review with Claude and pick This file, This area, Files I haven't read yet or All. Claude reads the files one area at a time, up to three areas at once, while you keep reading. Each finding is marked worth asking, worth knowing or holds up, with the lines it is about, Claude's reason, and a comment draft written as a question or suggestion to the author. Press Add as comment, Edit or Skip. Nothing is posted until you submit.
Generated files stay in the walkthrough but are left out of this review: lockfiles, minified or bundled output, snapshots, and files under dist, build, .next, out and generated.
How do you comment as you read?
Hover a changed line in the editor and click the + in the margin, or click Comment in the note above a change. Comments wait in Your Comments, where you can click one to go to its line, edit it or delete it. You can write a comment early and remove it later if another file answers your question.
Can you finish without reading everything?
Yes. Your place is kept per pull request. Reopen it and the start page offers Continue the review. A file counts as read once the review has passed its last change, or when you press Mark as seen.
Finish the review is at the bottom of the review all the time. It opens a check before anything is sent: how much you read, such as "You read 4 of 11 changes", the files not read yet, your comments, and any Claude findings you haven't decided on. Submit review asks Comment, Approve or Request changes, takes an optional summary, and posts your comments to GitHub as one review. The first time, VS Code asks you to sign in to GitHub. A comment on a line outside the diff goes in the review's body, with its file and line.
What happens when the author pushes new commits?
The review checks the pull request for new commits when you open it, and every 10 minutes while it is open and VS Code has focus. The check is a git fetch from your own remote. When there are new commits, a thin line at the top says so, such as "3 new commits · 4 files changed · Update", and files you had read that changed are marked ● in Files in This Change.
Update explains only the files the new commits changed, with the earlier notes as context. Files that didn't change keep their notes and their tick, and you stay on the change you were reading. Your comments stay too. One whose code changed is marked "The code under this comment changed", with Move to put it on the right line and Delete.
What does it cost?
The extension is free. Explaining and reviewing run on your own Claude Code, the same as any other session: on a subscription they count against your plan, and with an API key they are billed per token.
As an example, on a small sample pull request, explaining took about a minute and cost $0.21, and Review with Claude on all four areas took 43 seconds and cost $0.37, and the frontend area alone took 26 seconds and cost $0.11, with Claude Code's default model at the time. Your numbers depend on the size of the diff, how many areas you review and the model. How much does it cost to review a pull request with Claude? goes into it.
Where does your code go?
The diff, the notes and, when they are on, the parts of your Claude Code sessions that matter go to your own Claude Code, with passwords and keys removed from the session text first. Claude Code sends them to Anthropic, as it does in any session. See Anthropic's privacy policy and commercial terms for how that data is handled.
The extension also makes the GitHub requests your actions cause, git fetches from your own remote, and an update check to hyperpowers.dev. There is no Hyperpowers server in between, and it never runs code from the repository.
How do you send a walkthrough to someone else?
Click … on a walkthrough and choose Export walkthrough. You get one .walkthrough file with the explanation, the changed code and any screenshots. The person you send it to installs the extension, clicks Load Walkthrough File, and picks the file. They don't need the repository or Claude Code to read it.
Try it
Open the browser version to step through an example pull request. When you're ready to use it on your own pull requests, install the extension and follow Your first review. For a method that doesn't depend on any tool, see How to review a large pull request.
Common questions
Is the extension on the VS Code Marketplace?
No. You install it from a .vsix file, downloaded from hyperpowers.dev. Once installed, it checks for updates itself.
Does it post comments to GitHub on its own?
No. Your comments stay in VS Code until you press Submit review.
Can I review just the database migration?
Yes. Pick the database area on the start page, and the review shows only the files in it.
What if my editor has no right side bar?
In VS Code versions before 1.106, the review opens in the bottom panel. The setting hyperpowers.player.location lets you pick the side bar or the panel yourself.
Does the person I send a walkthrough to need Claude Code?
No. Reading a walkthrough needs only the extension. Creating one needs Claude Code.