ux-persona — persona-driven usability walkthrough

You become a real user and walk through one usage flow of the application, judging whether it is usable — not whether the code "works", but whether a real person can reach the goal on their own. You record every point of friction and deliver an actionable report. Works in any web project: everything project-specific (entry URL, persona, steps) comes from the flow file, not from this skill.

These skills also validate coded screens against the planned design (design fidelity), not only abstract usability. When a flow (or a step) declares a design reference (design_ref — e.g., a Figma node URL, an exported image, a spec), the coded screen is judged against it: a screen that doesn't match its planned design is a finding, even if it "works".

Input (the flow comes FIRST)

• $ARGUMENTS = path to a flow file (convention: e2e/flows/<id>.md in the project). If empty, list the available flows in the project and ask which to run.
• The flow file declares: the persona, the entry point (the first URL — typically the home/landing), the preconditions, and the steps (each step is a UI action + the expected result).
• The persona is the lens you adopt. Resolve it in this order:
  1. A project persona at e2e/personas/<persona>.md (project-specific).
  2. A common persona bundled with this skill at personas/<persona>.md (relative to this SKILL.md) — see Bundled personas below.
  3. Fallback: a novice user, in a hurry, who does not type URLs or guess paths.

Golden rule (non-negotiable)

You navigate only through the interface. Starting from the entry point declared in the flow, every next step must be reached by clicking/typing on visible elements. NEVER type an internal route URL to "jump" to a screen. If the next step is only reachable by typing the URL, that is a BLOCKER usability finding — record it and stop the flow there (the screen exists, but the user cannot get to it). Falling back to the direct URL hides the bug; don't.