Cursor Bugbot for QA is a practical way to review Playwright pull requests before they reach main. If your team already has tests running in CI, the next problem is usually review quality: weak assertions slip through, locators are fragile, and a passing run hides maintainability issues. Cursor’s official docs describe Bugbot as a pull-request review workflow, and Cursor’s June 5, 2026 changelog adds two details that matter for QA teams: you can run /review before pushing, and Bugbot can be configured to review only what is new since the last review.

That combination makes Bugbot useful for test automation work. Instead of asking a general assistant to ?look at my test,? you can place review instructions in repository rules or AGENTS.md, run a PR review, and focus the feedback on the exact test changes a human reviewer still needs to validate.

What the official Cursor sources support

Before building a workflow around any AI review tool, confirm what the vendor actually documents. For this tutorial, the useful points come directly from Cursor’s official docs and changelog:

  • Cursor’s Bugbot docs position the feature as a pull-request reviewer for bugs, security issues, and code quality.
  • Cursor’s Rules docs explain persistent instructions through Project Rules, Team Rules, User Rules, and AGENTS.md.
  • The June 5, 2026 changelog says /review can run Bugbot before push and that Bugbot can review only the changes that are new since the last review.

Those documented facts are enough to build a safe QA workflow without treating AI review as automatic approval.

Why QA teams should care

Playwright pull requests often look healthy when they are not. A test may pass locally while still being brittle in CI because the locator is fragile, the assertion is weak, or the flow change did not update nearby coverage.

Cursor Bugbot for QA works best as a first-pass reviewer for unstable locators, unnecessary waits, weak assertions, and missing coverage. Keep final approval with a QA engineer or SDET.

Before you start

  1. Use a repository that already contains Playwright tests and a pull request with meaningful test changes.
  2. Decide what you want Bugbot to inspect. For example: flaky waits, weak assertions, selector quality, missing negative coverage, or page-object drift.
  3. Add a small review instruction set through Cursor Project Rules or AGENTS.md so the feedback stays aligned with your QA standards.

Step 1: Add QA review instructions with Rules or AGENTS.md

Create a short instruction file that tells the agent how your team reviews Playwright changes. Keep it specific and test-focused. You do not need a long prompt library.

Try This Prompt

# QA review guidance for Playwright changes

When reviewing test automation changes:
- Flag brittle selectors and hidden timing assumptions.
- Prefer assertions on business outcomes, not only status codes or visible text.
- Call out missing negative or edge-case coverage when the PR changes a critical flow.
- Suggest the smallest safe fix first.
- Do not approve code automatically; provide review notes only.

This works well in AGENTS.md for a simple repository-wide setup. If your team already uses Project Rules or Team Rules, put the same review logic there. The important part is repeatability.

Step 2: Open the Playwright pull request and define the QA question

Do not ask for a generic review. Give the run a bounded QA objective. A strong example is: ?Review only the Playwright changes in this PR. Focus on unstable locators, unnecessary waits, weak assertions, and missing coverage for the edited checkout flow.?

This framing matters because AI review tools are noisy when the request is broad. QA teams get better results when they narrow the instruction to failure modes they already care about in code review.

Step 3: Run Bugbot before merge

Cursor’s June 5, 2026 changelog notes that /review can run Bugbot before push. In practice, that gives QA teams an earlier review checkpoint than waiting for a formal PR round. If your team prefers PR-based review, the same Bugbot workflow still fits after the branch is open.

When the review returns, read it like triage data, not as a verdict. Sort each comment into one of three buckets:

  • Likely valid: the finding points to a real test quality gap.
  • Needs human confirmation: the finding might be right, but you need repo context or product knowledge.
  • Noise: the comment is generic or conflicts with the intended test design.

Step 4: Review only the new changes on the next pass

One of the most useful details in Cursor’s June 5 changelog is the option to review only what is new since the last review. That is especially valuable for test automation PRs, where the second review round often contains only a few locator or assertion fixes. Limiting the review scope reduces repeated comments and keeps the signal on the actual edits.

For QA teams, this is the difference between ?AI review spam? and a workable loop:

  1. Run the first review on the PR or branch.
  2. Apply the valid fixes manually.
  3. Rerun Bugbot against only the new changes.
  4. Compare the remaining findings against CI results and your human checklist.

Copy Example: Human review checklist after Bugbot

After Bugbot comments are in, verify these manually:
1. Every important user action has a business-level assertion.
2. No locator depends on unstable placeholder text or layout order.
3. Retries or waits were not added as a shortcut for a real sync problem.
4. The PR still reads cleanly for the next maintainer.
5. CI evidence supports the change, not just local execution.

Screenshot checklist

  • Cursor Rules or AGENTS.md showing the QA review instructions.
  • The Playwright PR diff with the changed test or page object file.
  • The Bugbot review panel or comments for the first review pass.
  • A follow-up diff after you fix one or two findings.
  • The second review pass configured to focus on only new changes.
  • The final PR state alongside a passing Playwright or CI check.

Common mistakes to avoid

  • Using Bugbot as an approver: treat it as a reviewer, not a merge authority.
  • Writing vague rules: ?review this code? produces weaker feedback than ?check waits, selectors, and missing assertions.?
  • Ignoring false positives: noisy comments should refine your instructions, not train the team to ignore the tool.
  • Skipping CI evidence: review comments are not a substitute for actual test execution.

Best practices for a stable workflow

  • Start with one Playwright repository and one review objective.
  • Track which Bugbot comments your team accepts versus rejects for two weeks.
  • Update the rule text when the same useless comment appears repeatedly.
  • Use the ?review only new changes? behavior to keep later rounds readable.

Conclusion

Cursor Bugbot for QA is most useful when you combine three documented pieces: Bugbot for pull-request review, Rules or AGENTS.md for persistent QA instructions, and the June 5, 2026 changelog behavior that lets teams run review early and focus later passes on only new changes. That gives QA engineers a repeatable way to inspect Playwright pull requests without turning review into AI noise. Use Bugbot to surface likely risks, then let a human reviewer decide what actually improves test safety.

FAQ

Can Cursor Bugbot replace a QA code reviewer?

No. It can accelerate first-pass review, but human validation is still required for test intent, product risk, and CI evidence.

What is the best first use case for Bugbot in QA?

Reviewing Playwright pull requests for brittle selectors, weak assertions, and missing coverage is a strong starting point because the scope is narrow and easy to validate.

Should I use Rules or AGENTS.md?

Use AGENTS.md if you want a simple repository-wide instruction file. Use Rules when your team needs more structured or shared guidance.

How do I reduce repeated AI review comments?

Keep the review objective narrow, refine your repository instructions, and use the documented option to review only what is new since the last review.

References