novahiz 0.2.2 → 0.2.5

package/bundled-skills/expo-upgrade/references/expo-av-to-video.md

@@ -1,160 +0,0 @@
-# Migrating from expo-av to expo-video
-
-## Imports
-
-```tsx
-// Before
-import { Video, ResizeMode } from 'expo-av';
-
-// After
-import { useVideoPlayer, VideoView, VideoSource } from 'expo-video';
-import { useEvent, useEventListener } from 'expo';
-```
-
-## Video Playback
-
-### Before (expo-av)
-
-```tsx
-const videoRef = useRef<Video>(null);
-const [status, setStatus] = useState({});
-
-<Video
-  ref={videoRef}
-  source={{ uri: 'https://example.com/video.mp4' }}
-  style={{ width: 350, height: 200 }}
-  resizeMode={ResizeMode.CONTAIN}
-  isLooping
-  onPlaybackStatusUpdate={setStatus}
-/>
-
-// Control
-videoRef.current?.playAsync();
-videoRef.current?.pauseAsync();
-```
-
-### After (expo-video)
-
-```tsx
-const player = useVideoPlayer('https://example.com/video.mp4', player => {
-  player.loop = true;
-});
-
-const { isPlaying } = useEvent(player, 'playingChange', { isPlaying: player.playing });
-
-<VideoView
-  player={player}
-  style={{ width: 350, height: 200 }}
-  contentFit="contain"
-/>
-
-// Control
-player.play();
-player.pause();
-```
-
-## Status Updates
-
-### Before (expo-av)
-
-```tsx
-<Video
-  onPlaybackStatusUpdate={status => {
-    if (status.isLoaded) {
-      console.log(status.positionMillis, status.durationMillis, status.isPlaying);
-      if (status.didJustFinish) console.log('finished');
-    }
-  }}
-/>
-```
-
-### After (expo-video)
-
-```tsx
-// Reactive state
-const { isPlaying } = useEvent(player, 'playingChange', { isPlaying: player.playing });
-
-// Side effects
-useEventListener(player, 'playToEnd', () => console.log('finished'));
-
-// Direct access
-console.log(player.currentTime, player.duration, player.playing);
-```
-
-## Local Files
-
-### Before (expo-av)
-
-```tsx
-<Video source={require('./video.mp4')} />
-```
-
-### After (expo-video)
-
-```tsx
-const player = useVideoPlayer({ assetId: require('./video.mp4') });
-```
-
-## Fullscreen and PiP
-
-```tsx
-<VideoView
-  player={player}
-  allowsFullscreen
-  allowsPictureInPicture
-  onFullscreenEnter={() => {}}
-  onFullscreenExit={() => {}}
-/>
-```
-
-For PiP and background playback, add to app.json:
-
-```json
-{
-  "expo": {
-    "plugins": [
-      ["expo-video", { "supportsBackgroundPlayback": true, "supportsPictureInPicture": true }]
-    ]
-  }
-}
-```
-
-## API Mapping
-
-| expo-av | expo-video |
-|---------|------------|
-| `<Video>` | `<VideoView>` |
-| `ref={videoRef}` | `player={useVideoPlayer()}` |
-| `source={{ uri }}` | Pass to `useVideoPlayer(uri)` |
-| `resizeMode={ResizeMode.CONTAIN}` | `contentFit="contain"` |
-| `isLooping` | `player.loop = true` |
-| `shouldPlay` | `player.play()` in setup |
-| `isMuted` | `player.muted = true` |
-| `useNativeControls` | `nativeControls={true}` |
-| `onPlaybackStatusUpdate` | `useEvent` / `useEventListener` |
-| `videoRef.current.playAsync()` | `player.play()` |
-| `videoRef.current.pauseAsync()` | `player.pause()` |
-| `videoRef.current.replayAsync()` | `player.replay()` |
-| `videoRef.current.setPositionAsync(ms)` | `player.currentTime = seconds` |
-| `status.positionMillis` | `player.currentTime` (seconds) |
-| `status.durationMillis` | `player.duration` (seconds) |
-| `status.didJustFinish` | `useEventListener(player, 'playToEnd')` |
-
-## Key Differences
-
-- **Separate player and view**: Player logic decoupled from the view—one player can be used across multiple views
-- **Time in seconds**: Uses seconds, not milliseconds
-- **Event system**: Uses `useEvent`/`useEventListener` from `expo` instead of callback props
-- **Video preloading**: Create a player without mounting a VideoView to preload for faster transitions
-- **Built-in caching**: Set `useCaching: true` in VideoSource for persistent offline caching
-
-## Known Issues
-
-- **Uninstall expo-av first**: On Android, having both expo-av and expo-video installed can cause VideoView to show a black screen. Uninstall expo-av before installing expo-video
-- **Android: Reusing players**: Mounting the same player in multiple VideoViews simultaneously can cause black screens on Android (works on iOS)
-- **Android: currentTime in setup**: Setting `player.currentTime` in the `useVideoPlayer` setup callback may not work on Android—set it after mount instead
-- **Changing source**: Use `player.replace(newSource)` to change videos without recreating the player
-
-## API Reference
-
-https://docs.expo.dev/versions/latest/sdk/video/

