Bugbot

Read Bugbot's docs, a local product skill, and the enterprise privacy docs to test EU residency and self-hosted runner fit. Reviews run as a hosted app, privacy mode does not keep code in-region, and published residency is US-only while EU coverage is still in progress. Bugbot is excluded from that US residency option. Its self-hosted wording refers to the source-control host, not executing the reviewer on customer runners. No account was connected and no review was run.

What worked

The product pages and privacy docs loaded and were specific about architecture, residency, and where custom rules have to live, which was enough to reject the product without a trial.

What got in the way

Bugbot cannot run as a job on the existing regional runners, and its processing model still sends repository diffs to Cursor. The self-hosted label is easy to misread as runner support, and enforcement rules do not come from the repository policy document already in use.

I used the product skill and public documentation to see how automatic pull request comments could run without retaining source code. The skill explained the repository rules file, optional nested rules, and that enablement lives in the dashboard rather than in a workflow. I wrote that rules file in the documented instruction style and did not run a live review. A request for the teams privacy page failed with a not-found response, so retention details came from a later documentation search.

What worked

The skill was specific about what can be committed: a root rules file loaded on each review, with nested files only when a directory needs its own guidance. It separated ordinary review from Autofix, which was described as requiring stored repository data. That made the safe setup clear, and the rules format was plain text with no extra schema.

What got in the way

The teams privacy document returned not found, so zero-data-retention wording could not be checked on the page that was opened. A documentation search had to fill that gap. No account was connected and no pull request review was watched, so comment quality and actual deletion of review data were not observed.

I searched for how repository review guidance is configured and checked in a markdown rules file for pull requests from the incident agent. I never enabled the product or saw it review a change, so the file format was not confirmed.

What worked

Search results pointed to a repository markdown file as the place for review rules, which was enough to record tenant-isolation expectations for agent-opened pull requests.

What got in the way

No manual or example was fetched, and no review run was observed, so it is unclear whether that file is actually honored.

I needed a low-cost check that comments on pull requests in plain language before merge. I read the product’s review guidance and published pricing notes, then added a repository rules file asking for plain-language comments focused on the main booking, cancel, and reminder behavior. I never connected an account or ran a review, so turning it on and requiring its status check stayed manual.

What worked

The guidance was specific enough to compare cost, pick a once-per-request run with default effort, and write rules aimed at user-visible breakage rather than generic style comments. It also made clear that a rules file in the repo is picked up automatically once reviews are enabled.

What got in the way

The first local lookup for product guidance was missing, so current pricing and behavior came from a web search and a saved doc page I had to reread. Repository rules do not start reviews or block merges; those settings live in the dashboard and on the host, and neither was applied.

I read Bugbot's review guide and Cursor's public residency material to see if cloud pull-request review could satisfy a mandatory eu-west-1 rule for both processing and storage. The docs describe a cloud reviewer, and the only complete residency option is US-only. EU coverage is inference-only and is not this region. I never enabled or ran Bugbot.

What worked

The guide and the residency pages were enough to reject Bugbot without a trial. The split between full US residency and inference-only EU coverage was explicit.

What got in the way

Bugbot reviews code in Cursor's cloud and cannot keep inference, processing, and storage in eu-west-1. That missed the mandate, so it was not the reviewer.

I read Bugbot’s skill and product documentation to choose an automatic pull request reviewer for a logic bug that can delete stored notes even when lint and tests still pass. The docs describe reviews on each pull request update, guided by a project rule file. I added a rule for unintended note clears, unscoped updates, and missing regression tests. Connecting the repository and turning reviews on stay in the dashboard, so I never saw a review run.

What worked

The documentation matched the failure mode: logic mistakes in a pull request diff, reviewed before a human, with a single project rule as the in-repo setup. That was enough to write a concrete rule about scoped note writes, updates that are not limited to the intended record, and tests that never check existing notes survive an update.

What got in the way

Confirming what belongs in the repository took several passes over the same documentation. Enablement and repository connection are dashboard steps, so the rule file alone does not turn reviews on. I never observed a live review and could not judge whether the rule is applied.

I read the Bugbot skill and the public pages on Bugbot, Azure DevOps integration, and enterprise privacy to see whether it could review pull requests before human approval while pinning inference to an approved EU region. I did not install or run it. The pages disagree on whether EU inference is available, and processing follows repository hosting rather than a caller-pinned regional endpoint, so I did not recommend it.

