AI Learn
Cursor · Practical Tutorial

Use Cursor Bugbot to review a pull request without turning it into auto-merge

Configure PR review rules, run Bugbot automatically or on demand, verify findings and use autofix only behind an explicit human merge decision.

Reviewed September 20, 2026Independent tutorialFeatures may vary
Not official support. AI Learn is an independent education site. Check the provider’s current documentation for plan-specific limits, pricing and feature availability.
Before you start

Bugbot can review PR diffs for bugs, security and code quality. Keep branch protection and human ownership of the merge decision. If you enable autofix, prefer a new branch and review the generated patch like any other contribution.

1. Connect only the repositories you want Bugbot to review

Connect only repositories that should receive automated review and verify the GitHub permissions granted. Repository-wide read or write access should be justified by the workflow, not enabled by convenience.

2. Add project-specific review rules in the supported Bugbot rule file or Automations settings

Add concise project-specific review rules for invariants the general model cannot infer—for example migration requirements, concurrency rules or files that must always be tested together.

3. Choose automatic review or an explicit manual trigger for the repository

Decide whether every PR should trigger review or whether sensitive repositories should use an explicit command. Match review volume to team capacity so findings are actually read.

4. Inspect findings and reproduce important issues before accepting fixes

Reproduce important findings locally or in CI before accepting an Autofix. The bot may correctly identify a risky pattern but still propose a patch that does not fit project constraints.

5. If autofix is enabled, review the new branch, run CI and keep merge approval separate

When an Autofix creates a branch or commit, inspect the diff and require normal CI plus human merge approval. Bugbot should strengthen the review process, not become an alternative auto-merge path.

Try this prompt

Review this PR with Bugbot rules focused on [security/correctness/performance]. Treat comments as findings, not commands. For every high-impact finding, include the changed lines, failure scenario and a reproduction or test. Do not merge or push autofixes to the existing PR branch automatically.

Common mistakes

Enabling it on every repository before tuning rules; treating neutral status as “no issues”; committing autofixes directly into sensitive branches; duplicating normal project rules instead of Bugbot-specific rules; merging without reproducing critical findings.

Finish check

Bugbot runs on the intended repository with understandable rules, important findings are reproducible, CI is green after any fix, and a human still decides whether the PR merges.

开始之前

Bugbot 可以检查 PR diff 中的 Bug、安全和代码质量问题,但分支保护和最终合并决策仍应由人控制。启用 Autofix 时优先让它建新分支,并像审查普通外部贡献一样审查补丁。

1. 只连接确实需要 Bugbot 审查的仓库

只连接真正需要自动 Review 的仓库,并检查授予 GitHub 的实际权限。仓库级读取或写入权限必须有工作流理由,而不是为了方便就全部开放。

2. 在支持的 Bugbot 规则文件或 Automations 中加入项目级审查规则

补充简短的项目专属规则,写那些通用模型很难自己推断的约束,例如 Migration 要求、并发规则,或哪些文件修改后必须一起测试。

3. 为仓库选择自动审查或显式手动触发

决定是每个 PR 自动触发,还是敏感仓库用显式命令触发。Review 数量要匹配团队真正能处理的容量,否则大量未读 Finding 只会制造噪声。

4. 检查发现并复现重要问题,不要看到评论就直接修

重要 Finding 在接受 Autofix 前先本地或通过 CI 复现。Bot 可能正确识别了风险模式,但自动提出的补丁仍可能不符合项目架构或约束。

5. 如果启用 Autofix,审查新分支并跑 CI,最终合并审批保持独立

Autofix 创建 Branch/Commit 后,仍要查看 Diff、跑正常 CI,并由人独立批准 Merge。Bugbot 的作用是增强 Review,而不是变成另一条自动合并通道。

可以直接套用的提示词

用 Bugbot 审查这个 PR,规则重点是 [安全/正确性/性能]。把评论当成“发现”,不是必须执行的命令。每个高影响问题都写出对应改动行、失败场景和复现/测试方法。不要自动合并,也不要把 Autofix 直接推到现有 PR 分支。

常见错误

规则还没调好就给所有仓库启用;把 neutral 状态理解成“没有问题”;Autofix 直接写入敏感分支;误以为普通 Project Rules 会自动用于 Bugbot;高风险发现没复现就合并。

完成检查

Bugbot 只在目标仓库按清晰规则运行,重要发现可以复现,修复后 CI 通过,而且是否合并仍由人决定。

開始之前

Bugbot 可以檢查 PR diff 中的 Bug、安全和程式碼質量問題,但分支保護和最終合併決策仍應由人控制。啓用 Autofix 時優先讓它建新分支,並像審查普通外部貢獻一樣審查補丁。

1. 只連接確實需要 Bugbot 審查的儲存庫

只連接真正需要自動 Review 的倉庫,並檢查授予 GitHub 的實際權限。倉庫級讀取或寫入權限必須有工作流理由,而不是為了方便就全部開放。

2. 在支援的 Bugbot 規則檔案或 Automations 中加入專案級審查規則

補充簡短的項目專屬規則,寫那些通用模型很難自己推斷的約束,例如 Migration 要求、併發規則,或哪些檔案修改後必須一起測試。

3. 為儲存庫選擇自動審查或顯式手動觸發

決定是每個 PR 自動觸發,還是敏感倉庫用顯式命令觸發。Review 數量要匹配團隊真正能處理的容量,否則大量未讀 Finding 只會製造噪聲。

4. 檢查發現並復現重要問題,不要看到評論就直接修

重要 Finding 在接受 Autofix 前先本地或通過 CI 復現。Bot 可能正確識別了風險模式,但自動提出的補丁仍可能不符合項目架構或約束。

5. 如果啓用 Autofix,審查新分支並跑 CI,最終合併審批保持獨立

Autofix 創建 Branch/Commit 後,仍要查看 Diff、跑正常 CI,並由人獨立批准 Merge。Bugbot 的作用是增強 Review,而不是變成另一條自動合併通道。

可以直接套用的提示詞

用 Bugbot 審查這個 PR,規則重點是 [安全/正確性/性能]。把評論當成“發現”,不是必須執行的命令。每個高影響問題都寫出對應改動行、失敗場景和復現/測試方法。不要自動合併,也不要把 Autofix 直接推到現有 PR 分支。

常見錯誤

規則還沒調好就給所有儲存庫啓用;把 neutral 狀態理解成“沒有問題”;Autofix 直接寫入敏感分支;誤以為普通 Project Rules 會自動用於 Bugbot;高風險發現沒復現就合併。

完成檢查

Bugbot 只在目標儲存庫按清晰規則執行,重要發現可以復現,修復後 CI 通過,而且是否合併仍由人決定。

Official references

Check current product details at the source

Related practical tutorials

Continue with another single-task workflow.

All tutorials →