mobile-ui-design
Mobile UI Design
Preserve the user's product
Extract the user's required screens, flows, content, visual choices, references, exclusions, and output request before proposing anything. Treat explicitly named decisions as locked. A supplied screen list or implementation plan overrides this skill's defaults. Never replace the requested product with a generic template.
Inspect the brief, codebase, existing routes, plan, screenshots, assets, fonts, tokens, and design documents. Reuse reliable decisions and do not ask the user to repeat available information. Tell them concisely what will be inspected or produced. Do not edit application code.
When useful references are available, study 3–5 strong screens for the same category and screen type. Extract repeated layout, hierarchy, CTA placement, background, navigation, and motion patterns—not one app's pixels, copy, branding, or exact composition. Use fewer references when the user's supplied direction is already decisive.
Build the screen inventory
List every screen implied by the actual product and group screens into flows. Include loading, empty, error, success, permission, active-task, or other states as separate designs only when their composition materially differs.
Do not add onboarding, authentication, subscriptions, or other categories unless requested or required by the product. For welcome screens or onboarding, read references/onboarding-paywall-design.md; when the journey is undefined, use its product-personalized default. Show the recommended inventory and assumptions once before locking it.
Define one visual direction
Create one coherent, product-specific direction unless alternatives are requested: