Hyperpowers Code Review

Pull requests got too big to read. Hyperpowers guides you through every change, right in VS Code.

Open a pull request and Claude explains it before you read a line: first what it does, then each change in the order the code runs, with what changed and why next to the code. You read it, comment on lines like you do on GitHub, and submit your review. Nothing is posted until you press Submit.

• Review one part. Only need the frontend, the API or the database? Review just that part.
• Review with Claude. One click, or none: turn it on and the review is already there when you open the pull request. A card says whether it looks safe to merge, lists the findings by severity, and has a fix for each one you can apply, suggest on GitHub, or paste into Claude Code. It uses your Claude Code and the model you already use there. You decide what goes on the pull request.
• Ask about a change. Not sure what a change does? Ask Claude right under it.
• The why comes from the request. When the code was written with Claude Code, it reads that session, so each reason comes from what was actually asked.
• Share a walkthrough. Export a review as one file. Anyone opens it in VS Code and reads the same pull request the same way. They don't need Claude Code.

Free. Explaining a pull request uses your own Claude Code. Also works in Cursor, Windsurf, Antigravity and other editors built on VS Code. See it at hyperpowers.dev, or try it in your browser at hyperpowers.dev/try.

What you need

• Claude Code, signed in. The Claude Code extension for VS Code is enough: Hyperpowers uses the claude that comes with it when there is no claude command.
• A git checkout of the repository. Posting a review needs GitHub.

Explaining a pull request sends the diff, the notes and, when you allow it, excerpts of your Claude Code sessions (passwords and keys removed) to your own Claude Code, which sends them to Anthropic. Details: hyperpowers.dev/privacy.

The Hyperpowers icon in the activity bar holds the lists: Code Reviews, Files in This Change, Your Comments, Claude Findings, and Recorded Test Flows when there are recordings. The review itself sits in the right side bar, next to the code.

Create a walkthrough

You need Claude Code installed. The hyperpowers plugin is not needed.

1. Open the repository in VS Code and click the Hyperpowers icon in the left bar.
2. Click + (Create Walkthrough) at the top of Code Reviews, and paste the pull request's link or type its number.
3. It fetches the pull request with git and explains it with your Claude Code, a few minutes for a big one, with progress as it goes. When you built the change yourself with Claude Code, it reads those sessions too, so the explanation gives your own reasons. Passwords and keys in them are removed first.

The walkthrough is saved in your checkout, where git ignores it. Nothing is posted.

With the hyperpowers plugin you can also run /hyperpower:walkthrough explain 12 in Claude Code. Recordings a hyperpower run made of the change play with it, screen by screen.

Merged, closed, delete and regenerate

Code Reviews checks each walkthrough's pull request: after the list shows, when you come back to VS Code (at most every 10 minutes a pull request), and after you submit a review. It asks GitHub with the account you are signed in with, never asking you to sign in, else the gh command, else git (its head inside the base branch means merged). The last known state is kept, so the list shows at once and corrects itself after. When a check cannot reach GitHub, the row keeps its last state and its tooltip says so.

Once any pull request here is merged or closed, the list is grouped: Open (expanded), Merged and Closed (collapsed). Merged and closed rows are greyed, with when, such as "merged · 3 days ago". They still open, to read the walkthrough and Claude's review, with a note that the pull request was merged; reviewing it and posting are off.

On a walkthrough's … menu, or its right-click menu:

• Delete walkthrough deletes the walkthrough and its saved explanation (in .hyperpower/reviews), Claude's review of it, your decisions, your place, and Claude's answers. It asks first and says exactly that; when you have comments you have not submitted, it says they go too. Your code, your branches and anything on GitHub stay as they are.
• Regenerate walkthrough deletes it the same way, then explains the pull request again from scratch, with nothing cached reused.

Delete all merged on the Merged group deletes every merged walkthrough after one confirmation. While a walkthrough is being deleted or regenerated, its row greys out and says so; if it fails, the row comes back and a message says why.