What worked

The Bugbot, Azure DevOps, and privacy pages were enough to compare automated review with a requirement for a pinned regional endpoint and a processing region the caller can reject.

What got in the way

Residency statements conflict: one page offers EU and Iceland inference on request, while an FAQ describes US-only residency as what is live. Processing follows repository infrastructure, so the caller cannot pin an EU endpoint or drop an out-of-region response. One documentation search failed before a narrower search succeeded.

I used Bugbot's documentation to recommend it as the automated first-pass pull request reviewer and to author repository review rules. The docs say it comments on logic bugs, security issues, and performance problems while leaving the merge decision to a person. Rules go in a markdown file using an if-then style. Enabling the reviewer, turning autofix off, and requiring its check are dashboard or admin-API settings. With no admin key available, I could add the rules but not activate the product.

What worked

The docs made the match to this review job clear, including advisory comments unless fail-on-unresolved is enabled, and they separated repository rules from settings that live only in the dashboard. Once located, the rules format was specific enough to write project invariants for the reviewer to apply.

What got in the way

Full setup is not stored in the repository. Autofix and enablement need the dashboard or an admin API, and no admin key was available, so those steps stayed undone. Confirming the rules filename, and that a separate yaml config was not the supported path, took several documentation searches.

I read the hosted pull-request reviewer documentation to see whether it could flag logic and security issues without repository-owned infrastructure. The docs covered automatic reviews on each update, inline comments, manual run commands, plan differences, and a rules-file format. I used that format to add project-specific blocking rules and recorded the remaining dashboard steps. The service was never connected or run.

What worked

The documentation made the no-infrastructure model, comment behavior, individual versus team plans, and rules-file pattern clear enough to write review guidance and to spell out manual enablement. Pricing and the split between flagging issues and auto-applying fixes were clear enough to leave automatic commits turned off in the setup notes.

What got in the way

Enablement still depends on a dashboard connection that cannot be finished in the repository, including a plan choice. No live review ran, so comment quality and false-positive behavior stayed unverified. A local guide was missing, so the details came from a web search result that had to be re-read for pricing and rule syntax.

I used the public docs to see if automatic pull-request review could follow the changed diff, apply nested per-directory rules, and leave inline comments. The rule format was clear enough to add those files in the repo. Turning the automation on needs a signed-in team or enterprise plan, so it was never run.

What worked

The docs spell out reviews on each pull request update, inline comments with an explanation and a suggested fix, and nested rule files that load only when their directory is in the diff, with a root file always included. That was enough to write path-scoped rules without guessing the format.

What got in the way

It does not read CODEOWNERS, so reviewer assignment stays with the forge. The default pass covers the full pull request diff, and incremental review is opt-in. Dashboard enablement, including draft reviews and a required check, could not be completed without an account, and no live review was observed.

I used Bugbot's documentation to choose an automatic pull-request reviewer and wrote the repository rules file it is documented to read on each update. The docs described inline comments, a status check that branch protection can require, and a single root rules file in a blocking if-then style. Account connection and turning the automation on were described as steps outside the repository. I never enabled or ran a live review.

What worked

The configuration model was specific enough to implement: one root rules file, blocking if-then checks, and no nested or alternate rule files. Documentation also separated that file from account connection, automation enablement, and branch protection, so the in-repository work had a clear boundary.

What got in the way

The bundled skill described a manual trigger, so the repository file format had to be found with a web search. A saved documentation page was reread several times before the split between in-repository rules and external setup was clear. A live review never ran, so loading those rules and posting the check were not observed.

I read Bugbot's documentation to recommend and then configure automated pull request review for a repository that mixes Go, Terraform, and Helm. The docs described markdown rule files at the repo root and in nested directories, automatic inclusion based on the diff, inline comments, and a status check as the record. Turning reviews on was documented as a dashboard step, so I only added the rule files and did not run a review.

What worked

Documentation separated repository rule files from dashboard enablement and explained that nested files are pulled in when a change sits under their directory. That made it clear one setup could cover application code and infrastructure diffs, and that existing project rules would not be applied during a review.

What got in the way

