Skip to main content

/e2e-from-scratch

What it does​

/e2e-from-scratch is the design-first workflow: you describe the scenario in plain English and the pipeline does the rest. It chains three agents in sequence:

  1. Planner — turns your description into a structured spec file at tests/specs/{feature}/{name}.md, complete with frontmatter, data references, and numbered steps with intent and method fields.
  2. Generator — converts the spec into an executable .spec.ts file under tests/e2e/, then smoke-runs it.
  3. Reviewer — checks the generated test against the project rulebook (tests/agents/rules/playwright-rules.md) and emits a PASS or FAIL verdict. If the test fails review, the pipeline loops generate → review at most once before handing control back to you.

When to use it​

Use /e2e-from-scratch when you are designing a test up front — before recording or coding anything. Give it a scenario that describes the user action and the expected outcome.

If you already have a VS Code Playwright recording, use /e2e-from-recording instead — the Stabilizer handles raw recordings better than the Planner.

How to run it​

/e2e-from-scratch "add an Account Manager to the project team and see the row after save"

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

Example​

Input:

"add an Account Manager to the project team and see the row after save"

What you get back:

  1. A structured spec at tests/specs/project/team/add-key-member.md (Planner output), including field names, data references, and step-by-step intent/method pairs.
  2. A runnable test at tests/e2e/project/team/add-key-member.spec.ts (Generator output).
  3. A smoke-run result showing whether the test executes cleanly.
  4. A Reviewer verdict — PASS if the test meets all project standards, FAIL with line-precise findings if something needs fixing.

Notes​

  • The pipeline does not commit. You review the output and commit when satisfied.
  • Vague scenarios cause the Planner to halt. Your scenario must clearly describe what the user does and what a passing result looks like. Good: "add an Account Manager to the project team and see the new row appear in the grid after saving". Too vague: "test the team page".
  • Generate → review loop. If the Reviewer returns FAIL, the Generator revises and the Reviewer runs once more. After two review cycles the pipeline stops and presents the findings to you.