Visual Flow Storyboard

Use this skill to map what the product actually does, not what the docs say it should do. This owns the journey/storyboard artifact. For a persistent testable story matrix plus a fix loop, use ux-logic-loop (it should reuse this skill's output rather than re-deriving flows). For a pre-implementation plan inside a PR review, visual-pr-review should also reuse this output rather than re-mapping flows.

What to analyze

• Entry points, exits, and interrupted resumes
• Screens, states, branches, and transitions
• Roles, permissions, tenant states, and feature flags
• Hidden, legacy, or unreachable paths
• Error, empty, loading, cancellation, and recovery states
• UX friction across the full journey

Required approach

1. Start from the real codebase.
2. Identify the flow boundary: start point, end point, user role, and relevant flags or data states.
3. Trace the actual path through routes, guards, loaders, actions, APIs, redirects, and state transitions.
4. Build a state matrix for the meaningful variants.
5. Convert the states into a storyboard with numbered steps.
6. Mark uncertainty when a screen or branch is inferred rather than proven.
7. If asked for a future-state storyboard, describe the target flow and the changes needed to get there.
8. If asked for a change recap, compare before vs after and call out removed, added, or changed states.

What to inspect

• Routes, pages, views, forms, dialogs, navigation, and responsive variants
• Guards, middleware, permissions, feature flags, redirects, and validation rules
• Loading, error, empty, and recovery behavior
• Tests, analytics events, and screenshots or design artifacts when present

Output shape

Prefer a compact, structured storyboard:

• Flow summary
• Boundaries and roles
• State matrix
• Storyboard steps
• Branch diagram or table
• UX issues and friction points
• Target flow if requested
• Open questions or uncertain branches

Rules

• Do not invent screens that are not supported by code or evidence.
• Do not analyze screens in isolation when the real issue is the full flow.
• Do not assume a framework implies the rendering or navigation model.
• Focus on the actual user journey and how the system responds at each step.

Shared output profile

Compose the plan profile from output-templates. Keep every journey frame tied to state, action, transition, evidence, and any inferred gap. Preserve stricter domain rules above, omit empty components, and never fill a component with invented evidence.