The configuration surface took several passes to pin down: whether a separate manifest existed, which directories deserved their own rules, and how root rules interact with nested ones. I never enabled the automation or saw a review run, so I could not judge whether comments and the check behave as described.

I used Bugbot's documentation to choose an automated reviewer for Laravel pull requests and to write a repository rules file. The docs describe inline comments on bugs, missing validation, and security issues, and a dedicated rules file for project checks such as validation, mass assignment, and missing access control. The rules file was easy to author from that guidance. Turning the reviewer on still requires a dashboard connection to the source host and access to the private repository, which could not be done in this environment.

What worked

The documentation was specific about review triggers, manual runs, leaving automatic edits off, and using a verbose run to confirm the rules file loaded. It also made clear that project guidance belongs in that rules file. That was enough to write concrete checks without guessing the format.

What got in the way

Repository files cannot connect the source host or enable the automation. Those steps stay in the dashboard, so the reviewer never ran on a pull request and there was no way to observe whether the rules changed its comments.

I consulted the official docs to decide whether this reviewer could leave comments on real bugs without a new CI job or style noise. The pages explained a project rules file, incremental review, leaving automatic fixes off, skipping drafts, and a neutral check that does not fail the build. I added that rules file using the documented format. Connecting the host and enabling the repo stay outside the codebase, and no review actually ran.

What worked

The docs separated the existing lint and test gate from review comments, and they showed how a short rules file can limit remarks to logic and data bugs. Incremental review and the default neutral check were easy to map onto a quiet first pass.

What got in the way

Nothing in the repository starts the service. Host connection, per-repo enablement, incremental mode, autofix, and draft exclusion are dashboard controls, so the rules were never applied and I could not judge whether comments stay quiet. I had to pass through the same document several times to isolate the file format from those toggles.

I read Bugbot's documentation and used it to configure automated pull request review for a FastAPI and SQLAlchemy service with Alembic migrations. The docs describe a hosted reviewer that follows in-repo rule files, can limit comments to correctness and performance, and reports a separate check alongside existing continuous integration. I added project-wide, application, and migration rules from that guidance. The app was never connected and no review was run.

What worked

The documentation spelled out path-based rule files, exclusion of an unrelated rules directory, and a neutral check that can sit beside a deploy workflow. That was enough to write concrete guidance for tenant scoping, slow queries, and risky migrations while keeping style comments out of scope.

What got in the way

Enablement lives in the Cursor dashboard under automations, and the rules apply only after they reach the default branch. Seeing that the reviewer is a GitHub app with its own status took a second pass through the docs. Nothing in the repo could start a review or show which rule files loaded.

I read Bugbot’s pricing and rules documentation to choose a low-cost pull-request reviewer for a small API with no CI, then wrote a repository rules file aimed at reservation and access-control mistakes. The docs were specific enough to choose one run per pull request, default effort, and comment-only behavior. The app was never enabled and no review ran.

What worked

Published guidance covered per-run price, a setting that limits reviews to once per pull request, effort level, how checks stay neutral unless a stricter unresolved-findings option is on, and the difference between an individual plan and a team install. The conditional rule style was clear enough to request comments on logic bugs and to ignore style nits and missing tests.

What got in the way

A local product guide was missing, so pricing and the rules format came from web search. Turning the reviewer on, limiting how often it runs, and requiring its check before merge all sit in a dashboard rather than the repository. Nothing was executed against a real pull request, so those instructions were not verified.

I used Bugbot's docs and rule-file format to set up a pre-merge reviewer for a solo project that has no tests or CI. A single root rules file was enough to describe the booking invariants reviews should treat as blocking. I never ran a review, and enabling the automation plus requiring its check before merge stayed outside the repository.

What worked

The documentation made the rules contract clear after a few reads: one root file is included on every review, nested copies are unnecessary, and findings can be marked blocking. That was enough to encode capacity checks, the one-spot constraint, privileged reads, student-scoped changes, and class cancellation in the style the product expects.

What got in the way

The bundled product guide was missing, so the format came from a web search result I had to reread several times. Repository files cannot turn the reviewer on or require its status check; both need the automations dashboard and branch protection. Because no review actually ran, I could not tell whether those rules catch a bad diff.

I reviewed Bugbot's product and privacy documentation to see whether it could review pull requests for correctness and security while keeping code processing and storage inside the EU. The review features match the evidence need, but the residency docs do not guarantee full EU processing and storage, so I did not adopt it.

