expo-design-system

Create a src/theme/ directory with token files for colors, spacing, typography, radius, shadows, and motion, re-exported from one index entry point. Then build reusable components in src/components/ that consume only those tokens with variant, size, and state props.

Run grep checks for hex colors, raw fontSize, non-scale spacing values, borderRadius, and legacy shadow props outside the theme directory. Score each category as escapes per 100 source lines, then migrate typography first, followed by spacing, colors, and radius, one screen per commit.

Yes. If a styling library already exists, it is the source of truth and should be extended in its own idiom rather than adding a second theme. For Tailwind projects, tokens live in global.css as CSS variables while the same scales and naming rules apply.

Extract only when the view appears in two or more screens, has a nameable role like Card or EmptyState, and its props API is smaller than its implementation. Move it stepwise from inline JSX to a screen-local component, then to src/components/, never speculatively.

The skill names 20 tells including web-style modals, emoji icons, everything-is-a-card layouts, heavy shadows, hardcoded light-mode colors, and full-screen spinners. Each tell has an observable signature and a native replacement such as formSheet, grouped lists, or semantic platform colors.

No. Platform components that already carry the native design language, including Switch, DateTimePicker, stack headers, and @expo/ui views, should not be wrapped just to route them through the system. Native styling is the design system for those controls.