A GitLab merge request dashboard ordered by what needs you.
See which merge requests Need you, which are Waiting on others, and which can wait across projects and groups, using your glab CLI session.
Your review queue crosses the project tree.
Projects organize code. Review work is organized by the next action and who owes it.
Your work crosses the group tree
Merge requests from different projects land in one desktop queue, without a separate per-project setup step.
Assignee and reviewer are not the same role
An MR you authored and one awaiting your review need different actions. PR Flow keeps those states apart.
To-Do items are a queue you have to garden
PR Flow does not replace GitLab's project tools. It adds an attention view that keeps ageing work visible alongside current actions.
Unresolved discussions expose the next reply
Discussion counts appear on the row. A teammate reply returns the MR to Needs you with the reply action visible.
Merge requests, ranked by who is blocked.
One list, whatever group the project lives in.
Enable GitLab and involved merge requests visible to your glab session appear under Needs you, Your MRs, or Waiting on others.
- Smart views: Needs you · Your MRs · Waiting on others · Recently done
- A GitLab dot on every row, so provider is never ambiguous
- Unresolved discussion counts before you open anything
Read the diff, stage the reply, submit.
Open an MR for its diff, discussions, and linked ticket. With Agent Pipelines configured and the relevant helper enabled, advisory complexity and risk estimates appear too.
- Stage line comments, replies, a summary, and approve, request changes, or comment
- Nothing posts until you submit; merging stays in your hands
- “Submit & next” walks you down the queue
Connect from the machine that can reach your instance.
PR Flow uses the GitLab session already configured on your machine and does not proxy repository data through a PR Flow server.
Your instance, your session
PR Flow follows the instance selected by your glab session.
Nothing routed through us
Provider requests originate on your machine. PR Flow's servers do not receive your code or diffs.
Alongside other providers
GitHub, Azure DevOps, and Gerrit work can share the queue while keeping provider labels.
Full details in the security overview and privacy policy. AI review follows the same rule — see local AI code review.
Three steps to the first queue.
Install PR Flow
macOS, Windows or Linux. Free for 14 days — no account, email or card.
Confirm your session
PR Flow uses the same authentication your terminal already has.
Enable GitLab
One switch in Settings. Merge requests appear on the first poll and refresh quietly from then on.
Looking for a GitLab pull request dashboard?
GitLab calls them merge requests, and PR Flow keeps that terminology — a GitLab row is labelled an MR, with a GitLab provider dot. What you are probably after is the same thing either way: the merge requests you are involved in, pulled into one attention-ordered queue across projects and groups. If your week also spans GitHub pull requests, they land in that same queue under their own name.
GitLab specifics.
Does it work with self-managed GitLab?
Do I need to give PR Flow a GitLab access token?
Can I approve a merge request from the app?
Does it say "pull request" everywhere?
We use GitLab and something else. Does that work?
Keep reading
Keep the next GitLab action visible.
You still review, respond and merge. PR Flow keeps the queue and review workspace ready. Try it free for 14 days; a one-time licence keeps it after the trial.