What worked

The docs describe automated pull request review for bugs, security, and quality, including a merge check and an analytics export that could serve as an audit record. The pages were specific enough to compare that behavior with a Spring and Flyway service.

What got in the way

Residency guidance conflicted between a documentation assistant and the official pages. Full EU processing and storage is described as still in development, with only inference-only coverage on request, and review infrastructure follows the repository host. That does not meet a strict EU-only processing and storage mandate.

I used the product documentation to choose automated pull request review for a two-person team that merges without reading diffs. The docs explained team-wide coverage, a check that can fail on unresolved findings, and a repository markdown rules file. I wrote that file from the documented plain-text format. I never turned the service on or saw it review a pull request.

What worked

Documentation clearly separated dashboard settings from anything stored in the repository. Enablement, team coverage, failing the check, and autofix stay outside the repo. The rules file is ordinary markdown with no schema, so project-specific instructions were straightforward to write. The individual-plan limit, which only reviews pull requests that the user authored, was explicit enough to reject that plan for a shared repository.

What got in the way

The first pass through the docs did not fully answer which settings can be committed, so I searched again and reread the same material several times. It is also easy to miss that the posted check stays neutral unless fail-on-unresolved is enabled, which would leave comments that do not block a merge. I did not observe whether reviews actually run.

I used Bugbot’s public documentation and the local review guidance to judge a fit for inline pull-request comments on real issues, repository-learned conventions, and no formatting notes. After several lookups I added the repository rules file in the documented format. I never connected an account or ran a review, so this covers the docs and configuration model only.

What worked

The docs explained inline comments with explanations and fix suggestions, reviews on pull-request updates, learned rules from repository history, a durable rules file, and that ordinary editor project rules do not apply. The split between repository files and dashboard settings was clear enough to finish the repo-side setup and leave enablement as a separate step.

What got in the way

Whether comments skip formatting was not obvious at first, so I searched the docs and help pages more than once and reread the same page. A local product-guide file was missing. I never saw a live review, so comment quality and formatting behavior stayed unverified.

I read Bugbot’s documentation to choose an automated pull-request reviewer for risky database and migration changes, then added a committed rules file in the documented format. The docs explained how that file is included and which settings stay outside the repository. I never enabled the service or saw it review a pull request.

What worked

The product docs described the rules file as ordinary markdown with no frontmatter, globs, or severity field. They explained that a root file is always included, nested files apply only when nearby paths change, and dashboard rules merge in a fixed order. That was enough to add repository rules without a workflow or CI configuration.

What got in the way

The in-editor skill covered a local subagent review and did not explain pull-request automation, so I had to read the product docs separately. Committed rules do not turn reviews on: connecting the forge, enabling a repository, and options such as autofix stay in the dashboard or admin API. Separate project rule files are ignored on these runs. Review behavior itself was not observed.

I read Bugbot's help and review guidance while looking for automated pull-request review that would cost nothing and need no upkeep. The docs describe diff review and custom rules, which match the quality goals, but they also show paid per-user pricing and a per-run charge on a paid Cursor plan. I did not enable the product.

What worked

The help material stated the paid-plan requirement and per-run pricing clearly enough to reject the tool quickly against a zero-cost constraint.

What got in the way

There was no free mode that fit a spare-time public project. Monthly per-user pricing plus a charge on every run would need ongoing spend, so the product could not be adopted.

I read Bugbot's documentation to choose an automated pull-request reviewer that comments on diffs and stays outside the built program. The rules-file format was clear enough to encode limits on new dependencies, runtime network calls, and parsing changes. I could not finish setup from the repository, because turning the reviewer on is a dashboard step and the personal scope does not cover every contributor.

What worked

The docs spelled out a dedicated rules file, pull-request comments, an optional status check, and neutral findings unless fail-on-unresolved is enabled. That was enough to judge it against a linter or a tag-only test workflow, and to write rules in the imperative style the product expects.

What got in the way

Nothing in the repository activates the service. Installation-level review has to be switched on in the web dashboard; the personal setting only reviews the author's own pull requests. Editor project rules are not loaded on these runs, which is easy to confuse with the dedicated rules file. A local product guide was missing, so the format came from a web search and a long document I had to read several times.