Cursor rules for QA help teams stop getting different AI review quality from one pull request to the next. Cursor’s official rules docs say persistent instructions can come from Project Rules, Team Rules, User Rules, and AGENTS.md files, with attachment based on context. That is useful for QA engineers because most review mistakes are predictable: weak locators, flaky waits, shallow assertions, and missing negative coverage. Instead of repeating those expectations in every prompt, you can store them once and reuse them.

This tutorial shows a practical workflow for setting up Cursor rules for QA so AI reviews stay focused on automation risk instead of generic style feedback. The goal is not to let the agent approve test code on its own. The goal is to make its first review pass more consistent, then let a human tester decide what to keep.

Why this matters for QA reviews

AI code review can feel impressive on one pull request and vague on the next. The difference is often not the model. It is the review context. If the agent does not know your team’s standards for selectors, waits, assertion depth, or required test evidence, it falls back to broad suggestions.

That hurts QA work in familiar ways:

  • A Playwright test gets approved even though it uses brittle CSS selectors.
  • A Selenium change looks clean but still depends on timing-sensitive waits.
  • An API test checks only status codes and not response meaning.
  • A backend change merges without matching test updates.

Rules help because they turn those expectations into reusable instructions instead of one-off reminders.

What the official docs support

The Cursor rules docs support the practical pieces needed for this workflow:

  • Project, team, and user rules can all provide persistent instructions.
  • AGENTS.md files can be used as repository guidance.
  • Rules can be scoped so different paths get different instructions.
  • Rules can be imported from files or external URLs when teams want shared guidance.

The Cursor changelog from June 4, 2026 also notes new auto-review support in the SDK. That matters because consistent review instructions become more valuable when review behavior is reused across automated flows, not just interactive chat sessions.

From those sources, a safe conclusion is that Cursor is designed to carry persistent review guidance into repeated coding workflows. That makes it a strong fit for QA review checklists.

Step 1: Decide what your QA rules should actually enforce

Before writing any rule file, decide which defects you want the AI to detect early. Keep the scope narrow and reviewable. A strong first version usually covers four areas:

  • Locator quality
  • Wait strategy
  • Assertion quality
  • Required tests for risky code changes

Do not try to encode your entire testing philosophy on day one. Start with the repeated problems your reviewers already mention in pull requests.

Step 2: Add a repository instruction file

If your team already uses AGENTS.md, put the highest-signal QA review rules there. Keep the wording direct and test-specific.

Starter Snippet

# AGENTS.md

When reviewing test automation changes:
- Prefer stable selectors such as role, label, test id, or domain-specific data attributes.
- Flag sleeps or timing-based waits when an explicit product signal is available.
- Treat status-code-only API assertions as incomplete unless the endpoint is intentionally minimal.
- Ask for changed or new tests when production behavior changes in risky paths.
- Prefer comments about regression risk over style-only feedback.

This file gives the agent a stable baseline. It also makes human expectations easier to inspect because the guidance is in version control.

Step 3: Add path-scoped Cursor rules

Global guidance is useful, but QA review gets stronger when the rule matches the area being changed. Cursor’s rules docs support context-aware rules, so you can tailor instructions for UI tests, API tests, or helpers.

Copy Example

Title: Review Playwright tests like a QA engineer
Apply to: tests/ui/**

When reviewing Playwright tests:
- Prefer getByRole, getByLabel, getByTestId, or other stable locators.
- Flag nth-child or deep CSS selectors unless there is no better signal.
- Check that assertions prove visible user behavior, not just element existence.
- Call out missing coverage for validation, permission, or retry states.
- Mention flakiness risk if waits depend on time instead of UI or network signals.

You can create a similar rule for tests/api/** that focuses on schema checks, business rules, auth failures, and negative scenarios.

Step 4: Run a review against a real pull request or local diff

Cursor rules for QA become useful only when you test them on real changes. Use a pull request or a local diff with known review risks. A good sample is a UI automation change that adds one test and edits one helper. Then ask Cursor to review the diff with your normal workflow.

What you want to see:

  • The agent comments on assertion depth before cosmetic style issues.
  • It notices brittle selectors in changed test code.
  • It asks whether risky product changes need matching tests.
  • It avoids re-explaining your baseline standards because the rules already cover them.

If the review is still generic, the rule text is probably too broad. Tighten it.

Step 5: Refine the rules from accepted feedback

One of the easiest mistakes is writing rules as if they are policy documents. They work better as review instructions tied to recurring defects. After a few reviews, look at which comments were useful and which were noise. Then edit the rules.

For example, if the AI keeps flagging every network mock but your team allows them in component tests, say that directly. If it misses status-only API checks, add that exact phrase. Treat the rules like a QA checklist that improves from evidence, not theory.

Common mistakes

  • Writing vague rules like “review code quality thoroughly” instead of naming test-specific risks.
  • Mixing human process rules and tool behavior rules into one long document.
  • Forgetting path scope, so UI and API tests get the same review guidance.
  • Expecting the AI to enforce undocumented product requirements.
  • Accepting every AI comment just because it matches the rule wording.

Best practices for QA teams

  • Keep each rule focused on one type of review signal.
  • Use repository files for standards you want every reviewer to see.
  • Test the rules on a known diff before relying on them in routine reviews.
  • Update the rules when your team repeatedly accepts or rejects the same AI comments.
  • Use rules to improve consistency, not to remove human QA judgment.

Screenshot checklist

  • The repository AGENTS.md file with QA review guidance.
  • A Cursor rule scoped to UI or API test paths.
  • The test automation diff before review.
  • The Cursor review output highlighting locator, wait, or assertion problems.
  • The updated diff after applying the accepted review feedback.

FAQ

Should QA teams use AGENTS.md or Cursor rules first?
Use AGENTS.md for high-level repository guidance and add Cursor rules when you need path-specific or more targeted review behavior.

Can these rules help with both Playwright and API tests?
Yes. Keep the review guidance separate by path so UI test rules focus on locators and waits while API test rules focus on assertions, schemas, and negative coverage.

Do rules replace manual test review?
No. They improve review consistency, but a human still decides whether the suggested finding is real, relevant, and safe to act on.

What is the best first rule to add?
Start with the most expensive recurring issue in your repository, such as brittle locators, timing-based waits, or status-only API assertions.

Conclusion

Cursor rules for QA work best when they capture a few high-value review standards and apply them repeatedly across real diffs. The official Cursor docs support persistent repository guidance through rules and AGENTS.md, and the changelog shows review-oriented automation is becoming more important in broader workflows. For QA engineers and SDETs, that means you can make AI review more predictable without pretending the AI is your final reviewer.

References