Steps and prompts

One action or check per step

The agent works through your steps in order, deciding for each one whether it succeeded. Steps that bundle several actions make failures ambiguous; split them so the timeline tells you exactly where things went wrong.

Instead of this:

Log in, add a plush kangaroo to the cart, check out and confirm the order email arrives.

Write this:

1. Sign in with the test account.
2. Search for "plush kangaroo" and open the first result.
3. Add it to the cart and go to checkout.
4. Complete checkout with the saved test card.
5. Check that the order confirmation page shows an order number.

Refer to what a user can see

The agent reads the rendered page, not your source code. Describe targets by their visible text or role: "the Save button", "the email field", "the first row of the orders table". Never reference CSS classes, test ids, or internal component names; the agent does not see them any more than a user does.

Make checks explicit

A step like "check that the dashboard shows the new project" gives the agent a concrete success condition to judge. Vague endings ("make sure everything works") force the agent to guess what you meant, and its guess may not match yours.

Target URLs

Runs start from the project's base URL. A suite can set its own default URL, and CI runs can override the URL per run to point at a preview deployment (see GitHub Action). If a test needs to start from a specific page, say so in the first step: "Go to /pricing".