Scripted personas run genuine first-run sessions against your real app, in a real browser — and hand back a prioritized, implementation-ready findings spec.
Recruiting, scheduling and running a genuine first-run study takes real calendar time. Meanwhile the build keeps moving and the obvious usability holes ship anyway.
“Just ask a model to pretend to be a user” produces confident, fluent fiction. It reads exactly like a finding. Nothing in it tells you which parts a machine could actually check.
“Confirmed by 3/3 personas is one model agreeing with itself in three costumes.”
— line landed by a review council on this tool
Stands up a throwaway instance of your app loaded with realistic data.
Real Chrome, phone (390×844) and desktop (1280×900), screenshots at each stop.
Run against your actual source, not a description of it.
A non-technical small-business owner, an impatient power user, a privacy-adversarial IT pro — each clicking real buttons.
Prioritized and implementation-ready, not a wall of observations.
The spec stops here for a human decision before anything downstream runs.
Every finding gets a verdict recorded to a ledger. That ledger computes a precision number.
Personas are supplied as plain .md briefs. They must be rewritten for your product — see Limits.
Every invocation was plain conversational language to Amplifier. The interesting part is how the phrasing collapsed as the tool became routine.
That's the recommended pattern. Ask it at any point in a project's life — the tool is not tied to a phase.
Point it at a mockup before any implementation exists. You find the structural problems while they're still cheap.
Run it against the live app between builds. It reads your actual source and drives your actual UI.
A prioritized findings spec is a defensible input to the roadmap conversation, with each item labeled by how it was known.
Attention Firewall — a live, shipping WhatsApp / notification triage web app, v0.8.0. Each triaged round grades every finding real, noise, or won't-fix, and the ledger computes precision from that.
| Round | Findings | Graded real | Precision | Note |
|---|---|---|---|---|
| Round 2 | 6 P1 bugs | — | not triaged | First proof-run of the new pipeline |
| Round 3 | 23 | 20 | 87% | |
| Round 4 | 25 | 18 | 72% | Published as a mixed result, unsmoothed |
| Round 5 | 24 | 19 | 79% | |
| Round 6 | 20 | 18 | 90% | |
| Round 7 | 19 | 16 | 84% | |
| Round 8 | — | — | never triaged | Reached the gate; no verdicts recorded |
| Rounds 3–7 | 111 | 91 | 82% | The graded set |
Read these as self-audit. Every number above was measured on products the authors built themselves. See Limits.
No responsive layout — core actions were unreachable on mobile.
Mid-altitude action buttons permanently dead — the primary interaction of the screen did nothing.
Same caveat as the previous slide: this is a product the authors built. Self-audit, not independent validation.
A CRITICAL finding — “Rules Edit button does nothing” — was reported in rounds 3, 4 and 5. Round 5 even marked it REPRODUCED across two sessions.
Manual browser checks passed every single time. The button worked.
When the browser automation clicked a control that was outside the viewport, it reported success — but the click never landed. A DOM check afterwards then “confirmed” the control was broken.
Three rounds of a confident, cross-referenced, entirely fictional CRITICAL.
A research finding that survived into the product as a source comment explaining why the code is shaped the way it is.
Round 4 found three regressions that were the team's own.
Round 6's worst finding was, in the author's words, “ours.”
Every work node is wrapped by a quality gate that inspects the artifact on disk. It never trusts an agent's self-reported success.
A browser stage has to demonstrate the browser actually navigated. That rule exists because of the story two slides back.
It runs before real user research to make that research worth the calendar time. It does not substitute for it, and no result here should be presented as a user study.
Every precision figure in this deck is self-audit on our own products. KNOWN_ISSUES.md states plainly that finding-validity on a product the authors did not build is n=0. Treat 87% as “measured on us,” never as independent validation.
Running unchanged default personas against a different product produces fiction. The doctor subcommand warns you about exactly this.
It is a lead worth chasing, not testimony. Only OBSERVED findings carry machine-checkable reproduction steps. Do not quote a simulated finding as if a user said it.
Status: v0.1.0, beta. The repo is public and MIT-licensed, but is not accepting external contributions yet.
Whatever stands up a disposable instance of your app with realistic data in it.
Where the seeded instance lives, and how to get in.
.md filesRewritten for your product. This is the input that decides whether you get findings or fiction.
The conversational path — how it has actually been used:
The CLI path, if you want it:
.dot header, and session logs of the invocation phrasing