How to Generate a Test Suite from a Plain-English Prompt

The flows you care about most get checked on every release — and you define them by writing a sentence, not a script. Manta reads a plain-English description of a user journey and produces a structured, runnable test suite from it. This guide covers how to write a prompt that produces a good suite, and what to do with the result.

When to use this instead of autonomous exploration

A normal run explores your app and surfaces whatever breaks. That's the right tool for catching regressions you didn't anticipate. Prompt-based suites are for the opposite case: you know exactly what must keep working — "a new user can sign up and reach the dashboard," "an admin can invite a teammate" — and you want that verified deliberately, on demand, not discovered eventually.

Most teams run both: exploration for breadth, a handful of prompted suites for the journeys the business depends on.

Step 1 — Write the prompt

Describe the flow the way you'd explain it to a teammate who has never used the app. A good prompt has three parts:

A starting point — "From the login page…"
The steps, in order — "…sign in as an existing user, open Billing, and change the payment method to a new card."
What counts as success — "…the saved card should show the new last four digits."

Keep each step something a user actually does. You don't need selectors, URLs, or wait conditions — that's Manta's job.

A well-formed prompt reads like this:

From the logged-out home page, click "Sign up", register with a new email and password, verify the email, and complete onboarding. Success: the user lands on the dashboard with an empty project list.

[Screenshot: the prompt field with a multi-step flow typed in]

Step 2 — Review the generated suite

Manta turns the prompt into a set of discrete, ordered test steps. Read them before you run anything:

Check the steps match your intent and nothing is missing.
If a step is ambiguous ("update the profile" — which field?), tighten the wording in the prompt and regenerate.
Split genuinely separate journeys into separate suites. One suite should tell one story.

[Screenshot: the generated suite, a list of structured steps derived from the prompt]

Step 3 — Run it

Run the suite on demand. Each run gives you pass or fail per step, and for every failure a screenshot and the context around it — what Manta was looking at, what it tried, what happened instead. A failure points at a specific step, not a whole opaque "the flow is red."

Run it whenever you need the answer: after a risky merge, before a release, or on a schedule once that's available.

[Screenshot: a completed suite run, mostly green with one failed step expanded]

Writing better prompts

Do:

One journey per prompt. "Sign up, verify email, complete onboarding" is one story. "Sign up" and "delete account" are two suites.
Name concrete values — "enter the coupon code WELCOME10" beats "apply a discount."
State the assertion explicitly. If you don't say what success looks like, Manta can only check that the steps completed, not that they did the right thing.

Don't:

Don't describe the UI implementation ("click the button with id submit-btn"). Describe the action ("submit the form").
Don't chain ten steps with three assertions buried in the middle. Break it up.
Don't assume state. If the flow needs a team with no members, say so — "starting from an organization with no other users."
Don't leave references ambiguous. "Update the profile" — which field? Name it.

Good prompts are essentially acceptance criteria written in plain language, and designing their inputs benefits from the same test-design techniques — boundary values, decision-table rows, an explicit expected result rather than "it works."

What to try next

How to Read the Navigation Map — use the map to decide which flows are worth pinning down this way.
Release testing & pre-release QA — where prompted suites act as the must-pass gate.
Why Manual QA Doesn't Scale With Modern Release Cycles — where repeatable prompted suites fit in a fast release cycle.
Autonomous Testing vs. Scripted Tests — how this differs from maintaining Cypress or Playwright specs.

Start free and turn your first critical flow into a suite.