Antigravity rules QA workflows are useful when a team wants AI-assisted test automation to follow the same review standards every time. The goal is not to let an agent decide whether a test is good enough. The goal is to give the agent clear constraints, ask it to produce reviewable artifacts, and keep the QA engineer responsible for validation.

This tutorial shows a practical way to use Google Antigravity rules and workflows for test automation review. The workflow focuses on selector quality, assertion strength, browser evidence, permissions, and final test evidence before a QA engineer accepts any AI-generated change.

Why Antigravity Rules Help QA Teams

Official Antigravity documentation describes rules as constraints that guide agent behavior and workflows as reusable step sequences for repeated tasks. For QA teams, that maps well to everyday review standards: use stable selectors, avoid shallow assertions, capture browser evidence when UI behavior is involved, and always run deterministic checks before accepting a change.

Rules are most valuable when the same mistakes keep appearing in AI-assisted work. An agent may draft a Playwright test that only checks that a button exists. It may miss a negative case. It may suggest a locator that depends on layout text. A project rule gives the agent the same review checklist before it edits files or summarizes work.

Practical Use Case: Review a Generated UI Test

Use this workflow when an AI agent has created or changed a UI automation test. The example assumes a pull request or working branch contains a new checkout test. Your job is to make Antigravity inspect the change, capture evidence, and report risks without treating the AI output as automatically correct.

  1. Open the repository in Antigravity and identify the changed test files.
  2. Add or update project rules for test automation review.
  3. Ask the agent to inspect the change against those rules.
  4. Use browser tools when the behavior needs visible UI evidence.
  5. Review the generated artifact and comments.
  6. Run the test command yourself or through your normal CI workflow.
  7. Accept, edit, or reject the change based on evidence.

Starter Rule for Test Automation Review

Keep rules short enough that they will actually be followed. A QA rule should describe standards, risk checks, and validation output. Adapt this starter text to your repository conventions.

QA test automation review rules:
- Prefer stable user-facing selectors such as role, label, test id, or accessible name.
- Flag selectors that depend on layout, generated classes, or fragile text fragments.
- Do not approve status-only or visibility-only assertions when business behavior should be checked.
- Check positive, negative, boundary, and error-path coverage when relevant.
- List any data dependencies, environment assumptions, and cleanup requirements.
- For browser flows, request screenshots or action evidence for the changed path.
- Before final approval, report the exact command a human should run and what result to expect.
- Never claim the test passed unless the command output or CI result is available.

This rule does not replace code review. It makes the AI review more consistent so the human reviewer has fewer basic issues to rediscover.

Use a Workflow for Repeatable QA Review

Rules define expectations. A workflow defines the sequence. For a recurring QA task, create a simple process the agent can repeat each time a test file changes.

Workflow: review AI-generated UI test
1. Summarize the changed files and the user behavior under test.
2. Compare selectors against the QA rules.
3. Compare assertions against the expected business outcome.
4. Identify missing negative or boundary checks.
5. If browser evidence is needed, capture a screenshot or action artifact.
6. Produce a review artifact with: risks, suggested edits, validation command, and final human decision points.

The important detail is the final step. The artifact should make the decision easier, not hide the decision. Ask for risks and validation commands in the same place so reviewers can connect the recommendation to evidence.

Prompt to Run the Review

Here is a copy-ready prompt you can use after the rules are in place.

Review the changed UI automation tests using our QA test automation review rules.
Focus on selector stability, assertion quality, data dependencies, and missing negative cases.
If the browser flow needs visual evidence, use browser evidence and include the artifact in your summary.
Do not edit files yet. First return:
- changed behavior under test
- risky selectors
- weak or missing assertions
- missing coverage
- validation command I should run
- decision: accept, request changes, or investigate

After reading the first review, you can ask for a patch. Keep that second prompt narrow: fix only weak locators, add only the missing assertion, or add one negative case. Broad prompts often create noisy changes that are harder for QA teams to trust.

Permissions and Evidence Matter

Antigravity permissions are important because AI-assisted workflows can involve file edits, command execution, and browser interaction. For QA teams, start with the least access needed for the task. Let the agent read code and inspect diffs first. Allow edits only after the review artifact makes the intended change clear.

Browser evidence is also useful, but it has limits. A screenshot can show that an error message appeared. An action video can help reviewers understand the path. Neither proves that the automation is maintainable, isolated, or safe to merge. Treat browser artifacts as supporting evidence beside test output, assertions, and code review.

Screenshot Checklist

  • Screenshot of the project rule or workflow used for the QA review.
  • Screenshot of the changed test file before accepting AI edits.
  • Screenshot of the browser state for the tested user path.
  • Screenshot of the review artifact with risks and validation commands.
  • Screenshot of terminal or CI output after the deterministic test run.

Common Mistakes

Using rules as vague preferences. A rule like “write good tests” will not help much. State the exact checks: selector stability, assertion depth, data setup, cleanup, and evidence.

Letting the agent approve itself. The agent can recommend a decision, but the QA engineer should compare that recommendation against test output and product behavior.

Capturing evidence without assertions. A screenshot is useful for review, but automation still needs assertions that fail for the right reason.

Running broad edits too early. Ask for review first, then ask for a narrow patch. This keeps the change small and easier to validate.

Best Practices for Antigravity Rules QA Workflows

  • Keep one project-level QA rule focused on test automation standards.
  • Separate review prompts from edit prompts.
  • Ask for artifact comments when the agent produces implementation plans or walkthroughs.
  • Require the agent to list exact validation commands instead of saying the work is done.
  • Keep sensitive data, credentials, and production-only flows out of exploratory agent runs.
  • Review generated browser evidence for relevance before attaching it to a defect or pull request.

Conclusion

Antigravity rules QA workflows can make AI-assisted test automation more consistent by turning team standards into reusable constraints and review steps. The practical pattern is simple: write clear QA rules, run a review workflow, inspect browser or artifact evidence, then validate with deterministic test output. Used this way, Antigravity helps QA engineers review faster without handing over the final quality decision.

FAQ

Do Antigravity rules replace a QA test review checklist?

No. They help the agent follow the checklist earlier, but the QA engineer should still review selectors, assertions, data, and evidence before accepting changes.

Should I let the agent edit tests immediately?

For risky changes, start with a review-only prompt. Ask for edits only after the agent explains the risks and the intended patch.

Can browser evidence prove a test is correct?

No. Browser evidence supports review, but correctness still depends on assertions, test data, repeatability, and deterministic test execution.

What should a QA rule include?

Include selector standards, assertion expectations, coverage gaps, data dependencies, cleanup, evidence requirements, and validation commands.

References