package/bundled-skills/expo-upgrade/references/native-tabs.md

@@ -1,124 +0,0 @@
-# Native Tabs Migration (SDK 55)
-
-In SDK 55, `Label`, `Icon`, `Badge`, and `VectorIcon` are now accessed as static properties on `NativeTabs.Trigger` rather than separate imports.
-
-## Import Changes
-
-```tsx
-// SDK 53/54
-import {
-  NativeTabs,
-  Icon,
-  Label,
-  Badge,
-  VectorIcon,
-} from "expo-router/unstable-native-tabs";
-
-// SDK 55+
-import { NativeTabs } from "expo-router/unstable-native-tabs";
-```
-
-## Component Changes
-
-| SDK 53/54        | SDK 55+                             |
-| ---------------- | ----------------------------------- |
-| `<Icon />`       | `<NativeTabs.Trigger.Icon />`       |
-| `<Label />`      | `<NativeTabs.Trigger.Label />`      |
-| `<Badge />`      | `<NativeTabs.Trigger.Badge />`      |
-| `<VectorIcon />` | `<NativeTabs.Trigger.VectorIcon />` |
-| (n/a)            | `<NativeTabs.BottomAccessory />`    |
-
-## New in SDK 55
-
-### BottomAccessory
-
-New component for Apple Music-style mini players on iOS +26 that float above the tab bar:
-
-```tsx
-<NativeTabs>
-  <NativeTabs.BottomAccessory>
-    {/* Content above tabs */}
-  </NativeTabs.BottomAccessory>
-  <NativeTabs.Trigger name="(index)">
-    <NativeTabs.Trigger.Label>Home</NativeTabs.Trigger.Label>
-  </NativeTabs.Trigger>
-</NativeTabs>
-```
-
-On Android and web, this component will render as a no-op. Position a view absolutely above the tab bar instead.
-
-### Icon `md` Prop
-
-New `md` prop for Material icon glyphs on Android (alongside existing `drawable`):
-
-```tsx
-<NativeTabs.Trigger.Icon sf="house" md="home" />
-```
-
-## Full Migration Example
-
-### Before (SDK 53/54)
-
-```tsx
-import {
-  NativeTabs,
-  Icon,
-  Label,
-  Badge,
-} from "expo-router/unstable-native-tabs";
-
-export default function TabLayout() {
-  return (
-    <NativeTabs minimizeBehavior="onScrollDown">
-      <NativeTabs.Trigger name="(index)">
-        <Label>Home</Label>
-        <Icon sf="house.fill" />
-        <Badge>3</Badge>
-      </NativeTabs.Trigger>
-      <NativeTabs.Trigger name="(settings)">
-        <Label>Settings</Label>
-        <Icon sf="gear" />
-      </NativeTabs.Trigger>
-      <NativeTabs.Trigger name="(search)" role="search">
-        <Label>Search</Label>
-      </NativeTabs.Trigger>
-    </NativeTabs>
-  );
-}
-```
-
-### After (SDK 55+)
-
-```tsx
-import { NativeTabs } from "expo-router/unstable-native-tabs";
-
-export default function TabLayout() {
-  return (
-    <NativeTabs minimizeBehavior="onScrollDown">
-      <NativeTabs.Trigger name="(index)">
-        <NativeTabs.Trigger.Label>Home</NativeTabs.Trigger.Label>
-        <NativeTabs.Trigger.Icon sf="house.fill" md="home" />
-        <NativeTabs.Trigger.Badge>3</NativeTabs.Trigger.Badge>
-      </NativeTabs.Trigger>
-      <NativeTabs.Trigger name="(settings)">
-        <NativeTabs.Trigger.Label>Settings</NativeTabs.Trigger.Label>
-        <NativeTabs.Trigger.Icon sf="gear" md="settings" />
-      </NativeTabs.Trigger>
-      <NativeTabs.Trigger name="(search)" role="search">
-        <NativeTabs.Trigger.Label>Search</NativeTabs.Trigger.Label>
-      </NativeTabs.Trigger>
-    </NativeTabs>
-  );
-}
-```
-
-## Migration Checklist
-
-1. Remove `Icon`, `Label`, `Badge`, `VectorIcon` from imports
-2. Keep only `NativeTabs` import from `expo-router/unstable-native-tabs`
-3. Replace `<Icon />` with `<NativeTabs.Trigger.Icon />`
-4. Replace `<Label />` with `<NativeTabs.Trigger.Label />`
-5. Replace `<Badge />` with `<NativeTabs.Trigger.Badge />`
-6. Replace `<VectorIcon />` with `<NativeTabs.Trigger.VectorIcon />`
-
-- Read docs for more info https://docs.expo.dev/versions/v55.0.0/sdk/router-native-tabs/

