Antigravity QA test automation is easiest to understand when you use it on a small, bounded task instead of asking an agent to rewrite half a framework. Google’s official Antigravity docs describe a workflow built around projects, starting an agent, navigation, slash commands, skills, and artifacts. Google’s May 19, 2026 managed agents announcement adds a second useful idea for QA teams: the Antigravity agent pattern can reason, use tools, execute code in an isolated Linux sandbox, browse the web, and take custom instructions from AGENTS.md and SKILL.md.

That is enough to design a practical tutorial for QA engineers, SDETs, and automation testers. In this guide, the goal is simple: ask an agent to inspect an existing UI test repository, draft one small automation improvement, review the diff carefully, and validate the result before you trust it.

What the official sources support

Before using any AI coding tool in a production-like QA workflow, pin down what the vendor actually documents. The official Antigravity sources used for this tutorial support these points:

  • The docs list getting-started concepts such as creating a project, starting an agent, basic navigation, and slash commands.
  • The skills docs describe skills as folders that contain SKILL.md instructions the agent can follow.
  • The artifacts docs describe artifacts as outputs primarily generated during Planning Mode and accessible across Antigravity 2.0 and the CLI.
  • Google’s May 19, 2026 managed agents post says the Antigravity agent pattern can execute code in an isolated Linux sandbox, browse the web, and use AGENTS.md and SKILL.md for custom instructions.

This article stays inside that documented surface and avoids unsupported claims about hidden features or exact implementation details.

Why this is a good QA use case

AI tools are most useful in test automation when the task is narrow and the success criteria are clear. A small regression test improvement works well because you can review the generated change quickly, run it, and reject it if the assumptions are weak.

Examples of safe starter tasks include:

  • Adding one missing assertion to an existing Playwright test.
  • Refactoring one duplicated locator into a page object or helper.
  • Turning manual reproduction steps into one focused regression test draft.
  • Improving a flaky test’s setup or cleanup logic without changing the whole suite.

Do not start with a request like “generate the whole test framework.” That is where AI-written tests usually become noisy, brittle, and expensive to review.

Before you start

  1. Pick a repository with an existing test suite and a small known gap.
  2. Write down the desired outcome in one sentence. Example: “Add a checkout validation test that confirms the error banner appears when the postal code is missing.”
  3. Prepare project instructions in AGENTS.md if your repository has specific rules for selectors, waits, naming, test data, or assertions.
  4. Decide what you will accept as success: clean diff, readable test, stable locator choice, meaningful assertion, and a passing rerun.

Step 1: Create a project and give the agent bounded context

The Antigravity docs emphasize projects and starting an agent. For QA work, the important habit is not just opening the repository but bounding the task clearly. Tell the agent what area to inspect, what kind of change is allowed, and what it must not do.

Try This Prompt

Inspect this test automation repository.
Focus only on the checkout UI tests.
Find one small missing regression case for required-field validation.
Draft the smallest safe Playwright test change.
Do not modify unrelated files.
Explain assumptions before editing.

This is strong because it limits scope, points the agent at an exact feature, and asks for assumptions up front. QA teams should prefer this over vague prompts like “improve the tests.”

Step 2: Use repo instructions through AGENTS.md or a skill

If your test repository already has conventions, encode them so the agent sees them every time. Google’s managed agents announcement explicitly calls out AGENTS.md and SKILL.md as instruction mechanisms. That matters for QA because review quality depends heavily on local standards.

Starter Snippet

# AGENTS.md

When editing UI tests:
- Prefer stable data-testid or role-based locators.
- Add business-level assertions, not only visibility checks.
- Avoid hard-coded waits.
- Reuse existing fixtures and helpers when possible.
- Keep each change limited to the target scenario.

If your team repeats the same guidance across projects, a reusable skill can help. Keep it short and opinionated. The goal is not to automate judgment away. The goal is to reduce repeated prompting and keep AI output aligned with your test standards.

Step 3: Ask for a plan before code

The artifacts docs matter here. Since artifacts are tied to planning-oriented output, ask the agent to show its approach before it edits files. This creates a review checkpoint that many QA teams skip.

