Triage prioritization

|

​

How priority is derived

Triage ranks pull requests by the work they need and the value of acting on them. The ranking also considers:

• Review state, including approvals, requested changes, unresolved discussions, and whether CodeRabbit has reviewed the latest reviewable commit
• Recent human and provider activity
• Risk, security findings, and the likely impact of the change
• The effort required to review or complete the pull request
• CodeRabbit analysis, including review guidance and change context
• Dependencies, stacked changes, and whether one pull request blocks or affects another

These signals produce a priority, a workflow state, and a recommended next action. The ranking is recalculated as the pull request changes, new reviews arrive, checks finish, or related work moves forward. Checks, merge conflicts, draft or readiness state, and base-branch drift can change the shown workflow or next action. They do not by themselves raise or lower priority.

​

Priority levels

Triage currently assigns three priority levels against absolute thresholds: Priority does not change merely because other pull requests enter or leave the queue. It can change when new information arrives. Triage does not expose the internal numeric thresholds behind these levels.

​

Close candidates

A close candidate is separate from the P1–P3 scale. It means the available evidence suggests that a pull request should be reviewed for closure, for example because it appears dormant, duplicated, or superseded and has no protected blocker that requires it to stay open. The designation is conservative and does not close the pull request. A user chooses whether to close it, ignore the recommendation, restore it later, or report a false positive.

​

Workflow and responsibility

Priority answers which pull requests deserve attention first. Workflow state answers what must happen next. Triage can distinguish work that needs an author update, human review, a maintainer decision, conflict or CI repair, merge action, monitoring, or closure review. Responsibility is tracked separately from workflow, but cards do not currently display a responsible-role label. Instead, workflow tags such as Needs human review and Needs author action show who should act next. Two pull requests with the same provider state can rank differently. For example, two open pull requests awaiting review may differ in risk, blocked downstream work, review effort, or recent activity.

​

Reviewer suggestions

Triage can suggest reviewers from people and teams with evidence of fit for the change. Candidate sources include current or requested reviewers, CODEOWNERS, recent contributors, prior reviewers, and repository teams. Fit reflects signals such as ownership, prior review activity, contribution history, and coverage of the affected code. Bots are excluded from the human reviewer candidate pool. Suggestions remain user-controlled: you can request, remove, or replace a reviewer where the provider supports the action.

​

Freshness of review signals

Review-derived signals are useful only while they describe the current change. Blast radius, change type, issue severity, and security risk are displayed only when they cover the latest reviewable commit; if the author pushes a newer reviewable commit, these signals remain hidden until CodeRabbit analyzes the new version. Review effort, risk, and review guidance can persist across a push. For the underlying review concepts, see Estimated review effort and Git platform review metrics. Triage uses these concepts as inputs without changing their definitions.

​

What’s next