I have been experimenting with this PR Manager to help me review the PRs using Coding Agents. It sits on menu bar on macOS and has various lifecycle actions of PRs. feedbacks are welcome.
We’ve been building our own Review Pipeline, including automated review guides, risk detection and much more.
There’s SO much to be done around Code Review, I’m very surprised GitHub isn’t doing more.
They have the reach already, they have years of real review data. And yet, the PR itself is not using any of the newly available methods for more efficient review.
Agents are hammering PRs out left and right, and yet here I am still staring at the raw diff of 35 PRs and end up being called the bottleneck.
show comments
gz09
I wish they would instead focus on fixing the regressions with PRs first...
For example: There is a nasty bug that got introduced recently where you click "Merge when ready" but your chances of things actually going to the merge queue seem to be only at about 60-70%. When it happens the way you usually find out if things still aren't merged the next day.
Their support has acknowledged the issue to us over a month ago but no fix as of now.
show comments
habosa
This is a major improvement and still not great. I made CodeApprove (https://codeapprove.com) 6+ years ago just because the PR page on GitHub is so bad and I felt the urge to make it better.
IMO the correct design is pretty simple:
- Everything on one page, information dense
- Focus on code and unresolved discussions, maybe CI checks
- Keyboard navigation
Graphite gets pretty close! But it's become cluttered over the years. CodeApprove is far from perfect too (it's been a while since I worked on the UX much) but I'd hope GitHub could do a little better.
show comments
locallylinear
Idk, I just ask my agent what the status of the PR is in terms of failing checks, outstanding comments, etc.
But this seems fine
If anything I think the place to invest a better UX is on reviewing code, even “my” (agent’s) own code before I ask for a review. In a world where we’re moving away from IDEs, and using terminal apps or desktop apps to code, I often don’t even see the code until it’s on GitHub. But I still cling on to some semblance of needing to review, in particular what’s important.
And yes, me one year ago would be shocked at what I just said.
show comments
johnnypangs
I don’t like that they reversed the the comment thread order but didn’t include a native way to include previews. Now instead of having to scroll to bottom to see the merge button. I have to scroll to the bottom to see the preview.
verst
I've been using this for a few weeks but I don't quite like it. It's too many clicks to navigate to the PR discussion / comments for my liking.
show comments
pscanf
I tried it, but I don't understand the fanfare when it's basically the same old UI + a couple of minor layout changes. It definitely doesn't address the needs of the AI dev workflows.
ethin
I wish that instead of trying to make the UI look pretty GH would instead try to make the platform solid again
Been using Graphite all year. I had trouble adapting my GitHub mind to it at first and I still don’t love everything about Graphite, but _wow_ is Graphite’s PR review page organized better than GitHub. GitHub’s new PR stack is superior (atomic merges are life-changing) and having one fewer tokens to manage CLI to install is fantastic, but I’m still mostly Graphite because the page is just organized better.
Specifically, graphite wins on:
- I land on the page and immediately see an overview of my whole PR stack: what’s in the stack, what’s passing, what’s failing, what’s draft, unresolved and total comments. I know exactly where to spend my time. GitHub PR stacks offer no such convenience.
- Description is below stack details, then code, and I never have to switch tabs or pages. This hierarchy makes sense: top of the page is broad whole stack details, and as we go down we get more specific. GitHub forces me to jump between pages to see all of this.
- Comments in a drawer are nice. Being able to quickly scan them helps me get a sense of what’s there, who’s commenting, I can jump between them quickly.
- Approval, request, labels, etc are also logically oriented at the top near other metadata. GitHub sprawls this around the page. It’s especially rough on mobile browser.
I just checked the new overview. It’s a step up. Curious to see if it helps the PR stack experience. I’d love to fully migrate off Graphite, the non-atomic merge is truly a nightmare across a large stack, but at the end of the day I haven’t been able to give up the UX gains of managing my work on Graphite compared to GitHub.
pushcx
I tried it this morning, I guess it's for business rather than open source? The first PR I opened was slop that violated the project's policies. The new UI is missing both report and block.
There's not really any improvement to the core problem with PRs. You still have to read up and down the entire comments tab and then again the entire diff tab (hunting and clicking each "load more" and re-opening every "resolved" thread to find invisible replies) to reconstruct the timeline of what's happened in your head because nothing's in temporal order and there's still no interdiff.
lacoolj
Hoping to see this in GHE as soon as we can
I'm liking the changes. Hopefully the "lines changed" gets updated when you choose a specific commit in the file viewer now too
suralind
NGL, I know GH gets a lot of shit about the stability, that's well deserved, but they've been really doing nice UI improvements recently. Hopefully this is a new trend that will also continue with the stability.
greatgib
But at the same time, do they still hide/mask/minimize review comments when there are more than 10 in a row?
That is the worst with their UX currently, only challenged by the stupidity of the code diff page that hide the most modified files so you can easily miss them and it is impossible to do a ctrl+f search on the page.
show comments
monster_truck
Am I blind or is there no "try overview page" button on the header of this site? Or on any of my PRs
bakies
Right off the bat the ux is inconsistent in the examples. The grey bar is optional checks but required approvals
jeffbee
These were not really my beef with the PR review page. My beef is that the first round of PR comments becomes unmoored from ground truth after any subsequent commits, making it difficult to see whether comments were addressed, and how.
dawnerd
I’ve never once thought I was spending too much time scrolling.
show comments
UqWBcuFx6NV4r
> The merge box, distilled
Nobody, and I mean NOBODY, can legitimately like this Apple-style way or structuring sentences. The only people to remotely get away with it in my mind are Apple themselves (and only becuase they’re grandfathered in), and I get that in the late ‘00s / early ‘10s there was a trend of companies doing this to look more Apple-like, but in 2016 let alone 2026 it’s just camp and cringe. However, LLMs LOVE writing like this whenever they get a slight whiff that they’re being asked to do something in a marketing context. Are GitHub / MS using clearly AI-generated prose just to prove a point or something? Are the internal [dis-]incentives really this bad? Am I going insane? Is this just how all Californians talk?
varun_chopra
> The merge box, distilled
Ugh
rafram
Shovel manufacturer responds to complaints about customers throwing piles of manure in neighbors’ yards: “We’re trialing a free window cleaning service to help you get a clearer view of the manure”
kccqzy
> As people need to review more and more pull requests, time spent scrolling adds up
I can’t believe people would write this as the justification. You can press PgDn on your keyboard a few times or just End once to go to the bottom. If you are on a MacBook and your keyboard doesn’t have these keys, press Fn-Down instead of PgDn and Fn-Right instead of End. When done, use the opposite keys (PgUp/Home/Fn-Up/Fn-Left). I have never once found that scrolling takes too much time.
show comments
conceptme
95% if not more if claude thinks it's ok it's going in the sheer volume of code changes we are now doing are simply not doable by hand anymore.
It's basically the wild wet now :D bots reviewing bots.
Ideally only risky merges should get human attention, and some guard rails to enforce it but mistakes have been made.
hoektoe
So we getting UI updates just as humans are looking less and less at these screens via github....
ivanjermakov
Finally approve button is available on the main screen without having to open diff view which takes ages to load. Still two clicks though.
show comments
stock_toaster
Just more slopstick on the pig. :/
d33
I know it's boring at this point, but seeing Claudish headers like "The merge box, distilled" and "Keep your place. Focus your attention" just screams SLOP at me.
I can't read it. It's not really text.
smithcoin
too little too late - we migrated to self hosted gitea.
Karupan
> The merge box, distilled
What does that sub heading even mean!
cedws
Can you fix the inbox first please before reinventing more UI? The inbox is utterly broken and slow. It frequently says my PRs are waiting for review when they’ve already been approved.
a012
Loading PRs on GH is dog slow for me. If they could improve the performance and availability, otherwise Idgaf
show comments
calmbonsai
I give zero fucks. Just make Actions, 'ya know, some reasonable (3?) amount of 9s again.
I have been experimenting with this PR Manager to help me review the PRs using Coding Agents. It sits on menu bar on macOS and has various lifecycle actions of PRs. feedbacks are welcome.
Github Repo: https://github.com/vs4vijay/prx
We’ve been building our own Review Pipeline, including automated review guides, risk detection and much more.
There’s SO much to be done around Code Review, I’m very surprised GitHub isn’t doing more.
They have the reach already, they have years of real review data. And yet, the PR itself is not using any of the newly available methods for more efficient review.
Agents are hammering PRs out left and right, and yet here I am still staring at the raw diff of 35 PRs and end up being called the bottleneck.
I wish they would instead focus on fixing the regressions with PRs first... For example: There is a nasty bug that got introduced recently where you click "Merge when ready" but your chances of things actually going to the merge queue seem to be only at about 60-70%. When it happens the way you usually find out if things still aren't merged the next day.
Their support has acknowledged the issue to us over a month ago but no fix as of now.
This is a major improvement and still not great. I made CodeApprove (https://codeapprove.com) 6+ years ago just because the PR page on GitHub is so bad and I felt the urge to make it better.
IMO the correct design is pretty simple: - Everything on one page, information dense - Focus on code and unresolved discussions, maybe CI checks - Keyboard navigation
Graphite gets pretty close! But it's become cluttered over the years. CodeApprove is far from perfect too (it's been a while since I worked on the UX much) but I'd hope GitHub could do a little better.
Idk, I just ask my agent what the status of the PR is in terms of failing checks, outstanding comments, etc.
But this seems fine
If anything I think the place to invest a better UX is on reviewing code, even “my” (agent’s) own code before I ask for a review. In a world where we’re moving away from IDEs, and using terminal apps or desktop apps to code, I often don’t even see the code until it’s on GitHub. But I still cling on to some semblance of needing to review, in particular what’s important.
And yes, me one year ago would be shocked at what I just said.
I don’t like that they reversed the the comment thread order but didn’t include a native way to include previews. Now instead of having to scroll to bottom to see the merge button. I have to scroll to the bottom to see the preview.
I've been using this for a few weeks but I don't quite like it. It's too many clicks to navigate to the PR discussion / comments for my liking.
I tried it, but I don't understand the fanfare when it's basically the same old UI + a couple of minor layout changes. It definitely doesn't address the needs of the AI dev workflows.
I wish that instead of trying to make the UI look pretty GH would instead try to make the platform solid again
Discussion: https://github.com/orgs/community/discussions/212186
Been using Graphite all year. I had trouble adapting my GitHub mind to it at first and I still don’t love everything about Graphite, but _wow_ is Graphite’s PR review page organized better than GitHub. GitHub’s new PR stack is superior (atomic merges are life-changing) and having one fewer tokens to manage CLI to install is fantastic, but I’m still mostly Graphite because the page is just organized better.
Specifically, graphite wins on:
- I land on the page and immediately see an overview of my whole PR stack: what’s in the stack, what’s passing, what’s failing, what’s draft, unresolved and total comments. I know exactly where to spend my time. GitHub PR stacks offer no such convenience.
- Description is below stack details, then code, and I never have to switch tabs or pages. This hierarchy makes sense: top of the page is broad whole stack details, and as we go down we get more specific. GitHub forces me to jump between pages to see all of this.
- Comments in a drawer are nice. Being able to quickly scan them helps me get a sense of what’s there, who’s commenting, I can jump between them quickly.
- Approval, request, labels, etc are also logically oriented at the top near other metadata. GitHub sprawls this around the page. It’s especially rough on mobile browser.
I just checked the new overview. It’s a step up. Curious to see if it helps the PR stack experience. I’d love to fully migrate off Graphite, the non-atomic merge is truly a nightmare across a large stack, but at the end of the day I haven’t been able to give up the UX gains of managing my work on Graphite compared to GitHub.
I tried it this morning, I guess it's for business rather than open source? The first PR I opened was slop that violated the project's policies. The new UI is missing both report and block.
There's not really any improvement to the core problem with PRs. You still have to read up and down the entire comments tab and then again the entire diff tab (hunting and clicking each "load more" and re-opening every "resolved" thread to find invisible replies) to reconstruct the timeline of what's happened in your head because nothing's in temporal order and there's still no interdiff.
Hoping to see this in GHE as soon as we can
I'm liking the changes. Hopefully the "lines changed" gets updated when you choose a specific commit in the file viewer now too
NGL, I know GH gets a lot of shit about the stability, that's well deserved, but they've been really doing nice UI improvements recently. Hopefully this is a new trend that will also continue with the stability.
But at the same time, do they still hide/mask/minimize review comments when there are more than 10 in a row?
That is the worst with their UX currently, only challenged by the stupidity of the code diff page that hide the most modified files so you can easily miss them and it is impossible to do a ctrl+f search on the page.
Am I blind or is there no "try overview page" button on the header of this site? Or on any of my PRs
Right off the bat the ux is inconsistent in the examples. The grey bar is optional checks but required approvals
These were not really my beef with the PR review page. My beef is that the first round of PR comments becomes unmoored from ground truth after any subsequent commits, making it difficult to see whether comments were addressed, and how.
I’ve never once thought I was spending too much time scrolling.
> The merge box, distilled Nobody, and I mean NOBODY, can legitimately like this Apple-style way or structuring sentences. The only people to remotely get away with it in my mind are Apple themselves (and only becuase they’re grandfathered in), and I get that in the late ‘00s / early ‘10s there was a trend of companies doing this to look more Apple-like, but in 2016 let alone 2026 it’s just camp and cringe. However, LLMs LOVE writing like this whenever they get a slight whiff that they’re being asked to do something in a marketing context. Are GitHub / MS using clearly AI-generated prose just to prove a point or something? Are the internal [dis-]incentives really this bad? Am I going insane? Is this just how all Californians talk?
> The merge box, distilled
Ugh
Shovel manufacturer responds to complaints about customers throwing piles of manure in neighbors’ yards: “We’re trialing a free window cleaning service to help you get a clearer view of the manure”
> As people need to review more and more pull requests, time spent scrolling adds up
I can’t believe people would write this as the justification. You can press PgDn on your keyboard a few times or just End once to go to the bottom. If you are on a MacBook and your keyboard doesn’t have these keys, press Fn-Down instead of PgDn and Fn-Right instead of End. When done, use the opposite keys (PgUp/Home/Fn-Up/Fn-Left). I have never once found that scrolling takes too much time.
95% if not more if claude thinks it's ok it's going in the sheer volume of code changes we are now doing are simply not doable by hand anymore.
It's basically the wild wet now :D bots reviewing bots.
Ideally only risky merges should get human attention, and some guard rails to enforce it but mistakes have been made.
So we getting UI updates just as humans are looking less and less at these screens via github....
Finally approve button is available on the main screen without having to open diff view which takes ages to load. Still two clicks though.
Just more slopstick on the pig. :/
I know it's boring at this point, but seeing Claudish headers like "The merge box, distilled" and "Keep your place. Focus your attention" just screams SLOP at me.
I can't read it. It's not really text.
too little too late - we migrated to self hosted gitea.
> The merge box, distilled
What does that sub heading even mean!
Can you fix the inbox first please before reinventing more UI? The inbox is utterly broken and slow. It frequently says my PRs are waiting for review when they’ve already been approved.
Loading PRs on GH is dog slow for me. If they could improve the performance and availability, otherwise Idgaf
I give zero fucks. Just make Actions, 'ya know, some reasonable (3?) amount of 9s again.