Actions on a pull request

| Triage keeps the useful actions next to the queue, so deciding what to do and doing it are the same visit. They live on the card itself: the Next action button, the card’s action menu, the reviewer stack, and the check indicator. Anything that writes to your Git provider runs as you, using your own GitHub authorization — not as a shared CodeRabbit identity. Your teammates see your name on the close or the review request, and GitHub applies your real permissions, so Triage can never do something on a repository that you could not do yourself.

​

What each action needs

Without a seat, the actions that need one are shown but disabled, with a note asking an admin to assign you one. See Seat assignment. An action also appears only when it is possible on that pull request — a repair only when there is something to repair, a close only on a pull request Triage can close as you. Where Triage cannot act directly, the card offers Open in GitHub instead, so you are never left with a button that fails.

​

Open a pull request

Selecting a card opens it in Change Stack, where the change is broken into logical cohorts and layers with CodeRabbit’s findings attached. That is where the actual reading happens; Triage decides which pull request, Change Stack shows you what is in it. When Change Stack is not available for a pull request, the card offers Open in GitHub instead.

​

Start a CodeRabbit review

Start review requests a CodeRabbit review of the latest reviewable commit. The card follows the review’s progress, and the item disappears while a review is already running so you cannot queue two. Once a review has run, the same control becomes Retry review if it needs to be run again. For what the review itself produces, see CodeRabbit’s pull request review workflow.

​

Repair a pull request

One item in the card menu offers whichever repair applies right now: The item’s label tracks the repair through its whole life, so the card tells you where a request got to without opening the pull request: Requesting fix…, then Fixing CI… / Resolving conflicts… / Auto-fixing…, then one of Fix requested, CI fix proposed, Conflicts resolved, Auto Fix proposed, Manual CI fix required, or Retry CI fix when it did not work. Repairs are offered only on open pull requests that CodeRabbit is tracking, and only when that specific repair applies.

​

View check details

Open the GitHub Actions indicator on a card for the full check list: each check’s name, the app that reported it, its outcome (Successful, Failed, In progress, Skipped), how long it took, the summary the provider supplied, and a link to it on GitHub. Opening the panel fetches live results rather than reading the card. While at least one check is still running, the panel refreshes every few seconds and stops when everything finishes or you close it.

​

Manage reviewers

The reviewer stack on a card is also the control for changing reviewers. Suggestions. Triage proposes reviewers from evidence it already has, strongest first:

• Code owners for the paths the pull request touches
• People already requested or already reviewing
• Recent contributors to the same code, weighted toward recent and repeated work
• People who have reviewed this repository before
• People who have reviewed this author’s work before
• Reviewers named in your CodeRabbit configuration, and members of relevant teams

Evidence has to be substantial to count — a single old commit does not make someone a candidate. Bots are never suggested, and neither are you. Search. When the right person has no history here, search for them. Search covers anyone with access to the repository, not only people Triage has evidence about. It uses your own GitHub authorization, so you see exactly the people you can see on GitHub. Request and withdraw. Add a reviewer from the picker; withdraw or re-request an existing one from that person’s row in the reviewer stack. All three happen on GitHub immediately rather than being staged and saved, and all three need a Review seat and your own permission on the repository. Ping in Slack. If the reviewer’s GitHub account is linked to a Slack account, you can send the request straight to them in Slack, optionally requesting the review on GitHub at the same time. See Reviewer requests in Slack.

​

Close a pull request

Triage can close a pull request without you opening GitHub. This is what makes the Safe to close view actionable rather than just informative. Close PR closes immediately, with no comment and no confirmation step. Close with a comment… opens a box for a short note — “superseded by #4312” — which is posted on the pull request and then closes it. Closing another person’s work with an explanation is usually the kinder path. Both run as you, so the close is attributed to you and uses your permissions. For a close candidate you disagree with, use Ignore close candidate to park it for yourself, or Mark not a close candidate to tell CodeRabbit the recommendation was wrong. Neither needs a seat, and ignoring is reversible.

​

What’s next