When you're building an app, you already know where every button leads and what the user is supposed to do next.
Your first-time visitors don't.
...
For further actions, you may consider blocking this person and/or reporting abuse
The "Breaker" persona is the one I'd use most, because it catches the bugs that normal testing misses.
A human tester clicks the button that's supposed to work. A breaker tries the button that's supposed to fail, then clicks it twice, then hits back, then submits the form with the wrong content type. That's where the real bugs live.
Curious how the skill handles the "infinite loop" case. If the Breaker keeps finding bugs, does the audit stop at a certain number of issues, or does it keep going until the budget runs out?
There's no open-ended fix-and-retest loop. The Breaker pass stops at first success or when it hits an error, duplicate action, or unrecoverable flow, and records what happened. After all four baseline passes, the workflow allows one bounded fix pass, then fresh verification. Anything still broken goes into the report rather than triggering another automatic repair cycle. There isn't a numeric issue cap in the current instructions.
"One bounded fix pass, then fresh verification" is the right design. It prevents the "fix one thing, break another" loop that most automated testing tools fall into.
Curious how the "fresh verification" works. Does it re-run the same four personas, or does it focus only on the specific flow that was fixed? Asking because re-running everything after every fix is slow, but re-running only the fixed part might miss a regression.
It reruns all four personas after the bounded fix pass, using fresh browser sessions and the same first-success goal and starting conditions. It doesn't restart the full audit after every individual fix; focused automated tests cover those changes first.
That way, verification can catch a regression elsewhere in the journey. Where the runtime supports it, the verification agents get no baseline findings or fix details. If separate agents aren't available, the report must disclose that limitation.
"Verification agents get no baseline findings or fix details" is the detail that makes this trustworthy.
If the verifier knew what the fix was supposed to be, it would just confirm the fix. By giving it a fresh set of eyes (and no context about what changed), you're actually testing whether the fix worked, not whether the agent can read a diff.
Curious how you handle the "the fix broke something unrelated" case. If the verifier finds a new issue that wasn't in the baseline, does it just report it, or does it trigger another fix pass?
It gets reported as a new issue; it doesn't trigger another automatic fix pass. During consolidation, the reviewer gives it a new ID and keeps the reproduction steps and evidence in the after-pass report.
A problem appearing only in verification also doesn't prove the fix caused it. Comparing the same steps on both revisions would help establish that. Any further repair is a separate, scoped follow-up, so verification can't quietly turn into another repair loop.
This is a practical use case for AI agents beyond code generation. An application can pass its technical tests and still frustrate users because the onboarding is unclear, the next step isn't obvious, or an important action gives insufficient feedback. At IT Path Solutions, this is the kind of challenge worth considering when building AI-powered applications: development speed matters, but so does validating the experience people actually have when they use the product. An agent that repeatedly explores key user journeys and identifies friction points could help teams catch usability problems before release. The important part is making sure its findings are reproducible and easy for developers to verify.
Thanks, Glen. Reproducibility is a core part of the skill: findings should include screenshots, URLs, and steps to reproduce, followed by a fresh verification pass after fixes. The personas are simulated, though, so I see this as a complement to testing with real users.
Interesting! I’d definitely like to try it on a legacy app to see how it improves the existing UX without having to rebuild everything from scratch.
That's exactly the kind of app I'd be curious to test it on! I imagine there are a few UX quirks that everyone on the team is used to by now.
If you give it a try, I'd love to hear what it finds (or misses). Feel free to share your results here, even if things don't go as expected. It would really help me improve the skill.
👍