git review workflow — VS Code extension

Review a pull request by editing and running it, not just reading it. The whole PR lands in your working tree as one staged diff; your fixes are then extracted onto a clean branch automatically. This panel shows where you are in the review and drives every step of it without leaving the editor.

And when an AI agent wrote the change, it can write the reading order too — a walkthrough committed next to the code saying which file to read first and why. The panel picks it up on its own and walks you through the diff in that order, instead of alphabetically.

Project README · Website · Changelog

Watch the 40-second demo — follow the reasoning, fix a boundary error, run the tests, and keep your correction on a separate branch.

This is the editor surface of git-review-workflow, a git subcommand that stages an entire PR in your working tree as staged, uncommitted changes — so you read the diff, edit it inline and run the tests like ordinary local work, and git review finish then extracts your edits onto a separate branch. The extension does not reimplement any of that: it drives the same CLI and shows you its state.

The CLI is required. The extension is a panel over git review, not a standalone reviewer. See Requirements.

What the panel shows

A reading order, when the PR has one. If the author (often an AI coding agent) committed a walkthrough alongside the change, the review runs in walk mode and the panel shows the current entry: the file, its position in the order the author chose, whether they marked it key, and the why they wrote for it. The full sequence — and the files the walkthrough doesn't cover — is one keystroke away in a quick pick, and commands jump to the file, advance and go back without leaving the editor.

The files the range touches, when it doesn't. A review without a walkthrough runs in whole mode, and there the panel is the list of changed files: a row opens that file's diff, and one control above them opens every change at once. The last row you opened stays marked, so a list you are halfway through still says where you were after closing the editor.

Or the reading order you write yourself. When the PR ships without one, the start assistant offers Build a reading order first: it writes a skeleton listing every file in the range, and the assistant closes. Nothing waits on you.

The half-written order shows up in the panel, under Reading orders you started, with how far along it is (3/9, counted by the CLI) and four controls on its row — two buttons underneath and two glyphs beside the count:

• Copy for agent — puts a one-line instruction naming that file on the clipboard, for whatever you want to hand it to. Copying is copying: no service is contacted and no assistant is invoked.
• Validate and start — validates it (on the CLI, so a rejection tells you exactly what to fix, in the CLI's own words) and, when it passes, starts the review on your order. It stays switched off, with a tooltip saying why, while the order is unfinished or the CLI cannot tell how the draft was generated.
• Beside the count, open the reading order — the file, at the path the CLI reported — and discard it, after a confirmation that names the command.

The count is one unit per entry plus the ## Heads-up section, which is what --build demands too: it reaches N/N exactly when no placeholder is left. Deleting the whole heads-up section is a legal way to finish it, and the total drops when you do. The progress follows the file: hand the draft to an agent and the count moves on its own as it writes, with nobody hitting Refresh.

It survives closing the editor, so a reading order you started on Friday is the first thing the panel says on Monday. The draft is yours and local: it lives outside the working tree, never gets committed or staged, and git status does not change at any point. Nothing about it is written for you; it is a file you fill in. Once it is in, the review reads it exactly like an author's walkthrough, and the panel marks the mode (draft) so it is clear whose reading order you are on.

Your other reviews, when this branch has none. With no review on the current branch the panel lists the ones open elsewhere in the repository — active and saved, with their mode and position — so a review you put aside doesn't have to be remembered by name. Saved ones offer Continue; an active one is listed without an action, because going back to it is a branch checkout and the editor's branch picker already does that.

Getting started

1. Install the CLI. With Node:

   npm install -g git-review-workflow
   

   Homebrew, a native Windows (PowerShell) installer and a no-Node one-liner are all in the installation guide.

2. Tell it where PRs are integrated, once per repository — from the panel (git review: Set the Base Branch) or on the command line:

   git config reviewworkflow.base develop
   

3. Open the git review panel in the activity bar and hit Start a review. It asks for the branch, where to read it from, the range, and how to read it — offering only the layouts the CLI reports as viable for that PR. (Or run git review start feature/login in a terminal; the panel follows.)

Panel actions

Everything below is a command the panel exposes. Lifecycle actions (Finish, Save, Cancel, Preview and Refresh) are icon buttons on the view title bar; the rest are buttons inside the panel or entries in the Command Palette, all under the git review category.

Each one shells out to the matching git review verb — the extension never invents a second way to change review state.

The branches your finishes left behind. Every finish leaves a review-fixes/<branch>, and they pile up one per review. The empty state lists them under Edits you extracted, collapsed at the foot, each with what git can say about dropping it: empty (it still sits where finish created it, so it holds none of your work), merged, unmerged, or unknown with no base configured. Dropping one runs clean --fixes-only <branch>, which leaves the review session standing — including the undo point of a finish you can still abort. Discard all runs the same command with no branch: by clean's own scoping that only ever enumerates review-fixes/* and never touches a live review/* session, unlike a bare clean. It is still behind a confirmation, because what these rows hold is work you wrote by hand.

Mutations (the lifecycle actions, clean, forget, compare and writing a walkthrough) ask for a confirmation that names what will happen. Preview is read-only and does not.

A finished review is not the empty state: the panel names where your staged edits landed — review-fixes/<branch>, or the PR branch itself with --onto-source — and offers Clean (drop the leftover undo point, keep the edits) or Undo finish. Commit and push those edits from Source Control as usual. A finish stopped mid-conflict keeps the review readable (mode, branch, current entry) but locks navigation until you Continue or Undo finish.

Requirements

• VS Code 1.75 or newer.
• git-review-workflow 0.7.0 or newer, discoverable as a git subcommand (git review -h works), or pointed at directly with the gitReview.path setting.
• A single-folder workspace. Multi-root workspaces are not supported: the panel needs exactly one git repository root, the same way the CLI has one cwd. Open the repository folder on its own, or pick one root and open that.
• On Windows the CLI itself runs under Git Bash, which Git for Windows provides.

Settings

gitReview.path on Windows

On Windows, a bare POSIX path such as …/bin/git-review — no .cmd, .bat or .exe extension — is spawned through sh, which only works if Git Bash's sh is on your PATH. Prefer one of:

• leave gitReview.path empty and install the CLI so that git review works as a subcommand (npm or the PowerShell installer both set that up), or
• point gitReview.path at a Windows-native shim — the .cmd an npm global install leaves behind, for example.

If spawning fails with ENOENT while gitReview.path points at an extensionless file, the cause is the missing sh, not a missing CLI.

Troubleshooting

The panel reports what it found rather than failing silently — a missing CLI, a version too old, a repository with no base configured — and offers the action that fixes it. When you need the detail, git review: Show CLI Log prints every invocation the extension made and what came back.

Learn more

• Project README — the full command surface, the walkthrough format, and how the workflow fits together. Also in Spanish.
• Website
• Issues
• Contributing to the extension — running it from source, tests, and the panel preview.

License

MIT © EzeVillo