package/bundled-skills/expo-upgrade/references/new-architecture.md

@@ -1,79 +0,0 @@
-# New Architecture
-
-The New Architecture is enabled by default in Expo SDK 53+. It replaces the legacy bridge with a faster, synchronous communication layer between JavaScript and native code.
-
-## Documentation
-
-Full guide: https://docs.expo.dev/guides/new-architecture/
-
-## What Changed
-
-- **JSI (JavaScript Interface)** — Direct synchronous calls between JS and native
-- **Fabric** — New rendering system with concurrent features
-- **TurboModules** — Lazy-loaded native modules with type safety
-
-## SDK Compatibility
-
-| SDK Version | New Architecture Status |
-| ----------- | ----------------------- |
-| SDK 53+     | Enabled by default      |
-| SDK 52      | Opt-in via app.json     |
-| SDK 51-     | Experimental            |
-
-## Configuration
-
-New Architecture is enabled by default. To explicitly disable (not recommended):
-
-```json
-{
-  "expo": {
-    "newArchEnabled": false
-  }
-}
-```
-
-## Expo Go
-
-Expo Go only supports the New Architecture as of SDK 53. Apps using the old architecture must use development builds.
-
-## Common Migration Issues
-
-### Native Module Compatibility
-
-Some older native modules may not support the New Architecture. Check:
-
-1. Module documentation for New Architecture support
-2. GitHub issues for compatibility discussions
-3. Consider alternatives if module is unmaintained
-
-### Reanimated
-
-React Native Reanimated requires `react-native-worklets` in SDK 54+:
-
-```bash
-npx expo install react-native-worklets
-```
-
-### Layout Animations
-
-Some layout animations behave differently. Test thoroughly after upgrading.
-
-## Verifying New Architecture
-
-Check if New Architecture is active:
-
-```tsx
-import { Platform } from "react-native";
-
-// Returns true if Fabric is enabled
-const isNewArch = global._IS_FABRIC !== undefined;
-```
-
-Verify from the command line if the currently running app uses the New Architecture: `bunx xcobra expo eval "_IS_FABRIC"` -> `true`
-
-## Troubleshooting
-
-1. **Clear caches** — `npx expo start --clear`
-2. **Clean prebuild** — `npx expo prebuild --clean`
-3. **Check native modules** — Ensure all dependencies support New Architecture
-4. **Review console warnings** — Legacy modules log compatibility warnings

package/bundled-skills/expo-upgrade/references/react-19.md

