Autonomous creation
No human in the loop. Front-load all the context into one prompt, hit run, and review the finished flow.
Guided creation
A copilot workflow. Prompt for one small change at a time, discovering the app together with the AI.
Autonomous creation
In this mode Automate works unattended, so everything it needs to know has to be in the prompt before you hit run.Write a specific prompt
Vague prompts produce unreliable results. A prompt like “Create a test for the rate quote flow” gives Automate very little to work with. A stronger prompt includes:- Where to start (URL and login credentials)
- What the user does, step by step
- What a successful outcome looks like
- Anything specific you want asserted
Include assertions explicitly
If there’s something specific you need verified, say so. Automate won’t always infer what matters to you — telling it what to assert produces more useful tests.Link your app’s documentation
If a flow depends on setup that is only explained in your documentation, include the link in the flow description or your prompt. The AI reads linked documentation before it starts building and uses it to complete configuration steps it cannot discover from the UI alone.Structure the flow header around Arrange, Act, Assert
When Automate completes a flow on its own, the comment block at the top of the flow is its specification. Structuring that header around Arrange, Act, Assert tells Automate how far each verification should go. For example, a flow that disables a feature could simply reload the page and check that the toggle is still off. It could also go further and sign in as a different user to verify the feature is no longer accessible. An AAA header states which one you want, so Automate doesn’t have to guess:Use descriptive flow names
Before building a new flow, the AI searches your workspace for similar flows and reuses the parts that overlap instead of starting from scratch. Descriptive names help it find the right ones. If you want it to work from a specific example, point it at a working reference.Guided creation
In this mode you stay in the loop, hand-holding Automate to completion. Use it when you don’t have the full context yourself and are discovering the app at the same time as the AI, so it makes sense to work the problem together.Start prompts with “Insert code to”
When adding code at a specific point in a test, beginning your prompt with “Insert code to” helps Automate understand it should add rather than replace.Control where code is inserted
Automate inserts code relative to the current cursor position. If code ends up in the wrong place:- Click on the line where you want the code inserted before prompting
- Or tell it explicitly: “Insert code on line 42 to…”
Describe elements in plain language
You don’t need to tell Automate which Playwright locator to use. It’s better at finding the most relevant locator itself. If you prescribe a locator and it turns out not to work, Automate gets stuck between obeying your instruction and producing a working test, and the result suffers. Say “Click the Save button in the billing settings panel”, not “Clickpage.locator('#btn-save-2')”.
Hover before you prompt for elements
When targeting an element inside a container — for example, the first link within a specific panel — hover over the container for a second, then click the element. This gives Automate locators for both, and you can ask it to chain them:Trigger actions before prompting
For interactions that produce a result (a download, a new page, a modal), trigger the action yourself first and let it complete. Then tell Automate what happened. This helps it understand the outcome, not just the selector. Example:- Click the download button and wait for the download to start
- Then prompt: “Click the download button”
Use descriptive language for context
A few phrases that help Automate understand what it’s working with:- “in the row” — when an element is inside a table row
- “file” — for file-related actions like clicking download or handling file inputs