Skip to main content

Author from an English scenario

No recording? No problem. If you can describe the behavior you want to test in plain English, /e2e-from-scratch will design the spec, generate the TypeScript, and review the result — all in one command.

Use this path when:

  • You are designing a test for a feature that is not yet built.
  • The flow is simple enough that recording it would take longer than writing a sentence.
  • You want a spec that matches a particular edge case or error condition that is awkward to reproduce manually.

Step 1 — Write a clear one-behavior scenario​

The single most important step is writing a good scenario. The AI is only as precise as the description you give it.

What makes a good scenario​

A good scenario describes one behavior, names the specific PACE feature, and states the expected outcome.

Example
Good"A project manager opens an existing project, adds a new Key Member with role 'Account Manager' and saves — the new row appears in the grid and a success toast is shown."
Good"On the Deliverables tab, a user creates a new deliverable with number '2' and name 'Milestone A', selects a task and a cost code, and clicks 'Create and go to deliverables' — the deliverable row appears with status 'Draft'."
Vague"Test the deliverables page."
Vague"Check that saving works."

Rules of thumb:

  • Name the page or tab (e.g. "Deliverables tab", "Key Members grid").
  • Name the action (e.g. "creates", "edits", "deletes", "submits").
  • Name the outcome (e.g. "a success toast appears", "the row shows status 'Draft'").
  • One scenario = one behavior. If you want to test two things, write two scenarios and run the command twice.

Step 2 — Run /e2e-from-scratch​

Pass your scenario to the AI pipeline:

/e2e-from-scratch "<scenario>"

On Antigravity, the slash command takes no inline argument — run /e2e-from-scratch, then provide the scenario when prompted.

Replace <scenario> with the sentence you wrote in Step 1 (keep the quotes in Claude and Gemini).

Example:

/e2e-from-scratch "A project manager opens an existing project, adds a new Key Member with role 'Account Manager' and saves — the new row appears in the grid and a success toast is shown."

The pipeline runs three agents:

AgentWhat it produces
PlannerA structured spec at tests/specs/<feature>/<name>.md with frontmatter, Background, numbered Steps (each with intent + method), and Expected
GeneratorAn executable test at tests/e2e/<feature>/<name>.spec.ts (smoke-run included)
ReviewerA PASS / FAIL verdict with line-precise findings

For the full command reference, see /e2e-from-scratch.

Step 3 — Review the generated spec​

Open the spec file the Planner created (tests/specs/<feature>/<name>.md) and check:

  • Frontmatter — does the id, feature, and title match your intent?
  • Background — does it correctly describe the scenario you described?
  • Steps — are all the actions present and in the right order? Does each method: line reference a real page-object method?
  • Expected — does the expected outcome match what you wanted to test?

If anything is off, edit the spec directly (it is plain Markdown) and re-run /generate-test to regenerate the TypeScript from the corrected spec.

Step 4 — Run and commit​

Run the test locally to confirm it is stable:

pnpm run test --grep "<spec-title-or-id>"

Then commit both the spec and the generated test:

git add tests/specs/<feature>/<name>.md \
        tests/e2e/<feature>/<name>.spec.ts
git commit -m "test: add <description> e2e test"

Tips​

  • Iterate on the scenario. If the generated spec misses a step or gets the feature wrong, the fastest fix is to rewrite the scenario sentence to be more precise and run the command again.
  • Name real UI elements. If you know the button label or tab name, use it verbatim (e.g. 'Release for Execution' rather than 'the action button').
  • Check data references. The Planner will pull values from tests/data/*.jsonc for project numbers, user names, etc. Make sure the referenced keys exist (run pnpm run test:validate-data to check).