@@ -1,79 +0,0 @@
-# React 19
-
-React 19 is included in Expo SDK 54. This release simplifies several common patterns.
-
-## Context Changes
-
-### useContext → use
-
-The `use` hook replaces `useContext`:
-
-```tsx
-// Before (React 18)
-import { useContext } from "react";
-const value = useContext(MyContext);
-
-// After (React 19)
-import { use } from "react";
-const value = use(MyContext);
-```
-
-- The `use` hook can also read promises, enabling Suspense-based data fetching.
-- `use` can be called conditionally, this simplifies components that consume multiple contexts.
-
-### Context.Provider → Context
-
-Context providers no longer need the `.Provider` suffix:
-
-```tsx
-// Before (React 18)
-<ThemeContext.Provider value={theme}>
-  {children}
-</ThemeContext.Provider>
-
-// After (React 19)
-<ThemeContext value={theme}>
-  {children}
-</ThemeContext>
-```
-
-## ref as a Prop
-
-### Removing forwardRef
-
-Components can now receive `ref` as a regular prop. `forwardRef` is no longer needed:
-
-```tsx
-// Before (React 18)
-import { forwardRef } from "react";
-
-const Input = forwardRef<TextInput, Props>((props, ref) => {
-  return <TextInput ref={ref} {...props} />;
-});
-
-// After (React 19)
-function Input({ ref, ...props }: Props & { ref?: React.Ref<TextInput> }) {
-  return <TextInput ref={ref} {...props} />;
-}
-```
-
-### Migration Steps
-
-1. Remove `forwardRef` wrapper
-2. Add `ref` to the props destructuring
-3. Update the type to include `ref?: React.Ref<T>`
-
-## Other React 19 Features
-
-- **Actions** — Functions that handle async transitions
-- **useOptimistic** — Optimistic UI updates
-- **useFormStatus** — Form submission state (web)
-- **Document Metadata** — Native `<title>` and `<meta>` support (web)
-
-## Cleanup Checklist
-
-When upgrading to SDK 54:
-
-- [ ] Replace `useContext` with `use`
-- [ ] Remove `.Provider` from Context components
-- [ ] Remove `forwardRef` wrappers, use `ref` prop instead

package/bundled-skills/expo-upgrade/references/react-compiler.md

@@ -1,59 +0,0 @@
-# React Compiler
-
-React Compiler is stable in Expo SDK 54 and later. It automatically memoizes components and hooks, eliminating the need for manual `useMemo`, `useCallback`, and `React.memo`.
-
-## Enabling React Compiler
-
-Add to `app.json`:
-
-```json
-{
-  "expo": {
-    "experiments": {
-      "reactCompiler": true
-    }
-  }
-}
-```
-
-## What React Compiler Does
-
-- Automatically memoizes components and values
-- Eliminates unnecessary re-renders
-- Removes the need for manual `useMemo` and `useCallback`
-- Works with existing code without modifications
-
-## Cleanup After Enabling
-
-Once React Compiler is enabled, you can remove manual memoization:
-
-```tsx
-// Before (manual memoization)
-const memoizedValue = useMemo(() => computeExpensive(a, b), [a, b]);
-const memoizedCallback = useCallback(() => doSomething(a), [a]);
-const MemoizedComponent = React.memo(MyComponent);
-
-// After (React Compiler handles it)
-const value = computeExpensive(a, b);
-const callback = () => doSomething(a);
-// Just use MyComponent directly
-```
-
-## Requirements
-
-- Expo SDK 54 or later
-- New Architecture enabled (default in SDK 54+)
-
-## Verifying It's Working
-
-React Compiler runs at build time. Check the Metro bundler output for compilation messages. You can also use React DevTools to verify components are being optimized.
-
-## Troubleshooting
-
-If you encounter issues:
-
-1. Ensure New Architecture is enabled
-2. Clear Metro cache: `npx expo start --clear`
-3. Check for incompatible patterns in your code (rare)
-
-React Compiler is designed to work with idiomatic React code. If it can't safely optimize a component, it skips that component without breaking your app.

package/bundled-skills/expo-upgrade/references/react-navigation-to-expo-router.md

