Skip to main content

​
What it does

/test runs your full test suite, reports results with coverage percentages per file, flags files below the 80% minimum threshold, and diagnoses failures systematically before attempting any fix.

​
When to use

Use /test to verify behavior after implementation, check coverage before shipping, or investigate test failures. It is also used as the verification step inside /implement.

​
Prerequisites

  • A test framework configured in the project
  • Dependencies installed

​
Conversation mode

Fast Mode — recommended for direct test execution.

​
What happens

1

Run full test suite to establish baseline

The complete test suite runs first to capture the full picture before any analysis.
2

Report results

Results are reported as: total tests, passed, failed, skipped, and coverage % per file. For failures, exact error messages are shown — not summaries.
3

Flag coverage gaps

Files below 80% coverage are flagged. High-risk code (auth, payments, data mutations) is expected at 95%+.
4

Diagnose failures

On test failure, the systematic-debugging skill is loaded to investigate root cause. The fix is never attempted without a diagnosis. For mass failures (>20 tests), the failure pattern is identified first — the root cause is fixed once rather than test-by-test.
5

Verify before declaring done

The verification-before-completion skill runs before tests are declared fixed. Tests are actually run — not claimed to pass.

​
Skills invoked

  • test-driven-development — RED-GREEN-REFACTOR process
  • systematic-debugging — loaded on test failure to investigate root cause
  • verification-before-completion — final check before declaring tests fixed

​
Coverage standards

80% is the minimum floor for shipping — it is not a target. Do not write tests purely to increase coverage numbers.

​
Example

Antigravity runs the test suite and outputs:
If more than 20 tests fail simultaneously (e.g., after a major dependency upgrade), Antigravity will not fix them test-by-test. It first identifies the common root cause, fixes it once, then re-runs.

/implement

/test is embedded in the /implement workflow’s TDD cycle.

/build

Run /build after tests pass to verify the full production build.

/troubleshoot

For test failures that need the full four-phase debugging process.

/review

Review code quality and test coverage as part of the pre-ship checklist.