mobile-parity

# Mobile Parity Use this skill before planning or changing UI. Goal: desktop and mobile deliver the same user value, while each viewport gets an intentional composition and tests prove the mobile path. Before proposing a mobile design, read [Kandev Mobile UI Language](references/kandev-mobile-ui-language.md) and inspect the closest shipped mobile surface. Responsive CSS alone does not establish mobile parity. For buttons, single-line inputs, selectors, or control-size audits, also read [Control sizing](references/control-sizing.md). It defines desktop sizes, touch exceptions, and the sweep procedure. ## When It Applies Apply when task changes user-facing UI: - new or changed pages, routes, components, forms, dialogs, drawers, navigation, dashboards, tables, cards, toolbars, editors, settings, onboarding, or visual states - new frontend behavior attached to backend/API work - bug fixes where layout, touch behavior, scrolling, or viewport width can affect success If task has no UI surface, say why this skill does not apply and continue. ## Specification ownership When the task uses durable specifications, put mobile outcomes in the system that owns the feature contract. Do not create a second UI requirement or design only because the feature needs a phone surface. Use the UI system only for an independent reusable interaction contract. Keep the mobile composition in the owning feature design with its backend and desktop boundaries. Link to an existing UI contract when...