A useful plan should answer:

  • Which files the agent wants to inspect.
  • What existing test pattern it will follow.
  • What assumptions it is making about locators, data, and expected behavior.
  • What exact file changes it proposes.

If the plan is already wrong, stop there. Do not let the agent write code and hope the final diff will somehow improve.

Step 4: Generate one small test change

Once the plan looks reasonable, ask for a minimal implementation. For example, if your current suite covers a happy-path checkout but misses required-field validation, the agent can draft one failing-path test rather than altering the entire flow.

Copy Example

test('shows an error when postal code is missing', async ({ page }) => {
  await page.goto('/checkout');
  await page.getByLabel('Name').fill('QA User');
  await page.getByLabel('Address').fill('42 Test Street');
  await page.getByRole('button', { name: 'Place order' }).click();
  await expect(page.getByText('Postal code is required')).toBeVisible();
});

This example is intentionally small. A QA engineer still needs to confirm that the locators match the app, the message text is correct, and a stronger business assertion is not needed. The point is to generate a reviewable draft, not a guaranteed final answer.

Step 5: Review the diff like a QA engineer, not like a prompt user

Antigravity QA test automation only works if the diff review is strict. Read the change with the same discipline you would apply to a teammate’s pull request.

Check these items:

  • Did the agent touch only the intended files?
  • Are the locators stable and consistent with repo conventions?
  • Does the assertion validate the product behavior, not just a generic UI change?
  • Did the agent introduce unnecessary setup, retries, or hidden timing assumptions?
  • Would the next maintainer understand this test quickly?

If the answer to any of these is no, revise the instructions and rerun the small task instead of patching around the problem manually.

Step 6: Rerun and validate the result

Never stop at the diff. Execute the updated test and, if possible, the nearest related subset of the suite. The exact command depends on your repo, but the validation pattern is stable: rerun the changed test, check failure output if it breaks, and confirm the result is not a false pass.

Sample Request

Run only the updated checkout test.
If it fails, summarize the exact reason.
Do not broaden the fix without approval.
If it passes, explain what evidence suggests the test is meaningful and not flaky.

This keeps the agent from turning one failed run into a chain of unrelated edits.

Screenshot checklist

  • The Antigravity project view or workspace showing the target repository.
  • The first prompt that defines the small QA task and scope limits.
  • The planning output or artifact that lists files, assumptions, and intended edits.
  • The generated diff for the test file.
  • The rerun output for the updated test.
  • The final reviewed version of the test after human cleanup.

Common mistakes to avoid

  • Starting too large: broad requests create big diffs and weak reviewability.
  • Skipping instructions: without AGENTS.md or similar guidance, the agent often guesses your test standards.
  • Accepting status-only assertions: a passing click or page load is not enough for most regression tests.
  • Ignoring artifacts or planning output: the plan often exposes bad assumptions earlier than the diff does.
  • Trusting one passing run: a test can pass once and still be fragile.

Best practices for teams

  • Keep a small library of QA-specific prompt patterns for bug reproduction, missing assertions, flaky test triage, and API contract checks.
  • Store repo-level guidance in AGENTS.md so repeated sessions stay consistent.
  • Prefer one-task sessions over open-ended “improve everything” sessions.
  • Track where the agent was helpful versus where human review corrected it. That gives your team a realistic adoption pattern.

Conclusion

Antigravity QA test automation is most effective when you treat the agent like a bounded collaborator: give it a small task, supply local QA rules, review the plan, inspect the diff, and validate the rerun. Google’s official Antigravity docs and managed agent announcement support that workflow without requiring you to invent capabilities that are not documented. Start with one small regression improvement, and your team will learn much faster where AI genuinely saves time and where human QA still adds the most value.

FAQ

Is Antigravity a good fit for full test framework generation?

Not as a first use case. Start with one small, reviewable task so you can judge output quality and reduce risk.

Why should QA teams use AGENTS.md with Antigravity?

It helps the agent follow your local standards for locators, waits, assertions, and reuse instead of guessing.

What should I review first in an AI-generated test diff?

Check scope, locator quality, assertion strength, hidden waits, and whether the change matches the original task.

Do artifacts matter for QA workflows?

Yes. Planning-oriented artifacts help you inspect assumptions and intended changes before accepting code edits.

References