> ## 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.

# PR Walkthroughs

> Every time CodeRabbit reviews a pull request, it posts a **walkthrough comment** — a structured overview of the changes that appears at the top of the PR comment thread, separate from inline code comments. The walkthrough is on by default and fully configurable.

export const GitLabBadge = ({tip = "This feature is available on GitLab.", title = "GitLab", cta, href, disabled = false}) => {
  return <Tooltip tip={tip} cta={cta} href={href}>
        <Badge icon="gitlab" 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>;
};

## Overview

The walkthrough comment is made up of independent sections. Each section can be enabled or disabled separately to match your team's workflow.

By default the walkthrough is wrapped in a collapsible Markdown `<details>` block. Set [`collapse_walkthrough`](/reference/configuration#reviews) to `false` to keep it expanded.

```yaml .coderabbit.yaml theme={null}
reviews:
  collapse_walkthrough: false
```

## Walkthrough sections

### Changed files summary

A grouped summary of files changed in the PR. Related changes are consolidated into rows — for example, a PR that modifies one source file and 27 localization files produces two rows. Each row includes a plain-language description of what changed.

Enable/disable with [`changed_files_summary`](/reference/configuration#reviews) (default: `true`).

### Sequence diagrams

For PRs that affect component interactions — API calls, event flows, async workflows — CodeRabbit generates [Mermaid](https://mermaid.js.org/) sequence diagrams showing the updated flow. Diagrams are rendered inline in GitHub and GitLab.

Enable/disable with [`sequence_diagrams`](/reference/configuration#reviews) (default: `true`).

### Estimated review effort

A score from 1 (trivial) to 5 (very complex) estimating how much effort the PR requires to review thoroughly. The estimate considers the number of files changed, the nature of the changes, and logic complexity.

Enable/disable with [`estimate_code_review_effort`](/reference/configuration#reviews) (default: `true`).

### Related issues

Open and closed issues that are related to the PR changes, even if not explicitly linked. Useful for surfacing issues that may be affected by the change or provide useful context.

Enable/disable with [`related_issues`](/reference/configuration#reviews) (default: `true`).

### Linked issue assessment

When a PR references an issue via keywords like `Closes #123`, CodeRabbit reads the issue and checks whether the changes address it. It highlights gaps between what the issue requested and what the PR delivers.

See [PR Validation using Linked Issues](/issues/pr-validation) for guidance on writing effective issues and understanding how CodeRabbit evaluates Pull Requests against them.

Enable/disable with [`assess_linked_issues`](/reference/configuration#reviews) (default: `true`).

<Info>
  The linked issue assessment result also feeds into the [pre-merge checks](/pr-reviews/pre-merge-checks) system. See `issue_assessment` in the [configuration reference](/reference/configuration#reviews) to enforce this check as a merge requirement.
</Info>

### Related PRs

Merged and open PRs that touched the same areas of the codebase, helping reviewers understand the change history of a file or feature.

Enable/disable with [`related_prs`](/reference/configuration#reviews) (default: `true`).

### Suggested labels

Labels that describe the nature of the change, such as `bug`, `enhancement`, `frontend`, or `breaking-change`. When no [`labeling_instructions`](/reference/configuration#reviews) are configured, suggestions are inferred from labels used on similar past PRs.

Enable/disable with [`suggested_labels`](/reference/configuration#reviews) (default: `true`).

<Info>
  Labels can also be applied automatically — see [`auto_apply_labels`](/reference/configuration#reviews).
</Info>

### Suggested reviewers

Reviewers suggested based on git history and code ownership. Suggestions are included in the walkthrough and can optionally be assigned automatically.

Enable/disable with [`suggested_reviewers`](/reference/configuration#reviews) (default: `true`).

#### Custom reviewer rules <GitHubBadge /> <GitLabBadge />

When your team has subject-matter experts for different areas of the codebase, use [`suggested_reviewers_instructions`](/reference/configuration#param-suggested-reviewers-instructions) to pair natural-language instructions with the reviewers that should be suggested when a PR matches. Each rule contains an `instructions` field describing when the rule applies and a `reviewers` list identifying who to suggest.

Each reviewer entry can be:

* **An individual user** — set `type: user` (or omit `type`, since `user` is the default).
* **A team** — set `type: group` to reference a team handle such as `security-team`. Supported on GitHub only.

A single rule can include multiple reviewers, so one matching condition can fan out to several people or teams at once.

```yaml .coderabbit.yaml wrap theme={null}
reviews:
  suggested_reviewers: true
  auto_assign_reviewers: true
  suggested_reviewers_instructions:
    - reviewers:
        - handle: security-team
          type: group
        - handle: octocat
          type: user
      instructions: "Assign when the PR modifies authentication, encryption, or access-control logic."
    - reviewers:
        - handle: infra-team
          type: group
      instructions: "Assign when the PR changes CI/CD pipeline configuration files."
```

Reviewers matched by your rules appear in the walkthrough summary alongside any reviewers suggested from git history. When [`auto_assign_reviewers`](/reference/configuration#reviews) is enabled, the matched reviewers are also assigned as PR reviewers automatically.

When the `suggested_reviewers_instructions` list is empty, CodeRabbit falls back to suggestions based on prior PRs.

### Review status messages

Brief status messages posted when a review is skipped or cannot proceed — for example when a PR is in draft, matches an ignored title keyword, or review was manually paused.

Enable/disable with [`review_status`](/reference/configuration#reviews) (default: `true`).

### Poem

A short poem at the end of the walkthrough, generated from the changeset. Can be disabled if you prefer a strictly professional output.

Enable/disable with [`poem`](/reference/configuration#reviews) (default: `true`).

## Fortune while you wait

While a review is in progress, CodeRabbit posts a fortune message as a placeholder in the walkthrough comment. The placeholder is replaced by the full walkthrough once the review completes.

Enable/disable with [`in_progress_fortune`](/reference/configuration#reviews) (default: `true`).

## Including the PR summary

By default the [PR summary](/pr-reviews/summaries) is written into the PR description. To move it into the walkthrough comment instead, set [`high_level_summary_in_walkthrough`](/reference/configuration#reviews) to `true`. The summary will appear at the top of the walkthrough, above the changed files table.

```yaml .coderabbit.yaml theme={null}
reviews:
  high_level_summary_in_walkthrough: true
```

For the full list of walkthrough options with types and defaults, see the [configuration reference](/reference/configuration#reviews).