Send it to someone

Click … on a walkthrough and choose Export walkthrough. It saves one .walkthrough file: the explanation, the changed code, and any screenshots. Whoever gets it clicks the folder button (Load Walkthrough File) and picks the file. They need only this extension, not the repository. Help in the same menu shows them how, step by step.

Reading a walkthrough

The start page shows the pull request's title, who wrote it, its branch and when it was explained. Under that: what the pull request does in a few points, then How it works: the event that starts the change (When), how the app behaved before and how it behaves now, and the path the change takes in one to five steps. Each step says where it runs (Browser, Server, Database, Job and so on), the code that acts, and what it changes, with a link that opens the review at that step's first change. A failure path folds under the step it leaves from. A line marked Not in this diff names something the step depends on that the pull request does not show, such as a caller or a migration runner. Checked by names the tests, and Not part of this story lists the changes that are not on the path. Every claim is checked against the diff: a step whose code Claude could not find in the changes it cites is marked inferred. Walkthroughs explained before this show their numbered flow as before.

Start the review says how many changes there are and about how long they take. The review goes in the order of How it works, and its header names the step, such as Step 2 of 4 · Server · PUT /api/settings.

Press it, and the start page closes. The review opens in the right side bar, and the first change opens in the editor, full width, as a diff. The review shows one change at a time: Change 3 of 11, its area, what changed in two or three points, and why. Next change and Previous are at the bottom, or press → and ←. On the last change, Finish the review takes you to the check before you submit. The book icon at the top goes back to the summary.

Under each change, Ask Claude about this change takes a question. Claude reads the change and answers in a few sentences. Answers stay with the change, and Add as comment puts one on the change's first line.

In the editor, every changed section of the file carries its note above it: 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 changed files under their folders, each with what it is for. A file shows A or M until you read it, then a tick; a count when Claude has findings on it for you to decide. Click a file to open it on its own: the review stays where it was, and Back to change 3 returns. Right-click a file for See what changed since the pull request was explained.

If VS Code has no right side bar (versions before 1.106), the review opens in the bottom panel. The setting hyperpowers.player.location picks the side bar or the panel yourself.

Pull requests with a recording play in a player tab instead. Each screen shows the screenshot with numbered marks for what was clicked and checked. Click a mark to open the code that drew it. Put your cursor on a line in the editor and the mark it drew lights up.

Notes are written by a model reading the diff, and say so: check them against the code.

Review by area

A walkthrough created by this extension puts each changed file in an area: frontend, backend, database, setup, tests, docs or other. Without How it works, the review reads the files in the order the change flows: database, then backend, then frontend, then tests, with setup and docs last (first when the change is mostly setup). Inside an area, a file comes after the files it uses. Each change in the review shows its area.

To review one part only, pick it on the start page, above Start the review: All files, or an area such as Frontend 2, showing only the areas the change touches. The review then keeps to that area.

The area starts as a guess from the path (*.tsx is frontend, migrations/ is database, package.json is setup), and the model that explains the change corrects it where the code says otherwise. Walkthroughs made before this have no areas: they show the full review, as before.

Pick up where you left off

Your place is kept per pull request. A file counts as read once the review has passed its last change, or when you press Mark as seen next to it in Files in This Change. Reopen the pull request and the start page offers Continue the review.

New commits while you review

The review checks the pull request for new commits when you open it, and again every 10 minutes while it is open and VS Code has focus. The check is a git fetch from your own remote and nothing else; when you are offline it waits longer between tries. To check now, press ↻ at the top of the review, or ↻ on the pull request in Code Reviews. Turn the automatic check off with hyperpowers.walkthrough.checkForNewCommits.

When there are new commits, a thin line at the top of the review 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. The start page says it too.

Update fetches the new commits and explains only the files they changed, with the same Claude Code that Create Walkthrough uses and the earlier notes as context. The hyperpowers plugin is not needed. Files that did not change keep their notes, changed files get new ones, new files are added and files that left the pull request are dropped. The changes are numbered again in the same reading order, and progress shows as it does for Create Walkthrough. You stay on the change you were reading. Files that did not change keep their tick; changed files lose it.

