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

# Code Guidelines

> CodeRabbit automatically detects coding guideline files such as .cursorrules, CLAUDE.md, and AGENTS.md in your repository and applies them as review criteria—no extra configuration required.

CodeRabbit scans your repository for well-known AI coding assistant configuration files and uses their content as review criteria. If your team already writes instructions for tools like Cursor, Claude, or Windsurf, CodeRabbit picks those up automatically and enforces the same standards during code review.

## Supported files

The following file patterns are detected by default:

| File pattern | Associated tool |
| - | - |
| `**/AGENTS.md` | AI agent instructions |
| `**/.cursorrules` | Cursor |
| `.github/copilot-instructions.md` | GitHub Copilot |
| `.github/instructions/*.instructions.md` | GitHub Copilot (scoped instructions) |
| `**/CLAUDE.md` | Claude Code |
| `**/.claude/rules/**/*.md` | Claude Code (rules directory, see [Claude Code rules](#claude-code-rules)) |
| `**/GEMINI.md` | Gemini CLI |
| `**/.cursor/rules/*` | Cursor (rules directory) |
| `**/.windsurfrules` | Windsurf |
| `**/.clinerules/*` | Cline |
| `**/.rules/*` | Generic team rules |
| `**/AGENT.md` | AI agent instructions |

> [!NOTE]
>
> File names are case-sensitive. A file named `claude.md` is not matched by the `**/CLAUDE.md` pattern.

## How scoping works

By default, a guideline file applies to the directory it lives in and all of its subdirectories. CodeRabbit does not apply guidelines from one part of your repository tree to unrelated paths unless you explicitly map the guideline to source-file patterns with `applyTo` in a `filePatterns` object entry.

**Examples:**

* `CLAUDE.md` at the repository root → applies to all files
* `src/frontend/CLAUDE.md` → applies only to files under `src/frontend/`
* `src/backend/.cursorrules` → applies only to files under `src/backend/`

This directory-scoped behavior means you can maintain separate, purpose-fit guidelines for different areas of a monorepo without them interfering with each other. When directory placement does not match the files a guideline should govern, use the object form of `filePatterns` to define the mapping explicitly. Claude Code rules can declare their own scope instead, as described in [Claude Code rules](#claude-code-rules).

> [!NOTE]
>
> Without an explicit `applyTo` mapping, guidelines in a documentation or tooling
> directory will not affect code review unless the reviewed files live inside
> that same directory tree.

> [!WARNING]
>
> A common mistake is adding guideline file names (for example `CLAUDE.md`) to
> `path_instructions`. This tells CodeRabbit to **review** those files as
> changed code, not to **use** them as guidelines. Use `filePatterns` instead
> (see below), or rely on auto-detection.

## Claude Code rules

CodeRabbit reads every Markdown file in a `.claude/rules/` directory, including its subdirectories, the way Claude Code loads [path-specific rules](https://code.claude.com/docs/en/memory#path-specific-rules). When a rule declares `paths` in its YAML frontmatter, CodeRabbit applies that rule only to the files those globs match, so you don't need to repeat the rule's scope in CodeRabbit configuration.

```markdown .claude/rules/payments.md theme={null}
---
paths:
  - "src/payments/**"
---

# Payments

- Represent amounts with the `Money` type, never with floating-point numbers.
- Make every charge request idempotent.
```

CodeRabbit applies this rule when it reviews `src/payments/refunds.ts`, and not when it reviews `src/search/index.ts`. All of the rule's guidance stays within its `paths`, including general advice that doesn't name specific files.

`paths` is either a YAML list or a comma-separated string of globs. Brace expansion is supported, and a comma inside braces doesn't split the list. These two declarations are equivalent:

```yaml theme={null}
paths:
  - "src/**/*.{ts,tsx}"
  - "lib/**"
```

```yaml theme={null}
paths: "src/**/*.{ts,tsx}, lib/**"
```

As in Claude Code, `paths` is the only frontmatter field that affects a rule's scope.

### How rules are scoped

* **Rules without `paths`.** A rule with no frontmatter, or with frontmatter that has no `paths` field, keeps CodeRabbit's usual behavior: CodeRabbit infers the scope from the rule's content and keeps it within the directory that contains `.claude/`. A rule in the repository's root `.claude/rules/` can apply to any file.
* **Nested rules directories.** Globs in `paths` are relative to the project root, which is the directory that contains `.claude/`. For a nested directory such as `services/api/.claude/rules/`, CodeRabbit resolves `paths` under `services/api/`, so `paths: ["src/db/**"]` in `services/api/.claude/rules/db.md` matches files under `services/api/src/db/`.
* **Invalid frontmatter.** If CodeRabbit can't parse a rule's YAML frontmatter, it treats the rule as having no `paths`, as Claude Code does.
* **Unusable globs.** CodeRabbit ignores globs that it can't use as a scope: negations such as `!src/legacy/**`, globs with a `..` segment, and values that contain `:`, such as repository-qualified `repo:path` references. If every glob in a rule's `paths` is unusable, the rule applies to no file rather than to every file.

### Using `.claude/rules` with `filePatterns`

`.claude/rules` is a default pattern, so you don't need to list it in `filePatterns` or copy any rule's `paths` there. Add CodeRabbit configuration only when CodeRabbit should scope a rule differently from Claude Code.

An [object entry](#adding-custom-file-patterns) in `knowledge_base.code_guidelines.filePatterns` whose `files` matches a rule takes precedence over that rule's `paths`: CodeRabbit applies the rule to the entry's `applyTo` globs instead. The rule's guidance, including general advice, stays within those globs. String entries don't change a rule's scope, and a rule that no object entry matches keeps its own `paths`.

For example, a repository has these rules:

```text theme={null}
.claude/rules/
├── payments.md   paths: ["src/payments/**"]
├── frontend.md   paths: ["web/**/*.{ts,tsx}"]
└── style.md      no paths
```

Its configuration adds one string entry and overrides the scope of one rule:

```yaml .coderabbit.yaml theme={null}
knowledge_base:
  code_guidelines:
    filePatterns:
      - "**/CODING_STANDARDS.md"
      - files: ".claude/rules/frontend.md"
        applyTo: "web/**/*.{ts,tsx}, packages/ui/**/*.{ts,tsx}"
```

With this configuration:

* `payments.md` applies to files under `src/payments/`, from its own `paths`.
* `frontend.md` applies to TypeScript files under `web/` and `packages/ui/`, from `applyTo`, instead of its `paths`.
* `style.md` has no `paths`, so CodeRabbit infers its scope from its content.
* `CODING_STANDARDS.md` files are added to the default patterns and scoped to the directories they live in.

## Managing applied guidelines

The CodeRabbit UI shows the applied coding guidelines for a repository. Repository admins with write access can view applied guidelines and disable them. Select one or more applied guideline rows and click **Trash selected** to stop those rendered guidelines from being applied in future reviews.

Trashing a guideline does not delete the source guideline file from your repository. It suppresses the rendered path pattern and instruction text that CodeRabbit applied for that repository. If the source guideline changes enough to render as a different instruction, it can appear again as a new applied guideline.

To turn off code guidelines entirely for a repository, set `knowledge_base.code_guidelines.enabled` to `false`.

## Adding custom file patterns

If your team stores coding standards in files that are not in the default list, you can extend the detected patterns by setting `knowledge_base.code_guidelines.filePatterns` in your `.coderabbit.yaml`. Each entry can be either a glob string or an object with `files` and `applyTo` fields.

A string entry locates guideline files and scopes each matched file to its containing directory and subdirectories. An object entry uses `files` to locate the guideline document or documents and `applyTo` to define the source-file glob or globs they govern. This explicit mapping lets you store guidelines outside a source tree and apply them to any matching files.

Custom patterns are **added on top of** the defaults—they do not replace them.

```yaml .coderabbit.yaml theme={null}
knowledge_base:
  code_guidelines:
    filePatterns:
      - "**/CODING_STANDARDS.md"
      - files: "docs/guidelines/frontend.md"
        applyTo: "src/frontend/**/*.{js,jsx,ts,tsx}"
```

Glob patterns follow the same syntax used elsewhere in CodeRabbit configuration. The `**` wildcard matches any number of path segments.

In the configuration editor, the **Files** and **Apply To** fields correspond to the `files` and `applyTo` properties in an object entry.

## Guidelines from another repository

GitHub (Guidelines from another repository are supported on GitHub, including GitHub Enterprise Server.) GitLab (Guidelines from another repository are supported on GitLab.com and self-managed GitLab.) Azure (Guidelines from another repository are supported on Azure DevOps Services.) Bitbucket Cloud (Guidelines from another repository are supported on Bitbucket Cloud.) | Cloud Only (This feature is available on CodeRabbit Cloud only. It is not available on self-hosted CodeRabbit deployments.)

A string entry can name another repository as the source of your guideline files. The reference format and the boundary the source must stay within depend on your Git platform:

> [tab] GitHub
>
> Write `repo:path` to reuse the reviewed repository's organization, or `owner/repo:path` to name the organization explicitly. On GitHub.com, `owner/repo:path` can name a repository in another organization when the CodeRabbit GitHub App is installed in that organization with read access to the source repository. On GitHub Enterprise Server, the source and reviewed repositories must be in the same organization, and CodeRabbit rejects references to another organization. If the app can't read the source repository, CodeRabbit skips the source and reports that it couldn't be accessed.

> [tab] GitLab
>
> Write `repo:path` to reuse the reviewed repository's owner, or `owner/repo:path` to name the owner explicitly. The source and reviewed repositories must be in the same top-level group. CodeRabbit rejects references outside that group.

> [tab] Azure DevOps
>
> Write `repo:path` to select a repository in the reviewed repository's Azure project, or `org/project/repo:path` to select one in another project within the same organization. Use literal spaces in project names, for example `myorg/Sample Project/standards:rules.md`, rather than `%20`.

> [tab] Bitbucket Cloud
>
> Write `repo:path` to reuse the reviewed repository's workspace, or `owner/repo:path` to name the workspace explicitly. The source and reviewed repositories must be in the same workspace.

On every supported platform, CodeRabbit ignores an entry whose repository reference resolves to the repository being reviewed. The entry selects nothing, and it is not reported among the skipped sources in the review summary. Files in the reviewed repository are still discovered by their default names, such as `CLAUDE.md` or `.cursorrules`, but a file outside those names is selected only by an unqualified entry. To use `standards/internal.md` from the reviewed repository, write it as `standards/internal.md`, not as `your-repo:standards/internal.md`.

The path can be an exact file path or a glob, and it can be mixed freely with unqualified entries that locate files in the repository being reviewed. Entries that name no repository keep selecting files from the reviewed repository, following the [directory-based scoping](#how-scoping-works) described above.

> [tab] Using configuration file
>
> ```yaml .coderabbit.yaml theme={null}
> knowledge_base:
>   code_guidelines:
>     filePatterns:
>       - "**/CODING_STANDARDS.md"
>       - "engineering-standards:frontend/react.md"
>       - "engineering-standards:guidelines/**/*.md"
>       - "api-contracts:contracts/billing.md"
> ```

> [tab] Using web interface
>
> Add the same entries to the **File Patterns** field under **Knowledge Base > Code Guidelines**, one per row, for example `engineering-standards:frontend/react.md`.

At review time, CodeRabbit reads matching files from the source repository's default branch. Cross-repository guideline content is not pinned to a per-file revision, so later reviews can use updated content from that branch.

Object entries support cross-repository sources too: a `files` value can use the same qualified repository reference, and the entry's `applyTo` sets the paths in the reviewed repository that the guidelines in those files apply to. For example, a Python style guide in a central standards repository can apply only to `**/*.py` in every consuming repository:

> [tab] Using configuration file
>
> ```yaml .coderabbit.yaml theme={null}
> knowledge_base:
>   code_guidelines:
>     filePatterns:
>       - files: "engineering-standards:python/**/*.md"
>         applyTo: "**/*.py"
> ```

> [tab] Using web interface
>
> Under **Knowledge Base > Code Guidelines**, add a **File Patterns** row with the qualified reference in the **Files** field, for example `engineering-standards:python/**/*.md`, and the source-file patterns it governs in the **Apply To** field, for example `**/*.py`.

CodeRabbit does not treat cross-repository guidelines as repository-specific learnings.

Both entry forms apply when set through committed configuration files, the web interface, or [central configuration](https://docs.coderabbit.ai/configuration/central-configuration.md). [Pull request description overrides](#adding-guidelines-to-a-single-pull-request) do not yet honor object-form entries for guideline selection — use string entries there.

### How guidelines from another repository are scoped

CodeRabbit extracts the individual guidelines from each file it reads from another repository. The entry form decides which files in the reviewed repository each guideline applies to:

* **String entry.** A guideline applies only when its own text names the files it covers, such as a path, a folder, a file extension, or a glob. CodeRabbit reads that scope from the root of the reviewed repository. Guidelines that name no files are left out, and so are guidelines that say they apply across the whole codebase.
* **Object entry.** `applyTo` replaces each guideline's own scope. Every guideline in the matched files applies to the files `applyTo` matches, including a guideline that names other files.

This differs from guideline files in the reviewed repository, where a guideline that names no files applies within its file's directory, as described in [How scoping works](#how-scoping-works).

For example, `engineering-standards:frontend/react.md` contains three guidelines. The table shows where each one applies under each entry form:

| Guideline | String entry | `applyTo: "apps/web/**"` | `applyTo: "**"` |
| - | - | - | - |
| All `.tsx` files: use function components. | All `.tsx` files | All files under `apps/web/` | All files |
| Prefer async/await. | Not applied | All files under `apps/web/` | All files |
| Across the whole codebase, never log tokens. | Not applied | All files under `apps/web/` | All files |

To apply a file's guidelines everywhere, use an object entry with `applyTo: "**"`. To keep each guideline's own scope, use a string entry for files whose guidelines mostly name their files, and an object entry for files of general guidelines:

```yaml .coderabbit.yaml theme={null}
knowledge_base:
  code_guidelines:
    filePatterns:
      - "engineering-standards:frontend/react.md"
      - files: "engineering-standards:general/**/*.md"
        applyTo: "**"
```

Guidelines that apply only through `applyTo`, because they name no files, get low priority. When a review has more guidelines than its guideline budget allows, CodeRabbit leaves these out first.

`applyTo` takes only paths in the reviewed repository. If an object entry's `applyTo` has no usable path, CodeRabbit ignores the whole entry: it reads none of the entry's files and reports nothing about it in the review summary. This happens when `applyTo` is empty, contains only spaces or commas, or uses a `repo:path` value.

A [Claude Code rule](#claude-code-rules) file with `paths` in its frontmatter keeps its own `paths` under a string entry. An object entry's `applyTo` replaces them.

### Eligibility and access

* **Installation read access is required.** The CodeRabbit installation must be able to read the source repository so it can resolve and load matching files.
* **Administrator-approved sources in the same organization skip per-user checks.** A source in the reviewed repository's organization that is set through trusted organization, [central configuration](https://docs.coderabbit.ai/configuration/central-configuration.md), or target-branch configuration applies to every review, including for authors who cannot read the source repository directly.
* **Sources in another GitHub organization always need per-user access.** The pull request author must be able to read the source repository, and so must the user who triggered the review when that is someone else. This applies even when an administrator set the source or it comes from central configuration.
* **Not available on self-hosted CodeRabbit.** This feature requires CodeRabbit Cloud. That requirement is independent of whether your GitHub or GitLab instance itself is self-managed.
* **Knowledge Base persistence must be enabled.** Cross-repository sources are unavailable when `knowledge_base.opt_out` is `true`.

For sources introduced through a pull request or merge request, access checks depend on your Git platform:

> [tab] GitHub
>
> * **Author and pusher access is checked.** When a source is introduced through configuration on a collaborator's pull request branch, or through a [pull request description override](#adding-guidelines-to-a-single-pull-request), CodeRabbit confirms the pull request author can read the source repository and, if someone other than the author pushed to the branch, that they can read it too.

> [tab] GitLab
>
> * **Reporter-or-higher membership is required.** The merge request author and any distinct human account that triggers the review must have effective Reporter, Developer, Maintainer, or Owner membership in the source project. Guest membership does not qualify. Effective membership includes access inherited from a group or subgroup.
> * **Usernames must match exactly.** CodeRabbit resolves the exact GitLab username for an access check; prefixes and near matches do not qualify.
> * **Separate actor checks apply only when needed.** CodeRabbit skips the separate triggering-account check when the merge request author triggers the review or when CodeRabbit starts an automatic or command-triggered review.
> * **Project visibility does not replace membership.** Public or internal visibility without effective membership does not grant access to the source project for this feature.

Links in `AGENTS.md` or `CLAUDE.md` do not configure cross-repository retrieval: explicitly list the source files or globs in `filePatterns`.

Access checks fail closed. If CodeRabbit cannot confirm an identity or the required access, it omits that source and continues the review with the remaining guideline context instead of failing the review.

### Limits and validation

* **Entries.** You can configure at most 50 entries that name another repository. CodeRabbit counts distinct `repo:path` values, including each value in an object entry's `files`. Duplicates, entries that name the reviewed repository, and malformed entries don't count.
* **Entry length.** Each entry that names a repository can be at most 512 characters.
* **Files.** CodeRabbit reads at most 50 files per review from other repositories, counted across all sources after globs expand. Files from an object entry whose `applyTo` matches none of the pull request's changed files are skipped first and don't count.

When more files match, CodeRabbit reads source repositories in the order they first appear in `filePatterns`, with configured entries before entries from the pull request description. Within each repository, it takes files in alphabetical order by path. Files after the 50th are left out, and the review summary notes it. Keep `files` patterns narrow to stay under the limit.

CodeRabbit rejects absolute paths, parent-directory traversal, backslashes, malformed repository names, and entries with extra colons.

Only text and documentation files are read. A file is eligible when it has no extension, is a dotfile such as `.cursorrules`, or uses one of these extensions: `.md`, `.mdc`, `.txt`, `.rst`, `.json`, `.yaml`, `.yml`, `.csv`, `.log`, `.conf`, `.cfg`, `.ini`, `.toml`, `.xml`, `.html`, `.tsv`, `.ndjson`, `.jsonl`, `.adoc`, `.tex`, `.asc`. Source files such as `.ts` are skipped even though they are plain text.

### Data retention

Local guideline discovery is stateless. Cross-repository guideline sourcing stores content-derived guideline digests and is excluded for organizations that set `knowledge_base.opt_out`. See [Opt out of data retention](https://docs.coderabbit.ai/knowledge-base.md#opt-out-of-data-retention).

## Adding guidelines to a single pull request

Guideline sources can also be selected per pull request, which is useful when the standards that matter depend on what a pull request changes. Add a configuration override to the pull request description: the `@coderabbitai configuration override` line as plain text, outside any code block, immediately followed by a fenced YAML block.

````text Add guideline sources for this pull request only theme={null}
@coderabbitai configuration override

```yaml
knowledge_base:
  code_guidelines:
    filePatterns:
      - "platform-standards:security/**.md"
```
````

The override applies only to that pull request and changes nothing in your committed configuration. A description can hold more than one override block. An override accepts only these settings:

* `reviews.review_details`
* `reviews.path_instructions`: the entries are added to the configured [path instructions](https://docs.coderabbit.ai/configuration/path-instructions.md), and an entry for a path that already has instructions is skipped.
* `knowledge_base.code_guidelines.filePatterns`: the entries are added to the configured guidelines.

If a block contains any other setting, CodeRabbit rejects that block, applies none of its settings, and names the unsupported settings in the pull request.

Guidelines added this way apply only to that pull request, and only in addition to the guidelines your configuration already defines. They cannot replace or disable the configured set, so your organization's standards always still apply.

Because the selection lives in the pull request description, it can be written by hand or set programmatically. Tooling that opens or updates pull requests can choose the guideline documents that match the area of the codebase being changed, keeping the committed configuration to the standards that apply everywhere.

Path instructions and guideline entries require a pull request from a branch in the repository itself, opened by a repository collaborator, member, or owner. Pull requests from forks use the target branch's configuration, and their description accepts only `reviews.review_details`: CodeRabbit rejects a block from a fork's description that contains path instructions or guideline entries. Each repository a guideline entry names goes through the same per-platform access checks as other collaborator-introduced sources, described in [Eligibility and access](#eligibility-and-access) above. A source that fails them is skipped, and the review continues with your other guidelines.

## Guideline status in the review summary

The review summary reports the guidelines a review used separately from the problems CodeRabbit ran into. Applied guidelines get their own **🧰 Additional context used** entry at the top of the summary, and a source CodeRabbit could not use is reported as a warning in the note just above it.

### Guidelines that were applied

At the top of the review summary, below any note, expand **🧰 Additional context used** and open **📚 Code guidelines (N)**. It lists the guideline files that reached this review's prompt, one per line, plus any cross-repository sources added by the pull request description (see below). This block holds only the code guidelines. It is separate from the **🧰 Additional context used** section in the review details, which holds **📓 Path-based instructions** and the review's other context, and it appears even when review details are turned off (`reviews.review_details` is `false` by default).

Each repository file is labelled with where it came from:

* `configured`: the file matches one of your `code_guidelines.filePatterns`. This label takes precedence, so a file your patterns match is labelled `configured` even when CodeRabbit would also find it by name or as an Agent Skill.
* `auto-discovered`: CodeRabbit found the file by its name, for example `AGENTS.md`, `CLAUDE.md` or `.cursorrules`.
* `Agent Skill`: the file is a `SKILL.md` in a skill directory at the repository root, either `skills/<name>/SKILL.md` or the same path under `.agents/`, `.claude/`, `.codex/`, `.cursor/`, `.gemini/` or `.github/`, for example `.agents/skills/review/SKILL.md`. The `<name>` directory uses only lowercase letters, digits and hyphens. A `SKILL.md` at another path that your `filePatterns` match, such as `docs/review/SKILL.md`, is labelled `configured`.

Cross-repository sources appear in the same entry and the same count, whether they were configured for the organization or repository through `.coderabbit.yaml`, the web interface, or [central configuration](https://docs.coderabbit.ai/configuration/central-configuration.md), or added by this pull request's description. A configured source that CodeRabbit collected but then left out of the prompt is not listed. For example, the review's guideline budget can leave a source out. Sources added by this pull request's description are listed as CodeRabbit collected them, without that check, so one of them can appear in the entry even when the guideline budget left it out of the prompt.

```text theme={null}
📚 Code guidelines (5)
AGENTS.md — auto-discovered
.agents/skills/review/SKILL.md — Agent Skill
docs/guidelines.md — configured
acme/standards:security/auth.md
acme/standards:backend/api.md
```

On a public repository, a cross-repository source name could reveal a private repository, so those are counted instead of listed. The repository's own guideline files are already public, so they are still named:

```text theme={null}
📚 Code guidelines (5)
AGENTS.md — auto-discovered
.agents/skills/review/SKILL.md — Agent Skill
docs/guidelines.md — configured
2 cross-repository guideline sources
```

This entry describes the review that wrote the summary. If a later review of the same pull request applies no guidelines, the entry does not appear, the same way the path-based instructions in the review details describe only the files that review looked at.

### Sources CodeRabbit could not use

A note at the top of the summary appears only when something needs your attention, and lists **Skipped guideline sources (N)** with the reason next to each one, along with any configuration parse errors or warnings. CodeRabbit continues the review with local guidelines and other reachable sources, so a skipped source does not block the review. When every source was usable, the note does not appear at all.

```text theme={null}
Skipped guideline sources (1)
acme/standards:missing/**/*.md — no matching files were found in its default branch
```

Each skipped source shows one of these reasons:

| Reason | Meaning | What to do |
| - | - | - |
| `couldn't be accessed (not found, or no read access for the PR author or the user who triggered this review)` | The repository doesn't exist, or CodeRabbit, the pull request author, or the user who triggered the review can't read it. | Check the repository name and the access described in [Eligibility and access](#eligibility-and-access). |
| `names a repository outside this repository's organization` | The source is outside the boundary your Git platform allows. | Move the guideline file to a repository within that boundary. |
| `invalid entry; expected repo:path or owner/repo:path with a relative file path` | The entry is malformed. | Fix the entry as described in [Limits and validation](#limits-and-validation). |
| `not applied; the limit of 50 cross-repo guideline entries was reached` | The entry came after the 50th entry that names another repository. | Remove or combine entries. |
| `not applied; the limit of 50 cross-repo guideline files was reached` | The 50-file limit was reached before CodeRabbit got to this source. | Narrow the `files` patterns of your entries. |
| `only some of its files were applied; the limit of 50 cross-repo guideline files was reached` | The 50-file limit was reached partway through this source. | Narrow the `files` patterns of your entries. |
| `no matching files were found in its default branch` | The path or glob matches no file on the source repository's default branch. | Check the path against the default branch. |
| `couldn't be fetched` | CodeRabbit couldn't fetch the source's files. | Request another review. |
| `not applied; the time budget for fetching guideline sources ran out` | Fetching guideline sources took longer than the review allows. | Request another review, or reduce the number of sources. |
| `some of its guidelines couldn't be extracted and were left out` | CodeRabbit left out guidelines it couldn't extract from the source. The reason can end with the number of rules not found word for word in the source. The rest of the source applies. | No action is needed. |
| `not applied; its files were read, but processing them failed` | CodeRabbit read the files but couldn't process them. | Request another review. |
| `some of its rules have no file scope of their own and were not applied; add applyTo to this filePatterns entry` | Shown once per source repository. A string entry selected files in which some guidelines name no files. Those guidelines were left out, and the rest apply. | Add an object entry with `applyTo` for those files. |
| `N rules extracted, none applied; add applyTo to this filePatterns entry` | Shown once per file, labelled `owner/repo:path`. No guideline in the file names the files it covers, so none of them apply. | Add an object entry with `applyTo` for the file. |

The two reasons that end with `add applyTo to this filePatterns entry` mean that CodeRabbit left out some guidelines, not that the source failed. See [How guidelines from another repository are scoped](#how-guidelines-from-another-repository-are-scoped).

On a public repository this block keeps the reason next to each source, but sources from your configuration appear as `a configured source` instead of by name. Sources named in the pull request description are listed as written.

> [!NOTE]
>
> To see which guidelines are configured for a repository, visit the **Code Guidelines** page in the CodeRabbit UI.

## Configuration reference

```yaml .coderabbit.yaml theme={null}
knowledge_base:
  code_guidelines:
    enabled: true
    filePatterns:
      - "**/CODING_STANDARDS.md"
```

**enabled** `boolean` (default: true)

Apply your organization's coding standards during reviews.

**filePatterns** `array of object`

Additional guideline files, as glob strings or `{ files, applyTo }` objects. A string entry such as `**/CODING_STANDARDS.md` locates guideline files. An object entry sets `files` (the guideline documents) and `applyTo` (the source files they govern, for example `**/*.ts`), each a comma-separated list of globs. Either form can name a file in another repository of your organization as `repo:path` or `owner/repo:path` (for example `engineering-standards:frontend/react.md`), read from that repository's default branch. On Azure DevOps Services, use `repo:path` within the reviewed project or `org/project/repo:path` for another project in the same organization; write project names with literal spaces. Supplements the [default patterns](https://docs.coderabbit.ai/knowledge-base/code-guidelines.md#supported-files); does not replace them. File names are case-sensitive.

Full reference: [Code guidelines](https://docs.coderabbit.ai/reference/configuration.md#param-knowledge-base-code-guidelines)

> [!NOTE]
>
> Setting `filePatterns` to an empty list (`[]`) keeps the default patterns active. To disable code guidelines entirely, set `enabled: false`.

## What's next

> [card] [Knowledge base overview](https://docs.coderabbit.ai/knowledge-base.md)
>
> Learn about all knowledge base capabilities: learnings, code guidelines, and linked repositories.

> [card] [Learnings](https://docs.coderabbit.ai/knowledge-base/learnings.md)
>
> Teach CodeRabbit your team's review preferences through natural conversation.

> [card] [Configuration reference](https://docs.coderabbit.ai/reference/configuration.md#knowledge-base)
>
> Full reference for all `knowledge_base` configuration options.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.