Reviewing a Pull Request

Read the whole diff, act on AI findings, and submit — without leaving PR Flow.

Finding the pull request that needs you is half the job. The other half is reading it, and that is where most tools send you back to a browser tab.

PR Flow opens the whole change in a full-window review: the complete diff, the conversations already on it, the findings your AI raised, and the comments you are drafting — in one place, with the queue of everything else waiting behind it. Nothing you stage reaches the pull request until you submit.

Opening a review

Every surface that shows a pull request can open it: the Review changes action on a feed row, the Review button in PR Details, and any activity row — selecting a conversation opens the review at that exact thread. When a deep review finishes, View findings on the notification opens the review with its results already showing.

Opening a review snapshots your current Needs you list as a queue, respecting whatever filters you have applied. The pull request's title in the header is the queue selector: it shows where you are, and opening it lists everything in the queue with its repository and number, so two similarly named changes are never confused. The arrows beside it step through the same order and name their destination before you go.

If the change is part of a stack, a Layer n/m pager sits alongside — a different axis, moving up and down the chain rather than through your queue. See Stacked Pull Requests. Layers PR Flow already tracks open directly; the rest stay reachable from the stack map in PR Details.

← Queue or Esc takes you back.

Reading the diff

Every file renders in one continuous, syntax-highlighted diff, with the current file's header pinned as you scroll. Gaps between hunks expand in place — Expand N unchanged lines — on GitHub, GitLab, Gerrit and Azure DevOps alike. Large and generated files start collapsed behind a Load diff button so a lockfile never buries the change you came to read.

Mark viewed greys a file out and fills the progress bar in the rail. It is deliberately tied to the revision you reviewed: if the author pushes new commits, viewed marks clear, because you have not seen the new version.

The Commits selector narrows the diff to a range — Since last review is one click, and picks up exactly where you left off. The left rail switches between a flat file list and a directory tree, both showing per-file counts of findings and open conversations.

While you read, PR Flow keeps checking the head. If the author pushes, a bar appears — "pushed 3 new commits since you opened this" — with Update diff. The diff under you is never swapped silently.

The in-app review — the full diff with an AI finding pinned inline, one already accepted and staged as a review comment

Comments, findings and bots

The rail's Comments view collects everything on the pull request, grouped by where it came from: Human feedback, Bots, AI findings, and My staged comments. The bot group uses the bot accounts you configure in Settings, so a coverage report or a dependency bump never dilutes the count of things a person actually said.

Each group counts only what is still outstanding, and disappears entirely when it has none — a human-only or AI-only review reads as cleanly as a mixed one. Resolved conversations and dismissed findings stay one click away without inflating that count. A conversation on a line that has since moved stays outstanding and is marked as such: the code moved, the question did not go away. Every row carries the file and line it belongs to, and selecting it jumps straight there.

Agents that produce notes rather than line findings gather in their own Agent notes panel, since whole-PR advice has no line to pin to.

The review's Comments view — feedback grouped into human, bot, AI and staged lanes, each with its outstanding count

Leaving feedback

Hovering any line reveals a + to stage a comment there; the file header offers a comment on the whole file. Staged comments can be edited or removed right in the diff, and the composer says what it is: staged, nothing posts until you submit.

AI findings appear as pins on the lines they flag, tagged with the agent that raised them. On each one you can Accept it — staging it as your own review comment, editable first — Dismiss it, or Discuss it. Dismissing is yours alone: it writes nothing to the pull request. When PR Flow could not confirm the line a finding claimed, the pin says File scope rather than pinning a comment where it may not belong.

Two things do post immediately, and PR Flow labels them where they happen: replying to an existing conversation, and resolving or reopening one. Everything else — your staged comments, your summary, your verdict — waits for submit.

Discuss opens a panel beside the diff, scoped to the whole pull request, one file, or one finding. Answers stay in the panel and never post on their own; Add as comment turns one into a staged comment on that file or line, or appends it to your review summary. To jump from a diff line into your editor instead, see Open in Editor.

Finishing and submitting

The footer tracks your staged count and viewed progress. Finish review opens the sheet, where you pick a verdict — Approve, Request changes, or Comment — review the comments you staged, and write a summary. Draft with AI writes one for you, and asks before overwriting anything you already typed.

If any staged comment no longer matches the diff, the sheet says so before you submit and tells you exactly where it will land instead. On your own pull request, only Comment is available.

Submit posts everything at once. Submit & next does the same and moves you to the next pull request in the queue. If a submit only partly succeeds, PR Flow says precisely that — how many comments posted, what stayed in your draft, and whether the verdict landed anyway — and lets you retry without duplicating what already went through.

Every review PR Flow writes on your behalf is recorded in Settings → Logs → Write actions.

What differs by provider

The review works the same everywhere; the difference is how the write lands.

GitHubGitLabGerritAzure DevOps
ApproveApproveApproveCode-Review +2Reviewer vote
Request changesRequest changesNo native equivalent — posts your comments and leaves the merge request unapprovedCode-Review −1Reviewer vote
A comment that no longer matches the diffFolded into the summaryPosted as a general note, prefixed with its file and linePosted as a file-level commentFolded into the summary
SubmittingOne atomic reviewComment by comment, so a partial submit is realOne atomic reviewComment by comment

On Gerrit, if you do not have +2 rights an approval is posted as +1 and PR Flow tells you plainly that the author still needs a +2 from a maintainer — and holds you on that review so you see it.

Keyboard

The review is built to be driven from the keyboard. J and K step through files and findings, and through files alone. A accepts the focused finding and D dismisses it, C starts a comment, V marks a file viewed, X cycles the verdict, and F opens the finish sheet. Press ? at any time for the full list, which reflects your own bindings.

Every one of these can be remapped in Settings → Shortcuts. See Keyboard Shortcuts.