mobile-parity

# Mobile Parity Use this skill before changing UI code for a feature. Goal: feature works on desktop and mobile, and tests prove the mobile path. ## 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. ## Workflow 1. Map affected surfaces. - Identify every page, modal, menu, tab, empty state, loading state, and error state the feature touches. - Check where desktop layout assumptions can fail: fixed widths, hover-only controls, sidebars, tables, dense toolbars, keyboard shortcuts, overflow, and absolute positioning. 2. Design desktop and mobile behavior together. - Prefer existing responsive patterns in the repo. - Define mobile navigation, stacking order, scrolling region, touch targets, and truncated text behavior before coding. - Make primary actions reachable without hover and without horizontal page scroll. 3. Implement responsive UI. - Use semantic controls and existing design-system components. - Keep touch targets large enough for touch use, generally at least 44px in the active dimension. - Ensure forms, dialogs, sheets, menus, tables, and empty states fi...