Bugbot raised a high-severity regression finding on PR #471 even though the PR description explicitly stated that the relevant DB fields would be migrated to support full-sentence values. The review comment recommended adding a data migration, which was already documented in the PR description written by the AI agent used to solve the ticket.
Bugbot appears to review the diff in isolation and does not incorporate PR description text as context when evaluating whether a flagged issue is already addressed by the implementation plan described in the PR.
Steps to Reproduce
Use a Cursor AI agent to solve a ticket and open a PR — the agent generates a detailed PR description, including a note that existing DB fields will be migrated to support full-sentence values.
Enable Bugbot on the repository.
Let Bugbot review the PR.
Observe that Bugbot flags a high-severity regression (e.g. “short names spoken alone”) and recommends adding a data migration — the exact same mitigation already documented in the PR description.
Note that Bugbot’s comment makes no reference to the PR description and appears to have reviewed the diff in isolation.
Hey, thanks for the detailed report. Here’s the good news: Bugbot actually does not review a diff in isolation. It gets the PR title and description as context, and it’s explicitly instructed to use them to understand the intent of the changes. So it did see the description.
What actually happened: the description says the fields will be migrated, which is future intent, but the migration itself is not in the diff for this PR. Bugbot judges based on the code state at merge time. If this diff lands as-is without the migration, the short names spoken alone behavior breaks. That’s why it flagged a regression. This is not ignored context, it’s a judgment call: a planned migration is not the same as an implemented migration. Also, Bugbot often does not reference the description in its comment even when it used it, which can make it feel like it did not read it.
How to reduce these false triggers:
Include the migration in the same PR, or link to a specific PR that contains the migration in the description.
Add a .cursor/BUGBOT.md file with a rule describing the migration plan and how Bugbot should account for it during review. Docs: Bugbot | Cursor Docs. Note: Bugbot reads .cursor/BUGBOT.md specifically, it does not consider files in .cursor/rules/.
If the migration plan is already described in a separate docs file, .cursor/BUGBOT.md supports relative links to other .md and .mdc files in the repo, so you can link to it instead of duplicating the text.
If you believe it’s a false positive, dismiss the comment as false positive.
@deanrie thanks! One thing is that the data migration is handled by a separate repo, I have added it as a skill that rule but it seems to be ignored by Bugbot. How about you advise Bugbot to let us know about that?Add it as a managed rule, add it in the readme of the repo? I want to avoid adding it for each repo as we have quite a lot.
Here’s the catch: Bugbot only reads context from .cursor/BUGBOT.md inside the repo itself, plus Team Rules and repository rules learned or manual from the dashboard. It doesn’t pick up Skills or files from .cursor/rules/, so what you added as a skill or rule is being ignored.
For your case, when you don’t want to duplicate this across every repo, Team Rules are what you want. They apply to all repos in the team dashboard > bugbot > team rules. You actually recommended this in another thread. Add a rule there that says DB field migrations to full sentence values happen in a separate repo, and Bugbot shouldn’t flag a missing migration in the diff if it’s documented or planned.
A couple helpful notes:
Rule priority from the docs: Team Rules > repository rules learned plus manual > project BUGBOT.md including nested > User Rules. Team Rules come first, so if a specific repo has a conflicting BUGBOT.md, the Team Rule wins.
Inline learning for one repo: you can write @cursor remember [fact] in a comment on any PR, and Bugbot will save it as a learned rule for that repo. It’s a good targeted option, but it’s per repo, not org wide. For a rule across all repos, you still want Team Rules.
One more thing about cross repo behavior: Bugbot won’t go into another repo to read its files. It only sees the current repo PR plus the text in Team Rules, repository rules, and BUGBOT.md. Relative links only work for .md and .mdc inside the same repo. So the migration convention text needs to live directly in the Team Rule or in BUGBOT.md, not as a link to a file in another repo.
Let me know if Bugbot still flags it after you set up the Team Rule.
But If I wanna make it aware about external repos, like here are the APIs calling you, make sure you don’t break that flow, where is the best place to add that info? is the readme.md enough from that project? or should I make sure that the code has proper documentation?
Bugbot only reads the current repo PR diff and files in this repo, plus Team Rules, repository rules, and .cursor/BUGBOT.md. It does not open other repos, so it won’t see readme.md from an external project. That’s not a workable way to pass context.
If you want Bugbot to know about external API consumers and not break their flow, the info needs to live in the repo being reviewed:
Describe the contract right in .cursor/BUGBOT.md in the repo that serves the API. For example: “Endpoints /x, /y are called by service Z, don’t change their signatures or response shape without alignment.” This is the most reliable channel.
If you don’t want to bloat BUGBOT.md, move details into a separate .md or .mdc file in the same repo and link to it from BUGBOT.md using a normal markdown link. Bugbot follows those links and pulls the linked file into the review context. So you can keep BUGBOT.md as a light table of contents, and put the contract in docs/api-contracts.md and link it. Limits: only .md or .mdc, only relative paths, you can’t go above the repo root, and you can’t link to an external repo.
If a rule applies to multiple repos, put it in Team Rules dashboard > bugbot > team rules so you don’t duplicate it.
Docs in the code docstrings and comments near endpoints also help since those files are in the repo being reviewed. But the contract text in BUGBOT.md or a linked .md, or a Team Rule gives a more predictable result.
Main point: since the migration and calling services live in other repos, Bugbot won’t see them. You need to describe the convention in text within the current repo boundaries BUGBOT.md, a linked .md, or a Team Rule, not rely on files in external projects.
Let me know if, after setting this up, Bugbot is still flagging the wrong things.