user-walkthrough

# User walkthrough Screen reviews do not prove a journey. When `pnpm design:route` includes this skill, walk its declared scope: the changed path for a local journey change, the agent-handoff path for a handoff change, or the continuous north-star path for a new surface. ## Authority and limit Judge facts that live in the artifact: vocabulary, next-step visibility, control discoverability, feedback, perceived reversibility, waiting state, missing paths, and visible craft. Each can be proven by pointing at the screen. Do not claim facts that live in a person's mind: whether they want it, will return, recommend it, or pay. Simulated users mispredict real people inconsistently. “No observable stall” does not mean “they like it.” Demand, retention, and willingness come only from real people. ## Name patterns, not emotions Every finding carries a reusable pattern name. “This person will feel frustrated” is invention; “dead-end CTA—the primary button opens an empty destination” is a checkable pattern. Common patterns: | Pattern | Definition | |---|---| | Dead-end CTA | the strongest action leads nowhere useful | | Implementation-language label | the label describes program work, not the user's outcome | | Gate before value | the product requires something before showing why it matters | | Silent wait | work is happening with no visible progress | | Unknown reversibility | a risky-looking action shows no undo or cancellation path | | Builder vocabulary leak | internal develo...