> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coderabbit.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Actions on a pull request

> Review, repair, reassign, close, and follow a pull request from the Triage queue — what each action does, what it needs, and where it runs as you rather than as CodeRabbit.

export const OpenBetaBadge = ({tip = "This feature is currently in open beta. We are actively improving it based on your feedback. If you encounter any issues or have suggestions, please share them on our Discord community or visit the support page.", title = "Open Beta", cta = "Contact support", href = "/support", disabled = false}) => {
  return <Tooltip tip={tip} cta={cta} href={href}>
        <Badge icon="badge-alert" disabled={disabled || undefined}>
            {title}
        </Badge>
    </Tooltip>;
};

export const EssentialsPlanBadge = ({tip = "This feature is available on Essentials (formerly Pro), Team (formerly Pro+), Advanced, and Enterprise. Please refer to our pricing page for more information about our plans and features.", title = "Essentials Plan", cta = "Read more", href = "https://coderabbit.ai/pricing", disabled = false}) => {
  return <Tooltip tip={tip} cta={cta} href={href}>
        <Badge icon="shield-check" disabled={disabled || undefined}>
            {title}
        </Badge>
    </Tooltip>;
};

export const GitHubBadge = ({tip = "This feature is available on GitHub and GitHub Enterprise.", title = "GitHub", cta, href, disabled = false}) => {
  return <Tooltip tip={tip} cta={cta} href={href}>
        <Badge icon="github" disabled={disabled || undefined}>
            {title}
        </Badge>
    </Tooltip>;
};

<GitHubBadge title="GitHub Cloud" /> | <EssentialsPlanBadge /> <OpenBetaBadge />

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

| Action                                                               | Review seat |
| -------------------------------------------------------------------- | ----------- |
| [Open in Change Stack](#open-a-pull-request)                         | No          |
| [View check details](#view-check-details)                            | No          |
| [Ignore or correct a close recommendation](#close-a-pull-request)    | No          |
| [Start a CodeRabbit review](#start-a-coderabbit-review)              | Yes         |
| [Repair a pull request](#repair-a-pull-request)                      | Yes         |
| [Request or withdraw a reviewer](#manage-reviewers)                  | Yes         |
| [Close a pull request](#close-a-pull-request)                        | Yes         |
| [Follow in Slack](/triage/slack#follow-a-pull-request)               | No          |
| [Set a priority](/triage/prioritization#setting-a-priority-yourself) | Yes         |

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](/management/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](/pr-reviews/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](/guides/code-review-overview).

## Repair a pull request

One item in the card menu offers whichever repair applies right now:

| Repair                  | When it appears                    | What it does                                                                          |
| ----------------------- | ---------------------------------- | ------------------------------------------------------------------------------------- |
| **Fix merge conflicts** | The branch conflicts with its base | Asks CodeRabbit to [resolve the conflicts](/finishing-touches/resolve-merge-conflict) |
| **Fix CI**              | Checks are failing                 | Asks CodeRabbit to [repair the failing checks](/finishing-touches/fix-ci)             |
| **Auto Fix**            | Review feedback is outstanding     | Asks CodeRabbit to [address the review comments](/finishing-touches/autofix)          |

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.

<Info>
  This is the way to get a current answer about checks. The indicator on the card comes from Triage's stored view of the pull request, which can lag; the panel reads the provider when you open it.
</Info>

## 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](/triage/slack#reviewer-requests).

## Close a pull request

Triage can close a pull request without you opening GitHub. This is what makes the [Safe to close](/triage/prioritization#close-candidates) 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.

<Warning>
  If the comment posts but the close then fails, Triage tells you so and asks you to close again **without** a comment, so the note is not posted twice. Triage also remembers the exact comment for a short period and skips reposting an identical one on a retry.
</Warning>

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

<CardGroup cols={1}>
  <Card title="Triage in Slack" href="/triage/slack" icon="message-square" horizontal>
    Get the queue delivered as a digest, and act on pull requests without opening the app.
  </Card>

  <Card title="Views, filters, and layout" href="/triage/views-and-filters" icon="list-filter" horizontal>
    Build the working set you act on — by view, filter, grouping, or saved view.
  </Card>

  <Card title="Troubleshooting Triage" href="/triage/troubleshooting" icon="circle-question-mark" horizontal>
    Work out why an action is disabled, refused, or did not appear to take effect.
  </Card>
</CardGroup>