close
Skip to main content
| Triage answers two different questions about every pull request, and keeps the answers separate:
  • Priority — how much it is worth acting on this, compared to everything else in the queue.
  • Next action — what specifically has to happen for it to move.
Keeping them apart is deliberate. A pull request with failing CI is blocked, which tells you what to do about it, but that alone does not make it important. A trivial dependency bump with red checks should not outrank a customer-facing fix that is simply waiting for a reviewer. So mechanical state drives the next action, and value drives the priority.

​
What goes into a priority

Ranking is comparative: a pull request is placed against the rest of the open queue, not scored against a fixed bar.
Blockers do not raise priority. Failing checks, merge conflicts, draft status, a branch behind its base, unresolved review threads, and a stale approval all shape the next action and can make a pull request un-mergeable. They are not what makes it urgent.

​
Priority levels

Triage does not show a numeric score. Levels are the interface; the number behind them is not, and is deliberately not documented, because it changes as the ranking model improves. Two pull requests in the same provider state routinely land on different levels — that is the point. Same state, different risk, different blocked work behind them, different review cost.

​
Why this one is here

Each card carries a one-line priority reasoning explaining its rank. Triage picks the most specific explanation it has:
  1. A comparative explanation — why this pull request ranks where it does relative to others. Triage rejects an explanation that only restates mechanics (that checks are failing, that the branch needs a rebase), because that describes the next action, not the priority.
  2. The CodeRabbit review summary — used only while it covers the latest reviewable commit. A summary describing an older commit is never shown as the reason.
  3. A signal-specific sentence — for example, that the change is release-blocking, or that it offers high value relative to review effort.
  4. The next-action text — the fallback when nothing more specific applies.
Long reasoning is shortened on the card. Show full priority reason expands it in place, and View priority reason in the card menu opens the whole thing.

​
Close candidates

A close candidate is not a low priority — it is a different recommendation. It means the evidence suggests the pull request should be reviewed for closing, not reviewed for merging. Triage nominates one when:
  • It duplicates or is superseded by other work, and it has since gone quiet.
  • It looks abandoned and is blocked — no meaningful human activity, and something is in its way that nobody is clearing.
  • Its base has moved so far that the change no longer applies — the branch is many commits behind and old enough that the assumptions it was written against have changed.
Triage never nominates one that is watched or pinned, that carries a security or incident signal, that is release-critical, or that carries known high risk. Nomination is conservative by design.
Triage never closes a pull request by itself. A close candidate is a recommendation with a button next to it. Someone has to press it.
You have three responses:

​
Setting a priority yourself

When you know something the evidence does not, set the priority directly. Open the priority badge on a card, choose P0–P3, optionally say why, and save. It takes an active Review seat.
  • The priority you set wins over the calculated one everywhere — in grouping, filtering, and ordering — and it keeps winning as the queue is re-evaluated.
  • The calculated priority keeps being maintained underneath. You are overriding what is shown, not erasing what CodeRabbit concluded.
  • Every change is recorded in Priority history on the badge, with who made it, when, and the reason they gave.
Two things to know before you use it:
A manual priority cannot be cleared. You can change it to a different level, but there is no way to hand the card back to the calculated ranking. Setting a priority is a one-way decision on that pull request.
A manual priority dismisses a safe-close recommendation. If you give a close candidate a P0–P3, its close button disappears — you have said it matters, so Triage stops proposing that you close it.
If someone else changed the pull request while your board was open, saving can fail with a message telling you to refresh and try again. That is a safeguard against overwriting a priority you could not see; reload and set it again.

​
When a priority changes

A card is re-evaluated as its evidence changes — when commits land, reviews arrive, checks finish, or CodeRabbit reviews a new commit. Priorities can also move when a different pull request merges. After a merge into the default branch, Triage re-examines the repository’s other open pull requests: some are now duplicated or superseded, some have drifted far enough from their base to matter, and the relative order of the rest may have changed. So a pull request you did not touch can be ranked differently in the morning.

​
What’s next

Views, filters, and layout

Group the queue by priority to see the whole ranking at once, or filter to one level.

Actions on a pull request

Act on what the ranking surfaced — review, repair, reassign, or close.

Cards and signals

Look up what each signal on a card means and when it is withdrawn.