UI automation for the sites and apps you build yourself

What the agent can do for your tests

• Filesread_file, write_file, append_file, edit_file, delete_file, make_dir, move_file, copy_file, list_dir, grep and glob work inside the chat's working folder, and a counter shows files created, edited and read.
• Shellruns your test command, a linter or a build in local Windows, WSL or over SSH on a server you own, and judges success by the real exit code. Dangerous commands are blocked.
• Webweb_search finds pages and http_get reads one official documentation page, so a selector or wait question can be checked against the framework's own manual.
• Screenshots and imagesocr reads the text in a saved screenshot, for example the error banner of a failed run, and gen_image saves real image files when you need one.
• Orchestrationtask splits independent checks across parallel sub-agents, run_on_model sends one hard step to a bigger model, and skill stores a reusable playbook such as your usual repair routine.
• Approval modesAuto-run acts at once, Ask first pauses before actions that change something and shows the diff, and Plan only writes a plan and runs nothing. Plans survive restarts.
• Cronruns a prompt on a schedule, for example to run your test command at the times you set and report the exit code in the chat, so a flow that broke overnight is the first thing you read.
• Modelsconnect a cloud AI provider through a standard API endpoint, a model running locally on your PC, or the built-in model that is ready to use without your own endpoint. The Test button checks an endpoint before you start.

Four jobs the agent does in a test project

Write the first flow

Best practices for e2e tests start with a short list of flows that must never break, so ask FlowLatch to write only those. list_dir and glob show how your existing tests are named, read_file opens one as a pattern, and write_file creates the new file for the sign-in flow with a test account and fake data. Shell then runs your test command, and the card shows the real exit code. A first draft is rarely final, so ask for one change at a time, such as a clearer name or an added check on the page text. Before you accept, read the new file in the diff, run it yourself once and keep it only if it matches the flow you meant.

Run the suite and read the failure

Shell runs your test command and the card keeps the full output, so a red result is never a guess. grep searches that output for the failing step, and if your framework saved a screenshot, ocr reads the message in it. To reduce flakiness in end to end tests, ask FlowLatch to run the failing test again with the same command and compare the exit codes. A pass followed by a fail points at a fixed wait, shared test data or the order of the tests. Ask for a short explanation in the chat, then review it against the output before you change any file.

Repair a selector after a layout change

Whether e2e testing is worth the time for frontend work depends on the flow, so cover sign-in and checkout first. When the page layout changes, grep finds every selector that was tied to it, read_file shows the surrounding steps and edit_file proposes stable labels or test ids instead. In Ask first, FlowLatch pauses before each edit and shows a diff, one file at a time. Accept the lines that look right, reject the rest, then let Shell run the suite again to see the new exit code. Keep the diff small so a reviewer can read it in a minute.

Move a suite to another framework

When migrating e2e tests between frameworks, keep both suites in the repository until the new one passes. FlowLatch lists the old tests with glob, reads each with read_file and writes the matching new file with write_file, one flow at a time. web_search and http_get can read the new framework's own documentation for syntax you do not remember. Run both suites with Shell, compare the exit codes, and approve each file in Ask first before the old one is removed. Plans survive restarts, so a long migration can continue the next day.