Every review request, in one list.

The default sort is Priority, and the thing to know about it is that it is not a mystery score. Every row carries a chip saying why it is where it is — "Asked directly", "Waited 3d", "All checks green", "Unblocks others", "Draft", "Conflicts". Hover it and you get the full arithmetic, every term with its points. If you disagree with a placement you can see exactly what caused it, which is the difference between a ranked list you keep using and one you quietly stop reading.

Underneath, the list is cut into four bands before anything is scored. Pull requests that other work is stacked on, or that are queued to merge, come first — somebody besides the author is waiting on those. Then everything you could simply review. Then the ones where the ball is back with the author: conflicts, failing checks, changes already requested, because reviewing those now duplicates work they are already doing. Last, the ones that are not ready — drafts, and anything an agent is mid-way through pushing to.

The bands are a hard partition, and that is the point. Scoring inside a band can never promote a draft above a pull request that needs nothing but your approval, which is exactly what a single additive score does the first time forty small nudges add up.

Inside a band the ordering is ordinary arithmetic on things that are true right now. All checks green, everyone else has approved and only you are left, a human put your name on it rather than a team, the diff is small, you asked for changes and were re-requested — each of those is worth points, and each is nameable, which is why the chip can say one word. Machine-authored pull requests are pushed down hardest of anything that is not a band.

Waiting counts too, and it stops counting on purpose. The wait bonus climbs for about five days, holds to a fortnight, then drops away — because an ever-growing age bonus turns the list into a graveyard sorted by neglect, where the thing nobody will ever review is permanently first.

There is a personal term, and it is deliberately small. Talyn learns who you actually review, whose pull requests you tend to be reciprocated on, and which parts of the tree you know — from your own review history, per workspace. It only switches on after about 150 reviews, and only if it measurably beats the default on your own held-out history; until then everyone gets the same hand-set starting point. It is capped at twelve points, which is below the maximum the waiting bonus can reach, and that gap is the whole safety argument: familiarity can reorder your queue but can never bury something indefinitely.

The ranker cannot see a pull request title, its description, its diff, or a single comment. The complete list of what it is allowed to look at is structural: draft or not, author, when it was created, mergeable state, what is blocking it, the review decision, check counts, how many threads are unresolved and who opened them, how many lines changed, whether you were asked directly or through a team, and the top-level directories touched.

That is not an oversight, it is the design. Ordering that depends on what a pull request says is ordering you cannot predict and cannot argue with — and it would mean shipping your code somewhere to sort a list.

Being named as a reviewer and being in a team that was named are different requests with different urgency, and a list that treats them the same is a list you learn to ignore. Talyn shows which it was, and lets you filter to one team when you are doing a review round for a specific area.

A filter you use every morning can be saved, per workspace, so it is one click rather than four.

Opening a row gives you the diff, the checks and the conversation without a round trip to the browser. From there you can run one of your own review playbooks against it as a cloud agent task, or run a full code review whose findings stay in the app rather than landing as comments on somebody else's pull request.