Can I add instructions to BugBot for code reviews?

Yes. Cursor Bugbot takes instructions from .cursor/BUGBOT.md files in the repository, from team rules that admins write in Bugbot Automations for all repositories of a team, and from repository rules: learned ones, which Cursor generates "from your team's activity on GitHub" or saves from a @cursor remember [fact] comment, and manual ones written for a single repository. Cursor project rules (*.mdc files in .cursor/rules/) do not apply to Bugbot runs on their own, but a .md or .mdc file linked from .cursor/BUGBOT.md counts as its own rule. Cursor's help page gives the limits: "Rules are limited to 30,000 characters each, and 100,000 characters combined per review." A bugbot run verbose=true comment on the pull request makes Bugbot list the rules it used.

Which branch .cursor/BUGBOT.md is read from is not stated on Cursor's Bugbot docs or help page as of 7 November 2026; GitHub writes that Copilot reads its instructions from the pull request's head branch, and Anthropic that Code Review reads REVIEW.md from the base or default branch.

Every fact below comes from each vendor's own pages as I read them on 7 November 2026, and none of them saw this text before publication.

How to add instructions to Bugbot

Following Cursor's Bugbot docs, there are four ways to put your rules into a review and one way to see which rules it used. When several sources apply, "Bugbot merges them into one review-rules block.", in this order of inclusion: team rules, then .cursor/BUGBOT.md files including the nested ones, then learned rules, then manual rules.

1. Write .cursor/BUGBOT.md files. Cursor's docs say "Create .cursor/BUGBOT.md files to provide project-specific context for reviews." The root file goes into every review, and a file in a subfolder joins when the pull request changes code below it: "Bugbot always includes the root .cursor/BUGBOT.md file and any additional files found while traversing upward from changed files." Cursor's own example tree keeps one file at the project root and others in backend/, backend/api/ and frontend/.
2. Link the rule files you already keep. In Cursor's words, "Every .md or .mdc file linked from a .cursor/BUGBOT.md file counts as its own rule with its own 30,000-character limit, and Bugbot loads each linked path once." Linking from .cursor/BUGBOT.md is one way to bring an existing Cursor project rule into a Bugbot review.
3. Add team rules. "Team admins can create rules in Bugbot Automations that apply to all repositories in the team." Cursor adds that "These rules are available to every enabled repository, making it easy to enforce organization-wide standards.", and its section on limits says that past the 100,000-character cap "some rules may be omitted." and "Required team rules are prioritized over non-required rules."
4. Let Bugbot learn rules, or write them by hand. Manual rules are created on Bugbot's repository rules page, and a learned or manual rule can be limited to an optional glob such as src/components/** or left to cover the whole repository. Manual rules apply only while learning is on where the Automatically Learn Rules switch exists; Cursor notes that Azure DevOps has no such switch, and hand-written repository rules still apply there.
5. Look at what a review used. "Comment bugbot run verbose=true or cursor review verbose=true on a pull request." The docs go on: "Bugbot posts a table of every rule included in that run and flags any that were truncated or omitted."

The question behind this page came from a team lead who had just turned Bugbot on and asked whether it could also confirm that a pull request does what its issue asks for, and flag code comments left in Portuguese. The second need is an ordinary rule in .cursor/BUGBOT.md, written the way a reviewer would say it, for example Code comments are written in English. Flag any new or changed comment in another language. The first can be written as a rule in the same plain words. Cursor's blog describes rules as "additional instructions that enable greater customization of Bugbot runs", so a rule tells the review what to look for: a verbose=true run on a test pull request shows that the rule was loaded, and the review's comments show what came of it.

Rules Bugbot writes for you

With learning on, Bugbot also writes rules itself. It builds learned rules "from your team's activity on GitHub for that repository", or from the repository's history when someone backfills it, and it learns from a pull request once that pull request is merged or closed. Cursor names the cases where learning does not happen: "Learning doesn't run on a repository set to manual-only or, on an individual account, when your personal settings run Bugbot" only when mentioned, and turning off Automatically Learn Rules "stops it for that organization." A single fact can be taught directly: after a @cursor remember [fact] comment on any pull request, "Bugbot saves the fact as a learned rule and applies it to future reviews." The learned set does not stay fixed either, since "Cursor will automatically enable or disable rules as it learns more about your team's activity over time." Manual rules follow the same switch, as step 4 above says, and for each rule Cursor's analytics count the findings that involve it and the share of those the team accepted.