@@ -1,61 +0,0 @@
-# Migrating from react-navigation to expo-router
-
-In SDK 56+, application code must not import from `@react-navigation/*` directly. Repoint those imports to the matching `expo-router` entry points. Runtime API is unchanged — only the module specifiers move.
-
-## Steps
-
-1. Prefer the automated codemod (see below). If it is not viable, fall back to the manual mapping.
-2. Replace imports using the table. Use the entry point that matches the `@react-navigation/*` source.
-3. After rewriting, check whether any of the rewritten imports are deprecated in `expo-router` (see [Check for deprecated imports](#check-for-deprecated-imports)). If so, surface the deprecation reason and the suggested replacement to the user before continuing.
-4. Validate: search for remaining `@react-navigation/` references in source files, then run typecheck/build/start.
-5. Remove `@react-navigation/*` packages that are no longer imported from `package.json` and reinstall (delete `node_modules` if needed).
-
-## Automated migration (preferred)
-
-Run from the project root over your application code (replace `src` with the actual directory or glob):
-
-```sh
-npx expo-codemod sdk-56-expo-router-react-navigation-replace src
-```
-
-```sh
-npx expo-codemod sdk-56-expo-router-react-navigation-replace '**/*.{ts,tsx,js,jsx}'
-```
-
-## Manual API mapping
-
-| React Navigation source               | Expo Router target                                                       |
-| ------------------------------------- | ------------------------------------------------------------------------ |
-| `@react-navigation/native`            | `expo-router/react-navigation`                                           |
-| `@react-navigation/core`              | `expo-router/react-navigation`                                           |
-| `@react-navigation/elements`          | `expo-router/react-navigation`                                           |
-| `@react-navigation/routers`           | `expo-router/react-navigation`                                           |
-| `@react-navigation/stack`             | `expo-router/js-stack`                                                   |
-| `@react-navigation/bottom-tabs`       | `expo-router/js-tabs`                                                    |
-| `@react-navigation/material-top-tabs` | `expo-router/js-top-tabs`                                                |
-| `@react-navigation/native-stack`      | No direct equivalent. Use the `Stack` layout from `expo-router` instead. |
-
-**Stack caveat:** Do NOT rewrite `import { Stack } from "expo-router"` to `expo-router/js-stack`. The root `Stack` is the Expo Router layout component used in route files; only use `expo-router/js-stack` when replacing a `@react-navigation/stack` JS stack navigator.
-
-If you encounter a symbol that has no replacement, ask the user to file an issue in the `expo/expo` repository describing what is needed and why.
-
-## Check for deprecated imports
-
-A successful rewrite to `expo-router/*` does not guarantee the new import is the recommended one. Some symbols are re-exported as deprecated shims and the project may need to migrate further (for example, to a different `expo-router` API or to a first-party Expo package).
-
-For each symbol rewritten in step 2:
-
-1. Resolve the rewritten module to its source in `node_modules` (e.g., `node_modules/expo-router/build/react-navigation.d.ts`, `js-stack`, `js-tabs`, `js-top-tabs`).
-2. Look for a `@deprecated` JSDoc tag on the named export, or a runtime deprecation warning in the implementation file.
-3. If deprecated, capture both the reason and the recommended replacement from the JSDoc/comment.
-4. Report each deprecated symbol to the user with: the import path, the symbol, the deprecation reason, and the suggested replacement. Wait for the user to confirm before mass-applying further changes.
-
-## Done when
-
-1. No `@react-navigation/*` imports remain in source files.
-2. No unused `@react-navigation/*` entries remain in `package.json`.
-3. Typecheck and bundler start without `@react-navigation/*` errors.
-
-## Reference
-
-- Official Expo Router SDK 55 → 56 migration guide: https://docs.expo.dev/router/migrate/sdk-55-to-56

package/bundled-skills/expo-web-to-native/SKILL.md

@@ -1,91 +0,0 @@
----
-name: expo-web-to-native
-description: Framework (OSS). Migrate an existing web React app to a native iOS/Android app with Expo. Use when the user wants to turn a website into a mobile app, port a Next.js/Vite/CRA React codebase to React Native, reuse web code on native incrementally, or asks how web idioms (the DOM, CSS, React Router, localStorage, window) map to native. This is the end-to-end migration guide; use the `expo-dom` skill for the DOM-component mechanism itself.
-version: 1.0.0
-license: MIT
----
-
-# Web to Native
-
-A web React app does not *convert* to native — there is no transpiler. It **migrates**, screen by screen, the way a strangler fig grows around a tree and slowly replaces it: stand up a native shell, run the whole web UI inside it on day one, then strangle each screen into native in priority order. This skill is the spine that orders the work; each step hands off to an existing Expo skill rather than re-explaining it. It operationalizes Expo's [From Web to Native with React](https://expo.dev/blog/from-web-to-native-with-react) — read that for the why.
-
-```mermaid
-flowchart TD
-    A1[1 · Assess: write the worklist] --> A2[2 · Scaffold Expo shell]
-    A2 --> A3[3 · DOM-component shell<br/>· expo-dom · SHIP DAY ONE]
-    A3 --> A4[4 · Strangle screens to native<br/>highest-value first · expo-router]
-    A4 -->|more screens| A4
-    A4 --> A5[5 · Wire data / auth / storage<br/>· expo-data-fetching]
-    A5 --> A6[6 · Ship · eas-app-stores]
-```
-
-## Principles
-
-- **Migrate, don't rewrite.** Never big-bang it; every step keeps the app shippable.
-- **Ship on day one.** The web UI runs in a DOM-component shell (step 3) before anything is nativized — that's the milestone; everything after is polish.
-- **Strangle by value.** Nativize the hot screens; leave the rest in the webview. Each DOM screen carries a ~2 MB web runtime — reason enough not to ship everything as DOM.
-- **Nativize means redesign, not reskin.** A strangled screen should look like Apple/Google shipped it, not the web page reskinned. **Reach for `@expo/ui` first** - it renders real SwiftUI/Compose, so it feels *exactly* like the OS; styled RN primitives are the fallback for custom layouts only. Plus platform navigation (`expo-router`: NativeTabs, large titles), liquid glass and native components via `@expo/ui`, and mobile UX (sheets, swipe, haptics). The web→native pattern map is [`./references/native-patterns.md`](./references/native-patterns.md). If it still feels like a website, you ported instead of redesigned.
-- **Verify by running, not compiling.** A clean build proves nothing (a blank webview compiles fine). Run each screen — but judge *content and behavior* against the web original, not pixels (a nativized screen should look more native, not identical).
-- **Orchestrate, don't reinvent.** Each step routes into an existing skill. The value here is the *order* and the *gotchas* — the idiom-by-idiom mappings live in [`./references/false-friends.md`](./references/false-friends.md).
-
-## Run it as a loop (recommended)
-
-The migration is a long repeat-until-done loop, so the first move is to **write the goal objective and launch it** — not to grind screens by hand. Fill the objective in [`./references/run-as-goal.md`](./references/run-as-goal.md) for this app and present it; it **re-reads this skill every iteration**, so each `/goal` turn reloads the playbook + worklist and drives the next screen (it even self-bootstraps the assess step). Then run `/goal` with it — or, if the harness can't loop, write it to `migration-goal.md` and have the user launch it. The steps below are what each iteration does; run them by hand only if you're not looping.
-
-## The migration
-
-> **No repo to migrate** - just building native fresh as a web dev? You don't need these steps: use `expo-router`, and keep [`./references/false-friends.md`](./references/false-friends.md) open for the web→native idiom map. Everything below assumes an existing web app.
-
-### 1. Assess → write the worklist
-
-Read the repo and produce `migration-progress.md`, the durable worklist the rest of the migration checks off. Make two cuts:
-
-- **Screens vs backend.** Page routes (`page.tsx`) are screens you migrate; server routes (`route.ts`), the ORM, and auth handlers stay server-side. Decide the backend once: keep it deployed (the native app becomes an HTTP client) or move it to EAS Hosting (`eas-hosting`).
-- **Bucket each screen** by how it should land: **port-as-is** (presentational → ships in a DOM webview), **nativize-now** (hot, or needs native feel — gestures, lists, keyboard), **nativize-later**, or **hybrid** (a native shell around a web sub-tree, e.g. a chat list wrapping a markdown renderer).
-
-Note the framework signals as you read — RSC vs client, Tailwind/shadcn, where data is fetched — since they decide how each screen ports (false-friends has the mappings; async Server Components in particular must be split into a client fetch + a presentational component before they can move). **Flag third-party services/SDKs too** — browser SDKs don't carry over (`false-friends` → *Services & SDKs*); payments especially is a *fork, not a swap* (in-app digital goods must use store IAP via RevenueCat, ~30% — not Stripe), a business-model call to make now, not at App Store review. The worklist is only trustworthy once every route is sorted and every screen bucketed.
-
-### 2. Scaffold the shell
-
-`create-expo-app`, then mirror the web routes in Expo Router — Next's tree maps almost 1:1 (note `[id]/page.tsx` → `[id].tsx`, and routes may live in `src/app/`). Empty screens, one per route.
-
-### 3. Shell it in DOM components — the day-one milestone
-
-Bring every screen over as a DOM component (`'use dom'`, per the `expo-dom` skill) rendered by its native route, so the whole app runs on a phone before anything is nativized. Expect per-screen edits - unwrapping Server Components, swapping framework imports (`next/link`), carrying the styling over - all covered in false-friends. Then verify by running (below); this is shippable to TestFlight as-is.
-
-### 4. Strangle screens to native — by value
-
-Walk `migration-progress.md` top-down. For each screen, *redesign* it native - don't port the web layout. Reach for **`@expo/ui` first** (real SwiftUI/Compose - buttons, lists, sheets, pickers, sliders; [`./references/native-patterns.md`](./references/native-patterns.md) maps which web pattern becomes which native component), then platform navigation (`expo-router` - NativeTabs, large titles) and mobile UX (swipe, haptics, momentum/inverted scroll); RN primitives only for custom layouts. Consult [`./references/false-friends.md`](./references/false-friends.md) for each idiom. `@expo/ui` and DOM components both run in **Expo Go** (SDK 56+) - a dev build (the `expo-dev-client` skill) is only needed for *custom* native modules. Verify *content and behavior* against the running web original (the look should become more native), then check it off. One screen per pass, app shippable throughout. It's a loop over a durable worklist, so it can run unattended - hand it to a goal loop ([`./references/run-as-goal.md`](./references/run-as-goal.md)).
-
-### 5. Wire data, auth, and storage
-
-The web data layer doesn't survive the move - relative fetches, cookie sessions, `localStorage`, and env vars all change (swaps in false-friends). Use `expo-data-fetching` for requests and caching; add `eas-hosting` if the backend moved to EAS Hosting.
-
-### 6. Ship
-
-`eas-app-stores` for the store builds (App Store / Play / TestFlight), EAS Update for OTA pushes after.
-
-## Verify by running, not compiling
-
-A green `expo export` proves a screen *bundles*, not that it *renders* — a screen can build and still render blank or mis-render. So after the shell and after every nativized screen, compare the two **running** apps for the same route:
-
-- **Web original** — capture it with **`agent-browser`** (vercel-labs CLI): `open` the route, `snapshot --json` the accessibility tree, `screenshot`.
-- **Native** — drive the simulator with **`argent`**: `describe` / `debugger-component-tree` for structure, `flow` to replay the check each pass.
-
-Pass on parity of **content and behavior** — not pixels: a nativized screen should look *more* native than the web, never identical (the DOM-shell stage is the exception — there it *is* the web UI, so it should match). Feel is part of native and can't be screenshotted — for screens with transitions or gestures, capture a short recording, not just a still (see `native-patterns.md` → Feel). This loop is **opinionated about its tooling**: if `agent-browser` or `argent` isn't installed, ask the user and install it before proceeding — don't fall back to manual screenshots. Full recipe and setup in [`./references/verify-on-device.md`](./references/verify-on-device.md).
-
-## References
-
-- [`./references/false-friends.md`](./references/false-friends.md) — web idiom → native equivalent + the gotcha for each. The lookup for steps 3–5, and for any web dev unlearning idioms.
-- [`./references/native-patterns.md`](./references/native-patterns.md) — web UX *pattern* → native redesign (`@expo/ui`-first). The step-4 redesign playbook so screens feel OS-native, not reskinned.
-- [`./references/verify-on-device.md`](./references/verify-on-device.md) — the two-agent parity recipe: drive the web app (browser agent) and the native app (argent), open the same route, compare.
-- [`./references/run-as-goal.md`](./references/run-as-goal.md) — a ready-shaped, migration-specific goal objective for driving step 4 unattended (re-reads this skill each iteration).
-- [Expo — From Web to Native with React](https://expo.dev/blog/from-web-to-native-with-react) — the canonical guide this skill operationalizes.
-
-## Submitting Feedback
-If you encounter errors, misleading or outdated information in this skill, report it so Expo can improve:
-```bash
-npx --yes submit-expo-feedback@latest --category skills --subject "expo-web-to-native" "<actionable feedback>"
-```
-Only submit when you have something specific and actionable to report. Include as much relevant context as possible.
-If 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.

package/bundled-skills/expo-web-to-native/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Expo Web to Native"
-  short_description: "Migrate an existing web React app (Next.js, Vite, CRA) to a native iOS/Android app with Expo, screen by screen"
-  default_prompt: "Use $expo-web-to-native to migrate a web React codebase to native: assess and bucket screens, ship a DOM-component shell on day one, then nativize screens in priority order with @expo/ui and Expo Router."