Skip to main content
Your agent shows you every change before it makes it and waits for your approval. You ask in plain English; the examples below are the kind of thing you might say.

​
Understand failures

Why is the checkout test failing?
  • See everything currently failing in a project
  • Open one failure in full: cause and confidence, the exact error with line context, the script that ran, the failure screenshot, run history, and what it depends on
  • Summarise a whole batch run
  • Read a specific test case, or search across them — archived ones included when you ask
  • Pull a single artifact from a run
  • Show the execution plan behind a run

​
Run tests

Run the checkout suite against staging.
  • Kick off a test run in Peeps’s hosted CI
  • Check where that run has got to
Run plans identify production targets and queue nothing by themselves. Your agent shows you the plan and waits for your approval before anything runs.

​
Fix tests

Fix that selector and submit it.
  • Submit a proposed fix to a test script, and check whether it verified
  • Review a verified fix in full — the complete script change, any step changes, and where it ran — and publish it once you approve
  • Re-run the check when something changed since the fix was verified
  • Dismiss a suggested fix you don’t want, keeping its verification history
  • Update the written steps of a test case
Peeps self-heals script issues on its own, so this path is for what healing hands back: a fix that needs your local code to get right, or a failure Peeps diagnosed as something other than a broken selector. A submitted fix is verified by Peeps in its own hosted run, and verifying it never makes it live. Your agent then shows you the full review and publishes only after you say so. If the environment or the tests around it changed since the run, it asks to verify again first. When a fix is published, your organization’s owners and admins are notified.