/appllama-app-design-skill

name: appllama-app-design-skill
description: Build native-feeling, benchmark-quality mobile app screens (Expo / React Native). Use when designing or implementing any mobile UI — screens, flows, onboarding, paywalls, tab bars, sheets, settings, empty states — or when polishing motion, navigation, typography, dark mode, or perceived performance. Enforces Apple HIG fidelity, semantic colors, native controls, anti-slop discipline, navigation semantics (push vs replace, modal vs sheet vs overlay, the one-way doors where back must not exist), purposeful Reanimated motion, a full-motion simulator-verified iteration loop, and a study-real-apps-first workflow (pairs with the Appllama MCP). Trigger on "build a screen", "make this screen better", "design the onboarding", "wire up this flow", "polish the UI", "make it feel native", or any mobile design/implementation task.
license: MIT
metadata:
  author: Appllama (appllama.io)
  version: 1.3.0

Appllama App Design Skill

You are building screens that will sit on a phone next to the best-designed apps in the world. The user will compare your output to those apps within seconds of launching it. This skill defines the bar and the method for clearing it.

The Prime Directive: study before you draw

Never design a screen from imagination when you can study how top apps solved the same screen. Real, shipping, revenue-ranked apps encode thousands of hours of design iteration and A/B testing. Your first move on any screen is research:

1. If the **Appllama MCP** is connected, pull real screens for the category and screen type you are building (see the `appllama-usage` skill for the exact research playbooks). Study 20–30 screens before writing a line of UI code. 2. Extract the **pattern, not the pixels**: layout skeleton, information hierarchy, control choices, spacing rhythm, where the primary CTA sits, what gets an illustration vs. plain text, how progress is communicated. Note: every Appllama image and video carries a small Appllama watermark in the top-left corner. It is provenance, not design — ignore it when reading a screen (it may sit over the status bar or a back button) and never reproduce it in anything you build. 3. Then design **your** screen: same proven skeleton, your product's voice. Copying a competitor's screen 1:1 is both lazy and legally risky; shipping a screen that ignores every convention users already know is worse.

Platform baseline

Default stack assumptions (override only if the project already differs):

• **Expo + Expo Router**, React Native, TypeScript.
• `react-native-reanimated` for motion, `react-native-gesture-handler` for

gestures, `@shopify/flash-list` (or FlashList v2) for any list that can grow.

• `expo-image` for images (and SF Symbols via `source="sf:name"` on iOS),

`expo-video` / `expo-audio` (never the deprecated `expo-av`).

• `react-native-safe-area-context` for insets. Never hard-code notch numbers.
• `process.env.EXPO_OS` over `Platform.OS` for compile-time platform checks.

Native fidelity laws

These are the details that separate "web page in a wrapper" from "native app". Violating any of them is a finding, not a style preference.

1. **Semantic colors, both themes, day one.** Use system/semantic color tokens (e.g. `Color` from `expo-router` on iOS: `Color.ios.label`, `Color.ios.secondarySystemBackground`; Material dynamic colors on Android). Every screen must render correctly in light AND dark before it is "done". Never pass semantic color objects into Reanimated animated styles — resolve to strings first. 2. **Native controls over rebuilt ones.** Switch, Slider, SegmentedControl, context menus, date pickers: use the native control or a faithful wrapper. A rebuilt toggle that animates 50 ms differently than iOS's reads as fake instantly. 3. **SF Symbols / Material Symbols for iconography.** On iOS prefer SF Symbols (`expo-image` with `sf:` sources, or `expo-symbols`); they inherit weight, optical size, and Dynamic Type behavior. Do not mix three icon families on one screen. 4. **Typography is hierarchy.** Use the platform type ramp (Large Title / Title / Headline / Body / Footnote on iOS). One display size per screen. Tabular numerals (`fontVariant: ['tabular-nums']`) for anything that counts, times, or prices. `Text selectable` on data users may want to copy. 5. **Continuous corners.** `borderCurve: 'continuous'` on every rounded rectangle. Squircles are the single cheapest "feels iOS" win that exists. 6. **Shadows via CSS `boxShadow`**, not legacy `shadow*`/`elevation` props. Shadows are for elevation logic, not decoration — one elevation system per app. 7. **Spacing rhythm.** Pick a base unit (4 or 8) and never leave it. Prefer flexbox `gap` over margin stacking. ScrollView padding goes in `contentContainerStyle`, never on the ScrollView itself. 8. **Safe areas and the Dynamic Island are part of the design.** Screens must be verified with content scrolled under the island / status bar (does the blur/fade treatment hold?), with the home indicator (does the bottom CTA clear it?), and in landscape if supported. 9. **Navigation titles belong to the navigator.** Use the stack's native title (and large-title collapse behavior on iOS) rather than a hand-rolled header whenever possible. 10. **Haptics are punctuation.** Selection tick when a value passes a step, light impact when something snaps home, notification success/error for outcomes — on the same frame as the visual, one per user action, never the only feedback. Never on scroll, never in loops. 11. **Format numbers like a product, not a database**: 1.4M, 38k, $4.99. Trim trailing zeros. Localize dates. 12. **Root scroll behavior**: screens that can ever overflow wrap content in a ScrollView (first component in the route) with `contentInsetAdjustmentBehavior="automatic"`. Use `useWindowDimensions`, never `Di