Your comments stay. A comment whose line is gone, or whose code changed, is marked "The code under this comment changed" in Your Comments and on the code, with Move to put it on the right line and Delete. Claude's findings on unchanged files stay as they were. Findings on changed files are greyed and marked Outdated, with Review the changed files with Claude to check them again.

If this machine has no claude for the extension to run and the hyperpowers plugin is installed, Update runs the plugin's explain in a terminal instead.

Finish and submit

Finish the review is at the bottom of the review all the time, under Next change and Previous; on the last change it is the green button. It opens a check before anything is sent. The check says how much you read, such as "You read 4 of 11 changes" or "All 11 changes read", lists the files Not read yet (click one to go to it), then the files, your comments, and Claude's findings you have not decided yet. Click any of them to look again; Back to the check returns. You can submit at any point, read or not. Submit review… asks Comment, Approve or Request changes, and takes an optional summary for the author. Your comments then go to GitHub as one review.

After you submit

Once your review is on GitHub, the extension keeps an eye on the pull request for you: replies to your comments, new commits, threads resolved, other reviews, and a request to review it again. It asks GitHub with your existing sign-in, every 2 minutes for the pull request on screen, every 15 minutes for the rest of the Open group, and when VS Code gets focus. Each request is conditional, so an answer that has not changed comes back as a 304 and does not count against GitHub's rate limit. Merged and closed pull requests are not asked. After an error it waits twice as long each time, up to an hour, and when GitHub says the rate limit is low it waits for the reset.

What came shows in Code Reviews as a line on the row, such as "2 replies · 1 new commit", with a count badge, and the Hyperpowers icon counts the pull requests with news. Once per batch a notification says it in a sentence, such as "#2 Add an email notification setting: Praveen replied to 2 of your comments and pushed 1 commit.", with Open and Later. Opening the walkthrough clears the badge.

The start page then leads with Since your review on Oct 21: the commits and files since, who replied, and Review what changed, which walks only the interdiff (from the commit you reviewed to the head now) in the order of How it works, with each change's notes where the notes cover it. Below it, each of your comments with its status (Waiting for reply, Replied, Resolved, Code changed) and the last reply. Check if this was addressed asks Claude one small question per comment, with the lines then, the code now, your comment and the replies, and shows Addressed, Partly or Not addressed with one sentence, marked as Claude's read for you to check. Check all with Claude runs them three at a time. Finish and Submit review work as in the first round.

The Overview shows each conversation in full: the lines, your comment, the replies (markdown, drawn as text), and Reply, Resolve or Unresolve (when GitHub allows it for your account), Check if this was addressed and Open on GitHub. Needs you keeps the threads where someone answered and you have not.

Small pushes, 10 files or fewer and 400 changed lines or fewer, are explained in the background with the update path, only the files that changed, and "Updated with 1 new commit." shows until you close it. The change you are reading never moves. Bigger pushes wait for Explain and review what changed. Set hyperpowers.followUp.autoUpdate to always or ask to change this, and hyperpowers.followUp.notify or hyperpowers.followUp.watch to turn the notification or the watching off.

Review with Claude

Review with Claude reviews the whole pull request in the background while you read, and nothing is posted. It sits at the top of the start page, and above the Ask Claude box and as ✦ at the top of the review. Hyperpowers: Review with Claude in the command palette does the same. After a review, the start page says what the last one took: its time, its cost and its model.

To have it run by itself, set hyperpowers.review.autoRun to on: each pull request is then reviewed as soon as Create Walkthrough has explained it. The first time you create a walkthrough you are asked once; after a few reviews the question also says what they cost on average. Nothing runs by itself until you answer.

Which model

