Skip to content

PR Triage

This guide explains how CloudAEye picks the pull request you should review next, and why.

Overview

CloudAEye orders the open pull requests waiting on you, across every repository your organization connected, when you run /cloudaeye:triage-prs from your coding agent. It runs from the CloudAEye plugin, not from a PR comment.

It answers the question before the Risk Score and Reviewer Assignment: of everything waiting on you, which pull request to review next. The result names one pull request with a priority out of 100, the reasons, and what to look at, then the rest in order. Pull requests whose next move is their author's are listed apart and never picked. It reads only: nothing is written on GitHub or Jira.

Prerequisites

Step 1: Register

Sign up with CloudAEye SaaS.

Step 2: Setup Code Review

Setup Code Review by following the Getting Started guide.

Step 3: Install the Plugin

Install the CloudAEye plugin by following Claude Code → Setup.

Pick the Next Review

Run the following in your coding agent:

/cloudaeye:triage-prs

Add a note in your own words to steer the pick:

/cloudaeye:triage-prs I have half an hour before standup
/cloudaeye:triage-prs skip the UI repository today

A note never changes a priority: it leaves out what it rules out, naming it on the card, and I have half an hour prefers the smaller reviews. A Critical pull request is left out only when the note names it.

To narrow or widen the queue:

/cloudaeye:triage-prs here                    only this repository
/cloudaeye:triage-prs okrs:docs/okrs-q4.md    weigh the pull requests against an OKR document
/cloudaeye:triage-prs for:@ravi               someone else's queue
/cloudaeye:triage-prs repo                    every open pull request of this repository
/cloudaeye:triage-prs all                     every open pull request of every repository

An OKR document is read for that run only and never stored. repo and all are a lead's view: every open pull request with its next action and who it waits on, the low-risk ones that could merge quickly, and close candidates — a newer duplicate, one whose issues or tickets are already closed, or one idle for 30 days and blocked. Nothing is closed for you.

To review the pick, ask for it after the card; Claude runs /cloudaeye:review on it in a checkout of that repository.

Triage Card

The card includes:

  • Review next: the pick, numbered 1, with its priority out of 100, its risk, complexity and business impact, the reason, why now, and what to look at.
  • Then: the rest of your queue in order, numbered from 2, each with its priority and reason.
  • Not your move yet: pull requests waiting on their author — a draft, an unanswered change request, a merge conflict, or failing CI — with what the author has to do.
  • Could not be prioritised: pull requests in a repository CloudAEye has not mapped yet, whose code it cannot read.
  • Not measured: what could not be read, such as a risk score that has not run on a pull request.

When no pull request requests your review or is assigned to you, the card says so and lists the open pull requests nobody was asked to review instead. /cloudaeye:assign-reviewer puts a pull request in someone's queue.

See the full example in Skills & Commands.

What It Reads

Signal Description
Your queue Pull requests requesting your review, directly or through a team, assigned to you, or due again because the author pushed after your review
Urgency The Jira tickets a pull request names — priority, labels, due dates and parent epics — when the Jira app is installed, and its own labels and branch
Business impact What the changed code does — payments, authentication, schema, what users see — and the goals it serves, from an OKR document you name
Risk The Risk Score at the pull request's current commit; without one, an estimate from CloudAEye's review, open bugs in the changed files and recent reverts
Reach How much depends on the changed code: its callers, its routes, and the other connected repositories that call it

How It Orders

Every pull request is scored by the same fixed rules, so priorities compare across repositories. A pull request linked to an incident, a top-priority ticket, a hotfix branch or a release-blocker label is Critical and comes first. Then the order is by priority; between two of nearly the same priority, the one waiting only on you goes first, then the one that has waited longest.

CloudAEye also reads what fixed rules cannot, such as urgency a ticket states only in its words, and writes the reasons for the pick. That can raise a priority within limits; it never makes a pull request Critical on its own.

Priorities are not calibrated yet. They order your queue; they are not a verdict on any pull request. The card does not expose scoring weights or formulas.

Incomplete Evidence

Missing evidence is reported as not measured, never as low priority. A factor that could not be measured counts as typical, so a pull request with no risk score is not ranked below one that scored low.

PR Triage does not replace a code review. Use Review Code to check for bugs and security vulnerabilities.