[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M77RT2S6FEMJ8VBAAYCME5GR":3,"skill-same:01M77RT2S6FEMJ8VBAAYCME5GR":56},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":30,"ownerDescription":6,"updatedAt":31,"install":32,"resources":45},"01M77RT2S6FEMJ8VBAAYCME5GR","expo-design-system",null,"Framework (OSS). Build and maintain a design system inside an Expo app - a reusable theme of design tokens (color, spacing, typography, radius, shadow, motion), reusable component structure with variant\u002Fsize\u002Fstate prop conventions, and rules for when to extract a repeated view into a shared component. Use when creating or organizing theme files and design tokens (theme.ts \u002F theme\u002F), extending an existing theme or styling library (NativeWind, Tamagui, Restyle, Unistyles) in its own idiom, standardizing styles so screens (including AI-generated ones) look consistent and polished, building an in-app component library, or auditing an app for design-system drift (hardcoded colors, spacing, fonts). For platform styling specifics (semantic colors, HIG rules, native controls) use expo-native-ui; for Tailwind\u002FCSS setup use expo-tailwind-setup; for folder layout of a new app use expo-project-structure.","Reihantt6\u002Fsns-myagent","Reihantt6","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F219822095?v=4","01M77KK94PV8B7C2D9XWXNS8DJ","Mohamad Reihan tegar prasetya","01M77KK958QFMTHYXGXFV7KZ79",2,"MIT","https:\u002F\u002Fgithub.com\u002FReihantt6\u002Fsns-myagent\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fexpo-design-system\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\ndescription: \"Framework (OSS). Build and maintain a design system inside an Expo app - a reusable theme of design tokens (color, spacing, typography, radius, shadow, motion), reusable component structure with variant\u002Fsize\u002Fstate prop conventions, and rules for when to extract a repeated view into a shared component. Use when creating or organizing theme files and design tokens (theme.ts \u002F theme\u002F), extending an existing theme or styling library (NativeWind, Tamagui, Restyle, Unistyles) in its own idiom, standardizing styles so screens (including AI-generated ones) look consistent and polished, building an in-app component library, or auditing an app for design-system drift (hardcoded colors, spacing, fonts). For platform styling specifics (semantic colors, HIG rules, native controls) use expo-native-ui; for Tailwind\u002FCSS setup use expo-tailwind-setup; for folder layout of a new app use expo-project-structure.\"\nlicense: \"MIT\"\n---\n# Expo Design Systems\n\nMake every screen in an app draw from one visual source of truth: a token theme and a small set of reusable components. This skill defines where tokens live, what they cover, how reusable components are shaped, and when a repeated view earns promotion into the system.\n\nSibling skills own the layers around this one:\n\n- `expo-native-ui` - platform styling rules (HIG, semantic colors, controls, shadows syntax). Follow it for **what values look native**; follow this skill for **where values live and how they're reused**.\n- `expo-tailwind-setup` - if the project uses Tailwind, tokens live in `global.css` as CSS variables instead of TypeScript. The scales and naming in this skill still apply; only the storage format changes.\n- `expo-project-structure` - folder skeleton for new apps.\n\n## References\n\nConsult these resources as needed:\n\n```\nreferences\u002F\n  audit.md      Audit an existing app for design-system drift: grep checks,\n                scoring rubric, incremental adoption plan, and templates for\n                documenting or extending components\n```\n\n## Adopt Before You Build\n\nIn an app that already has screens, the first move is detection, not construction. Before writing any token file:\n\n1. **Look for a declared system.** Check `package.json` for a styling library - NativeWind\u002FTailwind (use `expo-tailwind-setup`), Tamagui, Restyle, Unistyles, styled-components. Then look for a token file: `theme.ts`, `src\u002Ftheme\u002F`, `constants\u002Ftheme.ts`, or `constants\u002FColors.ts` (the create-expo-app default).\n2. **If one exists, it is the source of truth.** Extend it in its own idiom - its names, its scale, its storage format. Audit drift against that system, not against the examples below.\n3. **If only de facto values exist** - the same greys and paddings repeated across screens, no theme file - there is no system yet. Those values are the input to the scales, not the authority: derive tokens from the most frequent ones, snapped to the 4-point grid (`references\u002Faudit.md` §5).\n4. **Never introduce a second system beside an existing one.** A fresh `src\u002Ftheme\u002F` next to a Tamagui config is design-system drift, not adoption.\n\nOnly when nothing exists do the defaults below apply as written.\n\n## The Theme\n\nIn an app without an existing system, all design tokens live under `src\u002Ftheme\u002F`. In a project without a `src\u002F` folder (the default `create-expo-app` template has `app\u002F`, `components\u002F`, and `constants\u002F` at the root), use the equivalent top-level location - typically `theme\u002F` or the existing `constants\u002F` - and keep the same file layout. Start small and split by token class as it grows:\n\n```\nsrc\u002Ftheme\u002F\n  colors.ts       # see expo-native-ui \"Colors\" for the palette pattern\n  spacing.ts\n  typography.ts\n  radius.ts\n  shadows.ts\n  motion.ts\n  index.ts        # re-exports everything: import { spacing, type } from \"@\u002Ftheme\"\n```\n\nA brand-new app can begin with a single `src\u002Ftheme.ts` holding all of the objects below, then promote it to the folder form once any one class needs its own file (same promotion rule as components). Either way there is exactly **one** theme entry point - never two competing token files.\n\nRules that make a theme worth having:\n\n- **Every repeated visual value is a token.** A literal that appears twice belongs in the theme.\n- **Components import tokens; screens import components.** A screen file that imports `spacing` for layout padding is fine; a screen file redefining a button color is drift.\n- **Never hardcode** hex colors, font sizes, or spacing multiples outside `src\u002Ftheme\u002F`. One-off values that are genuinely local (an icon's 17px optical nudge) may stay inline - with a comment saying why.\n\n### Colors\n\nBuild the palette from platform semantic colors: `Color` from `expo-router` wrapped in `Platform.select`, centralized in `theme\u002Fcolors.ts`. Semantic colors resolve on-device and adapt to light\u002Fdark automatically - prefer them for backgrounds, labels, and separators. (`expo-native-ui` \"Colors\" covers the full palette and rationale; the minimal version is:)\n\n```tsx\n\u002F\u002F theme\u002Fcolors.ts\nimport { Platform } from \"react-native\";\nimport { Color } from \"expo-router\";\n\nexport const colors = {\n  label: Platform.select({\n    ios: Color.ios.label,\n    android: Color.android.dynamic.onSurface,\n    default: \"#000000\",\n  })!,\n  secondaryLabel: Platform.select({\n    ios: Color.ios.secondaryLabel,\n    android: Color.android.dynamic.onSurfaceVariant,\n    default: \"#3c3c43\",\n  })!,\n  separator: Platform.select({\n    ios: Color.ios.separator,\n    android: Color.android.dynamic.outlineVariant,\n    default: \"#c6c6c8\",\n  })!,\n  systemBackground: Platform.select({\n    ios: Color.ios.systemBackground,\n    android: Color.android.dynamic.surface,\n    default: \"#ffffff\",\n  })!,\n  systemBlue: Platform.select({\n    ios: Color.ios.systemBlue,\n    android: Color.android.dynamic.primary,\n    default: \"#007aff\",\n  })!,\n  \u002F\u002F Deliberately fixed: text on a tinted (accent) surface stays white in both modes.\n  onTint: \"#ffffff\",\n};\n```\n\nAdd brand colors as explicit light\u002Fdark pairs only when the brand requires values the platform doesn't provide:\n\n```tsx\n\u002F\u002F theme\u002Fcolors.ts (brand additions)\nimport { useColorScheme } from \"react-native\";\n\nconst brandPalette = {\n  light: { accent: \"#5B21B6\", accentContrast: \"#FFFFFF\" },\n  dark: { accent: \"#A78BFA\", accentContrast: \"#1E1B4B\" },\n} as const;\n\nexport function useBrandColors() {\n  const scheme = useColorScheme();\n  return brandPalette[scheme === \"dark\" ? \"dark\" : \"light\"];\n}\n```\n\nKeep the brand set tiny (accent, accentContrast, maybe a tint per feature). Everything else stays semantic.\n\n**Static-safe vs hook-only.** The two patterns above have different reach - keep the boundary explicit:\n\n- Semantic\u002Fplatform colors (`colors` above) are **static-safe**: they resolve on-device, so plain token files like `theme\u002Ftypography.ts` can import them at module scope.\n- Brand light\u002Fdark pairs are **hook-only**: `useBrandColors()` reads the color scheme at render time, so brand colors can only be applied inside components. A static token file cannot call the hook.\n- Never mix the two in one file. If a static style (a `type` ramp step, a `variants` object) needs the brand accent, either apply the brand color in the component at render time, or wrap the pair in a static dynamic color (`DynamicColorIOS` on iOS) so it becomes static-safe.\n\n### Spacing\n\nOne scale, based on a 4-point grid. Name steps by size, not by use:\n\n```tsx\n\u002F\u002F theme\u002Fspacing.ts\nexport const spacing = {\n  xs: 4,\n  sm: 8,\n  md: 16,\n  lg: 24,\n  xl: 32,\n  xxl: 48,\n} as const;\n```\n\n- Use `gap` with spacing tokens for layout rhythm (`expo-native-ui` prefers gap over margin).\n- Screen edge padding is `spacing.md` unless the design says otherwise - pick one and keep it.\n- If a layout needs a value between steps, use the nearest step. The grid is the point.\n- If the same in-between multiple of 4 keeps recurring (12 and 20 are common), add it to the scale as a named step instead of scattering literals. The audit whitelist must then include it too.\n\n### Typography\n\nDefine named text styles, not raw font sizes. Mirror the platform ramp (Apple text styles) so sizes feel native:\n\n```tsx\n\u002F\u002F theme\u002Ftypography.ts\nimport { TextStyle } from \"react-native\";\nimport { colors } from \".\u002Fcolors\";\n\nexport const type = {\n  largeTitle: { fontSize: 34, fontWeight: \"700\", color: colors.label },\n  title: { fontSize: 22, fontWeight: \"600\", color: colors.label },\n  headline: { fontSize: 17, fontWeight: \"600\", color: colors.label },\n  body: { fontSize: 17, fontWeight: \"400\", color: colors.label },\n  subhead: { fontSize: 15, fontWeight: \"400\", color: colors.secondaryLabel },\n  caption: { fontSize: 12, fontWeight: \"400\", color: colors.secondaryLabel },\n} as const satisfies Record\u003Cstring, TextStyle>;\n```\n\nIf the project bundles static font files (one file per weight, loaded with `expo-font` or the config plugin), set weight via `fontFamily` names instead and omit `fontWeight` - otherwise iOS synthesizes the weight or falls back to the system font:\n\n```tsx\nheadline: { fontSize: 17, fontFamily: \"SFProRounded-Semibold\", color: colors.label },\n```\n\nExpose them through one component so screens never touch `fontSize`:\n\n```tsx\n\u002F\u002F components\u002Fthemed-text.tsx\nimport { Text, TextProps } from \"react-native\";\nimport { type } from \"@\u002Ftheme\";\n\nexport function ThemedText({\n  variant = \"body\",\n  style,\n  ...props\n}: TextProps & { variant?: keyof typeof type }) {\n  return \u003CText style={[type[variant], style]} {...props} \u002F>;\n}\n```\n\nScreen titles still come from the navigation stack header (`expo-native-ui` rule), so `largeTitle` is mostly for non-stack contexts.\n\n### Radius\n\n```tsx\n\u002F\u002F theme\u002Fradius.ts\nexport const radius = {\n  sm: 8,\n  md: 12,\n  lg: 16,\n  full: 9999, \u002F\u002F capsules\n} as const;\n```\n\nPair every non-capsule radius with `borderCurve: \"continuous\"` (per `expo-native-ui`).\n\n### Shadows\n\nShadows are `boxShadow` strings (never legacy shadow\u002Felevation props - see `expo-native-ui`). Two or three elevation levels are enough:\n\n```tsx\n\u002F\u002F theme\u002Fshadows.ts\nexport const shadows = {\n  card: \"0 1px 2px rgba(0, 0, 0, 0.05)\",\n  raised: \"0 4px 12px rgba(0, 0, 0, 0.10)\",\n  overlay: \"0 8px 24px rgba(0, 0, 0, 0.18)\",\n} as const;\n```\n\n### Motion\n\nDurations and shared spring\u002Feasing configs, so animations across the app feel related:\n\n```tsx\n\u002F\u002F theme\u002Fmotion.ts\nexport const motion = {\n  fast: 150, \u002F\u002F state feedback: press, toggle\n  base: 250, \u002F\u002F element transitions: enter\u002Fexit\n  slow: 400, \u002F\u002F large surfaces: sheets, screens\n} as const;\n```\n\nReanimated caveat: don't pass `Color`\u002F`PlatformColor` token values into Reanimated styles - use static colors there (see `expo-native-ui`).\n\n## Reusable Components\n\nThe theme controls values; components control structure. Shared primitives live in `src\u002Fcomponents\u002F` (see `expo-project-structure`).\n\n### The component contract\n\nEvery design-system primitive defines, explicitly:\n\n- **Variants** - visual intent: `primary`, `secondary`, `ghost`, `destructive`. Add a variant only when a real screen needs it.\n- **Sizes** - `sm`, `md`, `lg`. Default `md`. Sizes map to spacing\u002Ftypography tokens, never to fresh numbers.\n- **States** - default, **pressed** (not hover - this is touch), disabled, loading. Handle pressed with a `Pressable` style function; never leave a tappable element without pressed feedback.\n- **Style override** - accept a `style` prop and merge it **last**, so callers can adjust layout (margins, flex) without forking the component. Callers may override layout, not identity - a caller changing a button's colors is a signal the variant set is missing something.\n\n```tsx\n\u002F\u002F components\u002Fbutton.tsx\nimport { Pressable, ActivityIndicator, ViewStyle, StyleProp } from \"react-native\";\nimport { colors, spacing, radius } from \"@\u002Ftheme\";\nimport { ThemedText } from \".\u002Fthemed-text\";\n\nconst variants = {\n  primary: { backgroundColor: colors.systemBlue, color: colors.onTint },\n  secondary: { backgroundColor: colors.separator, color: colors.label },\n} as const;\n\nconst sizes = {\n  sm: { paddingVertical: spacing.xs, paddingHorizontal: spacing.sm },\n  md: { paddingVertical: spacing.sm, paddingHorizontal: spacing.md },\n} as const;\n\nexport function Button({\n  variant = \"primary\",\n  size = \"md\",\n  title,\n  loading,\n  disabled,\n  style,\n  onPress,\n}: {\n  variant?: keyof typeof variants;\n  size?: keyof typeof sizes;\n  title: string;\n  loading?: boolean;\n  disabled?: boolean;\n  style?: StyleProp\u003CViewStyle>;\n  onPress?: () => void;\n}) {\n  return (\n    \u003CPressable\n      accessibilityRole=\"button\"\n      disabled={disabled || loading}\n      onPress={onPress}\n      style={({ pressed }) => [\n        {\n          backgroundColor: variants[variant].backgroundColor,\n          borderRadius: radius.md,\n          borderCurve: \"continuous\",\n          alignItems: \"center\",\n          opacity: disabled ? 0.4 : pressed ? 0.7 : 1,\n          ...sizes[size],\n        },\n        style, \u002F\u002F caller overrides merge last\n      ]}\n    >\n      {loading ? (\n        \u003CActivityIndicator color={variants[variant].color as string} \u002F>\n      ) : (\n        \u003CThemedText variant=\"headline\" style={{ color: variants[variant].color }}>\n          {title}\n        \u003C\u002FThemedText>\n      )}\n    \u003C\u002FPressable>\n  );\n}\n```\n\n### Composition over configuration\n\nWhen a component's props start describing *content* (`leftIcon`, `subtitle`, `footerText`, `badgeCount`), stop adding props and accept `children` instead. A `Card` that renders `children` with token padding outlives any `Card` with twelve content props. Reserve props for the contract above: variant, size, state, style.\n\n### When to extract - and when not to\n\nPromote a view into `src\u002Fcomponents\u002F` when **all** of these hold:\n\n1. It appears (or is about to appear) in **two or more screens**. Until then it stays colocated in `screens\u002F\u003Cname>\u002F` (see `expo-project-structure`).\n2. It has a **nameable role** (\"Card\", \"EmptyState\", \"Badge\") - not \"the thing on the profile screen\".\n3. Its API is **smaller than its implementation**. If the props would just re-expose every internal style, it isn't a reusable component yet - it's a screen fragment.\n\nPromotion path: inline JSX → component in `screens\u002F\u003Cname>\u002F` → `src\u002Fcomponents\u002F`. Move one step at a time, when the trigger fires - never speculatively. Wrong abstractions cost more than duplication; a second copy of a view is cheaper than a primitive with a bad API.\n\nDo **not** wrap platform components that already carry the design language (`Switch`, `DateTimePicker`, stack headers, `@expo\u002Fui` views) just to route them through the system. Native styling *is* the design system for those.\n\n## Where Decisions Live\n\n| Decision | Lives in | Example |\n|---|---|---|\n| A visual value used anywhere twice | `src\u002Ftheme\u002F` | brand accent, spacing step |\n| Structure + variants of a reused element | `src\u002Fcomponents\u002F` | Button, Card, EmptyState |\n| One screen's private composition | `screens\u002F\u003Cname>\u002F` | profile header layout |\n| One-off local adjustment | inline, with a comment | optical nudge on an icon |\n| Screen titles, top-level chrome | navigation stack options | header title, large title |\n\n## Self-Critique Pass\n\nAfter building or changing a screen, screenshot it and check it against these principles (from [Expo's design-principles guide](https:\u002F\u002Fexpo.dev\u002Fblog\u002Fhow-to-apply-professional-design-principles-in-ai-app-development)). Each one maps to a system fix, not a local tweak:\n\n- **Hierarchy \u002F contrast** - is the most important element obviously first? Fix with `type` ramp steps, not ad-hoc font sizes.\n- **Proximity \u002F white space** - do related items sit closer than unrelated ones? Fix with `gap` + spacing tokens.\n- **Repetition \u002F unity** - do all corners, shadows, and accents match? If not, a value escaped the theme - move it in.\n- **Alignment** - do edges share axes? Fix with consistent screen edge padding.\n\nThe pass is complete only when all four checks pass, or every failing value has moved into the theme or a component. If a screen fails the same check twice, the fix belongs in the theme or a component - not in the screen.\n\n## Auditing an Existing App\n\nTo measure drift in an app that already has screens - hardcoded hex values, arbitrary spacing, inconsistent component APIs - follow `.\u002Freferences\u002Faudit.md`. It contains grep-based checks, a scoring rubric, an incremental adoption order for fixing a drifted app, and templates for documenting existing components and proposing new ones.\n\n## Submitting Feedback\nIf you encounter errors, misleading or outdated information in this skill, report it so Expo can improve:\n```bash\nnpx --yes submit-expo-feedback@latest --category skills --subject \"expo-design-system\" \"\u003Cactionable feedback>\"\n```\nOnly submit when you have something specific and actionable to report. Include as much relevant context as possible.\nIf an AI agent repeatedly failed or the user had to take over an Expo task, load the expo-skill-feedback skill and follow its eval-candidate flow instead of reusing the command above.\n","# Expo Design Systems\n\nMake every screen in an app draw from one visual source of truth: a token theme and a small set of reusable components. This skill defines where tokens live, what they cover, how reusable components are shaped, and when a repeated view earns promotion into the system.\n\nSibling skills own the layers around this one:\n\n- `expo-native-ui` - platform styling rules (HIG, semantic colors, controls, shadows syntax). Follow it for **what values look native**; follow this skill for **where values live and how they're reused**.\n- `expo-tailwind-setup` - if the project uses Tailwind, tokens live in `global.css` as CSS variables instead of TypeScript. The scales and naming in this skill still apply; only the storage format changes.\n- `expo-project-structure` - folder skeleton for new apps.\n\n## References\n\nConsult these resources as needed:\n\n```\nreferences\u002F\n  audit.md      Audit an existing app for design-system drift: grep checks,\n                scoring rubric, incremental adoption plan, and templates for\n                documenting or extending components\n```\n\n## Adopt Before You Build\n\nIn an app that already has screens, the first move is detection, not construction. Before writing any token file:\n\n1. **Look for a declared system.** Check `package.json` for a styling library - NativeWind\u002FTailwind (use `expo-tailwind-setup`), Tamagui, Restyle, Unistyles, styled-components. Then look for a token file: `theme.ts`, `src\u002Ftheme\u002F`, `constants\u002Ftheme.ts`, or `constants\u002FColors.ts` (the create-expo-app default).\n2. **If one exists, it is the source of truth.** Extend it in its own idiom - its names, its scale, its storage format. Audit drift against that system, not against the examples below.\n3. **If only de facto values exist** - the same greys and paddings repeated across screens, no theme file - there is no system yet. Those values are the input to the scales, not the authority: derive tokens from the most frequent ones, snapped to the 4-point grid (`references\u002Faudit.md` §5).\n4. **Never introduce a second system beside an existing one.** A fresh `src\u002Ftheme\u002F` next to a Tamagui config is design-system drift, not adoption.\n\nOnly when nothing exists do the defaults below apply as written.\n\n## The Theme\n\nIn an app without an existing system, all design tokens live under `src\u002Ftheme\u002F`. In a project without a `src\u002F` folder (the default `create-expo-app` template has `app\u002F`, `components\u002F`, and `constants\u002F` at the root), use the equivalent top-level location - typically `theme\u002F` or the existing `constants\u002F` - and keep the same file layout. Start small and split by token class as it grows:\n\n```\nsrc\u002Ftheme\u002F\n  colors.ts       # see expo-native-ui \"Colors\" for the palette pattern\n  spacing.ts\n  typography.ts\n  radius.ts\n  shadows.ts\n  motion.ts\n  index.ts        # re-exports everything: import { spacing, type } from \"@\u002Ftheme\"\n```\n\nA brand-new app can begin with a single `src\u002Ftheme.ts` holding all of the objects below, then promote it to the folder form once any one class needs its own file (same promotion rule as components). Either way there is exactly **one** theme entry point - never two competing token files.\n\nRules that make a theme worth having:\n\n- **Every repeated visual value is a token.** A literal that appears twice belongs in the theme.\n- **Components import tokens; screens import components.** A screen file that imports `spacing` for layout padding is fine; a screen file redefining a button color is drift.\n- **Never hardcode** hex colors, font sizes, or spacing multiples outside `src\u002Ftheme\u002F`. One-off values that are genuinely local (an icon's 17px optical nudge) may stay inline - with a comment saying why.\n\n### Colors\n\nBuild the palette from platform semantic colors: `Color` from `expo-router` wrapped in `Platform.select`, centralized in `theme\u002Fcolors.ts`. Semantic colors resolve on-device and adapt to light\u002Fdark automatically - prefer them for backgrounds, labels, and separators. (`expo-native-ui` \"Colors\" covers the full palette and rationale; the minimal version is:)\n\n```tsx\n\u002F\u002F theme\u002Fcolors.ts\nimport { Platform } from \"react-native\";\nimport { Color } from \"expo-router\";\n\nexport const colors = {\n  label: Platform.select({\n    ios: Color.ios.label,\n    android: Color.android.dynamic.onSurface,\n    default: \"#000000\",\n  })!,\n  secondaryLabel: Platform.select({\n    ios: Color.ios.secondaryLabel,\n    android: Color.android.dynamic.onSurfaceVariant,\n    default: \"#3c3c43\",\n  })!,\n  separator: Platform.select({\n    ios: Color.ios.separator,\n    android: Color.android.dynamic.outlineVariant,\n    default: \"#c6c6c8\",\n  })!,\n  systemBackground: Platform.select({\n    ios: Color.ios.systemBackground,\n    android: Color.android.dynamic.surface,\n    default: \"#ffffff\",\n  })!,\n  systemBlue: Platform.select({\n    ios: Color.ios.systemBlue,\n    android: Color.android.dynamic.primary,\n    default: \"#007aff\",\n  })!,\n  \u002F\u002F Deliberately fixed: text on a tinted (accent) surface stays white in both modes.\n  onTint: \"#ffffff\",\n};\n```\n\nAdd brand colors as explicit light\u002Fdark pairs only when the brand requires values the platform doesn't provide:\n\n```tsx\n\u002F\u002F theme\u002Fcolors.ts (brand additions)\nimport { useColorScheme } from \"react-native\";\n\nconst brandPalette = {\n  light: { accent: \"#5B21B6\", accentContrast: \"#FFFFFF\" },\n  dark: { accent: \"#A78BFA\", accentContrast: \"#1E1B4B\" },\n} as const;\n\nexport function useBrandColors() {\n  const scheme = useColorScheme();\n  return brandPalette[scheme === \"dark\" ? \"dark\" : \"light\"];\n}\n```\n\nKeep the brand set tiny (accent, accentContrast, maybe a tint per feature). Everything else stays semantic.\n\n**Static-safe vs hook-only.** The two patterns above have different reach - keep the boundary explicit:\n\n- Semantic\u002Fplatform colors (`colors` above) are **static-safe**: they resolve on-device, so plain token files like `theme\u002Ftypography.ts` can import them at module scope.\n- Brand light\u002Fdark pairs are **hook-only**: `useBrandColors()` reads the color scheme at render time, so brand colors can only be applied inside components. A static token file cannot call the hook.\n- Never mix the two in one file. If a static style (a `type` ramp step, a `variants` object) needs the brand accent, either apply the brand color in the component at render time, or wrap the pair in a static dynamic color (`DynamicColorIOS` on iOS) so it becomes static-safe.\n\n### Spacing\n\nOne scale, based on a 4-point grid. Name steps by size, not by use:\n\n```tsx\n\u002F\u002F theme\u002Fspacing.ts\nexport const spacing = {\n  xs: 4,\n  sm: 8,\n  md: 16,\n  lg: 24,\n  xl: 32,\n  xxl: 48,\n} as const;\n```\n\n- Use `gap` with spacing tokens for layout rhythm (`expo-native-ui` prefers gap over margin).\n- Screen edge padding is `spacing.md` unless the design says otherwise - pick one and keep it.\n- If a layout needs a value between steps, use the nearest step. The grid is the point.\n- If the same in-between multiple of 4 keeps recurring (12 and 20 are common), add it to the scale as a named step instead of scattering literals. The audit whitelist must then include it too.\n\n### Typography\n\nDefine named text styles, not raw font sizes. Mirror the platform ramp (Apple text styles) so sizes feel native:\n\n```tsx\n\u002F\u002F theme\u002Ftypography.ts\nimport { TextStyle } from \"react-native\";\nimport { colors } from \".\u002Fcolors\";\n\nexport const type = {\n  largeTitle: { fontSize: 34, fontWeight: \"700\", color: colors.label },\n  title: { fontSize: 22, fontWeight: \"600\", color: colors.label },\n  headline: { fontSize: 17, fontWeight: \"600\", color: colors.label },\n  body: { fontSize: 17, fontWeight: \"400\", color: colors.label },\n  subhead: { fontSize: 15, fontWeight: \"400\", color: colors.secondaryLabel },\n  caption: { fontSize: 12, fontWeight: \"400\", color: colors.secondaryLabel },\n} as const satisfies Record\u003Cstring, TextStyle>;\n```\n\nIf the project bundles static font files (one file per weight, loaded with `expo-font` or the config plugin), set weight via `fontFamily` names instead and omit `fontWeight` - otherwise iOS synthesizes the weight or falls back to the system font:\n\n```tsx\nheadline: { fontSize: 17, fontFamily: \"SFProRounded-Semibold\", color: colors.label },\n```\n\nExpose them through one component so screens never touch `fontSize`:\n\n```tsx\n\u002F\u002F components\u002Fthemed-text.tsx\nimport { Text, TextProps } from \"react-native\";\nimport { type } from \"@\u002Ftheme\";\n\nexport function ThemedText({\n  variant = \"body\",\n  style,\n  ...props\n}: TextProps & { variant?: keyof typeof type }) {\n  return \u003CText style={[type[variant], style]} {...props} \u002F>;\n}\n```\n\nScreen titles still come from the navigation stack header (`expo-native-ui` rule), so `largeTitle` is mostly for non-stack contexts.\n\n### Radius\n\n```tsx\n\u002F\u002F theme\u002Fradius.ts\nexport const radius = {\n  sm: 8,\n  md: 12,\n  lg: 16,\n  full: 9999, \u002F\u002F capsules\n} as const;\n```\n\nPair every non-capsule radius with `borderCurve: \"continuous\"` (per `expo-native-ui`).\n\n### Shadows\n\nShadows are `boxShadow` strings (never legacy shadow\u002Felevation props - see `expo-native-ui`). Two or three elevation levels are enough:\n\n```tsx\n\u002F\u002F theme\u002Fshadows.ts\nexport const shadows = {\n  card: \"0 1px 2px rgba(0, 0, 0, 0.05)\",\n  raised: \"0 4px 12px rgba(0, 0, 0, 0.10)\",\n  overlay: \"0 8px 24px rgba(0, 0, 0, 0.18)\",\n} as const;\n```\n\n### Motion\n\nDurations and shared spring\u002Feasing configs, so animations across the app feel related:\n\n```tsx\n\u002F\u002F theme\u002Fmotion.ts\nexport const motion = {\n  fast: 150, \u002F\u002F state feedback: press, toggle\n  base: 250, \u002F\u002F element transitions: enter\u002Fexit\n  slow: 400, \u002F\u002F large surfaces: sheets, screens\n} as const;\n```\n\nReanimated caveat: don't pass `Color`\u002F`PlatformColor` token values into Reanimated styles - use static colors there (see `expo-native-ui`).\n\n## Reusable Components\n\nThe theme controls values; components control structure. Shared primitives live in `src\u002Fcomponents\u002F` (see `expo-project-structure`).\n\n### The component contract\n\nEvery design-system primitive defines, explicitly:\n\n- **Variants** - visual intent: `primary`, `secondary`, `ghost`, `destructive`. Add a variant only when a real screen needs it.\n- **Sizes** - `sm`, `md`, `lg`. Default `md`. Sizes map to spacing\u002Ftypography tokens, never to fresh numbers.\n- **States** - default, **pressed** (not hover - this is touch), disabled, loading. Handle pressed with a `Pressable` style function; never leave a tappable element without pressed feedback.\n- **Style override** - accept a `style` prop and merge it **last**, so callers can adjust layout (margins, flex) without forking the component. Callers may override layout, not identity - a caller changing a button's colors is a signal the variant set is missing something.\n\n```tsx\n\u002F\u002F components\u002Fbutton.tsx\nimport { Pressable, ActivityIndicator, ViewStyle, StyleProp } from \"react-native\";\nimport { colors, spacing, radius } from \"@\u002Ftheme\";\nimport { ThemedText } from \".\u002Fthemed-text\";\n\nconst variants = {\n  primary: { backgroundColor: colors.systemBlue, color: colors.onTint },\n  secondary: { backgroundColor: colors.separator, color: colors.label },\n} as const;\n\nconst sizes = {\n  sm: { paddingVertical: spacing.xs, paddingHorizontal: spacing.sm },\n  md: { paddingVertical: spacing.sm, paddingHorizontal: spacing.md },\n} as const;\n\nexport function Button({\n  variant = \"primary\",\n  size = \"md\",\n  title,\n  loading,\n  disabled,\n  style,\n  onPress,\n}: {\n  variant?: keyof typeof variants;\n  size?: keyof typeof sizes;\n  title: string;\n  loading?: boolean;\n  disabled?: boolean;\n  style?: StyleProp\u003CViewStyle>;\n  onPress?: () => void;\n}) {\n  return (\n    \u003CPressable\n      accessibilityRole=\"button\"\n      disabled={disabled || loading}\n      onPress={onPress}\n      style={({ pressed }) => [\n        {\n          backgroundColor: variants[variant].backgroundColor,\n          borderRadius: radius.md,\n          borderCurve: \"continuous\",\n          alignItems: \"center\",\n          opacity: disabled ? 0.4 : pressed ? 0.7 : 1,\n          ...sizes[size],\n        },\n        style, \u002F\u002F caller overrides merge last\n      ]}\n    >\n      {loading ? (\n        \u003CActivityIndicator color={variants[variant].color as string} \u002F>\n      ) : (\n        \u003CThemedText variant=\"headline\" style={{ color: variants[variant].color }}>\n          {title}\n        \u003C\u002FThemedText>\n      )}\n    \u003C\u002FPressable>\n  );\n}\n```\n\n### Composition over configuration\n\nWhen a component's props start describing *content* (`leftIcon`, `subtitle`, `footerText`, `badgeCount`), stop adding props and accept `children` instead. A `Card` that renders `children` with token padding outlives any `Card` with twelve content props. Reserve props for the contract above: variant, size, state, style.\n\n### When to extract - and when not to\n\nPromote a view into `src\u002Fcomponents\u002F` when **all** of these hold:\n\n1. It appears (or is about to appear) in **two or more screens**. Until then it stays colocated in `screens\u002F\u003Cname>\u002F` (see `expo-project-structure`).\n2. It has a **nameable role** (\"Card\", \"EmptyState\", \"Badge\") - not \"the thing on the profile screen\".\n3. Its API is **smaller than its implementation**. If the props would just re-expose every internal style, it isn't a reusable component yet - it's a screen fragment.\n\nPromotion path: inline JSX → component in `screens\u002F\u003Cname>\u002F` → `src\u002Fcomponents\u002F`. Move one step at a time, when the trigger fires - never speculatively. Wrong abstractions cost more than duplication; a second copy of a view is cheaper than a primitive with a bad API.\n\nDo **not** wrap platform components that already carry the design language (`Switch`, `DateTimePicker`, stack headers, `@expo\u002Fui` views) just to route them through the system. Native styling *is* the design system for those.\n\n## Where Decisions Live\n\n| Decision | Lives in | Example |\n|---|---|---|\n| A visual value used anywhere twice | `src\u002Ftheme\u002F` | brand accent, spacing step |\n| Structure + variants of a reused element | `src\u002Fcomponents\u002F` | Button, Card, EmptyState |\n| One screen's private composition | `screens\u002F\u003Cname>\u002F` | profile header layout |\n| One-off local adjustment | inline, with a comment | optical nudge on an icon |\n| Screen titles, top-level chrome | navigation stack options | header title, large title |\n\n## Self-Critique Pass\n\nAfter building or changing a screen, screenshot it and check it against these principles (from [Expo's design-principles guide](https:\u002F\u002Fexpo.dev\u002Fblog\u002Fhow-to-apply-professional-design-principles-in-ai-app-development)). Each one maps to a system fix, not a local tweak:\n\n- **Hierarchy \u002F contrast** - is the most important element obviously first? Fix with `type` ramp steps, not ad-hoc font sizes.\n- **Proximity \u002F white space** - do related items sit closer than unrelated ones? Fix with `gap` + spacing tokens.\n- **Repetition \u002F unity** - do all corners, shadows, and accents match? If not, a value escaped the theme - move it in.\n- **Alignment** - do edges share axes? Fix with consistent screen edge padding.\n\nThe pass is complete only when all four checks pass, or every failing value has moved into the theme or a component. If a screen fails the same check twice, the fix belongs in the theme or a component - not in the screen.\n\n## Auditing an Existing App\n\nTo measure drift in an app that already has screens - hardcoded hex values, arbitrary spacing, inconsistent component APIs - follow `.\u002Freferences\u002Faudit.md`. It contains grep-based checks, a scoring rubric, an incremental adoption order for fixing a drifted app, and templates for documenting existing components and proposing new ones.\n\n## Submitting Feedback\nIf you encounter errors, misleading or outdated information in this skill, report it so Expo can improve:\n```bash\nnpx --yes submit-expo-feedback@latest --category skills --subject \"expo-design-system\" \"\u003Cactionable feedback>\"\n```\nOnly submit when you have something specific and actionable to report. Include as much relevant context as possible.\nIf an AI agent repeatedly failed or the user had to take over an Expo task, load the expo-skill-feedback skill and follow its eval-candidate flow instead of reusing the command above.\n",{"license":15,"description":7},"main","58843b159d7a4050d6b785a98b908cce505c0b92","agent\u002Fskills\u002Fexpo-design-system",0,"https:\u002F\u002Fgithub.com\u002FReihantt6\u002Fsns-myagent","https:\u002F\u002Fgithub.com\u002FReihantt6","reihsns.web.id","2026-08-19 20:08:18",{"source":8,"skillName":5,"commands":33,"prompt":43,"zipAvailable":44},[34,37,40],{"tool":35,"command":36},"npx","npx skills add Reihantt6\u002Fsns-myagent --skill expo-design-system",{"tool":38,"command":39},"bunx","bunx skills add Reihantt6\u002Fsns-myagent --skill expo-design-system",{"tool":41,"command":42},"pnpm","pnpm dlx skills add Reihantt6\u002Fsns-myagent --skill expo-design-system","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FReihantt6\u002Fsns-myagent\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fexpo-design-system\u002FSKILL.md",true,[46,52],{"path":47,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":50,"sourceHtmlUrl":51},"agents\u002Fopenai.yaml","REFERENCE","参考文档",576,"https:\u002F\u002Fgithub.com\u002FReihantt6\u002Fsns-myagent\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fexpo-design-system\u002Fagents\u002Fopenai.yaml",{"path":53,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":54,"sourceHtmlUrl":55},"references\u002Faudit.md",7961,"https:\u002F\u002Fgithub.com\u002FReihantt6\u002Fsns-myagent\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fexpo-design-system\u002Freferences\u002Faudit.md",[57,64,71,78,85,92],{"skillNo":58,"name":59,"nameZh":6,"description":60,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":63,"publishedAt":19},"01M77XDCYZ407XYMF2T4P6F7VT","youtube-transcript","Extract transcripts from YouTube videos. Use when the user asks for a transcript, subtitles, or captions of a YouTube video and provides a YouTube URL (youtube.com\u002Fwatch?v=, youtu.be\u002F, or similar). Supports output with or without timestamps.","https:\u002F\u002Fgithub.com\u002FReihantt6\u002Fsns-myagent\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fyoutube-transcript\u002FSKILL.md",[],[],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":19},"01M77XD7PBC98J6MXGJJ2TJ8DX","youtube-thumbnail-design","YouTube thumbnail design with specific dimensions, contrast rules, and mobile preview optimization. Covers safe zones, text placement, face expression psychology, and A\u002FB testing. Use for: YouTube thumbnails, video cover images, click-through optimization. Triggers: youtube thumbnail, thumbnail design, video thumbnail, click through rate, ctr optimization, youtube cover, video cover image, thumbnail maker, thumbnail tips, youtube design, video preview image","https:\u002F\u002Fgithub.com\u002FReihantt6\u002Fsns-myagent\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fyoutube-thumbnail-design\u002FSKILL.md",[],[],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":19},"01M77XD2541C8HXJ6RHYZP4NGJ","youtube-short-maker","Make YouTube Shorts that hold attention with Pexo — vertical 9:16, fast-paced, hook in the first 3 seconds. Describe your topic and Pexo writes the script, generates the shots, picks the models, and assembles a finished Short with music and captions. Use for YouTube Shorts: \"youtube short\", \"make a youtube short\", \"shorts video\", \"short-form video\". NOT for long-form or landscape video.","https:\u002F\u002Fgithub.com\u002FReihantt6\u002Fsns-myagent\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fyoutube-short-maker\u002FSKILL.md",[],[],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":19},"01M77XCXKVSYK7KTZ3PQBVVGFD","xcode-project-setup","Safely modifies Xcode projects (.pbxproj) to add Swift Packages and link files. Use this skill whenever an iOS project needs dependencies installed (e.g. Firebase, Alamofire).","https:\u002F\u002Fgithub.com\u002FReihantt6\u002Fsns-myagent\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fxcode-project-setup\u002FSKILL.md",[],[],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":19},"01M77XCR1DV8ZQK2NHWKVY4EWX","x402","Set up Browser Use Cloud payments with x402 — pay per request from a crypto wallet (USDC on Base mainnet), no signup or API key. Two setups it works out up front — \"just use it\" (set up a wallet so you or Claude Code can run cloud browser tasks paid from the wallet — Claude writes and runs throwaway scripts, nothing touches your codebase) or \"build it in\" (install the SDK and write the key + code into your project). Walks through wallet setup, funding, .env, and a ~$1 test run. Use when the user asks about x402, pay-per-use, USDC payments, or wants Browser Use Cloud without an API key. For the free-tier signup (reverse-CAPTCHA → API key), use `browser-use cloud signup` or the `cloud` skill instead.","https:\u002F\u002Fgithub.com\u002FReihantt6\u002Fsns-myagent\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fx402\u002FSKILL.md",[],[],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":19},"01M77XCMD3R3ZBZQQSW6E0793B","x-twitter-scraper","Build GitHub Copilot workflows with Xquik X API SDKs, REST endpoints, hosted Apify Actor runs, MCP tools, TweetClaw OpenClaw plugin installs, signed webhooks, tweet search, user lookup, follower exports, media actions, and agent automation.","https:\u002F\u002Fgithub.com\u002FReihantt6\u002Fsns-myagent\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fx-twitter-scraper\u002FSKILL.md",[],[]]