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.
That's why I built First User Audit — an open-source Agent Skill that helps coding agents explore your application from four different first-time-user perspectives.
It focuses on one question:
Can someone reach the first useful result without getting stuck?
Four perspectives, one app
The skill uses four simulated user behaviors:
- Impatient — Skims the page, clicks the obvious button, and quickly gives up when things get confusing.
- Skeptic — Checks pricing, privacy, and terms before trusting the product.
- Mobile — Explores the experience at a 375px viewport.
- Breaker — Tries invalid inputs, retries, back navigation, and double submissions.
What does the skill actually do?
It guides your coding agent through a simple process:
- Identify what first success means for your app.
- Explore the onboarding journey through four different behaviors.
- Record blockers with browser evidence and reproduction steps.
- Prioritize issues and propose safe technical fixes.
- Verify changes through fresh sessions when supported.
The idea is to catch friction that can be easy to overlook when you're already familiar with your product.
Try it with your coding agent
You can install it using the skills CLI, or simply copy this prompt into Claude Code, Codex, or another compatible coding agent:
Install the first-user-audit Agent Skill from:
https://github.com/BarganConstantin/agent-skills
Use the skills CLI:
npx skills add BarganConstantin/agent-skills --skill first-user-audit
Verify that the skill is installed.
Inspect my application and identify the first useful
outcome a new user should reach.
If a safe local or isolated preview environment and
browser automation are available, run the four
first-user personas with fresh browser sessions.
Collect evidence, identify friction, propose bounded
technical fixes, and verify changes with fresh
agent contexts when supported.
Do not use production data or live payments.
Ask before sensitive changes or reduced-isolation runs.
If anything is missing, explain how to set it up.
Never invent test results.
The skill requires connected browser tooling for the audit. Independent subagents depend on your coding environment, and simulated personas don't replace real usability testing.
It's open source under the MIT license.
Explore First User Audit on GitHub
Give it a try
If you use it on your own project, I'd love to hear what happens.
Did it catch an issue you hadn't noticed? Did it miss something obvious? Was the setup straightforward?
Share your experience in the comments. Feedback, ideas, and contributions are always welcome.
Top comments (9)
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?
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.