The review runs on your own Claude Code, with the model you already use there. It passes no model and no effort to Claude Code, so Claude Code picks them as it does for claude -p: the ANTHROPIC_MODEL environment variable, else the model in your Claude Code settings, else your plan's default; and the effortLevel in your settings, else the model's default. A model you choose with /model in Claude Code is saved to your settings when you press Enter, so the review uses it too. One you choose for that session only (s in the picker) is not saved, and the review does not see it.

To use another model for reviews, set hyperpowers.review.model to opus, sonnet, haiku or a full model id, and hyperpowers.review.effort to low, medium or high. Both start at default, which leaves Claude Code's own. The model also applies to Deep review, Ask Claude and Create Walkthrough, unless hyperpowers.walkthrough.explainModel names one for Create Walkthrough. The card's Details say which model did the review, how long it took and what it cost, as Claude Code reported it.

What it checks

The review picks its checks from what the pull request touches, and you don't pick anything:

• Always: what is most likely to break or surprise someone after it merges, and the risk of merging (low, medium or high) with one line why.
• A migration, a schema or an SQL file: locks on big tables, backfills, undoing it, defaults on existing rows, indexes. Always, when one is in the change.
• Auth, permissions, crypto, secrets, env or config files, or words such as password or innerHTML in the changed lines: secrets, injection, missing checks of who may do what, unsafe defaults. Always, when the change touches them.
• A manifest or lock file: new packages, major version jumps, lock file drift. Always.
• The Claude Code sessions the change was written in, when they are on this machine: whether the code does what was asked, and no more.
• Backend, frontend and test files: validation and errors, UI states and labels, and what is not tested. Exports, routes and env vars: what breaks for callers. Loops, queries and calls to other services: what gets slow or pages someone at night.

A check that applies is never dropped. The database, security and what-was-asked checks each get a Claude call of their own, so each gets full attention; the rest share one call on a small pull request (under 200 changed lines), two on a medium one and three on a large one. All the calls run at the same time, so the review takes about as long as its slowest call.

How it stays focused. The extension enforces this, whatever is in the code:

• Each call is sent only the files its checks need, without generated files, as diffs with the walkthrough's notes. Never whole files.
• On a small pull request, each change comes with 10 lines around it (6 on a medium one). Each call has a generous input budget; only on a very large pull request do the files not fit. Then the riskiest go first (the biggest changes, data and backend before tests and docs, changes with no reason in the notes, the words the checks look for), one file can be cut short, and the rest are left out. The card's details say so.
• Every call shares one system prompt, one answer format and one opening that describes the pull request, so Claude Code's prompt cache serves that part to the others.
• It runs with no tools and no MCP servers, each call with a 4-minute limit. A call that fails or times out says why, and the others carry on.
• Answers are short: a title, one sentence why, a one-sentence draft comment, and a fix only for critical and major findings. At most 8 findings per call on a small pull request.

On the sample app's pull request (8 files, 137 changed lines), with Claude Code's own model (Opus, at its effort setting), the review made three calls at once and took 33 to 38 seconds. It cost 27 to 32 cents, as Claude Code reported it.

The card

The card sits at the top of the start page, with Start the review still on the first screen:

• One line: whether it looks safe to merge, such as "Needs changes: 1 critical" or "Looks safe to merge after 2 questions", then the risk and the effort, 1 to 5 with about how many minutes it takes to review.
• A chip for each severity with its count. Click one to see only those findings. The top 3 show on the card, with Show all; click a title to open its lines.
• Nitpicks, folded away. They are not counted, never shown in the editor, and open only when you ask.
• Details, closed until you open it: what changed by area (each area's files and one line, from the walkthrough's notes, with no Claude call; click an area to review only that part), the risk's reason, what the review checked, and how long it took and what it cost.
• Fix all with Claude Code, Run again, and Deep review (slower).

While it runs, the card shows grey bars where the verdict will be, and you can start reading; findings show on their changes as they come. When part of it did not finish it says Partial, and when none did it says why, with Try again.

Findings

