An agent wrote the change. Let it write the reading order too.

git review puts the whole pull request in your working tree as one staged diff you can edit and run. If the branch ships a walkthrough, it takes you file by file — in the order the author chose, with the reason for each. Your fixes come back out on a separate branch. Review it where you already work.

Choose your interface → Watch the 40-second IDE demo →

See it in your IDE

AI wrote it. You own the review.

40 seconds · English · music on

Follow the reading order, fix a boundary error, run the tests, and take your correction to a separate branch. Captured in the real IDE.

Read the demo

A login rate limiter allows five attempts. The reviewer starts a guided review, reads the policy, then follows the author's note to the boundary check. They fix the comparison so that the request is blocked when the limit is reached and run the tests: all three pass. Finishing the review puts only that correction on review-fixes/rate-limit, staged and ready to commit.

Your interface

Review where you already work.

The reading order stays beside your work while you navigate the full project, inspect code beyond the diff, edit, and run it. Requires the git-review-workflow CLI.

VS Code

1.75+

Install →

JetBrains IDEs

2026.1+

Install →

Visual Studio

2022+

Install →

Terminal UI

macOS · Linux · Windows

Install →

The reading order

Whoever wrote the code writes the order you read it in.

You asked an agent for a feature. It touched fourteen files and handed you a diff sorted alphabetically — the one order guaranteed to carry no information. With git review walkthrough, the same agent that made the change also commits the order to read it in, plus a note on why each file matters. The reviewer runs git review start and lands in that order. Nothing to install on their side, nothing to configure.

walk on review/feature/rate-limit [1/4]

heads-up — the limiter sits in front of auth: get the bucket wrong and it is a public DoS, not a 500. The quota numbers are a judgement call, not a fact.

    ← →

    The loop

    Three commands, and the PR is just your working tree.

    01

    git review start feature/rate-limit

    The whole PR lands staged in your working tree, with HEAD at the merge-base — so git diff --cached is the entire change. Walk mode starts on its own if the branch ships a walkthrough.

    02

    edit it. run it. break it.

    It is your working tree, so any editor works. Fix the typo inline instead of writing a comment about it, run the tests, or point an agent at the staged diff and let it review the whole thing in place.

    03

    git review finish

    Your edits — and only yours — are extracted onto review-fixes/feature/rate-limit, staged for you to read and commit. The author's work stays untouched.

    Against the alternatives

    Every tool lets you see a PR. Almost none let you act on one.

    Guided order
    + why, per file    		 Edit & run as
    working tree    		 Auto-extract
    your fixes    		 Editor-agnostic
    git review ● ● ● ●
    gh pr checkout ○ ● ○ ●
    IDE PR panels ○ in-IDE only ○ ○
    GitHub / GitLab web ○ ○ ○ ●

    Install

    One command, then one line of config per repo.

    Everything plugs into git as a single subcommand. Needs git 2.23+ and a POSIX shell — on Windows that is Git Bash (install Git for Windows; the installers put git-review on your PATH).

    npm

    npm install -g git-review-workflow

    Homebrew (macOS / Linux)

    brew tap EzeVillo/git-review-workflow \
  https://github.com/EzeVillo/git-review-workflow
brew install git-review-workflow

    Windows (PowerShell)

    irm https://raw.githubusercontent.com/EzeVillo/git-review-workflow/main/web-install.ps1 | iex

    Linux, macOS, WSL, or Git Bash

    curl -fsSL https://raw.githubusercontent.com/EzeVillo/git-review-workflow/main/web-install.sh | sh

    Then, once per repository

    git config reviewworkflow.base develop   # where your PRs get integrated