The GitHub review requested filter, its siblings, and the inbox they almost add up to

The GitHub review requested filter is the closest thing GitHub has to a review inbox, and most developers use only its weakest form: glancing at the “Review requests” count on github.com/pulls. The search syntax underneath is considerably more capable. Every qualifier in this piece is checked against GitHub’s documentation on searching issues and pull requests, and the last section is about what no query can give you: an actual sense of priority.

The GitHub review requested filter family, verified

The qualifiers that matter for a reviewer, straight from the docs:

• review-requested:USERNAME matches pull requests where a specific person is requested for review. With @me, that person is you.
• user-review-requested:@me matches pull requests that you have directly been asked to review, the personal asks as distinct from requests that reach you another way.
• team-review-requested:ORG/TEAM matches PRs with a pending review request to that team, which is your queue view when reviews route through a team alias.
• reviewed-by:@me matches pull requests you have reviewed, useful for finding threads you started and then lost track of.
• review:none, review:required, review:approved, and review:changes_requested filter by review state, so you can find, say, every open PR sitting in changes-requested limbo.

Direct asks versus team asks

The distinction between review-requested and user-review-requested is the one worth internalizing. When someone types your username into the reviewers box, that is a personal ask with a social contract attached. When a CODEOWNERS rule or a team alias routes a PR to a group you belong to, you are one of several people who could take it. The docs define user-review-requested as the direct case, which is exactly why it deserves its own bookmark: those are the PRs where a specific human is waiting on you by name, and letting them age is how review requests quietly get lost. The team query, by contrast, is a shared pool; the failure mode there is everyone assuming someone else will pick it up. The docs also list a further variant, team-review-requested-user:USERNAME, which surfaces PRs with review requests to any team containing that user, handy for a lead who wants to see the load landing on one person through every team they belong to.

Watching the other side of the table

Two more queries round out the picture. reviewed-by:@me combined with is:open shows PRs you already reviewed that have not merged, which is where re-review requests hide after an author pushes fixes. And review:changes_requested scoped to your org surfaces every PR blocked on a rework cycle, the population most likely to be silently stuck. If your team has a turnaround expectation, these are the queries that make it inspectable; Google’s guidance on review speed argues that slow turnaround is a team-level cost, and we have covered how to formalize that in review SLAs. A query you can check is the difference between an aspiration and a practice.

Building the bookmark inbox

The practical setup takes five minutes. Create bookmarks for three URLs built on github.com/pulls or global search:

• Mine, by name: is:open is:pr user-review-requested:@me
• Everything waiting on me: is:open is:pr review-requested:@me, optionally scoped with org:YOURORG
• In flight: is:open is:pr reviewed-by:@me for the reviews you owe a second pass

Check the first one like you check messages; sweep the other two once or twice a day. This is crude, but it beats relying on notification emails that arrive interleaved with every other kind of GitHub noise. If you want one catch-all query for everything you touch, involves:@me matches issues and PRs you created, were assigned, were mentioned in, or commented on; it is too broad to be an inbox, but it is a good weekly sweep for threads that fell through the narrower queries.

Where the filters stop helping

Now the limits. Queries scope by org, but if you work across a company org, an open source org, and personal repos, no single query gives you a clean unified view without pulling in noise from all three. More fundamentally, search returns matches, not priorities: nothing in the result list tells you which PR is release-blocking, which is a two-minute approve, and which has been waiting three days. That ranking problem is a real capacity problem, and we have written about treating review capacity as a planned resource rather than an overflow buffer. Bookmarked filters are the right floor. Just know that they hand you an unsorted pile, and the sorting is still your job. The other quiet limitation is that bookmarks are pull, not push: a query only helps when you run it. If your day fills up and the tabs stay closed, the queue ages invisibly, which is why teams that get serious about turnaround pair the queries with an explicit checking cadence, or with tooling that watches the queue for them instead of trusting willpower.