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. ## 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. ## Mobile Design Contract When a task changes composition, navigation, overlays, touch behavior, scrolling, or breakpoint behavior, state these choices in the working plan or task notes. Keep them brief; do not create a separate document unless the task already uses a spec or committed plan. For copy, icon, color, or content-only styling inside an unchanged surface, identify the nearest mobile exemplar and the rendered mobile check instead of forcing the full contract. - desktop user outcome and mobile entry point - nearest shipped mobile exemplar and which interaction/geometry it contributes - mobile information hierarchy and ...