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.
![]()
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.
![]()
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.
| GitHub | GitLab | Gerrit | Azure DevOps | |
|---|---|---|---|---|
| Approve | Approve | Approve | Code-Review +2 | Reviewer vote |
| Request changes | Request changes | No native equivalent — posts your comments and leaves the merge request unapproved | Code-Review −1 | Reviewer vote |
| A comment that no longer matches the diff | Folded into the summary | Posted as a general note, prefixed with its file and line | Posted as a file-level comment | Folded into the summary |
| Submitting | One atomic review | Comment by comment, so a partial submit is real | One atomic review | Comment 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.