AI wrote the code. Review it with a reading order.

Follow the changed files in a proposed reading order, with a reason for each and the parts that deserve attention. Use the author's walkthrough or prepare your own. Review the code in your editor, run tests, and finish with your corrections on a separate branch.

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 guide: review a PR locally →

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. If the PR has no walkthrough, you can prepare your own reading order for that review.

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

    Follow the context. Inspect the change.

    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

    read it. check what matters.

    Follow the walkthrough, check its explanations against the implementation, and leave observations. The full project is available in your editor: run tests or make a correction when you need to check something.

    03

    git review finish

    Finish the review with any corrections staged on review-fixes/feature/rate-limit, separate from the author's work. A guided review can also finish without code corrections.

    Compare the workflow

    A reading order in the tools you already use.

    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