About mobile-ui-ux-designer
mobile-ui-ux-designer is a skill for designing or reviewing mobile interfaces from requirements, screens, user flows, and implementation requests. It guides designers through user goals, existing project context, accessibility, and scoped handoff requirements.
Key features
- 01Start from user goals and risks
- 02Inspect existing project context
- 03Adapt output to task size
- 04Specify components and behavior
- 05Include accessibility and reduced motion
- 06Require approval before implementation
Use cases
- 01Designing a mobile screen from a requirement
- 02Reviewing a flow for errors and empty states
- 03Preparing an implementation handoff within scope
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/mobile-ui-ux-designerin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
references/design.mdproject-context.mdunderstand.mdverify.mdDetails
From the project READMEMobile user interface and user experience design
Accept a feature, requirement, screenshot, wireframe, user flow, critique, or implementation request. Define the user's goal before visual design.
Start
- Read the applicable project instructions and product context.
- Identify the user, primary action, current problem, and failure risks.
- Find existing components, design tokens, navigation, localization, and tests.
- Select the task size below.
A design token is a named value for color, spacing, type, or another visual property. Use existing tokens before arbitrary values.
| Size | Scope | Output budget |
|---|---|---|
| LOW | One copy, component, spacing, or state change | 300–600 words |
| MEDIUM | One screen, form, sheet, or flow step | 900–1,600 words |
| HIGH | Several screens, sensitive flows, or design-system work | 1,800–3,500 words |
For context and research, read understand.md. For design contracts and limits, read design.md.
For review or implementation, read verify.md. Get actual project values through project-context.md.
Design requirements
Make essential content and the next action available on compact screens. Explain any constraint from large text, localization, keyboards, or safety warnings.
Use one dominant action in a usual task state. For equal alternatives, define an explicit choice state. Do not weaken a legitimate peer action.
Give error, empty, locked, and disabled states a clear next step. Explain unavailable features honestly. Keep user input on failure.
Specify concrete components, token roles, and behavior. Do not use vague design descriptions such as “modern” or “premium.”
Keep accessibility in every task size. Respect reduced motion. Use more than color or icons to communicate meaning.
Do not invent research. If browsing is unavailable, disclose the limit. Use verified local context and known platform constraints.
Merge overlapping sections. Omit irrelevant template sections. Keep the design and handoff within the selected budget.
Language and decisions
Use ASD-STE100 writing rules: active voice, simple verbs, consistent defined terms, and no contractions or semicolons.
Limit instructions to 20 words per sentence and descriptions to 25 words. Keep one topic and at most six sentences per paragraph.
Keep exact token names, interface labels, and quotations. Use the project's required locale for product copy.
Resolve unknown user goals, inaccessible states, missing data, and material scope changes before final design. Follow the approval rules in verify.md.
Approval already given for the same design stays valid. Do not infer approval from silence. Do not implement or publish beyond the authorized task.