Update to Expo2

{
  "description": "Entry point for Expo and EAS tasks. Load first when the request mentions Expo, EAS, Expo Go, or an expo-* package, or the project has an expo dependency. Identify the goal, apply shared SDK and setup rules, and select the relevant skill. Includes fully specified tasks; excludes React Native projects without Expo or EAS signals.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 650
    },
    {
      "relative_path": "references/launch-without-dev-menu.md",
      "size_in_bytes": 1751
    }
  ],
  "name": "expo-overview",
  "skill_md_contents": "---\nname: expo-overview\ndescription: Entry point for Expo and EAS tasks. Load first when the request mentions Expo, EAS, Expo Go, or an expo-* package, or the project has an expo dependency. Identify the goal, apply shared SDK and setup rules, and select the relevant skill. Includes fully specified tasks; excludes React Native projects without Expo or EAS signals.\nlicense: MIT\n---\n\n# `expo-overview` — router & shared rules for Expo / EAS\n\n## Start Here — read before doing anything\n\n**Do not guess the skill from project files alone.** Many Expo goals look similar from\nthe filesystem but need different skills.\n\n1. **Confirm this is Expo or EAS work** — the request mentions Expo or EAS, or\n   `package.json` has an `expo` dependency. Otherwise this skill does not apply.\n   A native app using EAS for delivery qualifies without an Expo runtime.\n2. **Read the user's goal** — what outcome do they want, in plain terms?\n3. **Classify it** using the Skill Map below, translating casual phrasing to a goal.\n4. **Confirm intent** if ambiguous (\"Sounds like you want to ship to the stores — that's\n   `eas-app-stores`. Right?\"), then load that skill's `SKILL.md` and follow it.\n5. **Trust the leaf skill** — it has its own detection logic and steps. Don't improvise.\n\n## Skill Map (by goal)\n\nMatch the goal to a category, then the skill, then load that leaf's `SKILL.md`.\n\n**Build the app**\n- `expo-project-structure` — folder layout for a **new** Expo Router project: where screens, components, and config live (never restructure an existing app to match)\n- `expo-native-ui` — screens, styling, semantic colors, native controls, SF Symbols, media, layout\n- `expo-router` — navigation: file-based routes, tabs / stacks / modals / sheets, links, headers\n- `expo-animation` — motion and gestures: Reanimated worklets, Gesture Handler, screen transitions, sheet and press feedback, haptics, and fixing animation that stutters on device\n- `expo-ui` — native UI components via `@expo/ui`: BottomSheet, Picker, Slider, Switch, Menu, Button, FieldGroup (grouped form sections), List / ListItem, and more — real SwiftUI on iOS, Jetpack Compose on Android. The universal layer needs SDK 56+ and runs in Expo Go; the drop-in replacements (`@gorhom/bottom-sheet`, `datetimepicker`, …) and platform-specific layers also exist on SDK 55.\n- `expo-design-system` — one visual source of truth: design tokens (color, spacing, typography, radius, shadow, motion), reusable component conventions, and audits for drift (hardcoded colors, spacing, fonts)\n- `expo-tailwind-setup` — Tailwind / NativeWind styling\n- `expo-data-fetching` — network requests, React Query / SWR, caching, offline, route loaders\n- `expo-dom` — run web code or reuse a web library inside native\n- `expo-web-to-native` — migrate an existing web / React app to a native iOS / Android app\n\n> **Component selection rule:** whenever you need a UI component (list rows, bottom sheets, pickers, sliders, menus, buttons, segmented controls, toggles), **consult `expo-ui` first** to check whether `@expo/ui` has a native equivalent before reaching for a React Native built-in or a community library. Native `@expo/ui` components give the best platform fit, and on SDK 56+ the universal ones run in Expo Go with no custom build. Load `expo-ui` alongside `expo-native-ui` for any app that renders lists, detail sheets, or form controls. One exception: `@expo/ui` `List` renders native grouped rows (an iOS Settings screen), **not** a virtualized list — use `FlatList` / `FlashList` for large datasets.\n\n**Ship & operate**\n- `eas-app-stores` — build and submit iOS/Android apps (Expo and other React Native projects, plus existing native apps), TestFlight, versions, and store metadata\n- `eas-hosting` — deploy the web bundle to EAS Hosting; also author Expo Router API routes (`+api.ts` handlers) and their environments / domains\n- `eas-workflows` — EAS Workflow YAML and CI/CD pipelines\n- `eas-simulator` — run and drive the app on a remote iOS / Android simulator on EAS cloud\n- `expo-dev-client` — custom development builds\n- `eas-update` — configure, publish, test, and debug compatible over-the-air updates\n- `eas-update-insights` — OTA update health: crash rate, adoption, payload size\n- `eas-observe` — startup / launch / TTI performance with EAS Observe\n\n**Extend natively**\n- `expo-module` — native modules and views (Swift / Kotlin) with the Expo Modules API\n- `expo-brownfield` — embed Expo / React Native screens in native SwiftUI/UIKit or Android apps; isolated artifacts and integrated builds\n- `expo-app-clip` — iOS App Clip target (AASA, smart app banner)\n\n**Maintain & learn**\n- `expo-upgrade` — upgrade the Expo SDK and fix dependency conflicts\n- `expo-examples` — canonical, version-matched integration examples (Stripe, Clerk, Supabase, …)\n\n### Translating vague asks\n\nSome everyday phrasings don't obviously map to a skill name — translate before routing:\n\n- \"Make it look native\" → grouped controls / settings forms = `expo-ui`; screens, styling = `expo-native-ui`; motion = `expo-animation`; navigation = `expo-router`.\n- \"Make the screens consistent\" / \"clean up the styling\" / \"set up a theme or design tokens\" → `expo-design-system`.\n- \"It looks AI-generated\" / \"too generic, not native\" → `expo-design-system` (named native-slop tells + audit), with `expo-native-ui` for the platform idioms.\n- \"Ship it\" / \"get an .ipa or .apk\" / \"release to the stores\" / \"put my Swift app on TestFlight\" → `eas-app-stores` (build + submit, TestFlight, versions, store metadata).\n- \"I'm new / where do I start\" → scaffold first (see Shared setup rules), then route by goal.\n\n## Shared setup rules\n\nApply the rules that match the project and the requested task.\n\n- **Native app using EAS for delivery?** Route to `eas-app-stores`; its\n  `references/native-ios.md` covers SwiftUI/UIKit on iOS. Keep the existing native\n  project. Apply EAS auth/linking below; Expo scaffolding, SDK, and package-install\n  rules do not apply to this path.\n- **Starting a new Expo app?** Start one the standard way before routing to a feature skill:\n  `npx create-expo-app`, laying out folders per `expo-project-structure`. Then\n  classify the user's goal and route.\n- **Detect the SDK version** before giving version-specific advice: read the `expo`\n  version in `package.json` (and `app.json` / `app.config.{js,ts}`). Many APIs and\n  defaults differ by SDK.\n- **Read the docs for that SDK, not `latest`.** Use the version-pinned URL, e.g.\n  `https://docs.expo.dev/versions/v56.0.0/sdk/ui/` on SDK 56 instead of\n  `https://docs.expo.dev/versions/latest/sdk/ui/` — the `latest` pages track the newest\n  SDK and can document APIs the project does not have yet.\n- **Moving to a newer SDK is its own task** — load `expo-upgrade` instead of bumping\n  versions by hand.\n- **Managed vs. bare/prebuild**: the presence of committed `ios/` and `android/`\n  directories means native projects exist (prebuild or bare). Config-plugin and\n  native-setup steps differ — note which one the project is in.\n- **Install packages with `npx expo install <pkg>`**, not raw `npm`/`yarn`/`pnpm add`,\n  so versions stay compatible with the project's SDK.\n- **Launching the app yourself?** When you open Expo Go or a development build to look\n  at, screenshot, or drive it, skip the first-launch onboarding, the dev menu that opens\n  at launch, and the floating Tools button. On SDK 58+, Expo CLI does this for launches\n  it starts from a non-interactive shell. On SDK 57 and earlier, and for any URL you open\n  yourself (`simctl openurl`, `adb`, a controller), follow\n  `./references/launch-without-dev-menu.md`.\n- **EAS auth & linking** (only needed for build/submit/update/observe/workflows): check\n  login with `npx --yes eas-cli@27.4.1 whoami`, log in with `npx --yes eas-cli@27.4.1 login`. A project is linked when\n  `extra.eas.projectId` exists in the app config; create it with `npx --yes eas-cli@27.4.1 init` if missing.\n\n## When to skip the router hop\n\n- Only when the user explicitly named a specific `expo-*` / `eas-*` skill → load that\n  skill directly.\n- A fully-specified task (SDK version pinned, file layout given, libraries named) is\n  **not** a reason to skip: the shared rules above still apply — check them, then route\n  to the matching leaf skill.\n\n## Submitting Feedback\nWhen the user requests feedback submission, use:\n```bash\nnpx --yes @expo/agent-cli@1.0.23 feedback --category skills --subject \"expo-overview\" \"<actionable feedback>\"\n```\nInclude only relevant technical details; keep credentials, private data, and conversation contents out of feedback.\n"
}