Dumb army
Dumb Army — fan out an army of dumb-but-real persona subagents over real screenshots to find where users get confused (burro-first UX/copy testing)
npx -y skills add ninja-automacoes/dumb-armyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when you need to know if an interface or artifact (web page, app screen, dashboard, PDF, email, Figma export, or raw copy) is easy to understand (low cognitive load / "burro-first"), where real users get confused, or before shipping copy/UX changes.
SKILL.md
5.4 KB, as published. Nobody here has run it
Testing UX with Persona Subagents
Overview
Find where users' brains stall by simulating many at once: a fleet of persona subagents — dumb, lazy, skeptical, but always inside the real audience — each reacting in character to the highest-fidelity view you can produce, aggregated into a ranked problem list.
Core principle: test what the eye sees, with the users you actually have. Extracted source copy and off-audience laypeople both lie.
Fidelity ladder (test the highest rung reachable): live render (screenshot) > visual export (Figma/PDF/email) > raw text. Dropping to raw text blinds you to visual confusion (an element reading as a button, what's above the fold, reading order) — flag it in the report.
When to Use
"Is this clear?" / "burro-first" checks; hunting confusion, abandon points, trust gaps before shipping; measuring whether a copy/UX fix actually reduced effort.
Not for: pixel-accurate visual QA, or when you already know the fix.
Method
Step 0 is the gate. Never fan out before it's confirmed — guessing the audience is the mistake that wastes the whole fleet.
- Intake (grill-me style): auto-derive, then confirm. First read the project (CLAUDE.md, CONTEXT.md, README, the artifact's own copy) and propose: the product in one line, the ICP and its segments, and a knowledge floor per segment — the minimum competence personas in that segment share (e.g. devs → "uses Claude Code"; advertisers → "has bought ads before"). Single-segment products get one floor. Then confirm with the owner one question at a time, recommending each answer; only ask what the repo didn't already answer. The owner sets persona count N (recommend ~8–12 per segment). Lock ICP, the floor(s), N, and what "good" looks like before spawning anything.
- Capture the highest-fidelity view (ladder + blind-spot rule above). Web → screenshot fold + full + mobile (
screenshot.mjs); other artifacts → export to images. PersonasReadthe files — never substitute extracted source for an available render. - Generate N personas from the intake, split across the ICP segments. Each persona meets its segment's knowledge floor (hard minimum); vary only the type of dumbness above the floor (impatient, skeptical, literal, low-English, mobile, non-marketing). Below-floor laypeople ("my aunt who sells clothes") produce noise, not bugs.
- Each persona reacts IN CHARACTER to the captured view, returns a schema (not prose):
firstImpression; the comprehension triad answered from the first screen only —gotWhat,gotForWhom,gotNext(booleans: do they know what it is, that it's for them, and the next action?);whatItDoes,wouldAct,confusing[](exact on-screen words),eyeCatch,abandonPoint,effort0–10,trust0–10,topFix. Cheap models (haiku), parallel. - Aggregate, don't read N essays. The headline burro-first KPI = % of personas passing all three of the comprehension triad on the first screen. Plus avg effort/trust (overall + per segment), confusing-term frequency, and convergence — 3+ personas hitting the same element = P0. Rank by (personas × severity).
- If you applied fixes, re-run the same fleet and compare the delta (triad %, effort, trust) — mandatory after any change, the only proof it worked. A pure diagnostic that changed nothing needs no re-run.
Quick Reference
| Step | Tool | Key rule |
|---|---|---|
| Intake | read repo + confirm w/ owner | lock ICP, floor per segment, N — the gate |
| Capture | playwright channel: "chrome" | fold + full + mobile |
| Fan out | Workflow / parallel Agent, haiku | N personas, knowledge floor = hard min |
| Collect | forced JSON schema | exact on-screen quotes in confusing[] |
| Aggregate | script over results | convergence = P0 |
| Verify | re-run fleet | measure effort/trust delta |
Common Mistakes
- Skipping intake / guessing the audience. The meta-failure: fanning out before locking ICP + knowledge floor means testing the wrong users (or burning a fleet on noise). Run Step 0 and confirm with the owner first.
- Testing extracted text instead of screenshots. The #1 in-test failure. The rendered hero, the element that looks clickable, the visual order — none survive text extraction.
- Personas below the knowledge floor. "Doesn't know what a dev is" is noise. Hold the floor; vary only how dumb/lazy/skeptical they are above it.
- Unstructured output. 20 freeform reactions you can't aggregate. Force a schema; the value is in the convergence math, not the essays.
- Too few personas. 5 finds gross breakage; 15–25 surfaces convergence and covers sub-segments (each side of a two-sided product).
- Shipping a fix without re-running. After any change to the artifact, re-run — skipping it means you never proved the fix worked. (A pure diagnostic that changed nothing needs no re-run.)
Real-World Impact
Text-only review missed that hero demo terminals read as buttons (18/20 personas) — surfaced only on screenshots. Swapping laypeople for real users moved avg effort 6.3→5.7, trust 5.3→6.3.