Other reviewers learn as well, each by its own route. CodeRabbit says "it learns your team's code-review preferences based on chat interactions" and uses these learnings "as additional context or instructions for its comment." Greptile writes that "Greptile automatically infers custom rules from team behavior without manual configuration". For Copilot code review, GitHub describes Copilot Memory: "When repository settings and applicable policies allow it, Copilot can store useful details it has learned about a repository and use them when reviewing pull requests." GitHub's changelog of 28 October 2026 adds Code review customization, a part of Copilot dreaming that "turns recurring accepted code-review feedback into guidance for Copilot code review."; dreaming is "now in public preview", "Dreaming is opt-in.", and "Changes to checked-in skills and instructions are proposed in pull requests for your team to review."

How other PR reviewers take your team's instructions

For a team that runs a second reviewer next to Bugbot, or is still choosing one, the table puts three questions about code review instructions to five reviewers: which files in the repository it reads, what can be set outside the repository, and which branch the repository files come from.

A cell says what each vendor's own pages say, as read on 7 November 2026; "not stated" means the pages named did not say it that day, not that the product lacks it.

Why the branch matters

The branch decides whether a pull request can change the instructions that its own review follows. When a reviewer reads instructions from the head branch, a pull request that edits them is reviewed under the edited version, and GitHub gives that as the purpose of its choice for Copilot: "so you can test changes to them in the same pull request without merging them first." When a reviewer reads from the base branch, the pull request under review cannot rewrite its rules for itself. Cursor says this about its settings file, "Bugbot does not read the PR head version, so a PR cannot change how Bugbot reviews itself.", Greptile says it about auto-approval in greptile.json, "Greptile reads this from the PR's base branch, so a PR cannot loosen it for itself.", and Anthropic puts it as an order of steps: "To change review behavior, merge the REVIEW.md change first."

For its settings file Cursor adds "Use code review and CODEOWNERS to control who can change this file." Applying the same step to instruction files such as .cursor/BUGBOT.md, .github/copilot-instructions.md, REVIEW.md or .greptile/rules.md is a suggestion of this text, not of a vendor. Where the branch is not stated, as for .cursor/BUGBOT.md, a test pull request that edits the file, with a bugbot run verbose=true comment on it, shows what that review included.

One set of rules for two reviewers

Several files serve more than one reviewer, by the vendors' own docs. Copilot code review reads AGENTS.md from the repository root, where GitHub suggests you "use AGENTS.md for standing rules you want to share across AI tools and agents", and it also reads CLAUDE.md, GEMINI.md and REVIEW.md. A path-specific *.instructions.md file can also be kept from the reviewer: "Optionally, to prevent the file from being used by either Copilot cloud agent or Copilot code review, add the excludeAgent keyword to the frontmatter block." CodeRabbit finds guideline files by name, its default list includes AGENTS.md, CLAUDE.md, .cursorrules, .cursor/rules/* and .github/copilot-instructions.md, and its review summary lists the guideline files a review used. Claude Code Review reads CLAUDE.md as project context and REVIEW.md as review instructions. Bugbot takes .cursor/BUGBOT.md, the .md and .mdc files linked from it and the rules in Automations, while .mdc files in .cursor/rules/ do not apply to its runs on their own. A rule file you already share with another reviewer can be linked from .cursor/BUGBOT.md; Cursor then counts it as its own rule, and bugbot run verbose=true shows whether a review included it.

A shared file reaches each reviewer within that reviewer's limits. For Bugbot these are the limits per rule and per review given at the top of this page. For files pulled into REVIEW.md, which Code Review includes only "when it reads REVIEW.md from a protected branch", Anthropic says to "include at most eight different files, and keep REVIEW.md and the files it includes under 150,000 bytes combined." GitHub's tutorial for Copilot code review advises "Limit any single instruction file to a maximum of about 1,000 lines.", warns that "Copilot may not follow every instruction perfectly every time.", and lists kinds of instruction that Copilot code review "currently does not support", among them "Block a PR from merging unless all Copilot code review comments are addressed".

Sources and method

Every page below was read on 7 November 2026, each quotation was matched word for word against its page that day, and this text describes the pages as of that date. For how Bugbot and CodeRabbit compare on hosts, triggers and billing, see CodeRabbit vs Bugbot?; for a wider comparison, see this overview of AI code reviewers.

Cursor: Bugbot docs, Bugbot help, learned rules, 8 April 2026

GitHub: Copilot code review, using code review, repository instructions, organization instructions, customizing code review, changelog, 28 October 2026

Anthropic: customizing Code Review

CodeRabbit: YAML configuration, path instructions, code guidelines, learnings

Greptile: .greptile/ configuration, configuration reference, greptile.json reference, memory and learning