Each finding has a severity (Critical, Major, Minor or Nitpick) and a category (Bug, Security, Performance, Data, API, Tests, Style, Ops, Dependencies or Other), on the card, on its change and in Claude Findings. A finding that only says "could" or "consider" is a nitpick at most. When the same thing is raised twice on the same lines, it shows once, with the higher severity. One cap applies on a pull request after that, the most pressing first: hyperpowers.review.maxFindings, 12 by default. Nitpicks, findings that hold up, the deep review's own and any you already decided are not counted.

On its change, each finding has the same Add as comment, Edit and Skip as before. Running the review again on the same commit replaces its findings, and your decisions carry over. Claude Findings, on the left, lists them by file in reading order, with nitpicks and the ones that hold up in closed groups at the end. What was found and what you decided is kept for the commit, so reopening the pull request shows it again without running Claude.

From a finding to a fix. A critical or major finding can carry a fix of up to 15 lines. It is checked against the file when Claude answers: the lines it replaces must be in the file, near the finding, or the fix is dropped and the finding kept. The fix shows as a small diff on the change.

• Copy prompt for Claude Code copies a prompt that stands on its own: the pull request and branch, the file and lines, the issue, why it matters, the fix, and to run the tests that cover the file.
• Fix all with Claude Code, on the card, copies one prompt for the findings you added as comments, or, when you added none, every open finding. Skipped findings and nitpicks are left out.
• Apply suggestion makes the edit in your checkout and opens the file at it, to commit like any other edit. It only edits the pull request's branch: when your checkout is on another branch, it says so and offers to check the branch out first (when nothing is edited), or to copy the prompt instead. When the lines changed since, it says so and changes nothing. Undo takes it out again, and so does the editor's own undo. It needs a trusted workspace.
• Suggest on GitHub puts the fix in the comment as a ```suggestion block, on the lines it replaces, so the author can commit it from GitHub. In the review you see the comment before you add it.

Overview

Overview, beside Summary at the top of the start page, shows every comment on the pull request in one place, the way a pull request page does. Open it from the card's See all comments, or from Show All Comments in Claude Findings.

At the top: whether it looks safe to merge, the risk and effort, the open findings by severity, and which model did the review, how long it took and what it cost. Below, one block per comment, in reading order: who wrote it (Claude, or you for a comment waiting to be submitted), its severity and category, the file and lines, and whether it is open, added as a comment, skipped, applied, outdated or pending. Each block shows the lines of the diff it is on, numbered, with added and removed lines coloured and its own lines marked, then what it says, and a suggested fix as a suggested change. Every action is there: Go to change, Add as comment, Edit, Skip, Apply, Suggest on GitHub and Copy prompt for Claude's; Edit and Delete for yours. Reviews you already submitted from here show at the end, with their verdict and comments.

Show All, Claude, Mine, Open or Resolved, and Group by file. Nitpicks and findings that hold up are folded at the end. While Claude reviews, grey blocks show where its comments will appear, and they fill in as each part finishes. j and k move between comments; Enter goes to the change.

Deep review

Deep review (slower), on the card, reads every area in full: one call per area, up to three at once, up to 60,000 characters of diff per call, with the same model as the review. On the sample app's pull request, all four areas took 43 seconds and cost $0.37 with Claude Code's default model. After an update, an outdated finding offers Review the changed files with Claude, and Review the rest in Claude Findings' title bar reads the files the deep review has not read.

Generated files stay in the walkthrough, but Claude does not review them: lock files, the journey lock files test runs write, minified or bundled output, snapshots, files under dist, build, .next, out and generated, and anything git attributes mark linguist-generated. The dependency check is the one exception: it reads lock files as a short list of the package lines that changed.

Every click answers at once

Clicking a walkthrough in Code Reviews opens its start page straight away, as a grey outline of the page with "Loading walkthrough…", and the walkthrough fills it. Looking for new commits with git happens after that, never before.

Every button changes as you click it, before anything else happens: it says what it is doing ("Starting the review…", "Applying…", "Adding…", "Copying…") and waits. Review with Claude, Deep review and Submit say each step as they go, with Stop. When something fails, or VS Code does not answer in time, the button comes back with the reason beside it and Try again. Next, Previous and Finish move the review at once; the code opens beside it right after. When a state arrives, the page changes only what changed, so what you are typing or reading stays put.

What Claude looks at

A review looks at what matters for each file's area: for frontend code, state and rendering, loading, empty and error states, accessibility and the words people see; for backend code, input validation, who is allowed to do it, error handling and data that stays correct; for a migration, whether it can be undone, defaults and indexes; for setup, risky dependency and config changes; for tests, whether they test the behaviour or only run the code.

When you wrote the code with Claude Code on this machine, the review also reads what you asked while writing it, and checks the code against that: something asked for and not done, or done and never asked for, is flagged. Turn this off with hyperpowers.walkthrough.useClaudeSessions.

It runs claude with no tools and no MCP servers, so it reads only the files, their diffs, the code around them, the notes and those requests. Ask Claude about this change works the same way, reading the change. Like any Claude Code session, it sends them to Anthropic.

Claude usage

Every call the extension makes to Claude (Create Walkthrough, Update, Review with Claude, Deep review, Ask Claude) is a claude -p run on your own Claude Code. It sends:

• A short system prompt of our own in place of Claude Code's: what each task is and its rules.
• The pull request: what the author wrote about it, each changed file's diff with numbered changes, the function or class each change sits in, and the first lines of what the changed lines call but the diff does not show. These come from your checkout with git, within a fixed size.
• The task itself: which files to explain or review, the notes on them, or your question.

It keeps that small in these ways:

• No tools, no MCP servers, and none of your CLAUDE.md files, skills, plugins or hooks. These would otherwise go with every call. Your login, your model and your effort setting still apply, and the run is not saved to your Claude Code history.
• The system prompt and the pull request are the same, byte for byte, in every call about one commit, so Claude Code's prompt cache keeps them. The first call writes them; the explain parts, the summary, the review and Ask Claude after it read them from the cache, at about a tenth of the price, for an hour. When several calls run at once, the first goes alone until Claude starts answering, then the rest start and read what it wrote.
• Nothing is asked twice. Opening or creating a walkthrough again at a commit Claude explained asks Claude nothing. Review with Claude runs by itself once per commit, and what it found is kept per commit. After new commits, Update explains only the files that changed, and with hyperpowers.review.autoRun on, the review runs again on those files only.

The card's Details and the walkthrough's tooltip in Code Reviews say what Create Walkthrough and the review took: calls, tokens, how many were read from the cache, time and cost, as Claude Code reported them. The Hyperpowers output channel has one line per call with its tokens.

Comments

Hover a changed line in any diff and click + to comment, or click Comment in the note above a change. Comments wait in Your Comments: click one to go to its line, or edit or delete it. Submit from Submit review… at the bottom of that list, or from the check at the end of the review. They go to GitHub as one review, exactly as you wrote them. A comment on a line outside the pull request's diff goes in the review's body, with its file and line.

Updates

Installed from the Extensions view (Visual Studio Marketplace or Open VSX), it updates like any other extension. The rest of this section is for the .vsix file from hyperpowers.dev.

Each time VS Code starts, the extension asks hyperpowers.dev whether a newer version is out. If there is one, an update button shows in the status bar (bottom left) and at the top of Code Reviews: click it, then reload the window. To check now, open the … menu of Code Reviews and choose Check for Updates. The download is checked against its published checksum before it is installed. Turn this off with hyperpowers.walkthrough.checkForUpdates.

What it does not do

It sends nothing anywhere except the GitHub requests your actions cause, git fetches from your own remote, the files you ask Claude Code to review, and the daily update check. It never runs code from the repository. In an untrusted workspace, playing recordings and commenting still work; checking out a pull request into a worktree does not.

Settings