Writing Prompts That Produce Durable Tests

The quality of a Studio test is decided almost entirely in the sentence you write to ask for it. Not by the tool, not by the application, and not by how long you spend editing afterward.

The one rule

Describe what a user does and what must then be true. Never describe how the page is built.

Everything else on this page is a consequence of that rule.

In selector-based automation the page structure was the test — you told the tool where to click because it had no other way to know. That coupling is why those suites rot: every redesign invalidates work that had nothing to do with behavior. Studio finds elements visually and contextually, so describing structure throws away the only thing that makes a test survive a redesign.

The second version is a test of your markup. The first is a test of your business.

The four parts of a good prompt

1. Where to start

Give the starting URL explicitly. "Go to the store" is ambiguous; a URL is not. If the journey needs a particular state — a signed-in user, an empty cart, a specific environment — say so, and supply the values from an execution preset rather than typing them into the prompt. See Test Data: Execution Presets, Variables and Secrets.

2. What the user does

In the order a person would do it, in the words a person would use. "Search for an air conditioner, open the first result, add it to the cart." Not "populate the search input, trigger the submit handler, navigate to the PDP".

Keep it to one journey. If you find yourself writing "and then also", you are writing two tests.

3. What must be true at the end — the oracle

This is the part people skip, and skipping it is how you get a suite of tests that cannot fail for the reason you care about.

Be specific about the value, not just its presence. "The subtotal is shown" passes when the subtotal is wrong. "The subtotal is $966.00" does not. If the exact value varies, state the rule: "the subtotal equals the sum of the line prices".

A test with no assertion is a screenshot with extra steps. See Exercise 2 - Write Assertions That Prove Something.

4. What must not happen

The most valuable line in most prompts, and the one almost nobody writes.

• "The guest is never asked to sign in."
• "No error banner appears at any point."
• "The price never changes between the product page and the cart."
• "A user without the manager role cannot open this screen."

Negative assertions are where real incidents live, because positive paths get exercised by hand constantly and negative ones almost never do.

The prompt template

Starting at <URL>, as a <kind of user>:

  1. <what they do, in order, in plain language>
  2. ...

Confirm that:
  - <the specific value or rule that must hold>
  - <a second one, if the journey genuinely proves two things>

Also confirm that:
  - <what must NOT happen>

It looks almost too simple. It produces markedly better tests than a paragraph, because it forces you to write the oracle down.

Five habits that make tests durable

Name the thing a human would name

"the Add to Cart button", "the search box", "the order confirmation number". Use the words printed on the screen. If the label changes and the behavior does not, the agent adapts; if you pinned an internal identifier, it cannot.

State values, not vibes

"$966.00" beats "the right price". "Within five seconds" beats "quickly". "Exactly one row" beats "some results". Every vague word is a place the test cannot fail.

One test, one question

If a red result would leave you asking "which part broke?", the test is too long. Split it. Short tests diagnose themselves.

Say what you do not care about

"Ignore the cookie banner" or "the promotional carousel is irrelevant" keeps the agent from asserting on things that change for reasons unrelated to your feature. Better still, handle the banner once at project level under Access & Auth → Cookies rather than in every test.

When the agent asks a question, read it

Studio flags contradictions rather than building something destined to fail. If it comes back with a question instead of a test, that is the product working, and the question is usually pointing at a genuine ambiguity in what you asked for. Answer it rather than rephrasing around it.

Prompt smells

Rewriting a bad prompt

Before

test the product page and cart, check it works, click add to cart on
the AC and go to cart and make sure the price is there

After

Starting at the Anaqa demo store home page, as a guest:

  1. Search for "Boltas" and open the Boltas 2 Ton 3 Star Split AC
     product page.
  2. Note the displayed price.
  3. Add it to the cart.
  4. Open the cart.

Confirm that:
  - The cart contains exactly one line for that product.
  - The line price on the cart matches the price shown on the product
    page.
  - The subtotal equals that line price.

Also confirm that:
  - The guest is never prompted to sign in.
  - No error banner appears at any point.

Same feature, same amount of typing, a completely different test. The second one can fail for four distinct real reasons; the first cannot fail for any.

The compounding benefit

Clear prompts cost less in every dimension at once. Fewer regenerations means lower credit consumption — a vague prompt that needs three attempts costs three times what a good one does. Fewer ambiguities means fewer questions and less back-and-forth. Better oracles mean failures that explain themselves.

And a prompt written as intent survives the redesign that would have invalidated a prompt written as structure. That is the whole bet: the description outlives the implementation.

Where to go next

• Agent Prompt Guide — the full reference, including the phrases that reliably change agent behavior.
• Why Skills Matter — how to teach the agent your domain so your prompts can be shorter.
• What Makes a Good Automation Candidate — deciding what to write a prompt about in the first place.