diff --git a/.agents/skills/eas-app-stores/SKILL.md b/.agents/skills/eas-app-stores/SKILL.md
new file mode 100644
index 0000000..7916b4f
--- /dev/null
+++ b/.agents/skills/eas-app-stores/SKILL.md
@@ -0,0 +1,160 @@
+---
+name: eas-app-stores
+description: EAS service (paid). Deploy Expo apps to the app stores with EAS - build and submit to the iOS App Store, Google Play Store, and TestFlight, configure eas.json build and submit profiles, manage app versions and build numbers, and publish App Store metadata and ASO. Use whenever the user wants to deploy, release, or ship an app to production or the app stores, is preparing a production build, running eas build or eas submit, shipping to TestFlight, bumping version or build numbers, or setting up store listing metadata. For deploying an Expo website or API routes, use the eas-hosting skill.
+version: 1.0.0
+license: MIT
+---
+
+# App Store Deployment
+
+> **EAS service - costs apply.** This skill uses Expo Application Services (EAS), a paid product with free-tier limits. `eas build` and `eas submit` consume your plan's build minutes, and store submission requires paid Apple Developer and Google Play accounts. Review https://expo.dev/pricing before running cloud commands.
+
+This skill covers building and releasing Expo apps to the iOS App Store, Google Play Store, and TestFlight using EAS (Expo Application Services). For deploying an Expo website or API routes to EAS Hosting, use the `eas-hosting` skill.
+
+## References
+
+Consult these resources as needed:
+
+- ./references/workflows.md -- CI/CD workflows for automated store releases and PR previews
+- ./references/testflight.md -- Submitting iOS builds to TestFlight for beta testing
+- ./references/app-store-metadata.md -- Managing App Store metadata and ASO optimization
+- ./references/play-store.md -- Submitting Android builds to Google Play Store
+- ./references/ios-app-store.md -- iOS App Store submission and review process
+
+## Quick Start
+
+### Install EAS CLI
+
+```bash
+npm install -g eas-cli
+eas login
+```
+
+### Initialize EAS
+
+```bash
+npx eas-cli@latest init
+```
+
+This creates `eas.json` with build profiles.
+
+## Build Commands
+
+### Production Builds
+
+```bash
+# iOS App Store build
+npx eas-cli@latest build -p ios --profile production
+
+# Android Play Store build
+npx eas-cli@latest build -p android --profile production
+
+# Both platforms
+npx eas-cli@latest build --profile production
+```
+
+### Submit to Stores
+
+```bash
+# iOS: Build and submit to App Store Connect
+npx eas-cli@latest build -p ios --profile production --submit
+
+# Android: Build and submit to Play Store
+npx eas-cli@latest build -p android --profile production --submit
+
+# Shortcut for iOS TestFlight
+npx testflight
+```
+
+## Web & API Route Hosting
+
+Deploying an Expo website or Expo Router API routes to EAS Hosting (`npx expo export -p web` then `eas deploy`) is covered by the `eas-hosting` skill. This skill focuses on native app store releases.
+
+## EAS Configuration
+
+Standard `eas.json` for production deployments:
+
+```json
+{
+  "cli": {
+    "version": ">= 16.0.1",
+    "appVersionSource": "remote"
+  },
+  "build": {
+    "production": {
+      "autoIncrement": true,
+      "ios": {
+        "resourceClass": "m-medium"
+      }
+    },
+    "development": {
+      "developmentClient": true,
+      "distribution": "internal"
+    }
+  },
+  "submit": {
+    "production": {
+      "ios": {
+        "appleId": "your@email.com",
+        "ascAppId": "1234567890"
+      },
+      "android": {
+        "serviceAccountKeyPath": "./google-service-account.json",
+        "track": "internal"
+      }
+    }
+  }
+}
+```
+
+## Platform-Specific Guides
+
+### iOS
+
+- Use `npx testflight` for quick TestFlight submissions
+- Configure Apple credentials via `eas credentials`
+- See ./references/testflight.md for credential setup
+- See ./references/ios-app-store.md for App Store submission
+
+### Android
+
+- Set up Google Play Console service account
+- Configure tracks: internal → closed → open → production
+- See ./references/play-store.md for detailed setup
+
+## Automated Releases
+
+EAS Workflows automate the build → submit → update pipeline for CI/CD. See ./references/workflows.md for store-release examples. To author or validate workflow YAML, use the `eas-workflows` skill - it works from the live workflow schema.
+
+## Version Management
+
+EAS manages version numbers automatically with `appVersionSource: "remote"`:
+
+```bash
+# Check current versions
+eas build:version:get
+
+# Manually set version
+eas build:version:set -p ios --build-number 42
+```
+
+## Monitoring
+
+```bash
+# List recent builds
+eas build:list
+
+# Check build status
+eas build:view
+
+# View submission status
+eas submit:list
+```
+
+## 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 "eas-app-stores" "<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.
diff --git a/.agents/skills/eas-app-stores/agents/openai.yaml b/.agents/skills/eas-app-stores/agents/openai.yaml
new file mode 100644
index 0000000..79ce425
--- /dev/null
+++ b/.agents/skills/eas-app-stores/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "EAS App Stores"
+  short_description: "Paid EAS service. Build and submit Expo apps to the iOS App Store, Google Play Store, and TestFlight, with eas.json profiles, versioning, and store metadata"
+  default_prompt: "Use $eas-app-stores when preparing production EAS builds, store submissions, TestFlight distribution, app-store metadata and ASO, or version and build-number management for an Expo app. For web or API route hosting, use eas-hosting instead."
diff --git a/.agents/skills/eas-app-stores/references/app-store-metadata.md b/.agents/skills/eas-app-stores/references/app-store-metadata.md
new file mode 100644
index 0000000..758a3bd
--- /dev/null
+++ b/.agents/skills/eas-app-stores/references/app-store-metadata.md
@@ -0,0 +1,497 @@
+# App Store Metadata
+
+Manage App Store metadata and optimize for ASO using EAS Metadata.
+
+## Contents
+
+- [What is EAS Metadata?](#what-is-eas-metadata)
+- [Getting Started](#getting-started)
+- [Configuration File](#configuration-file)
+- [App Store Optimization (ASO)](#app-store-optimization-aso)
+- [Categories](#categories)
+- [Localization](#localization)
+- [Dynamic Configuration](#dynamic-configuration)
+- [Age Rating (Advisory)](#age-rating-advisory)
+- [Release Strategy](#release-strategy)
+- [Review Information](#review-information)
+- [ASO Checklist](#aso-checklist)
+- [VS Code Integration](#vs-code-integration)
+- [Common Issues](#common-issues)
+- [CI/CD Integration](#cicd-integration)
+- [Tips](#tips)
+
+## What is EAS Metadata?
+
+EAS Metadata automates App Store presence management from the command line using a `store.config.json` file instead of manually filling forms in App Store Connect. It includes built-in validation to catch common rejection pitfalls.
+
+**Current Status:** Preview, Apple App Store only.
+
+## Getting Started
+
+### Pull Existing Metadata
+
+If your app is already published, pull current metadata:
+
+```bash
+eas metadata:pull
+```
+
+This creates `store.config.json` with your current App Store configuration.
+
+### Push Metadata Updates
+
+After editing your config, push changes:
+
+```bash
+eas metadata:push
+```
+
+**Important:** You must submit a binary via `eas submit` before pushing metadata for new apps.
+
+## Configuration File
+
+Create `store.config.json` at your project root:
+
+```json
+{
+  "configVersion": 0,
+  "apple": {
+    "copyright": "2025 Your Company",
+    "categories": ["UTILITIES", "PRODUCTIVITY"],
+    "info": {
+      "en-US": {
+        "title": "App Name",
+        "subtitle": "Your compelling tagline",
+        "description": "Full app description...",
+        "keywords": ["keyword1", "keyword2", "keyword3"],
+        "releaseNotes": "What's new in this version...",
+        "promoText": "Limited time offer!",
+        "privacyPolicyUrl": "https://example.com/privacy",
+        "supportUrl": "https://example.com/support",
+        "marketingUrl": "https://example.com"
+      }
+    },
+    "advisory": {
+      "alcoholTobaccoOrDrugUseOrReferences": "NONE",
+      "gamblingSimulated": "NONE",
+      "medicalOrTreatmentInformation": "NONE",
+      "profanityOrCrudeHumor": "NONE",
+      "sexualContentGraphicAndNudity": "NONE",
+      "sexualContentOrNudity": "NONE",
+      "horrorOrFearThemes": "NONE",
+      "matureOrSuggestiveThemes": "NONE",
+      "violenceCartoonOrFantasy": "NONE",
+      "violenceRealistic": "NONE",
+      "violenceRealisticProlongedGraphicOrSadistic": "NONE",
+      "contests": "NONE",
+      "gambling": false,
+      "unrestrictedWebAccess": false,
+      "seventeenPlus": false
+    },
+    "release": {
+      "automaticRelease": true,
+      "phasedRelease": true
+    },
+    "review": {
+      "firstName": "John",
+      "lastName": "Doe",
+      "email": "review@example.com",
+      "phone": "+1 555-123-4567",
+      "notes": "Demo account: test@example.com / password123"
+    }
+  }
+}
+```
+
+## App Store Optimization (ASO)
+
+### Title Optimization (30 characters max)
+
+The title is the most important ranking factor. Include your brand name and 1-2 strongest keywords.
+
+```json
+{
+  "title": "Budgetly - Money Tracker"
+}
+```
+
+**Best Practices:**
+
+- Brand name first for recognition
+- Include highest-volume keyword
+- Avoid generic words like "app" or "the"
+- Title keywords boost rankings by ~10%
+
+### Subtitle Optimization (30 characters max)
+
+The subtitle appears below your title in search results. Use it for your unique value proposition.
+
+```json
+{
+  "subtitle": "Smart Expense & Budget Planner"
+}
+```
+
+**Best Practices:**
+
+- Don't duplicate keywords from title (Apple counts each word once)
+- Highlight your main differentiator
+- Include secondary high-value keywords
+- Focus on benefits, not features
+
+### Keywords Field (100 characters max)
+
+Hidden from users but crucial for discoverability. Use comma-separated keywords without spaces after commas.
+
+```json
+{
+  "keywords": [
+    "finance,budget,expense,money,tracker,savings,bills,income,spending,wallet,personal,weekly,monthly"
+  ]
+}
+```
+
+**Best Practices:**
+
+- Use all 100 characters
+- Separate with commas only (no spaces)
+- No duplicates from title/subtitle
+- Include singular forms (Apple handles plurals)
+- Add synonyms and alternate spellings
+- Include competitor brand names (carefully)
+- Use digits instead of spelled numbers ("5" not "five")
+- Skip articles and prepositions
+
+### Description Optimization
+
+The iOS description is NOT indexed for search but critical for conversion. Focus on convincing users to download.
+
+```json
+{
+  "description": "Take control of your finances with Budgetly, the intuitive money management app trusted by over 1 million users.\n\nKEY FEATURES:\n• Smart budget tracking - Set limits and watch your progress\n• Expense categorization - Know exactly where your money goes\n• Bill reminders - Never miss a payment\n• Beautiful charts - Visualize your financial health\n• Bank sync - Connect 10,000+ institutions\n• Cloud backup - Your data, always safe\n\nWHY BUDGETLY?\nUnlike complex spreadsheets or basic calculators, Budgetly learns your spending habits and provides personalized insights. Our users save an average of $300/month within 3 months.\n\nPRIVACY FIRST\nYour financial data is encrypted end-to-end. We never sell your information.\n\nDownload Budgetly today and start your journey to financial freedom!"
+}
+```
+
+**Best Practices:**
+
+- Front-load the first 3 lines (visible before "more")
+- Use bullet points for features
+- Include social proof (user counts, ratings, awards)
+- Add a clear call-to-action
+- Mention privacy/security for sensitive apps
+- Update with each release
+
+### Release Notes
+
+Shown to existing users deciding whether to update.
+
+```json
+{
+  "releaseNotes": "Version 2.5 brings exciting improvements:\n\n• NEW: Dark mode support\n• NEW: Widget for home screen\n• IMPROVED: 50% faster sync\n• FIXED: Notification timing issues\n\nLove Budgetly? Please leave a review!"
+}
+```
+
+### Promo Text (170 characters max)
+
+Appears above description; can be updated without new binary. Great for time-sensitive promotions.
+
+```json
+{
+  "promoText": "🎉 New Year Special: Premium features free for 30 days! Start 2025 with better finances."
+}
+```
+
+## Categories
+
+Primary category is most important for browsing and rankings.
+
+```json
+{
+  "categories": ["FINANCE", "PRODUCTIVITY"]
+}
+```
+
+**Available Categories:**
+
+- BOOKS, BUSINESS, DEVELOPER_TOOLS, EDUCATION
+- ENTERTAINMENT, FINANCE, FOOD_AND_DRINK
+- GAMES (with subcategories), GRAPHICS_AND_DESIGN
+- HEALTH_AND_FITNESS, KIDS (age-gated)
+- LIFESTYLE, MAGAZINES_AND_NEWSPAPERS
+- MEDICAL, MUSIC, NAVIGATION, NEWS
+- PHOTO_AND_VIDEO, PRODUCTIVITY, REFERENCE
+- SHOPPING, SOCIAL_NETWORKING, SPORTS
+- STICKERS (with subcategories), TRAVEL
+- UTILITIES, WEATHER
+
+## Localization
+
+Localize metadata for each target market. Keywords should be researched per locale—direct translations often miss regional search terms.
+
+```json
+{
+  "info": {
+    "en-US": {
+      "title": "Budgetly - Money Tracker",
+      "subtitle": "Smart Expense Planner",
+      "keywords": ["budget,finance,money,expense,tracker"]
+    },
+    "es-ES": {
+      "title": "Budgetly - Control de Gastos",
+      "subtitle": "Planificador de Presupuesto",
+      "keywords": ["presupuesto,finanzas,dinero,gastos,ahorro"]
+    },
+    "ja": {
+      "title": "Budgetly - 家計簿アプリ",
+      "subtitle": "簡単支出管理",
+      "keywords": ["家計簿,支出,予算,節約,お金"]
+    },
+    "de-DE": {
+      "title": "Budgetly - Haushaltsbuch",
+      "subtitle": "Ausgaben Verwalten",
+      "keywords": ["budget,finanzen,geld,ausgaben,sparen"]
+    }
+  }
+}
+```
+
+**Supported Locales:**
+`ar-SA`, `ca`, `cs`, `da`, `de-DE`, `el`, `en-AU`, `en-CA`, `en-GB`, `en-US`, `es-ES`, `es-MX`, `fi`, `fr-CA`, `fr-FR`, `he`, `hi`, `hr`, `hu`, `id`, `it`, `ja`, `ko`, `ms`, `nl-NL`, `no`, `pl`, `pt-BR`, `pt-PT`, `ro`, `ru`, `sk`, `sv`, `th`, `tr`, `uk`, `vi`, `zh-Hans`, `zh-Hant`
+
+## Dynamic Configuration
+
+Use JavaScript for dynamic values like copyright year or fetched translations.
+
+### Basic Dynamic Config
+
+```js
+// store.config.js
+const baseConfig = require("./store.config.json");
+
+const year = new Date().getFullYear();
+
+module.exports = {
+  ...baseConfig,
+  apple: {
+    ...baseConfig.apple,
+    copyright: `${year} Your Company, Inc.`,
+  },
+};
+```
+
+### Async Configuration (External Localization)
+
+```js
+// store.config.js
+module.exports = async () => {
+  const baseConfig = require("./store.config.json");
+
+  // Fetch translations from CMS/localization service
+  const translations = await fetch(
+    "https://api.example.com/app-store-copy"
+  ).then((r) => r.json());
+
+  return {
+    ...baseConfig,
+    apple: {
+      ...baseConfig.apple,
+      info: translations,
+    },
+  };
+};
+```
+
+### Environment-Based Config
+
+```js
+// store.config.js
+const baseConfig = require("./store.config.json");
+
+const isProduction = process.env.EAS_BUILD_PROFILE === "production";
+
+module.exports = {
+  ...baseConfig,
+  apple: {
+    ...baseConfig.apple,
+    info: {
+      "en-US": {
+        ...baseConfig.apple.info["en-US"],
+        promoText: isProduction
+          ? "Download now and get started!"
+          : "[BETA] Help us test new features!",
+      },
+    },
+  },
+};
+```
+
+Update `eas.json` to use JS config:
+
+```json
+{
+  "cli": {
+    "metadataPath": "./store.config.js"
+  }
+}
+```
+
+## Age Rating (Advisory)
+
+Answer content questions honestly to get an appropriate age rating.
+
+**Content Descriptors:**
+
+- `NONE` - Content not present
+- `INFREQUENT_OR_MILD` - Occasional mild content
+- `FREQUENT_OR_INTENSE` - Regular or strong content
+
+```json
+{
+  "advisory": {
+    "alcoholTobaccoOrDrugUseOrReferences": "NONE",
+    "contests": "NONE",
+    "gambling": false,
+    "gamblingSimulated": "NONE",
+    "horrorOrFearThemes": "NONE",
+    "matureOrSuggestiveThemes": "NONE",
+    "medicalOrTreatmentInformation": "NONE",
+    "profanityOrCrudeHumor": "NONE",
+    "sexualContentGraphicAndNudity": "NONE",
+    "sexualContentOrNudity": "NONE",
+    "unrestrictedWebAccess": false,
+    "violenceCartoonOrFantasy": "NONE",
+    "violenceRealistic": "NONE",
+    "violenceRealisticProlongedGraphicOrSadistic": "NONE",
+    "seventeenPlus": false,
+    "kidsAgeBand": "NINE_TO_ELEVEN"
+  }
+}
+```
+
+**Kids Age Bands:** `FIVE_AND_UNDER`, `SIX_TO_EIGHT`, `NINE_TO_ELEVEN`
+
+## Release Strategy
+
+Control how your app rolls out to users.
+
+```json
+{
+  "release": {
+    "automaticRelease": true,
+    "phasedRelease": true
+  }
+}
+```
+
+**Options:**
+
+- `automaticRelease: true` - Release immediately upon approval
+- `automaticRelease: false` - Manual release after approval
+- `automaticRelease: "2025-02-01T10:00:00Z"` - Schedule release (RFC 3339)
+- `phasedRelease: true` - 7-day gradual rollout (1%, 2%, 5%, 10%, 20%, 50%, 100%)
+
+## Review Information
+
+Provide contact info and test credentials for the App Review team.
+
+```json
+{
+  "review": {
+    "firstName": "Jane",
+    "lastName": "Smith",
+    "email": "app-review@company.com",
+    "phone": "+1 (555) 123-4567",
+    "demoUsername": "demo@example.com",
+    "demoPassword": "ReviewDemo2025!",
+    "notes": "To test premium features:\n1. Log in with demo credentials\n2. Navigate to Settings > Subscription\n3. Tap 'Restore Purchase' - sandbox purchase will be restored\n\nFor location features, allow location access when prompted."
+  }
+}
+```
+
+## ASO Checklist
+
+### Before Each Release
+
+- [ ] Update keywords based on performance data
+- [ ] Refresh description with new features
+- [ ] Write compelling release notes
+- [ ] Update promo text if running campaigns
+- [ ] Verify all URLs are valid
+
+### Monthly ASO Tasks
+
+- [ ] Analyze keyword rankings
+- [ ] Research competitor keywords
+- [ ] Check conversion rates in App Analytics
+- [ ] Review user feedback for keyword ideas
+- [ ] A/B test screenshots in App Store Connect
+
+### Keyword Research Tips
+
+1. **Brainstorm features** - List all app capabilities
+2. **Mine reviews** - Find words users actually use
+3. **Analyze competitors** - Check their titles/subtitles
+4. **Use long-tail keywords** - Less competition, higher intent
+5. **Consider misspellings** - Common typos can drive traffic
+6. **Track seasonality** - Some keywords peak at certain times
+
+### Metrics to Monitor
+
+- **Impressions** - How often your app appears in search
+- **Product Page Views** - Users who tap to learn more
+- **Conversion Rate** - Views → Downloads
+- **Keyword Rankings** - Position for target keywords
+- **Category Ranking** - Position in your categories
+
+## VS Code Integration
+
+Install the [Expo Tools extension](https://marketplace.visualstudio.com/items?itemName=expo.vscode-expo-tools) for:
+
+- Auto-complete for all schema properties
+- Inline validation and warnings
+- Quick fixes for common issues
+
+## Common Issues
+
+### "Binary not found"
+
+Push a binary with `eas submit` before pushing metadata.
+
+### "Invalid keywords"
+
+- Check total length is ≤100 characters
+- Remove spaces after commas
+- Remove duplicate words
+
+### "Description too long"
+
+Description maximum is 4000 characters.
+
+### Pull doesn't update JS config
+
+`eas metadata:pull` creates a JSON file; import it into your JS config.
+
+## CI/CD Integration
+
+Automate metadata updates in your deployment pipeline:
+
+```yaml
+# .eas/workflows/release.yml
+jobs:
+  submit-and-metadata:
+    steps:
+      - name: Submit to App Store
+        run: eas submit -p ios --latest
+
+      - name: Push Metadata
+        run: eas metadata:push
+```
+
+## Tips
+
+- Update metadata every 4-6 weeks for optimal ASO
+- 70% of App Store visitors use search to find apps
+- Apps with 4+ star ratings get featured more often
+- Localized apps see 128% more downloads per country
+- First 3 lines of description are most critical (shown before "more")
+- Use all 100 keyword characters—every character counts
diff --git a/.agents/skills/eas-app-stores/references/ios-app-store.md b/.agents/skills/eas-app-stores/references/ios-app-store.md
new file mode 100644
index 0000000..ec6b882
--- /dev/null
+++ b/.agents/skills/eas-app-stores/references/ios-app-store.md
@@ -0,0 +1,371 @@
+# Submitting to iOS App Store
+
+## Contents
+
+- [Prerequisites](#prerequisites)
+- [Credential Setup](#credential-setup)
+- [Submission Commands](#submission-commands)
+- [App Store Connect Configuration](#app-store-connect-configuration)
+- [TestFlight vs App Store](#testflight-vs-app-store)
+- [App Review Process](#app-review-process)
+- [Version and Build Numbers](#version-and-build-numbers)
+- [Release Options](#release-options)
+- [Certificates and Provisioning](#certificates-and-provisioning)
+- [App Store Metadata](#app-store-metadata)
+- [Troubleshooting](#troubleshooting)
+- [CI/CD Integration](#cicd-integration)
+- [Tips](#tips)
+
+## Prerequisites
+
+1. **Apple Developer Account** - Enroll at [developer.apple.com](https://developer.apple.com)
+2. **App Store Connect App** - Create your app record before first submission
+3. **Apple Credentials** - Configure via EAS or environment variables
+
+## Credential Setup
+
+### Using EAS Credentials
+
+```bash
+eas credentials -p ios
+```
+
+This interactive flow helps you:
+- Create or select a distribution certificate
+- Create or select a provisioning profile
+- Configure App Store Connect API key (recommended)
+
+### App Store Connect API Key (Recommended)
+
+API keys avoid 2FA prompts in CI/CD:
+
+1. Go to App Store Connect → Users and Access → Keys
+2. Click "+" to create a new key
+3. Select "App Manager" role (minimum for submissions)
+4. Download the `.p8` key file
+
+Configure in `eas.json`:
+
+```json
+{
+  "submit": {
+    "production": {
+      "ios": {
+        "ascApiKeyPath": "./AuthKey_XXXXX.p8",
+        "ascApiKeyIssuerId": "xxxxx-xxxx-xxxx-xxxx-xxxxx",
+        "ascApiKeyId": "XXXXXXXXXX"
+      }
+    }
+  }
+}
+```
+
+Or use environment variables:
+
+```bash
+EXPO_ASC_API_KEY_PATH=./AuthKey.p8
+EXPO_ASC_API_KEY_ISSUER_ID=xxxxx-xxxx-xxxx-xxxx-xxxxx
+EXPO_ASC_API_KEY_ID=XXXXXXXXXX
+```
+
+### Apple ID Authentication (Alternative)
+
+For manual submissions, you can use Apple ID:
+
+```bash
+EXPO_APPLE_ID=your@email.com
+EXPO_APPLE_TEAM_ID=XXXXXXXXXX
+```
+
+Note: Requires app-specific password for accounts with 2FA.
+
+## Submission Commands
+
+```bash
+# Build and submit to App Store Connect
+eas build -p ios --profile production --submit
+
+# Submit latest build
+eas submit -p ios --latest
+
+# Submit specific build
+eas submit -p ios --id BUILD_ID
+
+# Quick TestFlight submission
+npx testflight
+```
+
+## App Store Connect Configuration
+
+### First-Time Setup
+
+Before submitting, complete in App Store Connect:
+
+1. **App Information**
+   - Primary language
+   - Bundle ID (must match `app.json`)
+   - SKU (unique identifier)
+
+2. **Pricing and Availability**
+   - Price tier
+   - Available countries
+
+3. **App Privacy**
+   - Privacy policy URL
+   - Data collection declarations
+
+4. **App Review Information**
+   - Contact information
+   - Demo account (if login required)
+   - Notes for reviewers
+
+### EAS Configuration
+
+```json
+{
+  "cli": {
+    "version": ">= 16.0.1",
+    "appVersionSource": "remote"
+  },
+  "build": {
+    "production": {
+      "ios": {
+        "resourceClass": "m-medium",
+        "autoIncrement": true
+      }
+    }
+  },
+  "submit": {
+    "production": {
+      "ios": {
+        "appleId": "your@email.com",
+        "ascAppId": "1234567890",
+        "appleTeamId": "XXXXXXXXXX"
+      }
+    }
+  }
+}
+```
+
+Find `ascAppId` in App Store Connect → App Information → Apple ID.
+
+## TestFlight vs App Store
+
+### TestFlight (Beta Testing)
+
+- Builds go to TestFlight automatically after submission
+- Internal testers (up to 100) - immediate access
+- External testers (up to 10,000) - requires beta review
+- Builds expire after 90 days
+
+### App Store (Production)
+
+- Requires passing App Review
+- Submit for review from App Store Connect
+- Choose release timing (immediate, scheduled, manual)
+
+## App Review Process
+
+### What Reviewers Check
+
+1. **Functionality** - App works as described
+2. **UI/UX** - Follows Human Interface Guidelines
+3. **Content** - Appropriate and accurate
+4. **Privacy** - Data handling matches declarations
+5. **Legal** - Complies with local laws
+
+### Common Rejection Reasons
+
+| Issue | Solution |
+|-------|----------|
+| Crashes/bugs | Test thoroughly before submission |
+| Incomplete metadata | Fill all required fields |
+| Placeholder content | Remove "lorem ipsum" and test data |
+| Missing login credentials | Provide demo account |
+| Privacy policy missing | Add URL in App Store Connect |
+| Guideline 4.2 (minimum functionality) | Ensure app provides value |
+
+### Expedited Review
+
+Request expedited review for:
+- Critical bug fixes
+- Time-sensitive events
+- Security issues
+
+Go to App Store Connect → your app → App Review → Request Expedited Review.
+
+## Version and Build Numbers
+
+iOS uses two version identifiers:
+
+- **Version** (`CFBundleShortVersionString`): User-facing, e.g., "1.2.3"
+- **Build Number** (`CFBundleVersion`): Internal, must increment for each upload
+
+Configure in `app.json`:
+
+```json
+{
+  "expo": {
+    "version": "1.2.3",
+    "ios": {
+      "buildNumber": "1"
+    }
+  }
+}
+```
+
+With `autoIncrement: true`, EAS handles build numbers automatically.
+
+## Release Options
+
+### Automatic Release
+
+Release immediately when approved:
+
+```json
+{
+  "apple": {
+    "release": {
+      "automaticRelease": true
+    }
+  }
+}
+```
+
+### Scheduled Release
+
+```json
+{
+  "apple": {
+    "release": {
+      "automaticRelease": "2025-03-01T10:00:00Z"
+    }
+  }
+}
+```
+
+### Phased Release
+
+Gradual rollout over 7 days:
+
+```json
+{
+  "apple": {
+    "release": {
+      "phasedRelease": true
+    }
+  }
+}
+```
+
+Rollout: Day 1 (1%) → Day 2 (2%) → Day 3 (5%) → Day 4 (10%) → Day 5 (20%) → Day 6 (50%) → Day 7 (100%)
+
+## Certificates and Provisioning
+
+### Distribution Certificate
+
+- Required for App Store submissions
+- Limited to 3 per Apple Developer account
+- Valid for 1 year
+- EAS manages automatically
+
+### Provisioning Profile
+
+- Links app, certificate, and entitlements
+- App Store profiles don't include device UDIDs
+- EAS creates and manages automatically
+
+### Check Current Credentials
+
+```bash
+eas credentials -p ios
+
+# Sync with Apple Developer Portal
+eas credentials -p ios --sync
+```
+
+## App Store Metadata
+
+Use EAS Metadata to manage App Store listing from code:
+
+```bash
+# Pull existing metadata
+eas metadata:pull
+
+# Push changes
+eas metadata:push
+```
+
+See ./app-store-metadata.md for detailed configuration.
+
+## Troubleshooting
+
+### "No suitable application records found"
+
+Create the app in App Store Connect first with matching bundle ID.
+
+### "The bundle version must be higher"
+
+Increment build number. With `autoIncrement: true`, this is automatic.
+
+### "Missing compliance information"
+
+Add export compliance to `app.json`:
+
+```json
+{
+  "expo": {
+    "ios": {
+      "config": {
+        "usesNonExemptEncryption": false
+      }
+    }
+  }
+}
+```
+
+### "Invalid provisioning profile"
+
+```bash
+eas credentials -p ios --sync
+```
+
+### Build stuck in "Processing"
+
+App Store Connect processing can take 5-30 minutes. Check status in App Store Connect → TestFlight.
+
+## CI/CD Integration
+
+For automated submissions in CI/CD:
+
+```yaml
+# .eas/workflows/release.yml
+name: Release to App Store
+
+on:
+  push:
+    tags: ['v*']
+
+jobs:
+  build:
+    type: build
+    params:
+      platform: ios
+      profile: production
+
+  submit:
+    type: submit
+    needs: [build]
+    params:
+      platform: ios
+      profile: production
+```
+
+## Tips
+
+- Submit to TestFlight early and often for feedback
+- Use beta app review for external testers to catch issues before App Store review
+- Respond to reviewer questions promptly in App Store Connect
+- Keep demo account credentials up to date
+- Monitor App Store Connect notifications for review updates
+- Use phased release for major updates to catch issues early
diff --git a/.agents/skills/eas-app-stores/references/play-store.md b/.agents/skills/eas-app-stores/references/play-store.md
new file mode 100644
index 0000000..9d67530
--- /dev/null
+++ b/.agents/skills/eas-app-stores/references/play-store.md
@@ -0,0 +1,248 @@
+# Submitting to Google Play Store
+
+## Prerequisites
+
+1. **Google Play Console Account** - Register at [play.google.com/console](https://play.google.com/console)
+2. **App Created in Console** - Create your app listing before first submission
+3. **Service Account** - For automated submissions via EAS
+
+Once these are complete, the default `eas submit` works for a first-time submission and creates the app's first release on the internal testing track. Store listing, content rating, and pricing are only required before promoting a release to production.
+
+## Service Account Setup
+
+### 1. Create Service Account
+
+1. Go to Google Cloud Console → IAM & Admin → Service Accounts
+2. Create a new service account
+3. Grant the "Service Account User" role
+4. Create and download a JSON key
+
+### 2. Link to Play Console
+
+1. Go to Play Console → Setup → API access
+2. Click "Link" next to your Google Cloud project
+3. Under "Service accounts", click "Manage Play Console permissions"
+4. Grant "Release to production" permission (or appropriate track permissions)
+
+### 3. Configure EAS
+
+Add the service account key path to `eas.json`:
+
+```json
+{
+  "submit": {
+    "production": {
+      "android": {
+        "serviceAccountKeyPath": "./google-service-account.json",
+        "track": "internal"
+      }
+    }
+  }
+}
+```
+
+Store the key file securely and add it to `.gitignore`.
+
+## Environment Variables
+
+For CI/CD, use environment variables instead of file paths:
+
+```bash
+# Base64-encoded service account JSON
+EXPO_ANDROID_SERVICE_ACCOUNT_KEY_BASE64=...
+```
+
+Or use EAS Secrets:
+
+```bash
+eas secret:create --name GOOGLE_SERVICE_ACCOUNT --value "$(cat google-service-account.json)" --type file
+```
+
+Then reference in `eas.json`:
+
+```json
+{
+  "submit": {
+    "production": {
+      "android": {
+        "serviceAccountKeyPath": "@secret:GOOGLE_SERVICE_ACCOUNT"
+      }
+    }
+  }
+}
+```
+
+## Release Tracks
+
+Google Play uses tracks for staged rollouts:
+
+| Track | Purpose |
+|-------|---------|
+| `internal` | Internal testing (up to 100 testers) |
+| `alpha` | Closed testing |
+| `beta` | Open testing |
+| `production` | Public release |
+
+### Track Configuration
+
+```json
+{
+  "submit": {
+    "production": {
+      "android": {
+        "track": "production",
+        "releaseStatus": "completed"
+      }
+    },
+    "internal": {
+      "android": {
+        "track": "internal",
+        "releaseStatus": "completed"
+      }
+    }
+  }
+}
+```
+
+### Release Status Options
+
+- `completed` - Immediately available on the track
+- `draft` - Upload only, release manually in Console
+- `halted` - Pause an in-progress rollout
+- `inProgress` - Staged rollout (requires `rollout` percentage)
+
+## Staged Rollout
+
+```json
+{
+  "submit": {
+    "production": {
+      "android": {
+        "track": "production",
+        "releaseStatus": "inProgress",
+        "rollout": 0.1
+      }
+    }
+  }
+}
+```
+
+This releases to 10% of users. Increase via Play Console or subsequent submissions.
+
+## Submission Commands
+
+```bash
+# Build and submit to internal track
+eas build -p android --profile production --submit
+
+# Submit existing build to Play Store
+eas submit -p android --latest
+
+# Submit specific build
+eas submit -p android --id BUILD_ID
+```
+
+## App Signing
+
+### Google Play App Signing (Recommended)
+
+EAS uses Google Play App Signing by default:
+
+1. First upload: EAS creates upload key, Play Store manages signing key
+2. Play Store re-signs your app with the signing key
+3. Upload key can be reset if compromised
+
+### Checking Signing Status
+
+```bash
+eas credentials -p android
+```
+
+## Version Codes
+
+Android requires incrementing `versionCode` for each upload:
+
+```json
+{
+  "build": {
+    "production": {
+      "autoIncrement": true
+    }
+  }
+}
+```
+
+With `appVersionSource: "remote"`, EAS tracks version codes automatically.
+
+## First Submission Checklist
+
+Before your first Play Store submission:
+
+- [ ] Create app in Google Play Console
+- [ ] Complete app content declaration (privacy policy, ads, etc.)
+- [ ] Set up store listing (title, description, screenshots)
+- [ ] Complete content rating questionnaire
+- [ ] Set up pricing and distribution
+- [ ] Create service account with proper permissions
+- [ ] Configure `eas.json` with service account path
+
+## Common Issues
+
+### "App not found"
+
+The app must exist in Play Console before EAS can submit. Create it manually first.
+
+### "Version code already used"
+
+Increment `versionCode` in `app.json` or use `autoIncrement: true` in `eas.json`.
+
+### "Service account lacks permission"
+
+Ensure the service account has "Release to production" permission in Play Console → API access.
+
+### "APK not acceptable"
+
+Play Store requires AAB (Android App Bundle) for new apps:
+
+```json
+{
+  "build": {
+    "production": {
+      "android": {
+        "buildType": "app-bundle"
+      }
+    }
+  }
+}
+```
+
+## Internal Testing Distribution
+
+For quick internal distribution without Play Store:
+
+```bash
+# Build with internal distribution
+eas build -p android --profile development
+
+# Share the APK link with testers
+```
+
+Or use EAS Update for OTA updates to existing installs.
+
+## Monitoring Submissions
+
+```bash
+# Check submission status
+eas submit:list -p android
+
+# View specific submission
+eas submit:view SUBMISSION_ID
+```
+
+## Tips
+
+- Start with `internal` track for testing before production
+- Use staged rollouts for production releases
+- Keep service account key secure - never commit to git
+- Set up Play Console notifications for review status
+- Pre-launch reports in Play Console catch issues before review
diff --git a/.agents/skills/eas-app-stores/references/testflight.md b/.agents/skills/eas-app-stores/references/testflight.md
new file mode 100644
index 0000000..e16932a
--- /dev/null
+++ b/.agents/skills/eas-app-stores/references/testflight.md
@@ -0,0 +1,58 @@
+# TestFlight
+
+Always ship to TestFlight first. Internal testers, then external testers, then App Store. Never skip this.
+
+## Submit
+
+```bash
+npx testflight
+```
+
+That's it. One command builds and submits to TestFlight.
+
+## Skip the Prompts
+
+Set these once and forget:
+
+```bash
+EXPO_APPLE_ID=you@email.com
+EXPO_APPLE_TEAM_ID=XXXXXXXXXX
+```
+
+The CLI prints your Team ID when you run `npx testflight`. Copy it.
+
+## Why TestFlight First
+
+- Internal testers get builds instantly (no review)
+- External testers require one Beta App Review, then instant updates
+- Catch crashes before App Store review rejects you
+- TestFlight crash reports are better than App Store crash reports
+- 90 days to test before builds expire
+- Real users on real devices, not simulators
+
+## Tester Strategy
+
+**Internal (100 max)**: Your team. Immediate access. Use for every build.
+
+**External (10,000 max)**: Beta users. First build needs review (~24h), then instant. Always have an external group—even if it's just friends. Real feedback beats assumptions.
+
+## Tips
+
+- Submit to external TestFlight the moment internal looks stable
+- Beta App Review is faster and more lenient than App Store Review
+- Add release notes—testers actually read them
+- Use TestFlight's built-in feedback and screenshots
+- Never go straight to App Store. Ever.
+
+## Troubleshooting
+
+**"No suitable application records found"**
+Create the app in App Store Connect first. Bundle ID must match.
+
+**"The bundle version must be higher"**
+Use `autoIncrement: true` in `eas.json`. Problem solved.
+
+**Credentials issues**
+```bash
+eas credentials -p ios
+```
diff --git a/.agents/skills/eas-app-stores/references/workflows.md b/.agents/skills/eas-app-stores/references/workflows.md
new file mode 100644
index 0000000..4901f75
--- /dev/null
+++ b/.agents/skills/eas-app-stores/references/workflows.md
@@ -0,0 +1,120 @@
+# EAS Workflows
+
+Automate builds, submissions, and PR-preview updates with EAS Workflows. The examples below are store-release-oriented starting points.
+
+When you need to write, edit, or validate a workflow YAML file beyond these examples, use the `eas-workflows` skill. For website and API-route deploy workflows (`type: deploy`), see the `eas-hosting` skill.
+
+## PR Previews with EAS Update
+
+Deploy OTA updates for pull requests:
+
+```yaml
+name: PR Preview
+
+on:
+  pull_request:
+    types: [opened, synchronize]
+
+jobs:
+  publish:
+    type: update
+    params:
+      branch: "pr-${{ github.event.pull_request.number }}"
+      message: "PR #${{ github.event.pull_request.number }}"
+```
+
+## Production Release
+
+Complete release workflow for both platforms:
+
+```yaml
+name: Release
+
+on:
+  push:
+    tags: ['v*']
+
+jobs:
+  build-ios:
+    type: build
+    params:
+      platform: ios
+      profile: production
+
+  build-android:
+    type: build
+    params:
+      platform: android
+      profile: production
+
+  submit-ios:
+    type: submit
+    needs: [build-ios]
+    params:
+      platform: ios
+      profile: production
+
+  submit-android:
+    type: submit
+    needs: [build-android]
+    params:
+      platform: android
+      profile: production
+```
+
+## Build on Push
+
+Trigger builds when pushing to specific branches:
+
+```yaml
+name: Build
+
+on:
+  push:
+    branches:
+      - main
+      - release/*
+
+jobs:
+  build:
+    type: build
+    params:
+      platform: all
+      profile: production
+```
+
+## Conditional Jobs
+
+Run jobs based on conditions:
+
+```yaml
+name: Conditional Release
+
+on:
+  push:
+    branches: [main]
+
+jobs:
+  check-changes:
+    type: run
+    params:
+      command: |
+        if git diff --name-only HEAD~1 | grep -q "^src/"; then
+          echo "has_changes=true" >> $GITHUB_OUTPUT
+        fi
+
+  build:
+    type: build
+    needs: [check-changes]
+    if: needs.check-changes.outputs.has_changes == 'true'
+    params:
+      platform: all
+      profile: production
+```
+
+## Tips
+
+- Use `workflow_dispatch` for manual production releases
+- Combine PR previews with GitHub status checks
+- Use tags for versioned releases
+- Keep sensitive values in EAS Secrets, not workflow files
diff --git a/.agents/skills/eas-hosting/SKILL.md b/.agents/skills/eas-hosting/SKILL.md
new file mode 100644
index 0000000..7ec4c20
--- /dev/null
+++ b/.agents/skills/eas-hosting/SKILL.md
@@ -0,0 +1,431 @@
+---
+name: eas-hosting
+description: EAS service (paid). Deploy Expo websites and Expo Router API routes to EAS Hosting - export the web bundle, run eas deploy for production and PR preview URLs, manage environment secrets and custom domains, and work within the Cloudflare Workers runtime. Also covers authoring API routes (+api.ts handlers, HTTP methods, request handling, CORS). Use when deploying an Expo web app or API routes, setting up EAS Hosting, or configuring hosting environments and domains. Not for native builds or store releases - use the eas-app-stores skill for those.
+version: 1.0.0
+license: MIT
+---
+
+# EAS Hosting
+
+> **EAS service - costs apply.** EAS Hosting is a paid Expo Application Services product with free-tier limits; production deploys use your plan's request and bandwidth allowance. See https://expo.dev/pricing. Authoring API routes and exporting the web bundle are free and open source, and you can self-host the exported server output instead of EAS Hosting.
+
+EAS Hosting deploys your Expo **web app and API routes** to Expo's managed edge (Cloudflare Workers). Export the web bundle with `npx expo export -p web` and ship it with `eas deploy` - the same command deploys any Expo Router API routes bundled alongside it. This skill covers deploying a website, authoring API routes, and the hosting runtime; see the Deployment section below for the deploy workflow.
+
+## When to Use API Routes
+
+Use API routes when you need:
+
+- **Server-side secrets** — API keys, database credentials, or tokens that must never reach the client
+- **Database operations** — Direct database queries that shouldn't be exposed
+- **Third-party API proxies** — Hide API keys when calling external services (OpenAI, Stripe, etc.)
+- **Server-side validation** — Validate data before database writes
+- **Webhook endpoints** — Receive callbacks from services like Stripe or GitHub
+- **Rate limiting** — Control access at the server level
+- **Heavy computation** — Offload processing that would be slow on mobile
+
+## When NOT to Use API Routes
+
+Avoid API routes when:
+
+- **Data is already public** — Use direct fetch to public APIs instead
+- **No secrets required** — Static data or client-safe operations
+- **Real-time updates needed** — Use WebSockets or services like Supabase Realtime
+- **Simple CRUD** — Consider Firebase, Supabase, or Convex for managed backends
+- **File uploads** — Use direct-to-storage uploads (S3 presigned URLs, Cloudflare R2)
+- **Authentication only** — Use Clerk, Auth0, or Firebase Auth instead
+
+## File Structure
+
+API routes live in the `app` directory with `+api.ts` suffix:
+
+```
+app/
+  api/
+    hello+api.ts          → GET /api/hello
+    users+api.ts          → /api/users
+    users/[id]+api.ts     → /api/users/:id
+  (tabs)/
+    index.tsx
+```
+
+## Basic API Route
+
+```ts
+// app/api/hello+api.ts
+export function GET(request: Request) {
+  return Response.json({ message: "Hello from Expo!" });
+}
+```
+
+## HTTP Methods
+
+Export named functions for each HTTP method:
+
+```ts
+// app/api/items+api.ts
+export function GET(request: Request) {
+  return Response.json({ items: [] });
+}
+
+export async function POST(request: Request) {
+  const body = await request.json();
+  return Response.json({ created: body }, { status: 201 });
+}
+
+export async function PUT(request: Request) {
+  const body = await request.json();
+  return Response.json({ updated: body });
+}
+
+export async function DELETE(request: Request) {
+  return new Response(null, { status: 204 });
+}
+```
+
+## Dynamic Routes
+
+```ts
+// app/api/users/[id]+api.ts
+export function GET(request: Request, { id }: { id: string }) {
+  return Response.json({ userId: id });
+}
+```
+
+## Request Handling
+
+### Query Parameters
+
+```ts
+export function GET(request: Request) {
+  const url = new URL(request.url);
+  const page = url.searchParams.get("page") ?? "1";
+  const limit = url.searchParams.get("limit") ?? "10";
+
+  return Response.json({ page, limit });
+}
+```
+
+### Headers
+
+```ts
+export function GET(request: Request) {
+  const auth = request.headers.get("Authorization");
+
+  if (!auth) {
+    return Response.json({ error: "Unauthorized" }, { status: 401 });
+  }
+
+  return Response.json({ authenticated: true });
+}
+```
+
+### JSON Body
+
+```ts
+export async function POST(request: Request) {
+  const { email, password } = await request.json();
+
+  if (!email || !password) {
+    return Response.json({ error: "Missing fields" }, { status: 400 });
+  }
+
+  return Response.json({ success: true });
+}
+```
+
+## Environment Variables
+
+Use `process.env` for server-side secrets:
+
+```ts
+// app/api/ai+api.ts
+export async function POST(request: Request) {
+  const { prompt } = await request.json();
+
+  const response = await fetch("https://api.openai.com/v1/chat/completions", {
+    method: "POST",
+    headers: {
+      "Content-Type": "application/json",
+      Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
+    },
+    body: JSON.stringify({
+      model: "gpt-4",
+      messages: [{ role: "user", content: prompt }],
+    }),
+  });
+
+  const data = await response.json();
+  return Response.json(data);
+}
+```
+
+Set environment variables:
+
+- **Local**: Create `.env` file (never commit)
+- **EAS Hosting**: Use `eas env:create` or Expo dashboard
+
+## CORS Headers
+
+Add CORS for web clients:
+
+```ts
+const corsHeaders = {
+  "Access-Control-Allow-Origin": "*",
+  "Access-Control-Allow-Methods": "GET, POST, PUT, DELETE, OPTIONS",
+  "Access-Control-Allow-Headers": "Content-Type, Authorization",
+};
+
+export function OPTIONS() {
+  return new Response(null, { headers: corsHeaders });
+}
+
+export function GET() {
+  return Response.json({ data: "value" }, { headers: corsHeaders });
+}
+```
+
+## Error Handling
+
+```ts
+export async function POST(request: Request) {
+  try {
+    const body = await request.json();
+    // Process...
+    return Response.json({ success: true });
+  } catch (error) {
+    console.error("API error:", error);
+    return Response.json({ error: "Internal server error" }, { status: 500 });
+  }
+}
+```
+
+## Testing Locally
+
+Start the development server with API routes:
+
+```bash
+npx expo serve
+```
+
+This starts a local server at `http://localhost:8081` with full API route support.
+
+Test with curl:
+
+```bash
+curl http://localhost:8081/api/hello
+curl -X POST http://localhost:8081/api/users -H "Content-Type: application/json" -d '{"name":"Test"}'
+```
+
+## Deployment to EAS Hosting
+
+### Prerequisites
+
+```bash
+npm install -g eas-cli
+eas login
+```
+
+### Deploy
+
+Deploying ships your web bundle and any Expo Router API routes together - `eas deploy` handles both. The export runs whether you have a full website, an API-routes-only backend, or both.
+
+```bash
+# Export the web bundle (includes any API routes)
+npx expo export -p web
+
+# Deploy a preview (PR-style URL)
+npx eas-cli@latest deploy
+
+# Deploy to production
+npx eas-cli@latest deploy --prod
+```
+
+Everything lands on EAS Hosting (Cloudflare Workers).
+
+### Environment Variables for Production
+
+```bash
+# Create a secret
+eas env:create --name OPENAI_API_KEY --value sk-xxx --environment production
+
+# Or use the Expo dashboard
+```
+
+### Custom Domain
+
+Configure in `eas.json` or Expo dashboard.
+
+### Automate with EAS Workflows
+
+Deploy the website (and API routes) on every push to main with a `type: deploy` workflow:
+
+`.eas/workflows/deploy.yml`
+
+```yaml
+name: Deploy
+
+on:
+  push:
+    branches:
+      - main
+
+# https://docs.expo.dev/eas/workflows/syntax/#deploy
+jobs:
+  deploy_web:
+    type: deploy
+    params:
+      prod: true
+```
+
+Preview deploys for pull requests use the same job type with `prod: false`:
+
+```yaml
+name: Web PR Preview
+
+on:
+  pull_request:
+    types: [opened, synchronize]
+
+jobs:
+  preview:
+    type: deploy
+    params:
+      prod: false
+```
+
+To author or validate workflow YAML beyond these examples, use the `eas-workflows` skill.
+
+## EAS Hosting Runtime (Cloudflare Workers)
+
+API routes run on Cloudflare Workers. Key limitations:
+
+### Missing/Limited APIs
+
+- **No Node.js filesystem** — `fs` module unavailable
+- **No native Node modules** — Use Web APIs or polyfills
+- **Limited execution time** — 30 second timeout for CPU-intensive tasks
+- **No persistent connections** — WebSockets require Durable Objects
+- **fetch is available** — Use standard fetch for HTTP requests
+
+### Use Web APIs Instead
+
+```ts
+// Use Web Crypto instead of Node crypto
+const hash = await crypto.subtle.digest(
+  "SHA-256",
+  new TextEncoder().encode("data")
+);
+
+// Use fetch instead of node-fetch
+const response = await fetch("https://api.example.com");
+
+// Use Response/Request (already available)
+return new Response(JSON.stringify(data), {
+  headers: { "Content-Type": "application/json" },
+});
+```
+
+### Database Options
+
+Since filesystem is unavailable, use cloud databases:
+
+- **Cloudflare D1** — SQLite at the edge
+- **Turso** — Distributed SQLite
+- **PlanetScale** — Serverless MySQL
+- **Supabase** — Postgres with REST API
+- **Neon** — Serverless Postgres
+
+Example with Turso:
+
+```ts
+// app/api/users+api.ts
+import { createClient } from "@libsql/client/web";
+
+const db = createClient({
+  url: process.env.TURSO_URL!,
+  authToken: process.env.TURSO_AUTH_TOKEN!,
+});
+
+export async function GET() {
+  const result = await db.execute("SELECT * FROM users");
+  return Response.json(result.rows);
+}
+```
+
+## Calling API Routes from Client
+
+```ts
+// From React Native components
+const response = await fetch("/api/hello");
+const data = await response.json();
+
+// With body
+const response = await fetch("/api/users", {
+  method: "POST",
+  headers: { "Content-Type": "application/json" },
+  body: JSON.stringify({ name: "John" }),
+});
+```
+
+## Common Patterns
+
+### Authentication Middleware
+
+```ts
+// utils/auth.ts
+export async function requireAuth(request: Request) {
+  const token = request.headers.get("Authorization")?.replace("Bearer ", "");
+
+  if (!token) {
+    throw new Response(JSON.stringify({ error: "Unauthorized" }), {
+      status: 401,
+      headers: { "Content-Type": "application/json" },
+    });
+  }
+
+  // Verify token...
+  return { userId: "123" };
+}
+
+// app/api/protected+api.ts
+import { requireAuth } from "../../utils/auth";
+
+export async function GET(request: Request) {
+  const { userId } = await requireAuth(request);
+  return Response.json({ userId });
+}
+```
+
+### Proxy External API
+
+```ts
+// app/api/weather+api.ts
+export async function GET(request: Request) {
+  const url = new URL(request.url);
+  const city = url.searchParams.get("city");
+
+  const response = await fetch(
+    `https://api.weather.com/v1/current?city=${city}&key=${process.env.WEATHER_API_KEY}`
+  );
+
+  return Response.json(await response.json());
+}
+```
+
+## Rules
+
+- NEVER expose API keys or secrets in client code
+- ALWAYS validate and sanitize user input
+- Use proper HTTP status codes (200, 201, 400, 401, 404, 500)
+- Handle errors gracefully with try/catch
+- Keep API routes focused — one responsibility per endpoint
+- Use TypeScript for type safety
+- Log errors server-side for debugging
+
+## 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 "eas-hosting" "<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.
diff --git a/.agents/skills/eas-hosting/agents/openai.yaml b/.agents/skills/eas-hosting/agents/openai.yaml
new file mode 100644
index 0000000..a5b2bf1
--- /dev/null
+++ b/.agents/skills/eas-hosting/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "EAS Hosting"
+  short_description: "Paid EAS service. Deploy Expo websites and Expo Router API routes to EAS Hosting, with environment secrets, custom domains, and the Cloudflare Workers runtime"
+  default_prompt: "Use $eas-hosting to deploy an Expo web app or Expo Router API routes to EAS Hosting, author +api.ts route handlers, manage hosting environment secrets and custom domains, and work within the Cloudflare Workers runtime."
diff --git a/.agents/skills/eas-observe/SKILL.md b/.agents/skills/eas-observe/SKILL.md
new file mode 100644
index 0000000..b2d0e10
--- /dev/null
+++ b/.agents/skills/eas-observe/SKILL.md
@@ -0,0 +1,54 @@
+---
+name: eas-observe
+description: EAS service (paid). Use for anything related to EAS Observe - adding `expo-observe` to an Expo project (AppMetricsRoot/ObserveRoot HOC, markInteractive and ObserveInteractiveMarker, the useObserve hook, the Expo Router / React Navigation integrations for per-route metrics, user-defined events via `Observe.logEvent`, error reporting via ObserveErrorBoundary and `Observe.reportError`, and runtime config such as sampleRate and dispatchInDebug), querying via the EAS CLI (`eas observe:metrics-summary`, `observe:metrics`, `observe:routes`, `observe:events`, `observe:session`, `observe:versions`), interpreting the resulting metrics (cold/warm launch, TTR, TTI, navigation cold/warm TTR, update download, and the TTI frameRate/device/network params for triaging slow startups), or shipping an Observe integration inside a third-party package.
+version: 1.1.0
+license: MIT
+---
+
+# EAS Observe
+
+> **EAS service - costs apply.** EAS Observe is an Expo Application Services product. The free EAS plan allows up to 10,000 monthly active users, with a limited set of features; higher usage requires a paid subscription. For details, see https://expo.dev/pricing#plan-features.
+
+EAS Observe tracks startup, navigation, and custom-event performance from production Expo apps. It needs a development or production build — the native library is not in Expo Go.
+
+> **Source of truth:** https://docs.expo.dev/eas/observe/ — always consult the canonical docs when API details matter, especially get-started, configuration, integrations, and the metrics reference. EAS Observe is evolving; this skill's references are written to stay accurate but may lag the docs.
+
+## Which reference to read
+
+The four reference files in `./references/` cover what people typically need this skill for:
+
+- **Adding EAS Observe to a project** → [`./references/setup.md`](./references/setup.md). Install, wrap the root layout (`AppMetricsRoot` on SDK 55, `ObserveRoot` on SDK 56+), mark the app interactive (global `markInteractive()` on SDK 55, the `useObserve()` hook or `<ObserveInteractiveMarker />` on SDK 56+), optional per-route navigation metrics through the Expo Router / React Navigation integrations, user-defined events via `Observe.logEvent` (SDK 56+), error reporting, and runtime configuration (sampling, dispatch, environments, custom endpoint).
+- **Querying metrics from the terminal** → [`./references/queries.md`](./references/queries.md). The six `eas observe:*` commands — `metrics-summary`, `metrics`, `routes`, `events`, `session`, `versions` — with flags, metric aliases, table layouts, JSON shapes, and common workflows.
+- **Reading a dashboard or CLI output** → [`./references/metrics.md`](./references/metrics.md). Target thresholds per metric, what the automatic TTI params mean (`frameRate.*`, `device.*`, `network.*`), and diagnostic patterns for telling slow-but-smooth startup apart from main-thread contention, hard blocks, or throttled devices.
+- **Shipping an Observe integration in a library** → [`./references/third-party.md`](./references/third-party.md). For package authors only (SDK 57+): optional peer dependency, config declaration merging, `Observe.registerIntegration()`, and event naming.
+
+## Quick links to the docs
+
+- Get started: https://docs.expo.dev/eas/observe/get-started/
+- Dashboard guide: https://docs.expo.dev/eas/observe/dashboard/
+- Querying with EAS CLI: https://docs.expo.dev/eas/observe/eas-cli/
+- Metrics reference: https://docs.expo.dev/eas/observe/reference/metrics/
+- Expo Router integration: https://docs.expo.dev/eas/observe/integrations/expo-router/
+- React Navigation integration: https://docs.expo.dev/eas/observe/integrations/react-navigation/
+- User-defined events: https://docs.expo.dev/eas/observe/events/
+- Configuration: https://docs.expo.dev/eas/observe/configuration/
+- Third-party integrations: https://docs.expo.dev/eas/observe/integrations/third-party/
+- EAS Update download performance: https://docs.expo.dev/eas/observe/eas-update/
+- Troubleshooting: https://docs.expo.dev/eas/observe/reference/troubleshooting/
+
+## Known gaps between the docs and the shipped code
+
+Verified against `eas-cli` 21.8.0 and `expo-observe` 57.0.9. Trust this skill's references over the docs on these points, but re-check with `--help` and the installed package before relying on them:
+
+- All six CLI commands are on the [Querying with EAS CLI](https://docs.expo.dev/eas/observe/eas-cli/) page. Older doc builds list only four and omit `observe:routes` and `observe:session`.
+- Navigation metric aliases are `nav_cold_ttr`, `nav_warm_ttr`, and `nav_tti`. There are no bare `cold_ttr` / `warm_ttr` aliases in the CLI.
+- Sorting uses `--sort <slowest|fastest|newest|oldest>`. There is no `--order` flag.
+- `ObserveErrorBoundary`, `Observe.reportError`, and `configure({ errorHandlingEnabled })` are exported but undocumented. Observe still has no crash reporting; use Sentry or BugSnag for that.
+
+## 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 "eas-observe" "<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.
diff --git a/.agents/skills/eas-observe/agents/openai.yaml b/.agents/skills/eas-observe/agents/openai.yaml
new file mode 100644
index 0000000..444535a
--- /dev/null
+++ b/.agents/skills/eas-observe/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "EAS Observe"
+  short_description: "Paid EAS service. Set up expo-observe app metrics and query launch, route, event, and version performance with the EAS CLI"
+  default_prompt: "Use $eas-observe to add expo-observe instrumentation (AppMetricsRoot/ObserveRoot, useObserve, ObserveInteractiveMarker, the router integrations, error reporting), query metrics with eas observe:* commands, and interpret cold/warm launch, TTR, and TTI results."
diff --git a/.agents/skills/eas-observe/references/metrics.md b/.agents/skills/eas-observe/references/metrics.md
new file mode 100644
index 0000000..5cf8a94
--- /dev/null
+++ b/.agents/skills/eas-observe/references/metrics.md
@@ -0,0 +1,98 @@
+# EAS Observe metrics — interpretation cheatsheet
+
+Quick reference for reading EAS Observe dashboards and CLI output.
+
+> Source: https://docs.expo.dev/eas/observe/reference/metrics/ — this is the canonical reference for metrics. Consult this page for the latest guidance, full prose definitions, optimization tips, and rationale.
+
+All durations are in seconds. Metric data is retained for a minimum of 60 days. By default, every installation dispatches all of its events; high-volume apps can sample per installation with `configure({ sampleRate })` — see [Sampling](https://docs.expo.dev/eas/observe/configuration/#sampling).
+
+## Target thresholds
+
+| Metric | Full name | Target | Auto-collected? |
+|---|---|---|---|
+| Cold launch | `expo.app_startup.cold_launch_time` | **< 1.5s** | Yes (native-only — JS code does not affect it) |
+| Warm launch | `expo.app_startup.warm_launch_time` | **< 0.5s** | Yes (OS decides when warm vs cold happens) |
+| Bundle load | `expo.app_startup.bundle_load_time` | **< 0.3s** | Yes (JS load + evaluation, before `runApplication`) |
+| Time to first render (TTR) | `expo.app_startup.ttr` | **< 2s** incl. cold launch | Yes when root is wrapped with `AppMetricsRoot` (SDK 55) / `ObserveRoot` (SDK 56+) |
+| Time to interactive (TTI) | `expo.app_startup.tti` | **< 3s** incl. cold launch | **No** — call `markInteractive()` once the screen is genuinely usable |
+
+Both TTR and TTI are measured *from native launch* through the React render, so the cold-launch portion counts against them.
+
+## Interpreting TTI events (automatic params)
+
+Every TTI event carries automatic params in three groups: frame rate, device state, and network state. Read the frame-rate group to classify *what kind* of slowness you're seeing, then read the device and network groups to decide whether the cause is the code or the conditions.
+
+### Frame rate — what kind of slowness
+
+| Param | Definition | What it indicates |
+|---|---|---|
+| `expo.frameRate.slowFrames` | Count of frames ≥ 17ms | Main thread consistently busy during launch (heavy layout, sync bridge calls, too many components rendering) |
+| `expo.frameRate.frozenFrames` | Count of frames ≥ 700ms | Hard freezes. Even one during startup is a serious issue (sync I/O, large JSON parsing, blocking network) |
+| `expo.frameRate.totalDelay` | Total accumulated time (seconds) frames exceeded their target duration | Best single "smoothness" number — compare to TTI |
+
+**Diagnostic patterns:**
+
+- **High TTI + low totalDelay** → slow but smooth. The launch sequence itself is long. Optimize bundle size, data-fetch waterfalls, initialization chains.
+- **High TTI + high totalDelay + many slowFrames** → main-thread contention. Offload work, simplify the initial render tree.
+- **High TTI + high totalDelay + any frozenFrames** → something is blocking hard. Look for synchronous I/O, large JSON parsing, or blocking network calls.
+
+### Device state — is the regression environmental?
+
+| Param | Type | What it indicates |
+|---|---|---|
+| `expo.device.lowPowerMode` | boolean | OS power saver was active (Low Power Mode on iOS, Battery Saver on Android). It throttles CPU, GPU, and background work. A regression that disappears when you filter this out is environmental, not a code change. |
+| `expo.device.thermalState` | `nominal` \| `fair` \| `serious` \| `critical` \| `unknown` | Sustained `serious`/`critical` means the OS is throttling. Startup slows independently of any app change. |
+| `expo.device.batteryLevel` | number, 0–1 | Fractional charge at TTI. Rules out throttling on devices that manage performance aggressively at low charge. Omitted when the OS reports no value. |
+| `expo.device.batteryCharging` | boolean | Charging raises sustained CPU ceilings on iOS and some Android OEMs. Non-charging samples are the more conservative population. |
+
+### Network state — is startup network-bound?
+
+| Param | Type | What it indicates |
+|---|---|---|
+| `expo.network.connected` | boolean | If TTI degrades only when `true`, startup is network-bound. If it degrades when `false`, the app does too much before showing cached content. |
+| `expo.network.type` | `wifi` \| `cellular` \| `ethernet` \| `none` \| `other` \| `unknown` | Compare cellular against Wi-Fi. A large gap points to network-bound startup work. VPN traffic reports the underlying transport. The value set is identical on both platforms, so dashboards need no per-platform branching. |
+| `expo.network.isExpensive` | boolean | Both platforms. The OS considers the connection metered (cellular, hotspot). Present only when a network exists. |
+| `expo.network.isConstrained` | boolean | **iOS only.** Low Data Mode is on for this path, so the system defers background transfers. |
+| `expo.network.dataSaverEnabled` | boolean | **Android only.** Data Saver is on. It is the nearest equivalent of Low Data Mode, but process-wide rather than per-path, hence the separate key. |
+
+### Network requests — was the network the cause?
+
+TTI events summarize the HTTP requests made during launch, from the end of the native launch to the `markInteractive()` call. Traffic is observed automatically — `URLSession` on iOS, `OkHttpClient` on Android, which covers `fetch` — and Observe's own uploads are excluded. All of these are omitted when the window held no requests.
+
+| Param | Unit | What it indicates |
+|---|---|---|
+| `expo.network.requests.count` | count | Requests that finished in the window. A request still in flight when the app became interactive is not counted anywhere in this table. |
+| `expo.network.requests.failed` | count | Errored, returned 4xx/5xx, never got a response, or broke partway through the body. Redirects are not failures. |
+| `expo.network.requests.bytesReceived` / `.bytesSent` | bytes | On-the-wire totals for the window. |
+| `expo.network.requests.totalDuration` | seconds | Sum of every request duration, failures included. Exceeds wall-clock when requests overlap; one timeout contributes the client's full timeout interval. |
+| `expo.network.requests.throughputBytesPerSecond` | bytes/sec | Received bytes over the time bytes were actually moving (union of transfer windows, measured from each first byte). Excludes DNS, connect, server think time, cache hits, and failures. Requests the OS did not clearly identify as network loads are excluded too. Omitted when nothing was received. |
+| `expo.network.requests.slowest.duration` | seconds | The single longest **completed** request. Requests that never produced a response are excluded, since a timeout measures the client's own setting. |
+| `expo.network.requests.slowest.host` | string | Host of that request. |
+| `expo.network.requests.slowest.statusCode` | number | Explains an empty response: `bytesReceived` of 0 is routine on a 304, a problem on a 200. |
+| `expo.network.requests.slowest.timeToFirstByte` | seconds | Includes server processing, so treat it as a proxy for network quality, not a measurement of it. |
+| `expo.network.requests.slowest.bytesReceived` | bytes | Separates "slow because it moved a lot of data" from "slow while idle". |
+
+**Diagnostic patterns:**
+
+- **`slowest.duration` mostly `timeToFirstByte`** → the server was slow to answer. Optimize the endpoint, or stop blocking startup on it.
+- **Small `timeToFirstByte` + large `bytesReceived`** → the transfer itself was slow. Shrink the payload or defer it.
+- **High `failed` + high `totalDuration`** → the launch burned time on requests that never arrived. Add timeouts and render cached content first.
+- **Low `throughputBytesPerSecond` on `wifi`** → suspect the population, not the code; cross-check `isExpensive` and `isConstrained` / `dataSaverEnabled`.
+
+> The summary is bounded by an in-memory ring buffer of the 200 most recent requests. A launch that makes more undercounts, so read these as a sample of a very busy window.
+
+### Custom params
+
+You can attach your own params to the TTI event, and override the route name it is tagged with. See [`./setup.md`](./setup.md) for the call syntax.
+
+## Dispatch caveats
+
+- **Debug builds** (native debug OR JS bundle with `__DEV__` = true) do **not** dispatch metrics unless `configure({ dispatchInDebug: true })` is set.
+- The `environment` tag (defaults to `process.env.NODE_ENV`) is metadata only — it does not gate dispatch by itself.
+- Offline events are buffered on-device and flushed when the app backgrounds or `Observe.dispatchEvents()` is called.
+
+## Cross-references
+
+- Full metric definitions and optimization guidance: https://docs.expo.dev/eas/observe/reference/metrics/
+- Setup steps (`AppMetricsRoot` / `ObserveRoot`, `markInteractive`): see [`./setup.md`](./setup.md).
+- Querying metrics via the EAS CLI: see [`./queries.md`](./queries.md).
diff --git a/.agents/skills/eas-observe/references/queries.md b/.agents/skills/eas-observe/references/queries.md
new file mode 100644
index 0000000..5abcb2c
--- /dev/null
+++ b/.agents/skills/eas-observe/references/queries.md
@@ -0,0 +1,403 @@
+# EAS Observe CLI
+
+EAS Observe collects app performance telemetry and custom events from Expo apps and exposes them through six EAS CLI commands. Pass the `--help` flag to any command for the latest API — the flags below were verified against `eas-cli` 21.8.0.
+
+> Source: https://docs.expo.dev/eas/observe/eas-cli/ — the canonical CLI page. This reference adds table layouts, JSON output shapes, and pagination details that the docs page does not cover.
+
+## Commands Overview
+
+| Command | Purpose |
+|---------|---------|
+| `eas observe:metrics-summary` | Per-version statistical aggregates for startup and navigation metrics (median, p90, etc.) |
+| `eas observe:metrics` | Individual metric samples ordered by value or timestamp (paginated) |
+| `eas observe:routes` | Per-route statistical aggregates for navigation metrics (Nav Cold TTR, Nav Warm TTR, Nav TTI) |
+| `eas observe:events` | Custom events emitted by the app via `logEvent` — name summary, all events, or filtered by event name (paginated) |
+| `eas observe:session` | Full timeline of metric and log events for one session |
+| `eas observe:versions` | App version hierarchy with build numbers, OTA update IDs, and event counts |
+
+> Older published docs list only `metrics-summary`, `metrics`, `events`, and `versions`. All six are on the [Querying with EAS CLI](https://docs.expo.dev/eas/observe/eas-cli/) page; run `--help` to confirm them on your installed version.
+
+All six commands share these flags:
+
+- `--start <ISO date>` and `--end <ISO date>` — explicit time range
+- `--days <N>` — show data from the last N days (mutually exclusive with `--start`/`--end`, minimum 1)
+- `--project-id <id>` — run against a specific project without needing a project directory. When passed, the command will not try to create a new EAS project where one is unneeded.
+- `--json` — machine-readable output (implies `--non-interactive`)
+- `--non-interactive` — fail instead of prompting
+
+`--platform ios` / `--platform android` (default: both) is on every command **except `observe:session`**, which is scoped to one session already.
+
+Default time range is the last 60 days when none of `--days`, `--start`, `--end` is given.
+
+**Plan gating.** Observe is a paid feature, and the server rejects queries the account's plan does not include (`EAS_OBSERVE_PLAN_UPGRADE_REQUIRED` or `EAS_OBSERVE_FEATURE_NOT_AVAILABLE_IN_FREE_TIER`). The CLI surfaces the server's upgrade message, which links to the account's billing page. Session timelines in particular are checked before the interactive picker runs. A plan-gate failure is not a bug in the command or its flags.
+
+## Supported Metrics
+
+### App-startup metrics
+
+| Alias | Full name | Display |
+|-------|-----------|---------|
+| `tti` | `expo.app_startup.tti` | Startup TTI (time to interactive) |
+| `ttr` | `expo.app_startup.ttr` | Startup TTR (time to render) |
+| `cold_launch` | `expo.app_startup.cold_launch_time` | Cold Launch |
+| `warm_launch` | `expo.app_startup.warm_launch_time` | Warm Launch |
+| `bundle_load` | `expo.app_startup.bundle_load_time` | Bundle Load |
+| `update_download` | `expo.updates.download_time` | Update Download |
+
+### Navigation metrics
+
+Emitted only when a navigation integration is enabled (SDK 56+). Measured per route name.
+
+| Alias | Full name | Display |
+|-------|-----------|---------|
+| `nav_cold_ttr` | `expo.navigation.cold_ttr` | Nav Cold TTR |
+| `nav_warm_ttr` | `expo.navigation.warm_ttr` | Nav Warm TTR |
+| `nav_tti` | `expo.navigation.tti` | Nav TTI |
+
+**Which command takes which alias.** `observe:metrics` (positional argument) and `observe:metrics-summary --metric` accept **all nine** aliases — startup and navigation. `observe:routes --metric` accepts only the three navigation aliases. Use the `nav_` prefix everywhere; there are no bare `cold_ttr` / `warm_ttr` aliases.
+
+`observe:metrics` also accepts a full metric name in place of an alias, for example `eas observe:metrics expo.app_startup.tti`. `observe:routes` accepts full navigation names the same way. The `--metric` flags on `metrics-summary` and `routes` are strict oclif options, so they take aliases only.
+
+## `eas observe:metrics-summary`
+
+Shows per-version statistical aggregates for one or more metrics, with separate tables per platform.
+
+```bash
+# All default metrics, last 60 days, both platforms
+eas observe:metrics-summary
+
+# Single metric
+eas observe:metrics-summary --metric tti
+
+# Multiple metrics — each renders as its own table
+eas observe:metrics-summary --metric tti --metric cold_launch
+
+# Navigation metrics aggregate per version here, per route in observe:routes
+eas observe:metrics-summary --metric nav_tti
+
+# Choose which statistics to display
+eas observe:metrics-summary --metric tti --stat median --stat p90 --stat eventCount
+
+# Narrow time range and platform
+eas observe:metrics-summary --metric tti --days 14 --platform ios
+```
+
+**Stat flags:** exactly `min`, `median`, `max`, `average`, `p80`, `p90`, `p99`, `eventCount`. This command takes **no aliases** — `med`, `avg`, and `count` are rejected here (they work only on `observe:routes`).
+
+**Default stats:** `median` + `eventCount` in the table; all eight in JSON.
+
+This command has no `--limit`, `--after`, `--app-version`, or `--update-id`. It always aggregates every version in the time range.
+
+**Table layout:**
+- One table per metric (with merged value + event count cells, e.g. `0.45s (150)`)
+- Each table shows iOS and Android in separate sections
+- App Version column includes build numbers in parentheses (e.g. `1.2.0 (42)`)
+- Footer row per platform shows total events per metric
+- **Update IDs are omitted from the table** to keep output readable when a version has many updates; they are included in the JSON output as an array per version
+
+**JSON output shape:**
+```json
+{
+  "versions": [
+    {
+      "appVersion": "1.2.0",
+      "platform": "IOS",
+      "buildNumbers": ["42"],
+      "updateIds": ["abc-def-...", "..."],
+      "metrics": {
+        "expo.app_startup.tti": { "median": 0.45, "p90": 0.9, "...": "..." }
+      }
+    }
+  ],
+  "totalEventCounts": {
+    "expo.app_startup.tti": { "IOS": 1234, "ANDROID": 890 }
+  }
+}
+```
+
+## `eas observe:metrics`
+
+Shows individual performance metric samples, paginated. The metric is a positional argument, not a flag. If omitted and running interactively, prompts for selection; in non-interactive mode it throws an error.
+
+```bash
+# Interactive: prompts for metric
+eas observe:metrics
+
+# Specify metric as positional arg
+eas observe:metrics tti
+
+# Navigation metrics work here too
+eas observe:metrics nav_tti --sort slowest
+
+# Filter by version or update, sort by slowest
+eas observe:metrics tti --app-version 1.2.0 --sort slowest --limit 20
+
+# Pagination — pass the endCursor from the previous run
+eas observe:metrics tti --after <cursor>
+```
+
+**Sample-specific flags:**
+- `--sort <oldest|newest|slowest|fastest>` — defaults to `oldest`
+- `--limit <N>` — samples per page (default 10, max 100)
+- `--after <cursor>` — pagination cursor from the previous run
+- `--app-version <version>` — filter by app version string
+- `--update-id <id>` — filter by EAS update ID
+
+**Table layout:**
+- Summary header shows the metric name, time range, and total sample count across all versions (e.g. `TTI samples for the last 60 days — 1,234 total events`)
+- Columns: Value, App Version (with build number), Update (only when any sample has one), Platform, Device, Country, Timestamp
+- When `hasNextPage` is true, prints `Next page: --after <endCursor>` hint below the table
+- JSON output also includes `sessionId`, `easClientId`, and a `customParams` object per sample
+
+## `eas observe:routes`
+
+Shows per-route statistical aggregates for navigation metrics (Cold TTR, Warm TTR, Nav TTI), grouped by route name with separate sections per platform.
+
+```bash
+# All three navigation metrics, default stats, last 60 days, both platforms
+eas observe:routes
+
+# Single metric, last 7 days, iOS only
+eas observe:routes --metric nav_tti --days 7 --platform ios
+
+# Multiple metrics and stats
+eas observe:routes --metric nav_cold_ttr --metric nav_warm_ttr --stat median --stat p90 --stat count
+
+# Filter to a single build
+eas observe:routes --app-version 1.2.0 --build-number 42
+
+# Narrow to specific routes (repeat the flag for multiple routes)
+eas observe:routes --route-name /new --route-name /settings
+
+# Pagination — each platform has its own cursor; pass the relevant endCursor
+eas observe:routes --after <cursor>
+```
+
+**Routes-specific flags:**
+- `--metric <nav_cold_ttr|nav_warm_ttr|nav_tti>` — navigation metric(s) to display, can be repeated. Defaults to all three.
+- `--stat <median|p90|count>` — statistic(s) per metric. Aliases: `med` → `median`, `event_count` / `eventCount` → `count`.
+- `--limit <N>` — routes per page (default **50**, max **200**, different from `metrics`/`events` which default to 10).
+- `--after <cursor>` — pagination cursor from the previous run.
+- `--app-version <version>` — filter by app version string.
+- `--build-number <number>` — filter by app build number (routes-only).
+- `--route-name <name>` — filter by route name. Repeatable; only the listed routes are returned across both platforms. Duplicates are de-duplicated; omitting the flag returns all routes.
+- `--update-id <id>` — filter by EAS update ID.
+
+**Default stats:** `median` + `count` in the table; `median`, `p90`, `count` in JSON.
+
+**Table layout:**
+- Summary header with the chosen stats and time range, e.g. `Med, P90 values (navigation count) for the last 7 days`.
+- Separate iOS and Android sections.
+- First column is **Route**, followed by one column per metric/stat. With both display stats and `count`, cells are merged like `0.32s (1240)`.
+- Each platform has its own pagination hint: `Next page (iOS): --after <endCursor>`.
+
+**JSON output shape:**
+```json
+{
+  "routes": [
+    {
+      "routeName": "(tabs)/home",
+      "platform": "IOS",
+      "metrics": {
+        "expo.navigation.cold_ttr": { "median": 0.32, "p90": 0.85, "count": 1240 },
+        "expo.navigation.tti":       { "median": 0.55, "p90": 1.10, "count": 1240 }
+      }
+    }
+  ],
+  "pageInfoByPlatform": {
+    "IOS":     { "hasNextPage": true,  "endCursor": "..." },
+    "ANDROID": { "hasNextPage": false, "endCursor": null }
+  }
+}
+```
+
+## `eas observe:events`
+
+Shows custom events emitted by the app via the `logEvent` API in `expo-observe`. Behavior depends on what is passed:
+
+| Invocation | Result |
+|---|---|
+| `observe:events` | Summary table of available event names with counts |
+| `observe:events --all-events` | Full list of events across **all** event names |
+| `observe:events <event-name>` | Full list of events filtered by that event name |
+
+```bash
+# List the available custom event names and their counts (last 60 days)
+eas observe:events
+
+# All events across all names, last 7 days, iOS only
+eas observe:events --all-events --days 7 --platform ios
+
+# Only events with the given name
+eas observe:events login_failed --limit 50
+
+# Drill into a single session
+eas observe:events --all-events --session-id <session-id>
+
+# Pagination
+eas observe:events login_failed --after <cursor>
+```
+
+**Events-specific flags:**
+- `--all-events` — when no event name argument is given, list all events instead of the name summary. Cannot be combined with an event name argument.
+- `--session-id <id>` — filter to events from a single session (events-only). With no event name argument, this lists the session's events instead of the event-name summary. For the full timeline — metrics as well as log events — use `observe:session`.
+- `--app-version <version>` — filter by app version string
+- `--update-id <id>` — filter by EAS update ID
+- `--limit <N>` — events per page (default 10, max 100)
+- `--after <cursor>` — pagination cursor
+
+**Table layout (event listings):**
+- Summary header: `<event-name> events <time range>` or `Custom events <time range>` for `--all-events`, with a total event count when available
+- Columns: Timestamp, Event (only when listing across multiple names), Severity (only when at least one event in the page has a severity), App Version (with build number), Platform, Device, Country
+- `Next page: --after <endCursor>` hint below the table when there is a next page
+
+**Empty-result helper:** if a specific event name is queried and returns no events, the command prints a yellow `No events found matching "<name>"` warning followed by the available event names + counts in the same time range — useful for fixing typos.
+
+**Truncation note:** the event-names summary may flag `Result is truncated; not all event names are shown.` when there are more names than the server returns in a single response.
+
+**JSON output shape (event listing):**
+```json
+{
+  "events": [
+    {
+      "id": "...",
+      "eventName": "login_failed",
+      "timestamp": "2026-...",
+      "sessionId": "...",
+      "severityNumber": 13,
+      "severityText": "WARN",
+      "properties": [{ "key": "reason", "value": "bad_password", "type": "string" }],
+      "appVersion": "1.2.0",
+      "appBuildNumber": "42",
+      "appUpdateId": null,
+      "appEasBuildId": null,
+      "deviceModel": "...",
+      "deviceOs": "iOS",
+      "deviceOsVersion": "17.4",
+      "countryCode": "US",
+      "environment": "production",
+      "easClientId": "..."
+    }
+  ],
+  "pageInfo": { "hasNextPage": true, "endCursor": "..." }
+}
+```
+
+The name-summary mode returns `{ "names": [{ "eventName": "...", "count": 123 }], "isTruncated": false }`.
+
+## `eas observe:session`
+
+Shows the full timeline of metric and log events for a single session — the CLI equivalent of the dashboard's session view. Use it after `observe:metrics` surfaces a slow sample: take that sample's `sessionId` (present in `--json` output) and replay everything that session recorded.
+
+```bash
+# Interactive: pick a metric, then pick a session from the candidate list
+eas observe:session
+
+# Inspect a known session
+eas observe:session <session-id>
+
+# Pick a session from the slowest TTI events in the last 7 days
+eas observe:session --event-name tti --sort slowest --days 7
+```
+
+**Session-specific flags:**
+- `[SESSIONID]` — positional. Omit it in interactive mode to choose from a list. **Required in non-interactive mode**, including under `--json`.
+- `--event-name <name>` — metric or log event used to build the candidate session list (for example `tti`, `cold_launch`, `login_pressed`). Prompts when omitted in interactive mode.
+- `--sort <slowest|fastest|newest|oldest>` — orders the candidate events. Prompts when omitted in interactive mode. No default, unlike `observe:metrics`.
+
+**The picker flags and the session ID are mutually exclusive.** `--event-name`, `--sort`, `--days`, `--start`, and `--end` describe how to *find* a session, so passing any of them together with a session ID throws. Query a known session with the ID alone.
+
+This command has no `--platform`, `--limit`, or `--after` flag. It takes the shared time-range, `--project-id`, `--json`, and `--non-interactive` flags.
+
+**JSON output shape:**
+```json
+{
+  "sessionId": "...",
+  "metadata": { "...": "..." },
+  "entries": [{ "...": "..." }],
+  "hasMoreMetricEvents": false,
+  "hasMoreLogEvents": false
+}
+```
+
+`entries` interleaves metric and log events for the session. The two `hasMore*` flags report truncation per event kind; there is no cursor to page with.
+
+## `eas observe:versions`
+
+Shows app version hierarchy with build numbers, OTA update IDs, and event counts per version.
+
+```bash
+# Both platforms, last 60 days
+eas observe:versions
+
+# iOS only, last 14 days
+eas observe:versions --days 14 --platform ios
+```
+
+No metric-related flags. Output shows separate iOS and Android tables with columns: **App Version, First Seen, Events, Users, Builds (count), Updates (count)**.
+
+JSON output returns the full nested hierarchy with `buildNumbers[].easBuilds[]` and `updates[].easBuilds[]`, including `firstSeenAt`, `eventCount`, and `uniqueUserCount` at every level.
+
+## Common Workflows
+
+**"What are my app's startup times right now?"**
+```bash
+eas observe:metrics-summary --days 7 --stat median --stat p90
+```
+
+**"Which TTI samples were slowest this week?"**
+```bash
+eas observe:metrics tti --sort slowest --days 7 --limit 20
+```
+
+**"How fast are over-the-air updates downloading in the field?"**
+```bash
+eas observe:metrics-summary --metric update_download --days 7
+```
+
+**"Which screens are slowest to navigate to?"**
+```bash
+eas observe:routes --metric nav_tti --stat median --stat p90 --days 7
+```
+
+**"What happened during that one slow session?"**
+```bash
+eas observe:metrics tti --sort slowest --days 7 --json   # read sessionId from a sample
+eas observe:session <session-id>
+```
+
+**"How does navigation perform on just the routes I care about?"**
+```bash
+eas observe:routes --route-name /home --route-name /checkout --days 7
+```
+
+**"What custom events is my app emitting?"**
+```bash
+eas observe:events --days 7
+```
+
+**"Show me every error event from one user's session."**
+```bash
+eas observe:events --all-events --session-id <session-id>
+```
+
+**"What versions of my app are in the field?"**
+```bash
+eas observe:versions
+```
+
+**"Show me metrics for a specific project without needing to be in the repo"**
+```bash
+eas observe:metrics-summary --project-id <uuid> --metric tti
+```
+
+**"Get JSON for scripting"**
+```bash
+eas observe:metrics-summary --metric tti --json --non-interactive
+```
+
+## Notes
+
+- Requires the user to be logged in (`eas login`).
+- When `--project-id` is provided, the command does not require running inside an EAS project directory; otherwise the project ID is read from the local `app.config` / `app.json`. If using this option, ensure that you are logged in as a user that has access to the specified project.
+- `observe:metrics-summary` does not print update IDs in the table but still returns them in JSON for scripting or piping into other commands.
diff --git a/.agents/skills/eas-observe/references/setup.md b/.agents/skills/eas-observe/references/setup.md
new file mode 100644
index 0000000..51f7def
--- /dev/null
+++ b/.agents/skills/eas-observe/references/setup.md
@@ -0,0 +1,476 @@
+# Set up EAS Observe in an existing project
+
+EAS Observe collects app-startup performance metrics (cold launch, warm launch, bundle load, TTR, TTI) from production Expo apps. This reference summarizes the steps to add `expo-observe` to an existing project.
+
+> Source: https://docs.expo.dev/eas/observe/get-started/ — consult this page for the latest guidance.
+
+## SDK 55 vs SDK 56+ at a glance
+
+The library exports differ between SDK versions. Pick the right one for the project's SDK before copying any snippet below.
+
+| Concern | SDK 55 | SDK 56 and later |
+|---|---|---|
+| Root layout HOC | `AppMetricsRoot.wrap(...)` | `ObserveRoot.wrap(...)` |
+| `markInteractive()` API | Global: `AppMetrics.markInteractive()` | Hook: `const { markInteractive } = useObserve()` |
+| Import source | `expo-observe` | `expo-observe` (same package) |
+
+Everything else — package name, build process, dashboard, debug-mode behavior — is the same across versions.
+
+## Prerequisites
+
+Before installing, confirm all of the following:
+
+1. **An Expo account.** Sign up at [expo.dev/signup](https://expo.dev/signup) if needed.
+2. **Expo SDK 55 or later.** Run `npx expo-doctor` to check, and `npx expo install --fix` to update dependencies. SDK 56+ unlocks the newer `ObserveRoot` / `useObserve` API.
+3. **An EAS project.** The app must have `extra.eas.projectId` set in its app config. If not, run `eas init` to create one.
+4. **A development build or a production build.** `expo-observe` is a native library, so it does **not** work in Expo Go. Testing the integration requires a [development build](https://docs.expo.dev/develop/development-builds/introduction/).
+
+## Step 1 — Install the library
+
+From the project root:
+
+```sh
+npx expo install --fix
+npx expo install expo-observe
+```
+
+## Step 2 — Wrap the root layout
+
+The HOC automatically measures **Time to First Render (TTR)**. Apply it to the file that exports the app's root component. The HOC name depends on the SDK version.
+
+**SDK 55** — use `AppMetricsRoot`:
+
+```tsx
+// app/_layout.tsx
+import { Stack } from 'expo-router';
+import { AppMetricsRoot } from 'expo-observe';
+
+function RootLayout() {
+  return <Stack />;
+}
+
+export default AppMetricsRoot.wrap(RootLayout);
+```
+
+**SDK 56 and later** — use `ObserveRoot`:
+
+```tsx
+// app/_layout.tsx
+import { Stack } from 'expo-router';
+import { ObserveRoot } from 'expo-observe';
+
+function RootLayout() {
+  return <Stack />;
+}
+
+export default ObserveRoot.wrap(RootLayout);
+```
+
+**Without Expo Router** (`App.tsx`): wrap the default-exported `App` component the same way — `export default AppMetricsRoot.wrap(App);` on SDK 55, or `export default ObserveRoot.wrap(App);` on SDK 56+.
+
+## Step 3 — Mark the app as interactive
+
+TTI is **not** collected automatically. Signal it once the screen is genuinely ready for the user — i.e. after splash-screen-blocking work like update checks, authentication, initial data fetching, or splash animations finishes. Place the call in a `useEffect` that runs once that work resolves.
+
+**SDK 55** — call the global `AppMetrics.markInteractive()`:
+
+```tsx
+// app/_layout.tsx
+import { Stack } from 'expo-router';
+import * as SplashScreen from 'expo-splash-screen';
+import { AppMetrics, AppMetricsRoot } from 'expo-observe';
+import { useEffect, useState } from 'react';
+
+SplashScreen.preventAutoHideAsync();
+
+function RootLayout() {
+  const [isReady, setIsReady] = useState(false);
+
+  useEffect(() => {
+    async function prepare() {
+      try {
+        await authenticateUser();
+        await fetchInitialData();
+      } catch (e) {
+        console.warn(e);
+      } finally {
+        setIsReady(true);
+      }
+    }
+    prepare();
+  }, []);
+
+  useEffect(() => {
+    if (isReady) {
+      SplashScreen.hide();
+      AppMetrics.markInteractive();
+    }
+  }, [isReady]);
+
+  if (!isReady) return null;
+  return <Stack />;
+}
+
+export default AppMetricsRoot.wrap(RootLayout);
+```
+
+**SDK 56 and later** — use the `useObserve()` hook to get a bound `markInteractive`:
+
+```tsx
+// app/_layout.tsx
+import { Stack } from 'expo-router';
+import * as SplashScreen from 'expo-splash-screen';
+import { ObserveRoot, useObserve } from 'expo-observe';
+import { useEffect, useState } from 'react';
+
+SplashScreen.preventAutoHideAsync();
+
+function RootLayout() {
+  const [isReady, setIsReady] = useState(false);
+  const { markInteractive } = useObserve();
+
+  useEffect(() => {
+    async function prepare() {
+      try {
+        await authenticateUser();
+        await fetchInitialData();
+      } catch (e) {
+        console.warn(e);
+      } finally {
+        setIsReady(true);
+      }
+    }
+    prepare();
+  }, []);
+
+  useEffect(() => {
+    if (isReady) {
+      SplashScreen.hide();
+      markInteractive();
+    }
+  }, [isReady, markInteractive]);
+
+  if (!isReady) return null;
+  return <Stack />;
+}
+
+export default ObserveRoot.wrap(RootLayout);
+```
+
+**Without Expo Router:** the structure is the same in `App.tsx`. Use `SplashScreen.hideAsync()` instead of `SplashScreen.hide()` and replace `<Stack />` with the app's root tree.
+
+### Multiple entry screens
+
+`markInteractive()` is safe to call repeatedly — only the **first** call per session is recorded. If the app has more than one entry screen (onboarding, login, deep-link targets), call `markInteractive()` on **each one**. Otherwise TTI will be missing for sessions that open via a deep link to a screen without the call.
+
+### Custom params and route name
+
+`markInteractive()` accepts an options object. Use `params` to slice TTI by an app-specific dimension (cohort, tenant, feature-flag variant, cache hit). Use `routeName` to override the route the event is tagged with — useful when the logical screen name differs from the router path, when the route is dynamic, or when the app does not use Expo Router. Param values may be strings, numbers, booleans, or any JSON-serializable value.
+
+```tsx
+// SDK 56+: const { markInteractive } = useObserve();
+// SDK 55:  AppMetrics.markInteractive({ ... })
+markInteractive({
+  routeName: '/feed',
+  params: { tenant: 'acme', cohort: 'beta', cacheHit: true },
+});
+```
+
+### Declarative alternative: `<ObserveInteractiveMarker />` (SDK 56+)
+
+Instead of calling `markInteractive()` from an effect, render the marker component at the point the screen becomes interactive. It renders nothing and calls `markInteractive()` once on mount.
+
+```tsx
+import { ObserveInteractiveMarker } from 'expo-observe';
+
+function Feed({ items }) {
+  if (!items) return <Spinner />;
+
+  return (
+    <>
+      <FeedList items={items} />
+      <ObserveInteractiveMarker params={{ cacheHit: true }} />
+    </>
+  );
+}
+```
+
+The marker fires **once**, on mount, so its `params` are read from the first render. Changing them later has no effect and logs a development warning. When the params are only known later, call `useObserve().markInteractive(...)` imperatively instead.
+
+## Step 4 — Build the app
+
+Metrics are collected from real builds, not from `expo start`:
+
+```sh
+eas build
+```
+
+> By default, metrics collected from **debug builds** are not dispatched. A build is treated as a debug build when either the native app is a debug build or the JS bundle is a development bundle (`__DEV__` is `true`). To dispatch anyway while testing the integration, set `dispatchInDebug: true` when calling `configure()` — see [Enable metrics in development](https://docs.expo.dev/eas/observe/configuration/#enable-metrics-in-development). This has no effect on release builds.
+
+## Step 5 — View the metrics
+
+Open the **Observe** tab in the EAS dashboard at `https://expo.dev/accounts/[account]/projects/[project]/observe` to view metrics from the app.
+
+To query metrics from the terminal with the EAS CLI, see [`./queries.md`](./queries.md). For interpreting the metrics themselves, see [`./metrics.md`](./metrics.md).
+
+## Optional — per-route navigation metrics (SDK 56+)
+
+By default `expo-observe` records app-wide startup metrics only. To additionally get **per-route / per-screen** navigation metrics (`cold_ttr`, `warm_ttr`, and a per-navigation `tti`, each tagged with the route/screen), enable one of the navigation integrations. These require **SDK 56 or later**; on earlier SDKs they are silent no-ops. Query the resulting data with `eas observe:routes`, or with `observe:metrics` / `observe:metrics-summary` under the CLI aliases `nav_cold_ttr`, `nav_warm_ttr`, and `nav_tti` (see [`./queries.md`](./queries.md)).
+
+Pick the integration that matches the app's router:
+
+### Expo Router
+
+Docs: https://docs.expo.dev/eas/observe/integrations/expo-router/
+
+1. Enable the integration at module scope, **before any screen mounts** (it cannot be toggled at runtime — calling `configure()` after mount throws):
+
+   ```tsx
+   // app/_layout.tsx
+   import { Observe } from 'expo-observe';
+
+   Observe.configure({
+     integrations: { 'expo-router': true },
+   });
+   ```
+
+2. Call `useObserve()` inside each screen to get a `markInteractive` scoped to the current route, and call it from a `useEffect` once the screen is interactive:
+
+   ```tsx
+   import { useObserve } from 'expo-observe';
+   import { useEffect } from 'react';
+
+   export default function Home() {
+     const { markInteractive } = useObserve();
+     useEffect(() => {
+       markInteractive();
+     }, [markInteractive]);
+     return (/* screen content */);
+   }
+   ```
+
+Events are tagged with the route **pattern** (e.g. `/(tabs)/sessions/[sessionId]`) so the dashboard buckets distinct param values together; the resolved `url` and `routeParams` are also included. Requires `expo-router` installed at runtime, or the integration no-ops.
+
+`router.prefetch()` does not count as a user navigation and never seeds a `cold_ttr` or `warm_ttr` measurement. The next user-driven navigation to a prefetched route emits `warm_ttr`, because the screen already rendered.
+
+### React Navigation
+
+Docs: https://docs.expo.dev/eas/observe/integrations/react-navigation/
+
+Requires `@react-navigation/native` 7.0.0 or later. Same `useObserve()` screen usage as above, plus **two** extra changes:
+
+1. Enable the integration at module scope, before mount:
+
+   ```tsx
+   // App.tsx
+   import { Observe } from 'expo-observe';
+
+   Observe.configure({
+     integrations: { 'react-navigation': true },
+   });
+   ```
+
+2. Connect the integration to the navigation tree. Which component you use depends on whether the app uses React Navigation's dynamic or static configuration. Both record the same per-screen metrics.
+
+   **Dynamic configuration** — replace the top-level `<NavigationContainer>` with `<ObserveNavigationContainer>`. It is a drop-in replacement that accepts the same props and forwards the same ref. If you pass a `linking` config it is used to resolve a human-readable screen path; otherwise the metric falls back to `route.name`.
+
+   ```tsx
+   import { ObserveNavigationContainer } from 'expo-observe/integrations/react-navigation';
+
+   export default function App() {
+     return <ObserveNavigationContainer>{/* navigators */}</ObserveNavigationContainer>;
+   }
+   ```
+
+   **Static configuration** — `createStaticNavigation()` renders the container for you, so there is nothing to replace. Create the navigation ref yourself, pass it to both `<Navigation>` and `<ObserveNavigationProvider>`, and the provider records the same timings by listening through that ref.
+
+   ```tsx
+   import { createStaticNavigation, useNavigationContainerRef } from '@react-navigation/native';
+   import { ObserveNavigationProvider } from 'expo-observe/integrations/react-navigation';
+
+   const Navigation = createStaticNavigation(RootStack);
+
+   export default function App() {
+     const navigationRef = useNavigationContainerRef();
+
+     return (
+       <ObserveNavigationProvider navigationRef={navigationRef}>
+         <Navigation ref={navigationRef} />
+       </ObserveNavigationProvider>
+     );
+   }
+   ```
+
+   `ObserveNavigationProvider` renders no container of its own, but it must be an ancestor of every screen so `useObserve()` works inside them. Pass the **same** ref to both elements; a ref that is not connected to a container emits no metrics.
+
+With React Navigation v7's default `lazy: true`, unfocused tabs stay unmounted, so their first focus records as `cold_ttr` rather than `warm_ttr`.
+
+In both integrations, `useObserve()` is safe to leave in place even when the integration is disabled or the router package is absent — it falls back to the global `markInteractive`.
+
+### Per-route event params
+
+Navigation events carry these params in addition to any custom ones passed to `markInteractive`:
+
+| Param | Type | Notes |
+|---|---|---|
+| `routeName` | string | Route pattern (`/(tabs)/sessions/[sessionId]`) with Expo Router, route-name path (`/Tabs/Sessions`) with React Navigation. Never contains param values. |
+| `url` | string | Resolved pathname. Expo Router only. |
+| `routeParams` | object | Resolved route params, e.g. `{ sessionId: 'abc' }`. |
+| `isAppLaunch` | boolean | `cold_ttr` only. `true` when measured from process start rather than from a navigation action. |
+| `urlHidden` | boolean | Present as `true` when a filtered param caused `url` to be omitted. See below. |
+
+### Filter sensitive params (SDK 57+)
+
+By default the integrations export the resolved URL and every serializable route and query param. If any of those carry sensitive values, list their keys in `filteredParams`:
+
+```tsx
+Observe.configure({
+  integrations: {
+    'expo-router': { filteredParams: ['userId', 'token'] },
+    // or: 'react-navigation': { filteredParams: ['userId', 'token'] },
+  },
+});
+```
+
+Filtered keys are removed from `routeParams`, and the event drops `url` in favor of `urlHidden: true`. `routeName` is unaffected, because it is a pattern and never contains param values.
+
+### Common integration mistakes
+
+- Calling `Observe.configure()` after mount, or toggling an integration flag mid-session, **throws**. Enable it at module scope.
+- `Calling markInteractive on unmounted screen` or `No metadata available for the current screen` means the call ran outside a screen component or after unmount. Move it into a `useEffect` inside the screen component.
+- Call `useObserve()` inside the screen component, not in a wrapper above it. A screen identity that changes between renders logs a warning.
+- With React Navigation, `markInteractive()` records only once the screen is focused. A call on an unfocused screen updates internal state but emits no `tti` event until focus.
+
+## Optional — user-defined events (SDK 56+)
+
+Beyond the automatic startup and navigation metrics, you can record your own named events from anywhere in the app to track product moments — a completed onboarding, an exported report, a selected item. Use `Observe.logEvent(name, options?)`.
+
+> Source: https://docs.expo.dev/eas/observe/events/ — consult this page for the latest guidance.
+
+```tsx
+import { Observe } from 'expo-observe';
+
+function handleOnboardingComplete() {
+  Observe.logEvent('onboarding.completed');
+}
+```
+
+`logEvent` is a plain function call — it is **not** a hook and needs no `useObserve()`. Call it from event handlers, effects, or any non-render code. The event is persisted on-device and dispatched on the next flush (see dispatch notes below); the call returns immediately and never blocks the UI.
+
+### Parameters
+
+| Parameter | Type | Required | Notes |
+|---|---|---|---|
+| `name` | `string` | yes | Stable, dot-separated identifier, e.g. `'report.exported'`. |
+| `options.attributes` | `Record<string, string \| number \| boolean \| array \| nested object>` | no | Structured context attached to the event. Other JS values (`Date`, `undefined`, functions) are dropped. |
+| `options.body` | `string` | no | Free-form message complementing the structured attributes. |
+| `options.severity` | `'trace' \| 'debug' \| 'info' \| 'warn' \| 'error' \| 'fatal'` | no | Defaults to `'info'`. |
+| `options.displayName` | `string` | no | Human-friendly label, e.g. `'Onboarding completed'`. Used **only** in the dashboard's session timeline view; grouping still keys off `name`. |
+
+**Attributes** are the primary way to make an event queryable — attach the identifiers and measurements you'll want to filter or break down by:
+
+```tsx
+Observe.logEvent('report.exported', {
+  attributes: {
+    format: 'csv',
+    rowCount: 1248,
+    durationMs: 532,
+    filters: ['status:active', 'region:us-west'],
+  },
+});
+```
+
+**Severity and body** may be used for operational events you may want to triage by level:
+
+```tsx
+Observe.logEvent('cache.evicted', {
+  body: 'Cache evicted because disk pressure exceeded the configured threshold.',
+  severity: 'warn',
+  attributes: { evictedItemCount: 42, freedBytes: 1048576 },
+});
+```
+
+### Naming and privacy
+
+- **Use lowercase, dot-separated names** (`task.completed`, `onboarding.skipped`). Keep them stable — `report_exported` and `report.exported` bucket as two separate events in the dashboard.
+- **Never put PII in event names, attribute keys, or attribute values.** Everything is transmitted off-device and visible in the dashboard.
+
+### Dispatch
+
+User-defined events are persisted on-device, batched, and dispatched on the next flush as **OpenTelemetry log records** — the same delivery path and timing as other metrics. The debug-build caveat from [Step 4](#step-4--build-the-app) applies unchanged: debug builds don't dispatch unless `configure({ dispatchInDebug: true })` is set.
+
+### Viewing events
+
+User-defined events appear under the **Events** tab in the Observe dashboard, and are queryable from the terminal with `eas observe:events` — see [`./queries.md`](./queries.md).
+
+## Optional — error reporting
+
+`expo-observe` records errors as non-fatal `exception` log events alongside the performance metrics. They arrive by three paths, and they are **not** a replacement for a crash reporter such as Sentry — EAS Observe has no crash reporting yet.
+
+> These APIs ship in `expo-observe` but are not covered by the published docs yet. Verify the exports against the installed package version before relying on them.
+
+**1. Unhandled JS errors — automatic.** A global `ErrorUtils` handler is installed when the package is first imported, which is earlier than any `configure()` call, so errors thrown before configuration are still recorded. React Native's own behavior is unchanged: the red box in development and fatal termination in production still happen. Turn the recording off with `configure({ errorHandlingEnabled: false })`.
+
+**2. Render-phase errors — `<ObserveErrorBoundary>`.** Render errors never reach `ErrorUtils`, so a boundary is the only way to capture them with the React component stack. The boundary records the error and then renders `fallback` in place of the subtree.
+
+```tsx
+import { ObserveErrorBoundary } from 'expo-observe';
+
+<ObserveErrorBoundary
+  fallback={({ error, resetError }) => <ErrorScreen error={error} onRetry={resetError} />}>
+  <Feed />
+</ObserveErrorBoundary>;
+```
+
+`fallback` is required and accepts a React element, `null`, or a function receiving `{ error, resetError }`. `resetError()` clears the caught error and re-mounts the children, so they restart from a clean state. There is no capture-and-rethrow mode — a boundary always renders one of the three fallback forms. Errors that no boundary catches still reach the global handler.
+
+**3. Handled errors — `Observe.reportError(error)`.** Report failures your code caught and recovered from, which reach neither the global handler nor a boundary.
+
+```tsx
+try {
+  await syncCart();
+} catch (error) {
+  Observe.reportError(error);
+}
+```
+
+The value is normalized before it is sent: an `Error` contributes `name`, `message`, and `stack`; any other thrown value (a string, a plain object, a number) is stringified into the message with no stack. `reportError` never throws — it is called from a `catch` block, so a failure inside it must not turn a handled error into an unhandled one.
+
+## Optional — runtime configuration
+
+`Observe.configure()` controls collection and dispatch. Call it at module scope, before mount. Integration flags in particular cannot be toggled at runtime.
+
+| Option | Type | Default | What it does |
+|---|---|---|---|
+| `environment` | string | `process.env.NODE_ENV`, falling back to `'production'` | Metadata tag used to group metrics; filterable in the dashboard. Does not gate dispatch. |
+| `dispatchingEnabled` | boolean | `true` | Master switch. While `false`, pending metrics are dropped, not queued. |
+| `dispatchInDebug` | boolean | `false` | Dispatch metrics collected from debug builds. No effect on release builds. |
+| `sampleRate` | number | `undefined` (all installations) | Fraction of installations that dispatch, in `[0, 1]`. |
+| `errorHandlingEnabled` | boolean | `true` | Record unhandled JS errors as `exception` events. |
+| `integrations` | object | `undefined` | Opt in to `expo-router`, `react-navigation`, or a third-party integration. |
+
+**Network request monitoring is automatic and has no off switch.** `expo-observe` observes `URLSession` traffic on iOS and `OkHttpClient` traffic on Android from launch, and attaches a rollup of the launch window to the TTI event — including the **host** of the slowest request (see [`./metrics.md`](./metrics.md)). Observe's own uploads are excluded. No `configure()` option disables it as of `expo-observe` 57.0.9, so treat request hosts as data that leaves the device.
+
+**Sampling** is deterministic per installation: an installation is permanently in-sample or out-of-sample for a given rate, so the slice is stable across launches rather than a random subset of sessions. Out-of-sample installations drop pending metrics instead of accumulating them, so lowering the rate later does not retroactively send earlier sessions. Values outside `[0, 1]` are clamped. Sampling depends on `dispatchingEnabled`.
+
+**Manual flush.** Events dispatch automatically when the app backgrounds — on Android through a background worker once connectivity returns, on iOS when the app resigns active or is about to terminate. Call `await Observe.dispatchEvents()` to flush early, which is mainly useful while testing.
+
+**Custom endpoint.** EAS Observe sends OTLP over HTTP with a JSON payload, posting to `<endpointUrl>/<project-id>/v1/metrics` and `<endpointUrl>/<project-id>/v1/logs`. Point it at any OpenTelemetry-compatible backend or collector through the **app config**, not `configure()`:
+
+```json
+{ "expo": { "extra": { "eas": { "observe": { "endpointUrl": "https://your-endpoint.com" } } } } }
+```
+
+The URL is baked into the native layer at build time, so run `npx expo prebuild` and rebuild after changing it. If the backend expects standard OTLP paths without the project-ID prefix, route through a collector.
+
+## Quick checklist
+
+- [ ] SDK ≥ 55, EAS project linked, development or production build (not Expo Go).
+- [ ] `expo-observe` installed via `npx expo install`.
+- [ ] Root component exported through `AppMetricsRoot.wrap(...)` (SDK 55) or `ObserveRoot.wrap(...)` (SDK 56+).
+- [ ] `markInteractive()` called from every entry screen once it is genuinely interactive — global `AppMetrics.markInteractive()` on SDK 55, or `useObserve()` hook on SDK 56+.
+- [ ] (Optional, SDK 56+) Per-route metrics enabled via `Observe.configure({ integrations: { ... } })`, plus `<ObserveNavigationContainer>` (dynamic) or `<ObserveNavigationProvider>` (static) for React Navigation.
+- [ ] (Optional, SDK 57+) Sensitive route/query params listed in `filteredParams`.
+- [ ] (Optional, SDK 56+) User-defined events emitted via `Observe.logEvent(name, { attributes })` with stable, lowercase, dot-separated names and no PII.
+- [ ] (Optional) `<ObserveErrorBoundary>` around risky subtrees and `Observe.reportError` in recovery paths.
+- [ ] New build produced with `eas build` and metrics visible in the Observe dashboard.
diff --git a/.agents/skills/eas-observe/references/third-party.md b/.agents/skills/eas-observe/references/third-party.md
new file mode 100644
index 0000000..42c15a0
--- /dev/null
+++ b/.agents/skills/eas-observe/references/third-party.md
@@ -0,0 +1,136 @@
+# Add an EAS Observe integration to a third-party package
+
+This reference is for **package authors**, not app developers. It describes how a library ships an optional EAS Observe integration so that apps using the library get events about problems that application code cannot detect on its own.
+
+> Source: https://docs.expo.dev/eas/observe/integrations/third-party/ — consult this page for the latest guidance.
+
+App-side setup lives in [`./setup.md`](./setup.md). Querying the resulting events is in [`./queries.md`](./queries.md).
+
+## When to use this
+
+Report actionable issues the developer can fix. Good candidates:
+
+- An image decoded at far higher resolution than the device screen needs.
+- A background task that exceeds its expected duration.
+- A native resource that loads slowly.
+
+Do not use it for general product analytics or for anything the app author could log themselves.
+
+## Requirements
+
+- **Expo SDK 57 or later.** `Observe.registerIntegration()` is not available earlier.
+- The consuming app must already have `expo-observe` installed and a build produced.
+
+## Step 1 — Depend on `expo-observe` optionally
+
+The package must keep working when `expo-observe` is absent. Declare it as an **optional peer dependency** plus a dev dependency for types and tests. Never make it a required runtime dependency.
+
+```json
+{
+  "peerDependencies": { "expo-observe": ">=57.0.0" },
+  "peerDependenciesMeta": { "expo-observe": { "optional": true } },
+  "devDependencies": { "expo-observe": "^57.0.0" }
+}
+```
+
+Load it with `require()` inside `try/catch`, and type it with `typeof import()` so the types survive:
+
+```ts
+// observe.ts
+let observeModule: typeof import('expo-observe') | undefined;
+
+try {
+  observeModule = require('expo-observe') as typeof import('expo-observe');
+} catch {
+  // The integration stays disabled when expo-observe is not installed.
+}
+```
+
+## Step 2 — Declare the integration config
+
+Use declaration merging to add your integration key to `ObserveIntegrationsConfig`:
+
+```ts
+// observe.types.ts
+export type YourPackageIntegrationConfig = {
+  thresholdMs?: number;
+};
+
+declare module 'expo-observe' {
+  interface ObserveIntegrationsConfig {
+    'your-package'?: boolean | YourPackageIntegrationConfig;
+  }
+}
+```
+
+Export this declaration from the package entry point so TypeScript loads it when the app imports your package. App developers then enable it the same way they enable the first-party integrations:
+
+```tsx
+Observe.configure({
+  integrations: {
+    'your-package': true,
+    // or, with options:
+    // 'your-package': { thresholdMs: 1500 },
+  },
+});
+```
+
+## Step 3 — Register the integration
+
+`Observe.registerIntegration(name, callback)` invokes the callback once, when the named integration config becomes available. The callback does not run when the key is omitted or set to `false`.
+
+```ts
+// observe.ts
+export function initObserveIntegration() {
+  // The `typeof window` check skips initialization during server-side rendering on web.
+  if (typeof window !== 'undefined' && observeModule) {
+    const { Observe } = observeModule;
+
+    Observe.registerIntegration('your-package', config => {
+      if (config) {
+        enableObserveIntegration(config === true ? {} : config);
+      }
+    });
+  }
+}
+```
+
+Call the initializer from the package entry point:
+
+```ts
+// index.ts
+import { initObserveIntegration } from './observe';
+
+export type { YourPackageIntegrationConfig } from './observe.types';
+
+initObserveIntegration();
+```
+
+Note the `config === true` normalization: the key accepts either a boolean or an options object, so collapse `true` to `{}` before using it.
+
+## Step 4 — Log events
+
+Emit through `Observe.logEvent()` when the package detects an actionable issue. Guard on both module presence and enablement, so a disabled integration costs nothing.
+
+```ts
+export function logExpensiveOperation(durationMs: number, thresholdMs: number) {
+  if (!observeModule || !enabled) {
+    return;
+  }
+
+  const { Observe } = observeModule;
+
+  Observe.logEvent('your-package.expensive-operation', {
+    severity: 'warn',
+    body: 'Reduce the work performed by this operation or increase the configured threshold.',
+    attributes: { durationMs, thresholdMs },
+  });
+}
+```
+
+Naming rules, matching the app-side event conventions in [`./setup.md`](./setup.md):
+
+- Lowercase, dot-separated, with **your package name as the first segment**: `your-package.expensive-operation`.
+- Keep names stable. The dashboard groups by exact name.
+- No PII in names, attribute keys, or attribute values.
+- Use `severity` to separate warnings from errors, and `body` for the remediation hint. The attributes carry the measurements.
diff --git a/.agents/skills/eas-simulator/SKILL.md b/.agents/skills/eas-simulator/SKILL.md
new file mode 100644
index 0000000..4dd9ea4
--- /dev/null
+++ b/.agents/skills/eas-simulator/SKILL.md
@@ -0,0 +1,208 @@
+---
+name: eas-simulator
+description: "EAS service (paid). Run and control a user's app on a remote iOS/Android simulator hosted on EAS cloud. Read before running any `eas simulator:*` commands - it has the current syntax for this experimental API. Use whenever the user needs a simulator they can't run locally - 'run my app on a cloud simulator', 'use eas simulator to run/install/screenshot my app', 'I'm on Linux/Cursor and need an iOS device', 'no sim on this box / headless CI', 'let an agent click through my app and screenshot it', 'test my dev build on a remote sim with live reload', 'stream a sim to my browser' - even when they don't say 'EAS Simulator' or 'cloud'. On a host WITHOUT a local simulator (Linux, CI, cloud sandbox) it's the default; on macOS, do NOT auto-trigger for a plain 'run on the simulator' - use it only for a cloud/remote/shareable sim, an iOS version they lack, or an agent-driven session. NOT for local sims (expo run:ios, Xcode, Android Studio), EAS Build/Update, web preview, or physical devices."
+version: 1.0.0
+license: MIT
+allowed-tools: "Bash(npx *eas-cli@*), Bash(npx *agent-device@*), Bash(npx expo *), Bash(eas *), Bash(expo *), Bash(xcodebuild*), Bash(pod*), Bash(argent *), Bash(ffmpeg*)"
+---
+
+# EAS Simulator
+
+> **EAS service - costs apply.** EAS Simulator runs on Expo Application Services cloud infrastructure, a paid product with free-tier limits; remote simulator sessions use your plan's compute allowance. See https://expo.dev/pricing.
+
+EAS Simulator runs a remote iOS simulator or Android emulator on EAS infrastructure that you drive from your machine — from the CLI, from an AI agent (via `agent-device`), and from a browser preview. It's the unlock for **environments that can't run a simulator locally** (Linux boxes, cloud/background agents like Cursor Cloud), and for letting an agent *verify* a change on a real device instead of only reasoning about code.
+
+The `simulator:*` commands are **experimental and hidden**, and need a recent eas-cli (≥ 20.3.0 as of writing) — which is why this skill runs everything via `npx --yes eas-cli@latest`. Flags and verbs may change; if a command fails, **`<cmd> --help` is authoritative.**
+
+## When to use
+
+The frontmatter `description` carries the trigger phrases. In short: use this to get a user's app onto a **cloud** simulator and interact with it — especially from a Mac-less or cloud/sandbox agent. **Not** for local sims (`expo run:ios`, Xcode, Android Studio), store builds/signing (that's EAS Build), or physical devices. For the macOS case, see *Cloud vs local* next.
+
+## Cloud vs local: decide this first
+
+- **Non-macOS** (Linux / CI / cloud sandbox like Cursor Cloud, detect via `uname -s` ≠ `Darwin`): the only way to get a sim — **proceed, once you've confirmed access** (see *Check availability first* below).
+- **macOS:** local sims exist and a cloud session costs money + latency, so **ask first** ("a remote cloud sim — to share a live preview, offload, or test an iOS version you lack — or just run locally?") unless the user explicitly said cloud/remote/shareable.
+- Always honor an explicit choice; for "run it locally" hand off to `expo run:ios` / Xcode.
+
+```bash
+# Programmatic detection — run this to decide before doing anything else:
+if [ "$(uname -s)" != "Darwin" ] || ! xcrun --find simctl &>/dev/null 2>&1; then
+  echo "no local sim — proceed with EAS Simulator"
+else
+  echo "local sim available — ask the user (cloud or local?)"
+fi
+```
+
+## Prerequisites
+
+- **Run every `eas` command via `npx --yes eas-cli@latest …`** — guarantees a CLI new enough to have `simulator:*` (a global `eas` is often too old), and `--yes` skips npx's prompt. (Bare `eas` is fine if `eas --version` is current.)
+- **Authenticated.** Interactive machine → `npx --yes eas-cli@latest login`. **Cloud sandbox / CI / headless agent has no browser login — set `EXPO_TOKEN`** (expo.dev → Account → Access Tokens) in the env instead. Verify either way with `npx --yes eas-cli@latest whoami`.
+- Run from an Expo **project directory.** A fresh app needs one-time setup: `npx --yes eas-cli@latest init` to create/link the project (when there's no `projectId`), and **set `ios.bundleIdentifier`** in app config if it's missing — a fresh `create-expo-app` often has none, and `prebuild`/`eas build` need it (they prompt or fail without it; e.g. `dev.<owner>.<slug>`). Read current config with `npx expo config --json` (it may live in `app.config.js`). The first Mode-C run is slow (native build); later runs reuse it.
+- A controller to drive the device. This skill uses **agent-device** (open source, MIT), run on demand via `npx agent-device@latest` — nothing globally installed. **argent** is an alternative (`--type argent` in `simulator:start`); see [references/controllers.md](./references/controllers.md).
+- **`.env.eas-simulator`** is written/managed by eas-cli (not this skill): it holds the session id (`EAS_SIMULATOR_SESSION_ID`) + the daemon URL/**token**, so `get`/`stop`/`exec` default to that session (usually **omit `--id`**; pass `--id <id>` to target another). It carries a **token → keep it gitignored** (eas-cli marks it "do not commit" but may not add the ignore rule, and a fresh app's `.gitignore` won't cover it — add `.env.eas-simulator` if missing).
+- `--max-duration-minutes` is paid-plan only; otherwise a default applies.
+- **The command blocks assume a POSIX shell** (bash/zsh) — `printf`, `lsof`, `$(seq …)` loops won't run in cmd/PowerShell. On Windows, run them in WSL or Git Bash, or translate as you go (the `eas-cli`/`agent-device` invocations themselves are cross-platform).
+
+## Check availability first
+
+EAS Simulator is a **limited-access** EAS feature that is still rolling out, so it isn't enabled on every account. Confirm access **before** starting a session — this is a read-only check: no session, no billing.
+
+```bash
+npx --yes eas-cli@latest simulator:availability --json
+# → {"available": true, ...}  enabled → continue to the core loop
+# → {"available": false, ...} not enabled → do NOT start a session
+```
+
+If it's **not** available, don't call `simulator:start` (it will fail). Instead, hand off gracefully so you keep making progress without this skill:
+- Tell the user EAS Simulator isn't available on their account yet — it's coming soon.
+- Fall back to their normal local path for the actual goal — `expo run:ios` / Xcode / Android Studio for a local sim/emulator, an EAS Build, or whatever else fits. Don't dead-end on the cloud sim; the request was almost never "use EAS Simulator specifically."
+
+(If `simulator:availability` isn't recognized, the CLI is too old — upgrade, or treat a `not enabled for this account` error from `simulator:start` the same way: stop and fall back.)
+
+## The core loop (always the same)
+
+A session is: **start → (install your app) → drive → stop.** `eas-cli` owns the *session*; the device *verbs* (open/tap/screenshot) come from the controller, which `npx --yes eas-cli@latest simulator:exec` runs for you with the session's connection env loaded.
+
+```bash
+# 1. Start a session (boots the remote sim + agent-device daemon; writes .env.eas-simulator).
+printf '# managed by eas-cli\n' > .env.eas-simulator   # clear any stale session first
+npx --yes eas-cli@latest simulator:start --platform ios --type agent-device --non-interactive \
+  --name "Checkout flow screenshots"   # always name it — see 'Always name the session'
+#    Then confirm it's live: simulator:get --json → status IN_PROGRESS (bounded poll in run-your-app.md).
+
+# 2. Drive it through `exec` (loads the session env, then runs the command you give it).
+#    agent-device runs on demand via npx — nothing installed globally.
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest open <app-or-url> --platform ios
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest snapshot -i          # interactive UI tree → @e1, @e2 refs
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest press @e2            # tap a ref (NOTE: 'press', not 'tap')
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest screenshot ./shot.png
+
+# 3. Stop (ends billing; tears down the VM) and reset the dotenv. Omit --id to target the dotenv session.
+npx --yes eas-cli@latest simulator:stop
+printf '# managed by eas-cli\n' > .env.eas-simulator
+```
+
+To **watch** it live, hand the user the `webPreviewUrl` that `start` prints (an `--type agent-device` iOS session runs serve-sim alongside the daemon, so it emits one — agent control *and* a browser preview in one session; Android has no preview, and `--type serve-sim` is preview-only). **This URL is for the *user's* browser — you cannot open it for them, and it must never touch the sim:**
+- **"Open it here" (Cursor/VS Code)** → print the URL on its own line and tell the user to open Simple Browser (`Cmd/Ctrl+Shift+P` → "Simple Browser: Show") and paste it. Then **stop**: do not shell out to a system browser or a Cursor/VS Code URL handler, and do not ask "did a tab appear?" — you can't confirm it, the handoff is done.
+- **Never `open` the `webPreviewUrl` on the sim.** It's a browser preview, not a deep link and not an `agent-device open` argument; routing it to the device renders a browser-in-a-browser (a real past failure).
+- **Headless agent** (no display) → just return the URL as the deliverable.
+- **Keeping it alive for the user to drive** → bound it: start with `--max-duration-minutes N` so it auto-stops; tell them it bills until stopped and when it auto-stops; offer to reopen/extend when it ends. (This is the one case where "stop right away" doesn't apply; one-shot `screenshot`/`get` runs still stop immediately.)
+
+`start` also prints a job-run URL.
+
+## Always name the session
+
+Pass `--name "<description>"` on every `simulator:start`. The name appears in `simulator:list`, `simulator:get`, and on the **Simulator sessions** page on expo.dev, where it replaces the generic title on each row. Unnamed, every row reads "Simulator session" over a random id — a wall of identical entries nobody can navigate. Write the name for a **human scanning that list days later**, not for yourself during this run.
+
+Write what the session is *for*, in a few plain words:
+
+```bash
+--name "Checkout flow screenshots"     # what you did
+--name "Dev build — dark mode fix"     # what you were testing
+--name "Login repro for issue 412"     # why it exists
+```
+
+Rules:
+- Derive it from the user's request, not from the mode or the tooling. `Mode C session`, `agent-device ios`, and `test` say nothing.
+- **Length: aim for 3–6 words, ~40 characters, and treat 50 as the practical limit.** It renders as a single-line title in a narrow table column, so a long name clips. The API accepts up to **255 characters** and rejects an empty/whitespace-only name, but 255 is a ceiling you never approach, not a target. One noun phrase, no sentences.
+- Be specific within that budget. Include a ticket or PR number when there is one.
+- **Sentence case:** capitalize the first word only, and leave identifiers in their real casing (`Dev build for expo-router v4`, `Repro for EXPO-1234`). It's a row title, so no Title Case, no all-lowercase, and no trailing period.
+- **Don't repeat what the table already shows.** Every row already displays the session id, platform, start time, duration, and who created it — so no ids, no `iOS`, no dates, no your-own-name. Spend the whole budget on what those columns can't say: the purpose.
+- If the user names it, use their name as-is.
+- Sessions are per-run, so name each new one for that run. Don't reuse an old name for different work.
+
+`--name` is newer than `simulator:start` itself, so an older installed `eas-cli` can reject it. If that happens, run via `npx --yes eas-cli@latest` or upgrade; as a last resort, retry once without `--name` (the session starts unnamed). See [references/troubleshooting.md](./references/troubleshooting.md).
+
+## Commands at a glance
+
+| Command | Purpose |
+|---|---|
+| `npx --yes eas-cli@latest simulator:start --platform ios\|android --name "<description>" [--type agent-device\|argent\|serve-sim] [--package-version X] [--max-duration-minutes N] [--non-interactive] [--json]` | Create a session; boot the sim + controller; write `.env.eas-simulator`; print `webPreviewUrl` + job-run URL. **Always pass `--name`** (see *Always name the session*). **`--json` suppresses the `.env.eas-simulator` write** — omit it for the `exec` flow, or set the env yourself from `remoteConfig`. |
+| `npx --yes eas-cli@latest simulator:exec <cmd> [args…]` | Load `.env.eas-simulator`, then run `<cmd>` with that env. The bridge to the controller. |
+| `npx --yes eas-cli@latest simulator:get [--id] [--json]` | Session status + connection details, including the session `--name`. **Use this to confirm readiness** (see *Operating principles*). |
+| `npx --yes eas-cli@latest simulator:list [--status …] [--type …] [--platform …]` | List an app's sessions by name — this is what the `--name` you pass to `start` is for |
+| `npx --yes eas-cli@latest simulator:stop [--id]` | Stop a session (idempotent) |
+
+## Running the user's app — pick a mode
+
+The remote sim boots **blank — no Expo Go, no apps.** Install a build, then drive it — but **match the build *type* to the goal first** (the box below); that's where live-session runs derail. Full sequences: [references/run-your-app.md](./references/run-your-app.md) — read before running a mode.
+
+> **Match the build to the goal before installing anything — this is where live-session runs derail.** Two traps, same root (grabbing a build that doesn't fit the request):
+> 1. **Wrong type.** Live edits (Mode C) **require a dev build.** A *static* build — a local Release (A), the default EAS sim build (B), or **any build left on the sim from an earlier screenshot run** — freezes its JS at build time and **can never hot-reload.** For a live request, **ignore existing builds entirely** and install a **dev** build (local Debug, or an EAS build with `developmentClient: true`). Never reconnect Metro to a static build hoping it'll reload — it won't.
+> 2. **Stale.** A static look must match current source — reuse only a fingerprint-matched build, else build fresh; reuse is explicit-only.
+>
+> So a leftover EAS/release build is **not** a shortcut for "iterate live" — it's the wrong binary. The fact that a build *exists* never makes it the right one.
+
+| Mode | What it is | Choose when | Live edits? |
+|---|---|---|---|
+| **A — Local release build** | Build a Release `.app` locally, `agent-device install` it (uploads) | User has a Mac toolchain and wants a quick "run my current code on a cloud device" | No (rebuild to see changes) |
+| **B — EAS build** (rare, explicit-only) | `eas build` a simulator build, `agent-device install-from-source <url>` (the VM downloads it) | **Only when explicitly asked** — the user names an existing/EAS build, or wants a static EAS artifact for CI/sharing. Not for "show me"/"iterate" (use C). Sim builds need no credentials. | No |
+| **C — Local dev build + tunnel** | Dev (Debug) build + `EXPO_UNSTABLE_TUNNEL_V2=1 expo start --tunnel` + connect the dev client to Metro | **The agentic edit-and-see loop** — change code and see it live (Fast Refresh) | **Yes** |
+
+Quick decision — **default to C; A and B are explicit-only:**
+- **C (almost everything):** iterate, interact, poke the app, live edits — *and* most "show me my app" (current code needs a build anyway, so live+current wins). Mac → dev client builds locally; no Mac → build it on EAS (`developmentClient: true`). **Unsure → C.**
+- **A:** only an explicit one-shot **static** screenshot on a Mac.
+- **B:** only when the user names an existing/EAS build or wants a static EAS artifact (CI/sharing) — see the box above for why a static build is the wrong tool for "iterate."
+
+## Driving the device (agent-device)
+
+`agent-device` is the controller. Common verbs (run each as `npx --yes eas-cli@latest simulator:exec npx agent-device@latest <verb>`):
+
+| Verb | Does |
+|---|---|
+| `apps --platform ios` | List user-installed apps (the blank sim shows none); add `--all` to include system apps |
+| `install <appId> <path> --platform ios` | Install a local `.app` (uploads it) |
+| `install-from-source <url> --platform ios` | Install from a URL — the VM downloads it (use for EAS artifacts) |
+| `open <appId\|deep-link> --platform ios` | Launch an app (bundle id) or follow an app **deep link** (`exp+slug://…`). A first-time deep link raises a system **"Open in '<app>'?"** dialog — expect it (don't burn a snapshot discovering it) and `press 'label="Open"'` to hand off; it can be slow, so bound it with agent-device's own `--timeout` (e.g. `press 'label="Open"' --timeout 120000`) — **not** a shell `timeout` wrapper (macOS has no `timeout` binary). (Mode C sidesteps this dialog for the Metro-connect link via "Enter URL manually" — see run-your-app.md.) **Not** for the `webPreviewUrl` — that's a browser preview for the user, never the device. |
+| `snapshot -i` | Interactive accessibility tree → `@e1`-style refs |
+| `press <ref\|selector>` | Tap (e.g. `press @e2` or `press 'label="Open"'`) — **the tap verb is `press`, not `tap`** |
+| `fill <ref> "text"` | Type into a field |
+| `screenshot <path>` | Capture the screen to a local PNG (downloaded from the daemon) — requires an app to be open (`open` first) |
+| `record start` / `record stop <path>` | Record the screen to a video — use this for **motion** (animations, gestures, transitions, timing), which a single screenshot can't capture |
+| `metro prepare` / `metro reload` | Point a dev client at Metro / reload (Mode C) |
+
+**Screenshots vs. video.** Default to `screenshot` for static state, but for anything that *moves* — an animation, a transition, a gesture, a timing/jank question — **record a video and inspect the frames** instead; a still can't prove motion. Both controllers record (agent-device `record start`/`stop`, argent `screen-recording-start`/`stop`). Recordings sample at ~30fps — enough to see visible jank, not to prove sub-frame 60/120Hz hitches. For **timing** specifically, argent drops static frames by default (turn `trimStatic` off) — that plus other per-controller gotchas are in [references/controllers.md](./references/controllers.md).
+
+For the full verb set and the `argent` controller alternative, see [references/controllers.md](./references/controllers.md).
+
+## Operating principles
+
+The non-obvious mental model worth internalizing. Specific error→fix lookups (hung verbs, `tap`→`press`, `--platform`, `--json`, `pod install` locale, orphaned sessions, boot variability) live in [references/troubleshooting.md](./references/troubleshooting.md).
+
+1. **Establish ground truth, then reset — don't patch-loop.** Never assume an existing session or Metro is yours or healthy. Before driving, confirm:
+   - **cwd** — you're in the intended Expo project dir (a misdirected `start`/`exec` sessions the *wrong app* + drops a stray `.env.eas-simulator`; `pwd` / check `app.json`).
+   - **session live** — `IN_PROGRESS` via `simulator:get --json` (a stopped session keeps its id + `remoteConfig`, so the dotenv alone isn't proof).
+   - **Metro on its own port** — reuse only if you started it this session; else start one on a free port (`--port <N>`, e.g. 8082), don't kill another server to reclaim `:8081` (run-your-app.md).
+   - **build fits intent** — a **release build can't live-reload**; if live edits are wanted and a release build is installed, **install the dev build, don't reconnect**.
+
+   If current code isn't rendering after your **first** connect, stop poking live state: **reset to baseline** (stop session → clear dotenv → kill your Metro) and redo the mode **once**; a second failure → stop and report. Never restart Metro in place, reconnect more than once, rebuild the native client to fix a JS/connection problem, or surface a preview URL while state is unknown. (A daemon drop — `ERR_NGROK_3200` / `Remote daemon is unavailable` — is the same: reset, don't retry.)
+2. **`exec` is a wrapper, not a driver.** `simulator:exec` loads `.env.eas-simulator` and spawns the command you pass; the device verbs come from the controller (`npx agent-device@latest`). There is no `simulator:tap`.
+3. **Act immediately; don't park an idle session.** Sessions are short-lived — install and drive right after `start`. Leaving one idle drops the tunnel/daemon (→ reset, per #1).
+4. **Stop on every exit path (billing) and reset the dotenv.** `--non-interactive` doesn't auto-stop, and a forgotten session bills until stopped. Don't `start` again to "retry" a slow boot — that orphans a second billed session.
+5. **Screenshot only the correct, fresh build.** Mode C only after the dev client connects to Metro; A/B only from a build matching current source — reusing a pre-existing build is the #1 "my edits don't show" cause (see the build caveat above). (`9:41` in the status bar is the sim default, not staleness.)
+
+## Stop and clean up
+
+Stop the session (ends billing) **and reset the dotenv** so a later run doesn't try to reuse the dead session:
+
+```bash
+npx --yes eas-cli@latest simulator:stop          # omit --id → stops the dotenv session (or pass --id <id>)
+printf '# managed by eas-cli\n' > .env.eas-simulator   # clear the stale session id so it isn't reused
+# if you started Metro for Mode C, stop it too (Ctrl+C in its terminal, or kill the expo process)
+```
+
+## References
+
+- [references/run-your-app.md](./references/run-your-app.md) — full command sequences for modes A, B, and C (read before running a mode).
+- [references/controllers.md](./references/controllers.md) — agent-device verb reference and the `argent` alternative.
+- [references/troubleshooting.md](./references/troubleshooting.md) — concrete errors and fixes.
+
+Source of truth: Expo docs and the `eas` / `agent-device` CLIs (`npx --yes eas-cli@latest simulator:* --help`, `agent-device --help`). This skill teaches how to apply them; it doesn't replace them.
+
+## 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 "eas-simulator" "<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.
diff --git a/.agents/skills/eas-simulator/agents/openai.yaml b/.agents/skills/eas-simulator/agents/openai.yaml
new file mode 100644
index 0000000..dc3573b
--- /dev/null
+++ b/.agents/skills/eas-simulator/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "EAS Simulator"
+  short_description: "Paid EAS service. Run and drive your app on a remote iOS/Android simulator on EAS cloud, from the CLI or an agent, with a live browser preview"
+  default_prompt: "Use $eas-simulator to run, install, screenshot, and drive an app on a remote EAS cloud simulator - especially when no local simulator is available (Linux, CI, cloud agents) or a shareable browser preview is needed."
diff --git a/.agents/skills/eas-simulator/references/controllers.md b/.agents/skills/eas-simulator/references/controllers.md
new file mode 100644
index 0000000..a53ea7b
--- /dev/null
+++ b/.agents/skills/eas-simulator/references/controllers.md
@@ -0,0 +1,86 @@
+# Controllers: agent-device and argent
+
+`eas-cli` has no device verbs — it manages the *session*. The verbs (open/tap/type/screenshot/inspect) come from a **controller** that `npx --yes eas-cli@latest simulator:exec` runs locally and that talks to the controller daemon on the remote VM. Two controllers are supported by `npx --yes eas-cli@latest simulator:start --type`:
+
+- `agent-device` (Callstack, MIT) — used throughout this skill; runs on demand via `npx agent-device@latest`, nothing installed globally.
+- `argent` (Software Mansion) — a capable alternative controller; check its license for your use.
+- `serve-sim` — not a controller; a streaming/preview-only type (iOS), no programmatic control.
+
+## agent-device verbs (run via `npx --yes eas-cli@latest simulator:exec npx agent-device@latest <verb>`)
+
+agent-device is a thin **client** talking to a **daemon** (the daemon runs on the VM in a session). `npx --yes eas-cli@latest simulator:exec` sets `AGENT_DEVICE_DAEMON_BASE_URL` + `AGENT_DEVICE_DAEMON_AUTH_TOKEN` from `.env.eas-simulator`, which switches the client into remote mode. Selectors and `@e`-refs come from the latest `snapshot`.
+
+The CLI help is written for agents and is the source of truth — run these for the full verb set and agentic loop guidance:
+
+```bash
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest --help
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest help workflow
+```
+
+EAS-specific notes:
+
+- **`press`, not `tap`.** The tap verb is `press` — `tap` is not a verb.
+- **`snapshot -i` is slow on iOS** — tens of seconds is normal; wait for it.
+- **`install` uploads** a local binary to the daemon; **`install-from-source`** has the VM download from a URL (use for EAS artifacts — avoids a large upload).
+- **Exercised against a live session:** `apps`, `install`, `install-from-source`, `open`, `snapshot -i`, `press`, `fill`, `screenshot`, `scroll`, `gesture` (needs a preset, e.g. `gesture swipe left`), `logs`, `record` (`start`/`stop <path>`), `network`, `perf`. `metro` (`prepare`/`reload`) is the Mode C dev-client bridge. Pass `--platform ios`; run `<verb>` with no args to see its required subcommand/args.
+
+## argent (alternative)
+
+`npx --yes eas-cli@latest simulator:start --type argent` provisions an argent remote session. The connection config it returns is different (`ARGENT_TOOLS_URL` / `ARGENT_AUTH_TOKEN`).
+
+**Invoking argent — run its tools directly.** Drive argent by running its tools directly — `argent run <tool> --udid <udid> …` (with `argent link` or the env-var config below) — where flags work (the examples here use this path); or via its MCP server, which passes structured params. Heads-up (flagged elsewhere, not reproduced in our own runs): routing an `argent run` call through `npx --yes eas-cli@latest simulator:exec` can **strip the `--flag` arguments**, so the tool runs with no options and fails confusingly. If you must go through `simulator:exec`, wrap it in `sh -c` and pass one `--args` JSON blob instead of flags: `npx --yes eas-cli@latest simulator:exec sh -c 'argent run <tool> --args "{\"udid\":\"<udid>\", …}"'`. argent's gesture tools take **normalized 0.0–1.0** coordinates, not pixels — check its help for the exact input shape.
+
+**Installing apps in an argent session.** `--type argent` provisions only an argent daemon on the VM — there is no agent-device daemon, so agent-device install verbs don't apply. Install a local build with argent's own `reinstall-app` (tar-upload):
+
+```bash
+argent run reinstall-app --udid <udid> --bundleId <bundle-id> --appPath ./MyApp.app
+```
+
+Whenever the tools client is routed to a remote tool-server, it tars the local bundle and streams it up automatically — no extra flag. "Remote" covers both `argent link` and the env-var MCP config (`ARGENT_TOOLS_URL`), so this works in sandboxed shells too. It's a registry tool, so the MCP server exposes it identically — same call by CLI or MCP. Works for iOS `.app` (a directory), Android `.apk`, and Vega `.vpkg`; the client prints an upload line on stderr.
+
+Needs argent ≥ 0.16.0 (the release that adds tar-upload) — verify with `argent --version`. On older versions `reinstall-app` resolves `--appPath` on the VM only, so a local path fails; drive an app already on the sim instead.
+
+**System dialogs on argent (e.g. the first-time deep-link "Open in '<app>'?").** argent's UI queries (`describe` / `await-ui-element`) may not see system dialogs / native modals — a screenshot shows the dialog, but element lookups time out. When that happens, argent surfaces a hint with the fix (today that's a `boot-device --force` to switch its AX backend); follow the hint, then locate and tap "Open". There's no single press-with-timeout — you wait for the element, then tap it. Use argent's own command help for the exact tools and flags.
+
+**Recording video on argent (`screen-recording-start`/`stop`).** The gotcha to know: argent **trims static stretches by default**, which drops the very frames you're measuring — turn that off when you care about cadence or timing (see argent's help for the flag). Recordings also carry a burned-in "Argent" watermark that can't be disabled on a hosted session — fine for diagnosis, mind it before sharing publicly. The stop call returns a video already downloaded locally; extract frames with `ffmpeg` (may need installing) to inspect motion frame by frame. The capture samples at ~30fps, so it shows visible jank but can't prove or disprove sub-frame hitches on 60/120Hz content.
+
+**Screenshot resolution and token cost.** Screenshots cost context tokens once the agent reads them, so resolution is a real tradeoff. **argent's `screenshot` has two independent levers.** `scale` sets the image resolution and defaults **low** (too coarse to judge layout), so pass a larger scale when you need to **read** the UI. `includeImageInContext:false` keeps an image **out of the agent's context entirely** (zero token cost) — use that for a baseline you'll only **diff** later, and keep *that* one at full resolution so the pixel diff stays accurate. So: scale down images you actually read; drop unread ones with `includeImageInContext`, don't just shrink them. Exact flags and the current default: argent's help.
+
+**agent-device** screenshots default to full resolution — a crisp PNG you read from disk, token-heavier for its size, so match the capture to the question. From **v0.20.6** it gains the same lever argent has and drops the old one: `screenshot --scale <0.01–1>` proportionally resizes both dimensions (`1` = full resolution), with a token-conscious default via `AGENT_DEVICE_SCREENSHOT_SCALE` (or `screenshotScale` in config) that an explicit `--scale` overrides — keep it unset or `1` for pixel-diff baselines; the former `--max-size` is removed (older calls refused with migration guidance). Verify the version with `agent-device --version`. One caveat for remote sessions: the resize runs on the daemon, so a newer client against an older EAS session daemon can have `--scale` silently ignored and get full-res back.
+
+**Connecting via MCP (Cursor, Claude Code, Codex, and others).** Install the CLI globally first — the package is `@swmansion/argent`, not `argent`:
+
+```bash
+npm install -g @swmansion/argent
+```
+
+Then run `argent init --yes` to register the Argent MCP server. Link the session credentials with `argent link` — the recommended path:
+
+```bash
+argent link '<ARGENT_TOOLS_URL>' --token '<ARGENT_AUTH_TOKEN>' --yes
+```
+
+Reload the agent after linking so its `argent mcp` process picks up the remote session.
+
+**Sandboxed shells** (Claude Code, some CI environments) can't write to `~/.argent/` so `argent link` won't work there. Use env vars in the MCP config file instead — this is argent's highest-precedence resolution and overrides any link:
+
+```json
+{
+  "mcpServers": {
+    "argent": {
+      "command": "argent",
+      "args": ["mcp"],
+      "env": {
+        "ARGENT_TOOLS_URL": "<ARGENT_TOOLS_URL from simulator:start>",
+        "ARGENT_AUTH_TOKEN": "<ARGENT_AUTH_TOKEN from simulator:start>"
+      }
+    }
+  }
+}
+```
+
+MCP config file location: `.cursor/mcp.json` (Cursor), `.claude/mcp.json` (Claude Code), `mcp.json` in the Codex project root. It carries a session token — **add it to `.gitignore`**.
+
+**Known issues:**
+- `argent init --help` launches an interactive wizard regardless of the flag — use `--yes` to skip it, or read the package source for non-interactive flags.
+- Re-running `argent link` against an already-linked URL **without `--yes`** reports "Already linked. No changes." and keeps the old token — every call then fails with `401 Unauthorized`. Always pass `--yes` (as above) so a rotated token is actually written.
diff --git a/.agents/skills/eas-simulator/references/run-your-app.md b/.agents/skills/eas-simulator/references/run-your-app.md
new file mode 100644
index 0000000..8661792
--- /dev/null
+++ b/.agents/skills/eas-simulator/references/run-your-app.md
@@ -0,0 +1,190 @@
+# Running your app on the remote sim — tested sequences
+
+The remote sim boots blank. You install a **simulator-targeted** build onto the session, then open it. Pick a mode from `SKILL.md`. (Sequences validated against eas-cli 20.3.x + agent-device 0.17.x in mid-2026; the commands are experimental — if one fails, re-check `<cmd> --help`.)
+
+In all modes, the session is started the same way and driven through `npx --yes eas-cli@latest simulator:exec`. Replace `dev.example.app` with the app's iOS `bundleIdentifier` (from `app.json` → `ios.bundleIdentifier`), and run from the project directory.
+
+> These sequences are **iOS**. For **Android**: build via `npx --yes eas-cli@latest build --platform android` (or local Gradle), `install` the `.apk` instead of an `.app`, skip `pod install`, and note there's **no `webPreviewUrl`** (Android is agent-driven / screenshot-only).
+
+## Starting a session (shared by all modes)
+
+```bash
+# Reset the dotenv first so the new session id isn't masked by an "Overwriting previous session" warning.
+printf '# managed by eas-cli\n' > .env.eas-simulator
+
+# Start (no --json, so it writes .env.eas-simulator). It boots the sim + agent-device daemon.
+# --name is required practice: it labels the session in simulator:list/get and on expo.dev.
+# Describe what the run is for, in the user's terms — see "Always name the session" in SKILL.md.
+npx --yes eas-cli@latest simulator:start --platform ios --type agent-device --non-interactive \
+  --name "Checkout flow screenshots"
+```
+
+`start`'s own poll is unreliable, so confirm liveness with a bounded loop (boot is ~90s–15min). `get`/`exec`/`stop` default to the session in `.env.eas-simulator`, so you can omit `--id`:
+
+```bash
+# Poll up to ~16 min; IN_PROGRESS + remoteConfig = live; a terminal status = failed boot (stop + restart).
+for i in $(seq 1 64); do
+  S=$(npx --yes eas-cli@latest simulator:get --json --non-interactive 2>/dev/null)
+  echo "$S" | grep -q '"status": *"IN_PROGRESS"' && echo "$S" | grep -q remoteConfig && { echo "live"; break; }
+  echo "$S" | grep -qE '"status": *"(STOPPED|ERRORED)"' && { echo "boot failed — stop + restart"; break; }
+  sleep 15
+done
+```
+
+If you need the id explicitly, it's `EAS_SIMULATOR_SESSION_ID` in `.env.eas-simulator`. `start` also prints a `webPreviewUrl` (iOS-only browser preview — surface it per the SKILL.md "watch it live" rules) and a job-run URL. Once live, the session env is in `.env.eas-simulator`, so `simulator:exec` works.
+
+---
+
+## Mode A — Local release build (embedded JS, no Metro)
+
+A Release build bundles the JS into the binary, so it renders without Metro. Good for a quick "run my current code on a cloud device" when a Mac toolchain is available.
+
+```bash
+# 1. Generate native project + build a Release simulator .app
+npx expo prebuild --platform ios          # set ios.bundleIdentifier in app.json first to avoid prompts
+# pod install can fail on Ruby 4 + CocoaPods with a Unicode/ASCII-8BIT error — fix with a UTF-8 locale:
+( cd ios && LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 pod install )
+LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 xcodebuild \
+  -workspace ios/<App>.xcworkspace -scheme <App> \
+  -configuration Release -sdk iphonesimulator -derivedDataPath ios/build build
+# → ios/build/Build/Products/Release-iphonesimulator/<App>.app
+
+# 2. Start a session (see "Starting a session" above), then install + open + drive
+APP=ios/build/Build/Products/Release-iphonesimulator/<App>.app
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest install dev.example.app "$APP" --platform ios
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest open dev.example.app --platform ios
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest screenshot ./shot.png
+
+# 3. Stop
+npx --yes eas-cli@latest simulator:stop          # omit --id → stops the dotenv session
+```
+
+The `install` here **uploads** the (~90MB) `.app` to the remote daemon over the tunnel, which installs it on the sim with `simctl`.
+
+---
+
+## Mode B — EAS build (the VM downloads it; no credentials)
+
+**Explicit-only** (see the SKILL.md mode picker): a *static* EAS artifact for CI/sharing, or when the user names an existing EAS build. For no-Mac **live** iteration use Mode C with an EAS dev-client build (see Mode C below), not this. **Simulator builds are unsigned, so EAS asks for no credentials.**
+
+⚠️ **Check for an existing build first.** Before triggering a new build, check if a fingerprint-matched one already exists — it saves ~15-20 min:
+
+```bash
+npx --yes eas-cli@latest build:list --platform ios --profile <your-sim-profile> --status finished --json | \
+  head -20   # <your-sim-profile> = the profile you find/create in step 1; look for one whose fingerprint matches current source
+```
+
+If one matches, skip straight to step 3 with its artifact URL.
+
+⚠️ **Order matters:** build FIRST, `start` the session LAST. The build takes ~15-20 min and a session left idle that long times out (`ERR_NGROK_3200`) — don't `start` until you have the artifact URL.
+
+```bash
+# 1. Find or create a simulator build profile in eas.json.
+#    Read eas.json if it exists and look for a build profile with ios.simulator: true.
+#    If one exists, note its name and skip to step 2.
+#    If not, add one named "sim" — use node, python3, jq, or a direct JSON edit, whichever
+#    is available. Preserve all other profiles. Minimum: { "ios": { "simulator": true } }
+
+# 2. Build (no credentials prompt for a simulator build). Prints an artifact URL when done (~15-20 min).
+npx --yes eas-cli@latest build --platform ios --profile sim --non-interactive
+# → https://expo.dev/artifacts/eas/<hash>.tar.gz
+
+# 3. Start a session, then install-from-source so the VM downloads the artifact (no local upload)
+ART="https://expo.dev/artifacts/eas/<hash>.tar.gz"
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest install-from-source "$ART" --platform ios
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest open dev.example.app --platform ios
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest screenshot ./shot.png
+
+# 4. Stop
+npx --yes eas-cli@latest simulator:stop          # omit --id → stops the dotenv session
+```
+
+**Build freshness:** reuse only a build whose **fingerprint matches current source** (`npx --yes eas-cli@latest build:list --platform ios --json`, or `get-build` by fingerprint per Callstack's public `eas-agent-device` workflow); otherwise **rebuild** or use Mode C. Tell the user which build you used. (Why this matters → SKILL.md "Reusing an existing build" caveat.)
+
+---
+
+## Mode C — Local dev build + tunnel (live edits via Fast Refresh)
+
+This is the agentic edit-and-see loop: a **dev (Debug) build** loads JS from your local **Metro** over **tunnel v2**, so code edits appear on the remote sim via Fast Refresh. It has the most steps — each is necessary.
+
+⚠️ **Don't install a release build as a "quick interim" and screenshot it** — that interim shows stale, build-time code (the "outdated screenshot" trap). Go straight to the dev build + Metro; screenshot only after the dev client is connected to Metro.
+
+**No local Mac toolchain?** (the common cloud/Linux case) Build the dev client on **EAS** instead of step 1 below. ⚠️ Same order-matters rule as Mode B: build first, start the session after you have the artifact URL.
+
+```bash
+# ── Non-Mac path: replace step 1 with these ──────────────────────────────────
+
+# Find or create a dev-client simulator build profile in eas.json.
+#    Read eas.json if it exists and look for a build profile with developmentClient: true + ios.simulator: true.
+#    If one exists, note its name and skip to the build step.
+#    If not, add one named "dev-sim" — use node, python3, jq, or a direct JSON edit, whichever
+#    is available. Preserve all other profiles. Minimum: { "developmentClient": true, "ios": { "simulator": true } }
+
+# Build (~15-20 min). Prints an artifact URL when done.
+npx --yes eas-cli@latest build --platform ios --profile dev-sim --non-interactive
+# → https://expo.dev/artifacts/eas/<hash>.tar.gz
+
+# Start a session AFTER the build finishes (don't start early — idle sessions time out).
+# Then in step 3 below, use install-from-source (VM downloads the artifact) instead of local install:
+ART="https://expo.dev/artifacts/eas/<hash>.tar.gz"
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest install-from-source "$ART" --platform ios
+# Continue from step 3a (open the dev client, enter Metro URL) onward — identical to the Mac path.
+```
+
+```bash
+# 1. Add expo-dev-client and build a Debug (dev-client) simulator .app
+npx expo install expo-dev-client
+npx expo prebuild --platform ios --clean   # set ios.bundleIdentifier first (as in Mode A) to avoid prompts
+( cd ios && LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 pod install )
+LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 xcodebuild \
+  -workspace ios/<App>.xcworkspace -scheme <App> \
+  -configuration Debug -sdk iphonesimulator -derivedDataPath ios/build-debug build
+DEVAPP=ios/build-debug/Build/Products/Debug-iphonesimulator/<App>.app
+
+# 2. Start Metro with tunnel v2 on its OWN port — don't force :8081 or kill anything to reclaim it.
+#    Each `expo start --tunnel` gets its own unique tunnel URL, so a second Metro never has to fight
+#    for the first one's port. Pick a free high port with `--port <N>` (e.g. 8082). Only reuse a
+#    running Metro if YOU started it this session — there's no command to prove ownership, so when
+#    unsure just start a new one on another port; never kill someone else's server. A bare `&` won't
+#    survive across agent shell calls — use a long-lived/background run or a separate terminal. tunnel
+#    v2 (durable-object, not ngrok) works from robot/cloud agents where plain --tunnel is blocked.
+EXPO_UNSTABLE_TUNNEL_V2=1 npx expo start --tunnel --port <N>
+#    → capture the tunnel/manifest URL + deep link it prints (format like https://<host>.on.expo.app).
+#      The port is NOT in the URL, so read it from stdout — `--port` only identifies the local process.
+
+# 3. Start a session, install the dev build, then connect it to Metro.
+#    RELIABLE path = "open the dev client, then Enter URL manually". The deep-link + system "Open in
+#    '<app>'?" dialog is flaky: the dialog may not appear, and `press 'label="Open"'` can hang ~90s
+#    against a slow daemon. Don't make the loop depend on it.
+#    The button labels below ("Enter URL manually"/"Connect"/"Reload"/"Go back", and the system "Open")
+#    are expo-dev-client / iOS / expo-router UI — the same across ANY Expo app (not app-specific), but
+#    UI text that can shift across versions. Treat them as illustrative: if a label doesn't match,
+#    `snapshot -i` and press the current ref. The flow matters, not the exact strings.
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest install dev.example.app "$DEVAPP" --platform ios
+
+#    a) launch the dev client (it opens its launcher, which only auto-discovers LAN Metro — ours is remote):
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest open dev.example.app --platform ios
+
+#    b) point it at your remote Metro via "Enter URL manually":
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest press 'label="Enter URL manually"'
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest snapshot -i          # get the text-field ref
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest fill @<field> "<manifest URL Metro printed in step 2>"   # e.g. https://<host>.on.expo.app
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest press 'label="Connect"'
+
+#    c) first-run dev menu → Reload to fetch the bundle (first build+transfer over the tunnel ~40-60s):
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest press 'label="Reload"'
+
+#    d) expo-router may show "Unmatched Route" (the connect URL was parsed as a path) → go to home:
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest press 'label="Go back"'
+
+# 4. Edit a source file locally → Fast Refresh pushes it to the remote sim with NO reload. Screenshot to confirm.
+npx --yes eas-cli@latest simulator:exec npx agent-device@latest screenshot ./live.png
+
+# 5. Stop the session AND Metro
+npx --yes eas-cli@latest simulator:stop          # omit --id → stops the dotenv session
+# kill the `expo start --tunnel` process
+```
+
+Notes:
+- The launcher's auto-discovery only scans the LAN, so a remote Metro must be entered via "Enter URL manually" — that's why this is the connect step.
+- **This "Enter URL manually" + public tunnel URL flow is the ONLY connect path.** If it fails, don't switch mechanisms or reconnect in a loop — reset to baseline and redo Mode C once (SKILL.md principle 1). (`agent-device`'s `metro prepare --proxy-base-url` bridge exists but is not part of this loop.)
diff --git a/.agents/skills/eas-simulator/references/troubleshooting.md b/.agents/skills/eas-simulator/references/troubleshooting.md
new file mode 100644
index 0000000..d0e0785
--- /dev/null
+++ b/.agents/skills/eas-simulator/references/troubleshooting.md
@@ -0,0 +1,41 @@
+# Troubleshooting
+
+Concrete errors seen while validating this flow, and the fix.
+
+| Symptom | Cause | Fix |
+|---|---|---|
+| `Command simulator:start not found` | `eas-cli` too old (commands are hidden but present from ≥ 20.3.0) | Run via `npx --yes eas-cli@latest …`, or upgrade `eas-cli`. |
+| `simulator:start` rejects `--name` (e.g. `Nonexistent flag: --name`) | `eas-cli` too old — `--name` was added after `simulator:start` itself | Run via `npx --yes eas-cli@latest …`, or upgrade `eas-cli`. If you can't upgrade, retry once **without** `--name`; the session starts unnamed. |
+| `An Expo user account is required` / `whoami` shows logged-out | No browser login on a cloud/CI/headless box, or `EXPO_TOKEN` unset/invalid | Set **`EXPO_TOKEN`** (expo.dev → Account → Access Tokens) in the env; verify `npx --yes eas-cli@latest whoami`. (Interactive machines can `eas login`.) |
+| `simulator:start`/`build`: no linked project / missing `projectId` | A fresh `create-expo-app` isn't linked to EAS | `npx --yes eas-cli@latest init` to create/link it (writes `extra.eas.projectId`). |
+| `prebuild`/`eas build` prompts for or fails on a missing **iOS bundle identifier** | A fresh app often has no `ios.bundleIdentifier` | Set it in app config (e.g. `dev.<owner>.<slug>`); confirm via `npx expo config --json` (may live in `app.config.js`). |
+| `--max-duration-minutes` rejected | The flag is **paid-plan only** | Drop `--max-duration-minutes` to use the default. |
+| `simulator:start` fails with `not enabled for this account` / not-allowlisted | EAS Simulator is limited-access and isn't enabled for this account | Don't retry. Confirm with `simulator:availability`, then hand off gracefully — tell the user and fall back to a local sim / EAS Build (see SKILL.md *Check availability first*). |
+| `start` keeps "Waiting for … session to be ready" but it never returns | `start`'s readiness poll can miss a session that's actually live | Don't rely on it — poll `npx --yes eas-cli@latest simulator:get --id <id> --json` for `status: IN_PROGRESS` + a populated `remoteConfig`. |
+| `ERR_NGROK_3200` / endpoint offline; `Remote daemon is unavailable` | The session's tunnel/daemon dropped — left idle and timed out, or the VM was torn down | A drop invalidates the **whole** session (installed app, `@e` refs, Metro). **Don't retry the failed verb** — start a fresh session, reset the dotenv, and re-run install→open→drive from the top, acting immediately. |
+| Two sessions running / orphaned session / surprise double billing | A second `start` (e.g. to "retry" a slow boot) creates a second billed session and overwrites the dotenv id, orphaning the first | Never `start` again to retry — poll the existing session instead. Find orphans with `simulator:list --status in-progress` and stop each with `simulator:stop --id <id>`. |
+| A device verb hangs (no return for a minute+) | Slow daemon; `press`/`screenshot` can block ~90s | Bound it with agent-device's own `--timeout <ms>` (e.g. `--timeout 120000`) — **not** a shell `timeout` wrapper (macOS has no `timeout` binary, so `timeout 120 …` fails with `command not found` and skips the verb). On timeout `snapshot -i` to see if the action landed before retrying (taps can double-fire). Don't blind-retry. |
+| `install requires an active session or an explicit device selector` | `install` can't infer the device | Pass `--platform ios` (or `open` something first to establish a session). |
+| `Unknown command: tap` | The tap verb is `press` | Use `press <ref\|selector>` (e.g. `press @e2` or `press 'label="Open"'`). |
+| `SESSION_NOT_FOUND: No active session. Run open first.` | A verb (e.g. `screenshot`) ran before any app/session was opened | `open <app\|url>` first (or pass `--platform ios`). |
+| `simulator:exec` / `build` / `simulator:stop`: "Run this command inside a project directory." | Run from the wrong cwd | Run from the Expo project directory (where `app.json`/`eas.json` live). |
+| New session's id shows as the *previous* one; "Overwriting previous simulator session (id: …)" | The stale `.env.eas-simulator` had an old `EAS_SIMULATOR_SESSION_ID`; the warning line masks the new id | Reset the dotenv before `start`: `printf '# managed by eas-cli\n' > .env.eas-simulator`. |
+| No `.env.eas-simulator` written after `start` | `--json` suppresses the dotenv | Run `start` *without* `--json` for the `exec` flow; with `--json` you must read `remoteConfig` from stdout and set the env yourself. |
+| `pod install` fails: `Unicode Normalization not appropriate for ASCII-8BIT` | Ruby 4 + CocoaPods with a non-UTF-8 locale | Re-run with `LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 pod install`. |
+| (Mode C) Deep-link `open` lands on the dev-client launcher, not the app | Opening the deep link triggers a system "Open in '<app>'?" dialog; and the launcher only auto-discovers Metro on the LAN | `press 'label="Open"'` to dismiss the dialog, then "Enter URL manually" → `fill` the `https://<host>.on.expo.app` manifest URL → "Connect". |
+| (Mode C) App shows expo-router "Unmatched Route" | The connect URL was parsed as a route path | `press 'label="Go back"'` (or navigate to `/`). |
+| (Mode C) Dev client shows a `?` placeholder / blank after connect | Bundle not fetched yet | `press 'label="Reload"'` and wait ~40-60s for the first build+transfer over the tunnel. |
+| (Mode C) `expo start` fails: "port 8081 already in use" | Something already owns that port (often another Metro) | Don't kill it — start on another port (`--port <N>`, e.g. 8082). Each `expo start --tunnel` gets its own tunnel URL, so ports coexist. Only reuse a running Metro if you started it this session. |
+| (Mode C) `expo start` / `node` killed with **exit 137** | 137 = SIGKILL — almost always the **OOM killer** (memory pressure, common in constrained cloud sandboxes, esp. a native build + Metro at once). **Not** a port clash. | Reduce memory pressure: don't run a native build and Metro concurrently; give the sandbox more memory; retry. |
+| (Mode C) Edits won't live-reload no matter how often you reconnect | A **release** build is installed — its JS is baked in, so it ignores Metro | Stop reconnecting: **install the dev (Debug) build**, connect it to Metro, reload. Reconnecting a release build to Metro is a no-op. |
+| `expo start --tunnel` errors for a robot/`EXPO_TOKEN` user | The ngrok robot-user guard | Use tunnel v2: `EXPO_UNSTABLE_TUNNEL_V2=1 expo start --tunnel`. |
+| Unexpected charges / a session you forgot | `start --non-interactive` does NOT auto-stop | Always `npx --yes eas-cli@latest simulator:stop --id <id>`. List leftovers with `npx --yes eas-cli@latest simulator:list`. |
+| Screenshot shows **old content** / my recent edits don't appear | Running a **release build (Mode A/B)** whose JS was baked in *before* your edits — typically a reused/stale build | A/B reflect code at build time, not now. **Rebuild** (ensure the build's fingerprint matches current source), or use **Mode C** (dev + Metro) so live edits show via Fast Refresh. The screenshot itself is fresh — it's the build that's stale. (`9:41` in the status bar is the sim default, not staleness.) |
+| (argent) Every `argent run`/`tools` call returns `401 Unauthorized` right after linking | `argent link` without `--yes` no-ops on an already-linked URL ("Already linked. No changes."), keeping a stale token from a previous session | Re-link with `--yes` so the new token is written — see the link command in [controllers.md](./controllers.md). |
+
+## Performance expectations
+
+Set the user's expectations honestly — this is experimental:
+- **Boot is variable**: ~90s warm to ~15 min cold. Poll patiently.
+- **`snapshot` can be slow** on iOS (tens of seconds).
+- **First bundle load** over the tunnel (Mode C) is the slow part; subsequent Fast Refreshes are fast.
diff --git a/.agents/skills/eas-update-insights/SKILL.md b/.agents/skills/eas-update-insights/SKILL.md
new file mode 100644
index 0000000..36777c6
--- /dev/null
+++ b/.agents/skills/eas-update-insights/SKILL.md
@@ -0,0 +1,238 @@
+---
+name: eas-update-insights
+description: "EAS service (paid). Check the health of published EAS Update: crash rates, install/launch counts, unique users, payload size, and the split between embedded and OTA users per channel. Use when the user asks how an update is performing, whether a rollout is healthy, how many users are on the embedded build vs OTA, or wants to gate CI on update health."
+version: 1.0.0
+license: MIT
+allowed-tools: "Bash(eas *)"
+---
+
+# EAS Update Insights
+
+> **EAS service - costs apply.** Insights cover updates published through EAS Update, a paid Expo Application Services product with free-tier limits. Update delivery and the data behind these commands count against your plan's EAS Update usage. Review https://expo.dev/pricing.
+
+Query the health of published EAS Update directly from the CLI: launches, failed launches, crash rates, unique users, payload size, the embedded-vs-OTA user split per channel, and the most popular updates per runtime version. The data is the same data that powers the update and channel detail pages on expo.dev; these commands expose it in the terminal in human and JSON form.
+
+## When to use this skill
+
+Use this when the user wants to assess the health or adoption of a published EAS Update: crash rates, install counts, unique users, bundle size, or the split between embedded and OTA users on a channel.
+
+Example prompts:
+
+- "How is the latest update doing?"
+- "Is the latest update healthy?"
+- "Is the new release crashing more than the last one?"
+- "How many users are on the latest update vs the embedded build?"
+- "Which update is most popular on production right now?"
+- "How big is our update bundle?"
+
+Also fits: post-publish rollout monitoring and regression detection.
+
+Don't use when the user needs per-user crash detail or device-level reporting; this skill only exposes aggregate EAS metrics.
+
+## Prerequisites
+
+- `eas-cli` installed (`npm install -g eas-cli`).
+- Logged in: `eas login`.
+- For `channel:insights`: run from an Expo project directory (the command resolves the project ID from `app.json`). `update:insights` only needs a login.
+
+## Commands at a glance
+
+| Command | Purpose |
+|---|---|
+| `eas update:list` | Discover recent update groups, their `group` IDs, and branch names |
+| `eas update:insights <groupId>` | Per-platform launches, failed launches, crash rate, unique users, payload size, daily breakdown |
+| `eas update:view <groupId> --insights` | Update group details + the same metrics appended |
+| `eas channel:insights --channel <name> --runtime-version <version>` | Embedded/OTA user counts, most popular updates, cumulative metrics for a channel + runtime |
+
+All of these support `--json --non-interactive` for programmatic parsing.
+
+## Discovering IDs
+
+Before querying insights for an update group, you need its `group` ID. Use `eas update:list` with either `--branch <name>` (updates on that branch) or `--all` (updates across all branches). Always pass `--json --non-interactive` when running non-interactively; without a branch/`--all` flag the command will otherwise prompt for a branch selection:
+
+```bash
+# Latest group id across all branches
+eas update:list --all --json --non-interactive | jq -r '.currentPage[0].group'
+
+# Latest group id on a specific branch
+eas update:list --branch production --json --non-interactive | jq -r '.currentPage[0].group'
+```
+
+The JSON response has a `currentPage` array with one entry per update group (both platforms of the same publish are collapsed into one entry):
+
+```json
+{
+  "currentPage": [
+    {
+      "branch": "production",
+      "message": "\"Fix checkout crash\" (1 week ago by someone)",
+      "runtimeVersion": "1.0.6",
+      "group": "03d5dfcf-736c-475a-8730-af039c3f4d06",
+      "platforms": "android, ios",
+      "isRollBackToEmbedded": false
+    }
+  ]
+}
+```
+
+Entries also carry `codeSigningKey` and `rolloutPercentage`, but only when those features are in use for the group (undefined values are omitted from the JSON output).
+
+When called with `--branch <name>`, the response also includes `name` (the branch name) and `id` (the branch ID) at the top level.
+
+## `eas update:insights <groupId>`
+
+Shows launches, failed launches, crash rate, unique users, launch asset count, and average payload size for a single update group, broken down **per platform** (iOS, Android), plus a daily breakdown of launches and failures.
+
+### Basic use
+
+```bash
+eas update:insights 03d5dfcf-736c-475a-8730-af039c3f4d06
+```
+
+### Flags
+
+| Flag | Description |
+|---|---|
+| `--days <N>` | Look back N days. Default: **7**. Mutually exclusive with `--start`/`--end`. |
+| `--start <iso-date>` / `--end <iso-date>` | Explicit time range, e.g. `--start 2026-04-01 --end 2026-04-15`. |
+| `--platform <ios\|android>` | Filter to a single platform. Omit to see all platforms in the group. |
+| `--json` | Machine-readable output. Implies `--non-interactive`. |
+| `--non-interactive` | Required when scripting. |
+
+### JSON output shape
+
+Top level: `groupId`, `timespan` (`start`, `end`, `daysBack`), and `platforms[]` with one entry per platform the group was published to. Each platform entry has `updateId`, `totals` (`uniqueUsers`, `installs`, `failedInstalls`, `crashRatePercent`), `payload` (`launchAssetCount`, `averageUpdatePayloadBytes`), and a `daily[]` time series of `{ date, installs, failedInstalls }`.
+
+For the complete schema and field reference, see [references/update-insights-schema.md](./references/update-insights-schema.md).
+
+Fields that matter for health assessment:
+
+- `platforms[].totals.crashRatePercent`, computed as `failedInstalls / (installs + failedInstalls) * 100`. Zero when there are no installs.
+- `platforms[].totals.installs` and `uniqueUsers` give the adoption signal.
+- `platforms[].daily` is a time series, useful for spotting a sudden spike in failures.
+
+### Errors
+
+- `Could not find any updates with group ID: "<id>"` — group doesn't exist or you lack access.
+- `Update group "<id>" has no ios update (available platforms: android)` — `--platform ios` was used but the group wasn't published for iOS.
+- `EAS Update insights is not supported by this version of eas-cli. Please upgrade ...` — the server deprecated a field the CLI relies on. Run `npm install -g eas-cli@latest`.
+
+## `eas update:view <groupId> --insights`
+
+Extends the standard `update:view` output with the same per-platform insights, inline.
+
+```bash
+# Human-readable
+eas update:view 03d5dfcf-... --insights
+eas update:view 03d5dfcf-... --insights --days 30
+
+# JSON: wrapped as { updates: [...], insights: {...} }
+eas update:view 03d5dfcf-... --json --insights
+```
+
+Without `--insights`, `update:view` behaves exactly as before — no JSON shape change for existing consumers. The `--days` / `--start` / `--end` flags only apply when `--insights` is set; passing them alone errors.
+
+## `eas channel:insights --channel <name> --runtime-version <version>`
+
+Shows, per channel, how many users are on the embedded build vs over-the-air updates and which updates are pulling the most traffic. Must be run from an Expo project directory.
+
+### Basic use
+
+```bash
+eas channel:insights --channel production --runtime-version 1.0.6
+```
+
+### Flags
+
+| Flag | Description |
+|---|---|
+| `--channel <name>` | **Required.** The channel name (e.g. `production`, `staging`). |
+| `--runtime-version <version>` | **Required.** Match exactly what was published. Check `runtimeVersion` values in `update:list`. |
+| `--days <N>` | Look back N days. Default: **7**. |
+| `--start` / `--end` | Explicit time range, like `update:insights`. |
+| `--json` / `--non-interactive` | Machine-readable output. |
+
+### JSON output shape
+
+Top level: `channel`, `runtimeVersion`, `timespan`, `embeddedUpdateTotalUniqueUsers`, `otaTotalUniqueUsers`, `mostPopularUpdates[]` (each with `rank`, `groupId`, `message`, `platform`, `totalUniqueUsers`), `cumulativeMetricsAtLastTimestamp[]`, plus chart-shaped `uniqueUsersOverTime` and `cumulativeMetricsOverTime` objects with `labels` and `datasets`.
+
+For the complete schema and field reference, see [references/channel-insights-schema.md](./references/channel-insights-schema.md).
+
+Fields that matter:
+
+- `embeddedUpdateTotalUniqueUsers` is the count of users running the embedded (binary-bundled) build.
+- `mostPopularUpdates[]` is updates ranked by `totalUniqueUsers`. **Caveat**: this is the top-N the server returns; `otaTotalUniqueUsers` is a sum of that list and may undercount total OTA reach if more than top-N updates are active.
+- `uniqueUsersOverTime` and `cumulativeMetricsOverTime` are daily data series for charting.
+
+### Errors
+
+- `Could not find channel with the name <name>` — typo or wrong account.
+- "No update launches recorded" in the table / empty `mostPopularUpdates` in JSON — no OTA update has been launched for that channel + runtime yet. Usually means the channel is still serving the embedded build only.
+
+## Common workflows
+
+### Verify the update I just published is healthy
+
+```bash
+# 1. Grab the latest publish on production
+GROUP_ID=$(eas update:list --branch production --json --non-interactive \
+  | jq -r '.currentPage[0].group')
+
+# 2. Give it some adoption time (minutes to hours), then check crash rate
+eas update:insights "$GROUP_ID" --json --non-interactive \
+  | jq '.platforms[] | {platform, installs: .totals.installs, crashRate: .totals.crashRatePercent}'
+```
+
+Compare the `crashRate` across platforms and against previous releases; sudden spikes or asymmetric behaviour (iOS spiking while Android is flat, or vice versa) is the signal to investigate.
+
+### Compare adoption between two channels
+
+```bash
+for channel in production staging; do
+  echo "--- $channel ---"
+  eas channel:insights --channel "$channel" --runtime-version 1.0.6 --json --non-interactive \
+    | jq '{
+        channel,
+        embedded: .embeddedUpdateTotalUniqueUsers,
+        ota: .otaTotalUniqueUsers,
+        topUpdate: .mostPopularUpdates[0]
+      }'
+done
+```
+
+### Detect a rollout regression in the last 24 hours
+
+```bash
+eas update:insights "$GROUP_ID" --days 1 --json --non-interactive \
+  | jq '.platforms[] | select(.totals.crashRatePercent > 1)'
+```
+
+### Summarize group metrics for release notes
+
+```bash
+eas update:view "$GROUP_ID" --insights --days 30
+```
+
+Human-readable group details plus 30 days of launches/failures per platform — suitable for pasting into a changelog or incident review.
+
+## Output tips
+
+- Pipe JSON through `jq`; payloads are structured for easy filtering.
+- `--json` implies `--non-interactive`, but passing both is explicit and scripting-friendly.
+- Dates in `daily[].date` are UTC ISO timestamps; the human-readable table renders them as `YYYY-MM-DD` (UTC).
+- The CLI table labels say "Launches" / "Crashes" while JSON uses `installs` / `failedInstalls`. Same field, different display name.
+
+## Limitations
+
+- **Unique users across platforms** may double-count users who run the same publish on both iOS and Android. The same caveat applies to `otaTotalUniqueUsers` in channel insights, which is a sum over `mostPopularUpdates`.
+- **Fresh publishes** may show zeros for a short period while the metrics pipeline catches up.
+- **Installs are downloads, not launches**: the `installs` / "Launches" field counts users who downloaded the manifest and launch asset. A confirmed run only registers on the user's *next* update check (typically up to 24h later, depending on the app's update policy). So metrics lag the real-world state slightly.
+- **Crashes are self-reported**: `failedInstalls` / "Crashes" counts updates that errored during install/launch and were reported on the next update check. Crashes that don't trigger an update request (e.g. process kill before recovery) won't appear.
+
+## 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 "eas-update-insights" "<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.
diff --git a/.agents/skills/eas-update-insights/agents/openai.yaml b/.agents/skills/eas-update-insights/agents/openai.yaml
new file mode 100644
index 0000000..b838395
--- /dev/null
+++ b/.agents/skills/eas-update-insights/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "EAS Update Insights"
+  short_description: "Paid EAS service. Check EAS Update health, adoption, crash rates, launch counts, payload size, and OTA vs embedded usage"
+  default_prompt: "Use $eas-update-insights to inspect published EAS Update with eas-cli, compare rollout health, gather update or channel metrics, parse JSON output, and gate releases on aggregate update performance."
diff --git a/.agents/skills/eas-update-insights/references/channel-insights-schema.md b/.agents/skills/eas-update-insights/references/channel-insights-schema.md
new file mode 100644
index 0000000..204dc75
--- /dev/null
+++ b/.agents/skills/eas-update-insights/references/channel-insights-schema.md
@@ -0,0 +1,47 @@
+# `eas channel:insights` JSON schema
+
+Complete JSON output shape returned by `eas channel:insights --channel <name> --runtime-version <version> --json --non-interactive`.
+
+```json
+{
+  "channel": "production",
+  "runtimeVersion": "1.0.6",
+  "timespan": { "start": "...", "end": "...", "daysBack": 7 },
+  "embeddedUpdateTotalUniqueUsers": 2401,
+  "otaTotalUniqueUsers": 8312,
+  "mostPopularUpdates": [
+    {
+      "rank": 1,
+      "groupId": "abc123",
+      "message": "Fix checkout crash",
+      "platform": "ios",
+      "totalUniqueUsers": 4210
+    }
+  ],
+  "cumulativeMetricsAtLastTimestamp": [
+    { "id": "...", "label": "Embedded update", "data": 12345 },
+    { "id": "...", "label": "Embedded update failed installs", "data": 0 }
+  ],
+  "uniqueUsersOverTime": { "labels": ["..."], "datasets": [ { "id": "...", "label": "...", "data": [100, 200] } ] },
+  "cumulativeMetricsOverTime": { "labels": ["..."], "datasets": [ { "id": "...", "label": "...", "data": [10, 20] } ] }
+}
+```
+
+## Field reference
+
+| Path | Meaning |
+|---|---|
+| `channel` | The channel queried. |
+| `runtimeVersion` | The runtime version filter used. Channel insights are always scoped to a single runtime. |
+| `timespan.start` / `.end` / `.daysBack` | Window bounds (UTC ISO) and size in days. |
+| `embeddedUpdateTotalUniqueUsers` | Distinct users running the embedded (binary-bundled) build in the window. |
+| `otaTotalUniqueUsers` | Sum of `totalUniqueUsers` across `mostPopularUpdates`. May undercount if more than top-N updates are active (see caveat below). |
+| `mostPopularUpdates[]` | Top-N updates ranked by `totalUniqueUsers`. Each entry has `rank`, `groupId`, `message`, `platform`, `totalUniqueUsers`. |
+| `cumulativeMetricsAtLastTimestamp[]` | Snapshot totals at the end of the window, labelled (e.g., "Embedded update", "Embedded update failed installs"). |
+| `uniqueUsersOverTime` | Chart-shaped object with `labels` (dates) and `datasets` for plotting unique users over time. |
+| `cumulativeMetricsOverTime` | Chart-shaped object for plotting cumulative metrics over time. |
+
+## Caveats
+
+- `otaTotalUniqueUsers` is a sum of `mostPopularUpdates[].totalUniqueUsers`. If more OTA updates are active than the top-N the server returns, this figure undercounts true OTA reach.
+- A user running the same publish on both iOS and Android may be counted on each platform. Don't treat `uniqueUsers` as cross-platform-deduped.
diff --git a/.agents/skills/eas-update-insights/references/update-insights-schema.md b/.agents/skills/eas-update-insights/references/update-insights-schema.md
new file mode 100644
index 0000000..9624476
--- /dev/null
+++ b/.agents/skills/eas-update-insights/references/update-insights-schema.md
@@ -0,0 +1,69 @@
+# `eas update:insights` JSON schema
+
+Complete JSON output shape returned by `eas update:insights <groupId> --json --non-interactive`.
+
+```json
+{
+  "groupId": "03d5dfcf-736c-475a-8730-af039c3f4d06",
+  "timespan": {
+    "start": "2026-04-10T00:00:00.000Z",
+    "end": "2026-04-17T00:00:00.000Z",
+    "daysBack": 7
+  },
+  "platforms": [
+    {
+      "platform": "android",
+      "updateId": "019d72ca-...",
+      "totals": {
+        "uniqueUsers": 500,
+        "installs": 990,
+        "failedInstalls": 10,
+        "crashRatePercent": 1.0
+      },
+      "payload": {
+        "launchAssetCount": 4,
+        "averageUpdatePayloadBytes": 1115771
+      },
+      "daily": [
+        { "date": "2026-04-10T00:00:00.000Z", "installs": 182, "failedInstalls": 2 },
+        { "date": "2026-04-11T00:00:00.000Z", "installs": 195, "failedInstalls": 1 }
+      ]
+    },
+    {
+      "platform": "ios",
+      "updateId": "019d72ca-...",
+      "totals": { "uniqueUsers": 100, "installs": 1, "failedInstalls": 0, "crashRatePercent": 0 },
+      "payload": { "launchAssetCount": 4, "averageUpdatePayloadBytes": 1115771 },
+      "daily": [ { "date": "2026-04-10T00:00:00.000Z", "installs": 1, "failedInstalls": 0 } ]
+    }
+  ]
+}
+```
+
+## Field reference
+
+| Path | Meaning |
+|---|---|
+| `groupId` | The update group queried. |
+| `timespan.start` / `.end` | UTC ISO timestamps bounding the window. |
+| `timespan.daysBack` | Convenience field: size of the window in days. |
+| `platforms[]` | One entry per platform the group was published to (`ios`, `android`). |
+| `platforms[].updateId` | Platform-specific update ID (distinct from the group ID). |
+| `platforms[].totals.uniqueUsers` | Distinct users who ran this update in the window. |
+| `platforms[].totals.installs` | Launches / successful installs in the window. |
+| `platforms[].totals.failedInstalls` | Crashes / failed installs in the window. |
+| `platforms[].totals.crashRatePercent` | `failedInstalls / (installs + failedInstalls) * 100`. Zero when no installs. |
+| `platforms[].payload.launchAssetCount` | Number of assets the manifest references. |
+| `platforms[].payload.averageUpdatePayloadBytes` | Mean bundle size for the window. |
+| `platforms[].daily[]` | Per-day time series of installs and failed installs. |
+
+## `eas update:view <groupId> --insights --json`
+
+The `update:view --insights --json` command wraps the same insights payload:
+
+```json
+{
+  "updates": [ /* standard update:view entries */ ],
+  "insights": { /* same shape as eas update:insights above */ }
+}
+```
diff --git a/.agents/skills/eas-workflows/SKILL.md b/.agents/skills/eas-workflows/SKILL.md
new file mode 100644
index 0000000..83c1376
--- /dev/null
+++ b/.agents/skills/eas-workflows/SKILL.md
@@ -0,0 +1,99 @@
+---
+name: eas-workflows
+description: EAS service (paid). Helps understand and write EAS workflow YAML files for Expo projects. Use this skill when the user asks about CI/CD or workflows in an Expo or EAS context, mentions .eas/workflows/, or wants help with EAS build pipelines or deployment automation.
+allowed-tools: "Read,Write,Bash(node:*),Bash(npx *eas-cli@*)"
+version: 1.0.0
+license: MIT License
+---
+
+# EAS Workflows Skill
+
+> **EAS service - costs apply.** EAS Workflows run on Expo Application Services, a paid product with free-tier limits. Each workflow job consumes your plan's build/compute minutes, and jobs that build or submit also need paid Apple Developer and Google Play accounts. Review https://expo.dev/pricing before triggering runs.
+
+Help developers write and edit EAS CI/CD workflow YAML files.
+
+## Reference Documentation
+
+Fetch these resources before generating or editing workflow files, or when answering syntax questions. First resolve this skill's directory, then use the fetch script in its `scripts/` directory. It is implemented using Node.js and caches responses using ETags for efficiency:
+
+```bash
+# Fetch resources
+node <skill-dir>/scripts/fetch.js <url>
+```
+
+1. **JSON Schema** — https://api.expo.dev/v2/workflows/schema
+   - It is NECESSARY to fetch this schema
+   - Source of truth for the workflow YAML structure; EAS CLI remains the authoritative final validator
+   - All job types and their required/optional parameters
+   - Trigger types and configurations
+   - Runner types, VM images, and all enums
+
+2. **Syntax Documentation** — https://raw.githubusercontent.com/expo/expo/refs/heads/main/docs/pages/eas/workflows/syntax.mdx
+   - Overview of workflow YAML syntax
+   - Examples and English explanations
+   - Expression syntax and contexts
+
+3. **Pre-packaged Jobs** — https://raw.githubusercontent.com/expo/expo/refs/heads/main/docs/pages/eas/workflows/pre-packaged-jobs.mdx
+   - Documentation for supported pre-packaged job types
+   - Job-specific parameters and outputs
+
+Do not rely on memorized values; these resources evolve as new features are added.
+
+## Workflow File Location
+
+Workflows live in `.eas/workflows/*.yml` (or `.yaml`). Each file must be 16 KiB or smaller.
+
+## Top-Level Structure
+
+A workflow file has these top-level keys:
+
+- `name` — Display name for the workflow
+- `on` — Triggers that start the workflow (at least one required)
+- `jobs` — Job definitions (required)
+- `defaults` — Shared defaults for all jobs
+- `concurrency` — Control parallel workflow runs
+
+Consult the schema for the full specification of each section.
+
+## Expressions
+
+Use `${{ }}` syntax for dynamic values. The schema defines available contexts:
+
+- `github.*` — GitHub repository and event information
+- `inputs.*` — Values from `workflow_dispatch` inputs
+- `needs.*` — Outputs and status from dependent jobs
+- `jobs.*` — Job outputs (alternative syntax)
+- `steps.*` — Step outputs within custom jobs
+- `workflow.*` — Workflow metadata
+
+## Generating Workflows
+
+When generating or editing workflows:
+
+1. Fetch the schema to get current job types, parameters, and allowed values
+2. Validate that required fields are present for each job type
+3. Verify job references in `needs` and `after` exist in the workflow
+4. Check that expressions reference valid contexts and outputs
+5. Ensure `if` conditions respect the schema's length constraints
+
+## Validation
+
+After generating or editing a workflow file, validate it with EAS CLI from the Expo project root:
+
+```sh
+npx -y eas-cli@latest workflow:validate .eas/workflows/<workflow.yml> --non-interactive
+```
+
+Run the command separately for each changed workflow file. It requires a logged-in EAS CLI session and a linked Expo project. Unlike schema-only validation, it also checks build profile references against the project's `eas.json` and performs EAS server-side validation. Fix every reported error and rerun the command until it prints `Workflow configuration YAML is valid.` Do not replace this command with a local YAML or JSON Schema validator.
+
+## Answering Questions
+
+When users ask about available options (job types, triggers, runner types, etc.), fetch the schema and derive the answer from it rather than relying on potentially outdated information.
+
+## 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 "eas-workflows" "<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.
diff --git a/.agents/skills/eas-workflows/agents/openai.yaml b/.agents/skills/eas-workflows/agents/openai.yaml
new file mode 100644
index 0000000..2b280ec
--- /dev/null
+++ b/.agents/skills/eas-workflows/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "EAS Workflows"
+  short_description: "Paid EAS service. Write and validate EAS workflow YAML files for Expo projects"
+  default_prompt: "Use $eas-workflows when creating or editing .eas/workflows YAML, validating EAS workflow configuration, or answering questions about workflow triggers, jobs, runners, and expressions."
diff --git a/.agents/skills/eas-workflows/scripts/fetch.js b/.agents/skills/eas-workflows/scripts/fetch.js
new file mode 100644
index 0000000..466bfc7
--- /dev/null
+++ b/.agents/skills/eas-workflows/scripts/fetch.js
@@ -0,0 +1,109 @@
+#!/usr/bin/env node
+
+import { createHash } from 'node:crypto';
+import { readFile, writeFile, mkdir } from 'node:fs/promises';
+import { resolve } from 'node:path';
+import process from 'node:process';
+
+const CACHE_DIRECTORY = resolve(import.meta.dirname, '.cache');
+const DEFAULT_TTL_SECONDS = 15 * 60; // 15 minutes
+
+export async function fetchCached(url) {
+  await mkdir(CACHE_DIRECTORY, { recursive: true });
+
+  const cacheFile = resolve(CACHE_DIRECTORY, hashUrl(url) + '.json');
+  const cached = await loadCacheEntry(cacheFile);
+  if (cached && cached.expires > Math.floor(Date.now() / 1000)) {
+    return cached.data;
+  }
+
+  // Make request, with conditional If-None-Match if we have an ETag.
+  // Cache-Control: max-age=0 overrides Node's default 'no-cache' to allow 304 responses.
+  const response = await fetch(url, {
+    headers: {
+      'Cache-Control': 'max-age=0',
+      ...(cached?.etag && { 'If-None-Match': cached.etag }),
+    },
+  });
+
+  if (response.status === 304 && cached) {
+    // Refresh expiration and return cached data
+    const entry = { ...cached, expires: getExpires(response.headers) };
+    await saveCacheEntry(cacheFile, entry);
+    return cached.data;
+  }
+
+  if (!response.ok) {
+    throw new Error(`HTTP ${response.status}: ${response.statusText}`);
+  }
+
+  const etag = response.headers.get('etag');
+  const data = await response.text();
+  const expires = getExpires(response.headers);
+
+  await saveCacheEntry(cacheFile, { url, etag, expires, data });
+
+  return data;
+}
+
+function hashUrl(url) {
+  return createHash('sha256').update(url).digest('hex').slice(0, 16);
+}
+
+async function loadCacheEntry(cacheFile) {
+  try {
+    return JSON.parse(await readFile(cacheFile, 'utf-8'));
+  } catch {
+    return null;
+  }
+}
+
+async function saveCacheEntry(cacheFile, entry) {
+  await writeFile(cacheFile, JSON.stringify(entry, null, 2));
+}
+
+function getExpires(headers) {
+  const now = Math.floor(Date.now() / 1000);
+
+  // Prefer Cache-Control: max-age
+  const maxAgeSeconds = parseMaxAge(headers.get('cache-control'));
+  if (maxAgeSeconds != null) {
+    return now + maxAgeSeconds;
+  }
+
+  // Fall back to Expires header
+  const expires = headers.get('expires');
+  if (expires) {
+    const expiresTime = Date.parse(expires);
+    if (!Number.isNaN(expiresTime)) {
+      return Math.floor(expiresTime / 1000);
+    }
+  }
+
+  // Default TTL
+  return now + DEFAULT_TTL_SECONDS;
+}
+
+function parseMaxAge(cacheControl) {
+  if (!cacheControl) {
+    return null;
+  }
+  const match = cacheControl.match(/max-age=(\d+)/i);
+  return match ? parseInt(match[1], 10) : null;
+}
+
+if (import.meta.main) {
+  const url = process.argv[2];
+
+  if (!url || url === '--help' || url === '-h') {
+    console.log(`Usage: fetch <url>
+
+Fetches a URL with HTTP caching (ETags + Cache-Control/Expires).
+Default TTL: ${DEFAULT_TTL_SECONDS / 60} minutes.
+Cache is stored in: ${CACHE_DIRECTORY}/`);
+    process.exit(url ? 0 : 1);
+  }
+
+  const data = await fetchCached(url);
+  console.log(data);
+}
diff --git a/.agents/skills/eas-workflows/scripts/package.json b/.agents/skills/eas-workflows/scripts/package.json
new file mode 100644
index 0000000..bbea404
--- /dev/null
+++ b/.agents/skills/eas-workflows/scripts/package.json
@@ -0,0 +1,6 @@
+{
+  "name": "@expo/eas-workflows-skill",
+  "version": "0.0.0",
+  "private": true,
+  "type": "module"
+}
diff --git a/.agents/skills/expo-animation/LICENSE b/.agents/skills/expo-animation/LICENSE
new file mode 100644
index 0000000..57b46f1
--- /dev/null
+++ b/.agents/skills/expo-animation/LICENSE
@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Emil Kowalski
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/.agents/skills/expo-animation/RECIPES.md b/.agents/skills/expo-animation/RECIPES.md
new file mode 100644
index 0000000..a02e6b8
--- /dev/null
+++ b/.agents/skills/expo-animation/RECIPES.md
@@ -0,0 +1,385 @@
+# Expo Animation Recipes
+
+Ready-to-build implementations for the cases that come up most in a React Native app. Start from the recipe, then adapt.
+
+---
+
+## Setup the recipes assume
+
+```bash
+npx expo install react-native-reanimated react-native-worklets react-native-gesture-handler expo-haptics
+```
+
+(`react-native-keyboard-controller` only for the keyboard recipe.) `expo install`, not `npm install` — it resolves the versions that match the SDK. The worklets Babel plugin is configured by `babel-preset-expo` automatically.
+
+`GestureHandlerRootView` wraps the app once — in Expo Router, the root `_layout`:
+
+```jsx
+import { GestureHandlerRootView } from 'react-native-gesture-handler';
+
+export default function RootLayout() {
+  return (
+    <GestureHandlerRootView style={{ flex: 1 }}>
+      <Stack />
+    </GestureHandlerRootView>
+  );
+}
+```
+
+Imports and constants every recipe below shares:
+
+```js
+import { useState, useEffect, useMemo } from 'react';
+import Animated, {
+  useSharedValue, useAnimatedStyle, useAnimatedScrollHandler, useAnimatedReaction,
+  withSpring, withTiming, interpolate, Extrapolation, Easing,
+  FadeInDown, FadeOutDown, LinearTransition,
+} from 'react-native-reanimated';
+import { Gesture, GestureDetector } from 'react-native-gesture-handler';
+import { scheduleOnRN } from 'react-native-worklets';
+import * as Haptics from 'expo-haptics';
+
+const EASE_OUT = Easing.bezier(0.23, 1, 0.32, 1);      // strong ease-out for UI
+const EASE_IN_OUT = Easing.bezier(0.77, 0, 0.175, 1);  // on-screen movement
+const EASE_SHEET = Easing.bezier(0.32, 0.72, 0, 1);    // iOS sheet curve
+```
+
+Three conventions, explained once here instead of in every recipe:
+
+- **Shared values are read and written with `.get()` / `.set()`**, the form the Reanimated docs recommend for React Compiler support. `.value` still works, but the compiler can't see through it.
+- **`scheduleOnRN(fn, ...args)` replaces the deprecated `runOnJS(fn)(...args)`** for calling back to the React Native runtime from a worklet.
+- **Gestures are wrapped in `useMemo`.** Rebuilding a gesture on every render can reattach the recognizer and drop a drag that's mid-flight.
+
+**Gesture Handler v3:** Expo installs v2, and the recipes use its `Gesture.Pan()` builder. If the project is already on v3, the builder is legacy — each gesture is a hook taking one config object, with `onStart` → `onActivate`, `onEnd` → `onDeactivate`, and the `success` flag replaced by `event.canceled` (inverted). The hook manages its own identity, so drop the `useMemo`:
+
+```jsx
+const pan = usePanGesture({
+  activeOffsetY: [-10, 10],
+  onActivate: () => { context.set(translateY.get()); },
+  onUpdate: (e) => { translateY.set(context.get() + e.translationY); },
+  onDeactivate: (e) => { /* settle with withSpring as below */ },
+});
+```
+
+---
+
+## Two worklets you'll need everywhere
+
+Momentum projection decides *where a flick was going*, so a fast short swipe commits and a slow long one doesn't. Rubber-banding makes a boundary resist instead of stopping dead.
+
+```js
+// Where the finger would come to rest if it kept decelerating.
+// Apple's exponential-decay form — not the v²/2a from physics class.
+function project(velocity, decelerationRate = 0.998) {
+  'worklet';
+  return ((velocity / 1000) * decelerationRate) / (1 - decelerationRate);
+}
+
+// The further past the edge, the less the element follows.
+function rubberband(overshoot, dimension, constant = 0.55) {
+  'worklet';
+  return (overshoot * dimension * constant) / (dimension + constant * Math.abs(overshoot));
+}
+```
+
+---
+
+## Press feedback
+
+Every pressable in the app. This passes the frequency gate only because it's near-imperceptible: 120ms and a 3% scale is the ceiling for something touched this often — anything longer or larger belongs to rarer moments, per step 1 in SKILL.md. No gesture, no shared value — a CSS transition is the whole implementation.
+
+```jsx
+import Animated from 'react-native-reanimated';
+import { Pressable, StyleSheet } from 'react-native';
+
+function PressableScale({ onPress, children }) {
+  const [pressed, setPressed] = useState(false);
+  return (
+    <Pressable
+      onPress={onPress}
+      onPressIn={() => setPressed(true)}
+      onPressOut={() => setPressed(false)}
+      hitSlop={12}
+      pressRetentionOffset={16}
+    >
+      <Animated.View style={[styles.box, pressed && styles.pressed]}>{children}</Animated.View>
+    </Pressable>
+  );
+}
+
+const styles = StyleSheet.create({
+  box: {
+    transform: [{ scale: 1 }],
+    transitionProperty: 'transform',
+    transitionDuration: '120ms',
+    transitionTimingFunction: 'cubic-bezier(0.23, 1, 0.32, 1)',
+  },
+  pressed: { transform: [{ scale: 0.97 }] },
+});
+```
+
+`setState` is fine here — it fires twice per press, not per frame. `hitSlop` brings a small icon up to the 44pt target without growing it; `pressRetentionOffset` stops a slight finger drift from cancelling.
+
+---
+
+## Bottom sheet you can drag to dismiss
+
+Before writing this: if the sheet is its own destination, use `presentation: 'formSheet'` (see **Screen transitions**) and get the platform's real sheet for free. Build this only when the sheet has to live inside an existing screen.
+
+```jsx
+const translateY = useSharedValue(0);
+const context = useSharedValue(0);
+
+const pan = useMemo(() => Gesture.Pan()
+  .activeOffsetY([-10, 10])   // let a horizontal swipe win; require intent before committing
+  .onStart(() => {
+    context.set(translateY.get());   // start from the current on-screen value, not from 0
+  })
+  .onUpdate((e) => {
+    const next = context.get() + e.translationY;
+    // downward is free; upward past the top resists
+    translateY.set(next >= 0 ? next : rubberband(next, HEIGHT));
+  })
+  .onEnd((e) => {
+    const projected = translateY.get() + project(e.velocityY);
+    if (projected > HEIGHT * 0.4) {
+      translateY.set(withSpring(HEIGHT, {
+        duration: 300, dampingRatio: 1, velocity: e.velocityY, overshootClamping: true,
+      }, (finished) => { if (finished) scheduleOnRN(onClose); }));
+    } else {
+      translateY.set(withSpring(0, { duration: 300, dampingRatio: 0.8, velocity: e.velocityY }));
+      scheduleOnRN(Haptics.impactAsync, Haptics.ImpactFeedbackStyle.Light);   // it snapped home
+    }
+  }), [onClose]);
+
+const sheetStyle = useAnimatedStyle(() => ({ transform: [{ translateY: translateY.get() }] }));
+```
+
+The four details that separate this from a bad drag:
+
+- **`onStart` captures the current value.** Without it, grabbing a sheet mid-animation teleports it — the animation must continue from where the eye last saw it.
+- **Velocity decides, not distance.** `project()` means a quick flick dismisses even a few pixels down. Requiring 40% travel makes the sheet feel heavy.
+- **Velocity is handed to the spring**, so there's no seam between the finger releasing and the animation continuing. This is the single detail that most separates "fluid" from "fine".
+- **`overshootClamping` on dismissal** — otherwise the sheet springs past the bottom of the screen and flashes a gap.
+
+The backdrop derives from the same value, so it's always in sync and costs nothing:
+
+```jsx
+const backdropStyle = useAnimatedStyle(() => ({
+  opacity: interpolate(translateY.get(), [0, HEIGHT], [1, 0], Extrapolation.CLAMP),
+}));
+```
+
+---
+
+## Swipe to delete a row
+
+Before writing this: gesture-handler ships [`ReanimatedSwipeable`](https://docs.swmansion.com/react-native-gesture-handler/docs/components/reanimated_swipeable/), which already does swipe-to-reveal actions — thresholds, overshoot, open/close methods — on the UI thread. Reach for it when the row reveals action buttons. Build the gesture yourself only when the interaction is different in kind: swipe-to-commit with momentum projection, like this one.
+
+```jsx
+const x = useSharedValue(0);
+const context = useSharedValue(0);
+
+const pan = useMemo(() => Gesture.Pan()
+  .activeOffsetX([-10, 10])   // must declare the axis, or it fights the vertical scroll
+  .onStart(() => { context.set(x.get()); })   // grab mid-spring continues from where the row is, not from 0
+  .onUpdate((e) => { x.set(Math.min(0, context.get() + e.translationX)); })
+  .onEnd((e) => {
+    const projected = x.get() + project(e.velocityX);
+    if (projected < -SWIPE_THRESHOLD) {
+      x.set(withTiming(-WIDTH, { duration: 200, easing: EASE_OUT }, (f) => {
+        if (f) scheduleOnRN(onDelete, id);
+      }));
+    } else {
+      x.set(withSpring(0, { duration: 300, dampingRatio: 1, velocity: e.velocityX }));
+    }
+  }), [onDelete, id]);
+```
+
+Closing the gap the deleted row left is the list's job, not the row's:
+
+```jsx
+const ROW_CLOSE = LinearTransition.duration(200);   // module scope — builders rebuilt in render cost every re-render
+
+<Animated.FlatList data={items} itemLayoutAnimation={ROW_CLOSE} ... />
+```
+
+`activeOffsetX` is the mobile-specific part. A pan handler inside a scroll view with no axis declared will steal vertical scrolls, and the list will feel broken in a way that looks like a scrolling bug rather than a gesture bug.
+
+---
+
+## Collapsing header on scroll
+
+```jsx
+const scrollY = useSharedValue(0);
+const onScroll = useAnimatedScrollHandler((e) => { scrollY.set(e.contentOffset.y); });
+
+const titleStyle = useAnimatedStyle(() => ({
+  opacity: interpolate(scrollY.get(), [0, 60], [1, 0], Extrapolation.CLAMP),
+  transform: [{ translateY: interpolate(scrollY.get(), [0, 60], [0, -12], Extrapolation.CLAMP) }],
+}));
+
+<Animated.ScrollView onScroll={onScroll} scrollEventThrottle={16}>
+```
+
+**Never animate the header's `height` to collapse it.** That runs a layout pass on the header and everything below it on every scroll frame — the one animation guaranteed to stutter, because it's competing with the scroll itself. Give the container a fixed height and translate the content inside it, clipping with `overflow: 'hidden'`.
+
+`Extrapolation.CLAMP` is not optional: without it, scrolling past 60 keeps driving opacity negative and the header reappears inverted at the bottom of a long list.
+
+---
+
+## List entrances
+
+```jsx
+// The Reanimated docs recommend building layout animations outside components,
+// or in useMemo — an inline chain in JSX rebuilds the builder on every render.
+// A per-index delay can't live at module scope, so the row memoizes its own:
+function Row({ item, index }) {
+  const entering = useMemo(() => FadeInDown.duration(250).delay(index * 40), [index]);
+  return <Animated.View entering={entering}>{/* ... */}</Animated.View>;
+}
+
+{items.map((item, i) => <Row key={item.id} item={item} index={i} />)}
+```
+
+Stagger 30–80ms. Longer feels slow, shorter reads as simultaneous.
+
+**Never put `entering` on a row inside `FlatList`, `FlashList`, or any virtualized list.** Rows are recycled, so the animation re-fires every time one scrolls back into view — the list appears to flicker while the user scrolls. Animate the list container once on mount, or use `itemLayoutAnimation` for reflow only.
+
+Entrance animations are for content the user asked for and is waiting on. A list they scroll past all day should already be there.
+
+---
+
+## Keyboard-synced UI
+
+Needs its own module and a one-time provider ([Expo keyboard guide](https://docs.expo.dev/guides/keyboard-handling/)):
+
+```bash
+npx expo install react-native-keyboard-controller
+```
+
+```jsx
+import { KeyboardProvider } from 'react-native-keyboard-controller';
+
+// Root _layout, next to GestureHandlerRootView — hooks below do nothing without it.
+<KeyboardProvider>
+  <Stack />
+</KeyboardProvider>
+```
+
+```jsx
+import { useReanimatedKeyboardAnimation } from 'react-native-keyboard-controller';
+
+const { height } = useReanimatedKeyboardAnimation();   // 0 → -keyboardHeight, on the UI thread
+const footerStyle = useAnimatedStyle(() => ({ transform: [{ translateY: height.get() }] }));
+```
+
+Never build this from `Keyboard.addListener` plus a timing animation. The keyboard rides a private system curve, the event arrives on the JS thread after the keyboard has already started moving, and any duration you pick will visibly lag or lead it. The UI must be driven by the keyboard's actual position, frame by frame.
+
+---
+
+## Tab / segmented indicator
+
+Measure once, then animate transforms.
+
+```jsx
+const [layouts, setLayouts] = useState({});   // measured with onLayout, not per frame
+const x = useSharedValue(0);
+const w = useSharedValue(0);
+
+useEffect(() => {
+  const l = layouts[active];
+  if (!l) return;
+  x.set(withTiming(l.x, { duration: 250, easing: EASE_IN_OUT }));
+  w.set(withTiming(l.width, { duration: 250, easing: EASE_IN_OUT }));
+}, [active, layouts]);
+
+const pillStyle = useAnimatedStyle(() => ({
+  transform: [{ translateX: x.get() }],
+  width: w.get(),
+}));
+```
+
+This is the sanctioned `width` animation: the pill is absolutely positioned with no children, so nothing else re-lays-out, and its corner radius survives — `scaleX` would smear the corners into ovals.
+
+`ease-in-out`, because the pill is moving across the screen rather than entering or leaving it. Fire `Haptics.selectionAsync()` on the press, not when the pill lands.
+
+---
+
+## Screen transitions (Expo Router)
+
+Configure the native stack. Never rebuild a screen transition in JS: the native one runs on the platform side, keeps the interactive back gesture, and matches every other app on the device.
+
+```jsx
+<Stack screenOptions={{ animation: reduced ? 'fade' : 'default' }}>
+  <Stack.Screen name="settings" options={{ animation: 'slide_from_right', animationMatchesGesture: true }} />
+  <Stack.Screen name="compose" options={{ presentation: 'modal' }} />
+  <Stack.Screen name="filter" options={{
+    presentation: 'formSheet',
+    sheetAllowedDetents: 'fitToContents',
+    sheetGrabberVisible: true,
+  }} />
+</Stack>
+```
+
+| Navigation | Option |
+| --- | --- |
+| Deeper into a hierarchy | `animation: 'default'` — the platform push, unmodified |
+| A self-contained task the user can abandon | `presentation: 'modal'` |
+| A short interruption: picker, filter, share | `presentation: 'formSheet'` with detents |
+| Between tabs | `animation: 'none'` |
+| Reduced motion | `animation: 'fade'` |
+
+`animationMatchesGesture: true` makes the iOS back swipe run your transition in reverse under the finger, instead of the default push. Set it whenever you set a custom `animation`, or dragging back looks like a different app than pushing forward.
+
+`formSheet` is native on both platforms, but not the same on both — the [Expo modal docs](https://docs.expo.dev/router/advanced/modals/#form-sheet-presentation) have the full list:
+
+- **Android caps detents at three.** A longer `sheetAllowedDetents` array works on iOS and silently truncates on Android — design for three.
+- **`sheetGrabberVisible` is iOS-only.** Android shows no grabber; don't rely on it as the only "this is draggable" affordance.
+- **Android form sheets can't host native headers or nested stacks.** Keep the sheet's content a single screen; if it needs its own navigation, use `presentation: 'modal'` instead.
+- **`fitToContents` needs explicitly sized content.** A `flex: 1` root has no intrinsic height to fit — size the content, or the detent is wrong.
+
+---
+
+## Toast
+
+```jsx
+// Module scope — layout-animation builders live outside the component.
+const TOAST_ENTER = FadeInDown.duration(300).easing(EASE_OUT);
+const TOAST_EXIT = FadeOutDown.duration(250).easing(EASE_OUT);
+
+<Animated.View
+  entering={TOAST_ENTER}
+  exiting={TOAST_EXIT}
+  style={{ position: 'absolute', bottom: insets.bottom + 16, left: 16, right: 16 }}
+/>
+```
+
+- **The 300ms cap holds here too.** A toast isn't an exception — it's uninvited, so if anything it should be quicker and quieter than motion the user asked for.
+- **It exits the way it entered.** Entering from the bottom and leaving to the side reads as two unrelated elements.
+- **Exit ~20% faster than entry.** The user has finished reading; the arrival deserves the time, the departure doesn't.
+- **Safe area insets, always.** A toast at `bottom: 16` sits under the home indicator on every modern iPhone.
+
+If toasts stack and the list reflows, add `itemLayoutAnimation` and expect to tune the opacity against the reflow by eye — there's no formula for that pair. Look at it again the next day.
+
+---
+
+## Firing something once at a threshold
+
+When a crossing point matters — a detent, a snap, a pull-to-refresh arming — don't poll it from JS and don't `scheduleOnRN` every frame.
+
+```jsx
+const armed = useSharedValue(false);
+
+useAnimatedReaction(
+  () => pullDistance.get() > REFRESH_THRESHOLD,
+  (isArmed, wasArmed) => {
+    if (isArmed !== wasArmed) {
+      armed.set(isArmed);
+      scheduleOnRN(Haptics.impactAsync, Haptics.ImpactFeedbackStyle.Light);
+    }
+  }
+);
+```
+
+The comparison runs on the UI thread every frame; the JS call happens twice per pull. That's the pattern for every "do something when the animation reaches X".
diff --git a/.agents/skills/expo-animation/SKILL.md b/.agents/skills/expo-animation/SKILL.md
new file mode 100644
index 0000000..7b81e5c
--- /dev/null
+++ b/.agents/skills/expo-animation/SKILL.md
@@ -0,0 +1,267 @@
+---
+name: expo-animation
+description: Framework (OSS). Build animations in React Native and Expo, making the decisions in the order that determines whether they feel right — should it animate, which thread it runs on, which properties, spring or timing, how the gesture hands off, how it degrades. Writes the implementation with Reanimated, Gesture Handler, Expo Router and expo-haptics. Use when animating anything in an Expo app, adding gestures, sheets, screen transitions, press feedback or haptics, or fixing motion that stutters on device. For web animation use `animate`.
+version: 1.0.0
+license: MIT
+---
+
+# Building Animations in Expo
+
+This skill was created in collaboration with [Emil Kowalski](https://github.com/emilkowalski) and can also be found in the [emilkowalski/skills](https://github.com/emilkowalski/skills) repository, along with other useful animation skills.
+
+A construction skill for React Native. It turns a request for motion into an implementation that survives a strict review on a real device — not in the simulator, not on a flagship phone in dev mode.
+
+Mobile changes three things about animation, and everything in this skill follows from them:
+
+1. **There is no hover.** Every affordance the web puts in hover has to live in press, position, or nothing.
+2. **There are two runtimes.** Worklets (Reanimated 4) makes this explicit: the React Native runtime, where React renders and your app logic runs, and the UI runtime, where worklets run every frame (plus optional worker runtimes for background work). An animation that touches the RN runtime stutters the moment the app does anything else. The whole craft is keeping motion on the UI runtime.
+3. **The user's finger is on the element.** Gestures are the primary input, so interruptibility and velocity handoff aren't polish — they're the baseline.
+
+## Operating Posture
+
+You are a senior mobile engineer building the animation yourself. Make the call, state the reasoning in one line, write the code. Never present motion options as a menu.
+
+Two failure modes, and the first is worse:
+
+1. **Animating something that shouldn't animate.** The gate below exists to produce zero lines of code sometimes.
+2. **Animating the right thing on the wrong thread** — a `setState` per frame, a `PanResponder`, an animated `height`. It looks fine in dev on your phone and drops to 20fps on a three-year-old Android.
+
+## Hard Rules
+
+1. **Run the sequence in order.** Steps 1 and 2 gate everything.
+2. **Reanimated, not core `Animated`.** Core `Animated` can't be driven by a gesture without crossing the bridge, and `useNativeDriver` refuses anything but transform and opacity anyway. Reanimated worklets run on the UI thread and keep running while JS is busy.
+3. **No approximated values.** Curves and spring configs come from the tables below.
+4. **Reduced motion ships with the animation**, not as a follow-up.
+5. **Feel is judged on a release build on the slowest device you support.** Nothing else counts as verified.
+
+## The Build Sequence
+
+### 1. Should this animate at all?
+
+| Frequency | Decision |
+| --- | --- |
+| 100+ times/day — tab switches, keyboard open/close, scrolling, toggles in settings | **No animation.** Platform default or nothing. Stop here. |
+| Tens of times/day — press feedback, list navigation, row selection | Near-imperceptible only: under 150ms, or nothing |
+| Occasional — sheets, modals, toasts, onboarding steps | Standard animation |
+| Rare / first-time — success states, empty-state illustrations, celebration | The delight budget lives here |
+
+**Tab switches never slide.** Tabs are peers, not a hierarchy — sliding implies depth that isn't there, and the user pays for it dozens of times a session. `animation: 'none'`.
+
+If the request fails this gate, say so and don't write it.
+
+### 2. What is the purpose?
+
+Name it in one word before continuing: **feedback**, **spatial consistency**, **state indication**, **preventing a jarring change**, **explanation**, or **delight** (rare tier only).
+
+Can't name it? Don't build it.
+
+### 3. Pick the tool — cheapest that works
+
+Walk down; stop at the first that fits.
+
+| Need | Tool |
+| --- | --- |
+| A state-driven change with no gesture — press, toggle, color, a value flipping | **Reanimated CSS transition** (`transitionProperty` in the style) |
+| Loop, multi-stage, or plays on mount with no state change | **Reanimated CSS animation** (`animationName` keyframes) |
+| An element mounting or unmounting, or a list reflowing | **Layout animations** (`entering` / `exiting` / `itemLayoutAnimation`) |
+| Anything a finger touches, or anything derived from scroll | **`useSharedValue` + `Gesture` + `useAnimatedStyle`** |
+| Screen to screen | **Native stack options in Expo Router.** Never hand-roll this |
+| A bottom sheet that is its own screen | **`presentation: 'formSheet'`** — it's a real UISheetPresentationController, free and correct |
+| Tab bar | **`NativeTabs`** (from `expo-router/unstable-native-tabs`) — the platform's real tab bar, its behaviors and transitions included |
+| Context menu, press-and-hold preview | **`Link.Menu` / `Link.Preview`** (Expo Router, iOS-only) — native menus and peek, never rebuilt in JS |
+| Header that collapses into a large title | **`headerLargeTitleEnabled`** on the native stack (iOS-only; `headerLargeTitle` is deprecated) — not a scroll worklet |
+| Pull to refresh | **`RefreshControl`** — hand-roll only when it's a signature interaction (see the threshold recipe) |
+| UI that tracks the keyboard | **`react-native-keyboard-controller`** — the keyboard's real position, frame by frame, on the UI thread |
+| Vector illustration, celebration, empty state | **Lottie** — for illustration only, never for UI state |
+| A huge animated scene, freeform drawing | **`@shopify/react-native-skia`** — a canvas, for when the view hierarchy itself is the bottleneck |
+
+Reach for a shared value only when the value is continuous or interruptible. A press scale is a CSS transition; a drag is a shared value. Using a worklet for a two-state toggle is the mobile equivalent of installing a motion library for a fade.
+
+**Dependencies.** Install with `npx expo install <package>` — it resolves the version that matches the project's SDK, which plain `npm install` won't:
+
+| Need | Package |
+| --- | --- |
+| Animation | `react-native-reanimated` + `react-native-worklets` |
+| Gestures | `react-native-gesture-handler` |
+| Navigation, sheets, native tabs, menus | `expo-router` |
+| Haptics | `expo-haptics` |
+| Keyboard-following UI | `react-native-keyboard-controller` (needs `KeyboardProvider` at the root — see the keyboard recipe) |
+| Illustration, celebration | `lottie-react-native` |
+| Very large animated scenes, custom drawing | `@shopify/react-native-skia` |
+
+### 4. Pick the properties
+
+- **`transform` and `opacity` are free.** Everything else is a layout pass. `width`, `height`, `margin`, `padding`, `flex`, `top`, `left`, `gap` re-run Yoga on every frame for that node *and its siblings*.
+- **The one exception: an absolutely positioned element with no children** — a tab pill, a progress bar fill. It's out of flow, so nothing else re-lays-out, and animating `width` keeps the corner radius that `scaleX` would smear.
+- **Never `scale(0)`.** Start from `scale(0.9–0.97)` + `opacity: 0`. Nothing in the real world appears from nothing.
+- **`transform` is an array and order matters** — `[{ translateY }, { scale }]` scales after moving; reversed, the translate gets scaled too. Keep translate first unless you want the multiplication.
+- **Android shadows are `elevation`, and animating elevation re-renders the shadow every frame.** Animate opacity of a pre-shadowed layer instead.
+- **Never animate `BlurView` intensity.** On Android it re-renders the blur each frame. Crossfade the opacity of a static `BlurView` instead.
+- **Percentages work in `translate`** and are relative to the element's own size — `translateY('100%')` moves a sheet by its own height whatever its content.
+
+### 5. Timing or spring
+
+**If a finger was involved, use a spring.** Springs carry velocity through an interruption; timing curves restart. Everything else uses timing.
+
+Reanimated's spring takes Apple's two designer parameters directly — use this form, not mass/stiffness/damping:
+
+| Interaction | Config |
+| --- | --- |
+| Default settle, no overshoot | `{ duration: 400, dampingRatio: 1 }` |
+| Reposition / snap back after a drag | `{ duration: 400, dampingRatio: 0.8, velocity }` |
+| Sheet, drawer | `{ duration: 300, dampingRatio: 0.8, velocity }` |
+| Must not pass a hard edge | add `overshootClamping: true` |
+
+**Bounce only when the gesture carried momentum.** Overshoot on a menu that faded in feels wrong; overshoot on a card you flicked feels right.
+
+**Easing**, for everything without a finger on it:
+
+| Situation | Easing |
+| --- | --- |
+| Entering or exiting | `ease-out` |
+| Moving / morphing on screen | `ease-in-out` |
+| Constant motion (progress, marquee) | `linear` |
+| Default | `ease-out` |
+
+**Never `ease-in` on UI.** It starts slow, delaying the exact moment the user is watching. Reanimated's built-ins are as weak as CSS's — use these:
+
+```js
+import { Easing } from 'react-native-reanimated';
+
+const EASE_OUT = Easing.bezier(0.23, 1, 0.32, 1);      // strong ease-out for UI
+const EASE_IN_OUT = Easing.bezier(0.77, 0, 0.175, 1);  // on-screen movement
+const EASE_SHEET = Easing.bezier(0.32, 0.72, 0, 1);    // iOS sheet curve
+```
+
+**Duration:**
+
+| Element | Duration |
+| --- | --- |
+| Press feedback | 100–150ms |
+| Toggle, chip, small state change | 150–200ms |
+| Sheet, modal, drawer | spring, ~300ms perceived |
+| Screen transition | the platform default — don't override it |
+
+Mobile UI animations stay under 300ms, same as web. The platform's own transitions are longer (iOS push is 350ms); match the platform for navigation, beat it everywhere else.
+
+### 6. Keep it off the JS thread
+
+This is the mobile-specific craft, and it's where most React Native motion dies.
+
+- **Never `setState` from a gesture or scroll handler.** One React render per frame is the single biggest cause of jank in RN apps. Shared value → `useAnimatedStyle`, and React never re-renders at all.
+- **Never schedule back to the RN runtime inside `onUpdate` or a scroll handler.** `scheduleOnRN(fn, ...args)` from `react-native-worklets` — the Reanimated 4 replacement for the deprecated `runOnJS(fn)(...args)` — queues an RN-runtime call, and in `onUpdate` that's 60–120× per second. It belongs in `onEnd`, or in a `useAnimatedReaction` that fires when a value crosses a threshold.
+- **Never read a shared value during render** (`translateY.get()` in JSX). It's a snapshot that never updates and it silently desyncs. **Never write one during render either** — it fires mid-reconciliation, and a re-render you didn't cause replays the write. Touch shared values only in worklets, handlers, and effects.
+- **Use `.get()` / `.set()`, not `.value`.** Same API, but direct `.value` access is the form the React Compiler can't see through — the Reanimated docs call `get`/`set` the compiler-safe way. `set` also takes a functional update: `sv.set((v) => v + 1)`.
+- **Functions called from a worklet need `'worklet'`** as their first line, or they throw at runtime on device while working fine in the debugger.
+
+### 7. Press, not hover
+
+Every hover affordance from the web has to be redesigned, not ported.
+
+- **Feedback on press-in, commit on press-out.** Waiting for the tap to complete before showing anything feels dead — this is the latency the user actually perceives.
+- **`scale: 0.97` in 100–150ms** on any pressable, `Pressable` + a CSS transition. `scale` takes the label and icons with it, which is what makes it read as physical.
+- **44×44pt minimum touch target** (48dp Android). If the visual is smaller, add `hitSlop` — don't grow the visual.
+- **`pressRetentionOffset`** so a finger drifting a few pixels doesn't cancel a press the user meant.
+- **Android ripple only in a Material-styled app.** In a custom-designed app, the same scale on both platforms is more coherent than a ripple on one.
+
+### 8. Haptics
+
+Mobile has a sense the web doesn't. Use it sparingly and it becomes the thing that makes the app feel expensive; use it everywhere and users turn it off.
+
+| Moment | Call |
+| --- | --- |
+| A value ticks past a step — picker, slider detent, segmented control | `Haptics.selectionAsync()` |
+| Something snaps home, a sheet detent catches, a drag commits | `Haptics.impactAsync(ImpactFeedbackStyle.Light)` |
+| A heavy object lands, a destructive action fires | `Haptics.impactAsync(ImpactFeedbackStyle.Medium)` |
+| Operation succeeded or failed | `Haptics.notificationAsync(NotificationFeedbackType.Success / Error)` |
+
+Three rules, and they're absolute:
+
+- **Same frame as the visual.** A haptic that lags its animation reads as a glitch, not as feedback. Fire it at the causal moment — the detent catching — not when the animation finishes.
+- **One per user action.** Never on scroll, never per frame, never on an entrance animation the user didn't cause.
+- **Never the only feedback.** Haptics are off system-wide for many users, and silent on most Android hardware. The visual has to stand alone.
+
+From a worklet, haptics must be scheduled back to the RN runtime: `scheduleOnRN(Haptics.selectionAsync)`.
+
+### 9. Reduced motion and accessibility
+
+```jsx
+import { useReducedMotion, ReduceMotion, withSpring } from 'react-native-reanimated';
+
+const reduced = useReducedMotion();
+const y = useSharedValue(reduced ? 0 : SHEET_HEIGHT);
+
+// or let each animation decide
+withSpring(0, { duration: 300, dampingRatio: 0.8, reduceMotion: ReduceMotion.System });
+```
+
+Reduced motion means **fewer and gentler**, not zero: keep opacity and color changes that explain a state change, drop translation, scale, parallax and overshoot. Screen transitions become `animation: 'fade'`.
+
+**Text scales.** `allowFontScaling` is on by default, so any height you measured at default type size is wrong at 200%. Never animate to a hardcoded height — measure with `onLayout`, or animate a transform instead.
+
+## Setup that silently breaks motion
+
+Check these first when "the animation just doesn't run":
+
+- Install through Expo so versions match the SDK: `npx expo install react-native-reanimated react-native-worklets`. In an Expo project, `babel-preset-expo` configures the worklets Babel plugin automatically — no `babel.config.js` step. Only a bare RN project without that preset adds the plugin manually, and there it must be last in the list. A missing or misplaced plugin doesn't silently fall back anymore — it throws `Failed to create a worklet` at runtime.
+- `GestureHandlerRootView` must wrap the app, or gestures do nothing with no error.
+- Reanimated 4 requires the New Architecture.
+- **Expo Go is not a performance environment.** Judge feel in a release build; a dev build's JS thread is slow enough to hide exactly the problems you're looking for.
+
+## 120fps
+
+On ProMotion iPhones, third-party animations are capped at 60fps unless `CADisableMinimumFrameDurationOnPhone` is set. Recent Expo SDKs set it by default — confirm it's there, and add it if not:
+
+```json
+{ "expo": { "ios": { "infoPlist": { "CADisableMinimumFrameDurationOnPhone": true } } } }
+```
+
+Then the frame budget is 8ms, not 16. This is also why a UI-thread animation matters more on mobile than it does on web.
+
+## Recipes
+
+For ready-to-build implementations — press feedback, drag-to-dismiss sheet, swipe-to-delete, collapsing header, list entrances, keyboard-synced UI, tab indicator, screen transitions — see [RECIPES.md](RECIPES.md). Load it whenever the request matches one; start from the recipe rather than from a blank file.
+
+## Never Ship
+
+| Never | Instead |
+| --- | --- |
+| `PanResponder` | `Gesture.Pan()` from gesture-handler |
+| `setState` in a gesture or scroll handler | shared value + `useAnimatedStyle` |
+| `runOnJS` (deprecated in Reanimated 4) | `scheduleOnRN` from `react-native-worklets` |
+| `scheduleOnRN` per frame | `onEnd`, or `useAnimatedReaction` at a threshold |
+| Reading or writing a shared value during render | `.get()` / `.set()` in worklets, handlers, effects |
+| Core `Animated` for anything a finger touches | Reanimated |
+| Animating `height` / `width` / `margin` / `flex` / `top` | `transform` + `opacity` (absolute, childless elements exempt) |
+| Animating `BlurView` intensity or Android `elevation` | crossfade a static layer |
+| `entering` on a virtualized list row | animate the container, or `itemLayoutAnimation` |
+| A screen transition rebuilt in JS | native stack `animation` |
+| Sliding between tabs | `animation: 'none'` |
+| `Easing.in(...)` on a UI element | `Easing.bezier(0.23, 1, 0.32, 1)` |
+| `scale(0)` entrance | `scale(0.95)` + `opacity: 0` |
+| Distance-only dismissal threshold | velocity **or** distance — a flick is enough |
+| Hard stop at a boundary | rubber-band resistance |
+| A haptic per frame, or as the only feedback | one per commit, always paired with a visual |
+| Judging feel in Expo Go or the simulator | release build, slowest supported device |
+
+## Output
+
+Write the code. Then, in at most a few lines:
+
+- **The gate result** — frequency tier and named purpose. Say what you rejected and why.
+- **The ingredients** — tool, properties, spring or curve + duration, thread.
+- **What to feel-check on device** — gestures, velocity handoff and haptic timing cannot be judged from code. Name what to try: flick it, interrupt it mid-flight, reverse it, run it on the slowest Android you have.
+
+The code is the deliverable. Don't pad it into a report.
+
+## Tone
+
+Opinionated and brief. When the honest answer is "this shouldn't animate," or "this needs a real device before I can tell you if it's right," give it.
+
+## 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-animation" "<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.
diff --git a/.agents/skills/expo-animation/agents/openai.yaml b/.agents/skills/expo-animation/agents/openai.yaml
new file mode 100644
index 0000000..312c925
--- /dev/null
+++ b/.agents/skills/expo-animation/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Expo Animation"
+  short_description: "Build polished Expo and React Native animations"
+  default_prompt: "Use $expo-animation to build a polished, accessible animation for this Expo app."
diff --git a/.agents/skills/expo-app-clip/SKILL.md b/.agents/skills/expo-app-clip/SKILL.md
new file mode 100644
index 0000000..50cbaa9
--- /dev/null
+++ b/.agents/skills/expo-app-clip/SKILL.md
@@ -0,0 +1,290 @@
+---
+name: expo-app-clip
+description: Framework (OSS). Add an iOS App Clip target to an Expo app. Use when the user mentions App Clip, AASA, apple-app-site-association, appclips, smart app banner, or wants to ship a lightweight iOS Clip invoked from a URL alongside their parent app.
+---
+
+# Add an App Clip to an Expo App
+
+> **Requirements.** Adding the App Clip target is open source. Shipping one requires an Apple Developer Program membership and App Store review, and the AASA file must be served over HTTPS on your domain (any HTTPS host works; EAS Hosting is one option). Building via EAS Build or `bunx testflight` uses your EAS plan's build minutes. See https://expo.dev/pricing and https://developer.apple.com/app-clips/.
+
+Adds an iOS App Clip target to an Expo project. The Clip lives in `targets/clip/`, ships alongside the parent app, and is invoked from a URL on the app's domain via an Apple App Site Association (AASA) file.
+
+The parent app's bundle ID becomes `com.<username>.<app-name>` and the Clip's is automatically derived as `<parent>.clip` (e.g. `com.bacon.may20.clip`).
+
+## 1. Set `bundleIdentifier` and `appleTeamId`
+
+`bun create target` warns if these are missing. Add to `app.json`:
+
+```json
+{
+  "expo": {
+    "ios": {
+      "bundleIdentifier": "com.<username>.<app-name>",
+      "appleTeamId": "XX57RJ5UTD"
+    }
+  }
+}
+```
+
+## 2. Add the App Clip target
+
+```sh
+bun create target clip
+```
+
+This installs [`@bacons/apple-targets`](https://github.com/EvanBacon/expo-apple-targets), adds it to the `plugins` array in `app.json`, and writes:
+
+- `targets/clip/expo-target.config.js` — the target's config plugin
+- `targets/clip/Info.plist` — Clip Info.plist
+- `targets/clip/AppDelegate.swift`, `Assets.xcassets`, etc.
+
+Pick a good icon or reuse the existing one defined in the app — check it with `bunx expo config` under the `icon` or `ios.icon` key.
+
+## 3. Wire up associated domains
+
+The parent app and the Clip each need the Associated Domains entitlement pointing at the domain that hosts the AASA file.
+
+In `app.json`, add both `applinks:` (parent) and `appclips:` (Clip invocation) entries:
+
+```json
+{
+  "expo": {
+    "ios": {
+      "associatedDomains": [
+        "applinks:may20.expo.app",
+        "appclips:may20.expo.app"
+      ]
+    }
+  }
+}
+```
+
+In `targets/clip/expo-target.config.js`, declare the Clip's entitlement:
+
+```js
+/** @type {import('@bacons/apple-targets/app.plugin').ConfigFunction} */
+module.exports = (config) => ({
+  type: "clip",
+  icon: "https://github.com/expo.png",
+  entitlements: {
+    "com.apple.developer.associated-domains": ["appclips:may20.expo.app"],
+  },
+});
+```
+
+> If you skip this, `expo prebuild` will print: `Apple App Clip may require the associated domains entitlement but none were found`.
+
+## 4. Register bundle IDs and create the App Store entry
+
+```sh
+bunx setup-safari
+```
+
+This logs in to the Apple Developer account, registers `com.bacon.may20`, creates the App Store Connect entry, and prints:
+
+- A starter `apple-app-site-association` JSON
+- A `<meta name="apple-itunes-app">` tag with the iTunes app id
+- Team ID, iTunes ID, and Bundle ID
+
+## 5. Host the AASA file
+
+App Clips are invoked when iOS fetches `https://<your-domain>/.well-known/apple-app-site-association` and finds a matching `appclips` entry.
+
+```sh
+mkdir -p public/.well-known
+touch public/.well-known/apple-app-site-association
+```
+
+Paste the JSON `setup-safari` printed, but **add an `appclips` block** for the Clip's full app ID (`<TeamID>.<ClipBundleID>`). The output of `setup-safari` only covers the parent app:
+
+```json
+{
+  "applinks": {
+    "details": [
+      {
+        "appIDs": ["XX57RJ5UTD.com.bacon.may20"],
+        "components": [{ "/": "*", "comment": "Matches all routes" }]
+      }
+    ]
+  },
+  "appclips": {
+    "apps": ["XX57RJ5UTD.com.bacon.may20.clip"]
+  },
+  "activitycontinuation": {
+    "apps": ["XX57RJ5UTD.com.bacon.may20"]
+  },
+  "webcredentials": {
+    "apps": ["XX57RJ5UTD.com.bacon.may20"]
+  }
+}
+```
+
+Notes:
+
+- The file has **no extension** and **no `Content-Type` requirements** beyond being served as-is. Expo Router static export serves files in `public/` verbatim.
+- The `appclips` block is what lets a URL on the domain launch the Clip.
+- `webcredentials` is used for sharing credentials between the website, parent app, and the App Clip.
+- `activitycontinuation` is optional and used for sharing the link between mobile and desktop. Must be used with `Head` from expo-router — see https://docs.expo.dev/router/advanced/apple-handoff/
+- Notation and route-disabling details: https://sosumi.ai/documentation/xcode/supporting-associated-domains
+
+## 6. Add the Smart App Banner meta tag
+
+Create `src/app/+html.tsx` (Expo Router's HTML shell) and add the tag from `setup-safari`. Create the versioned template if it doesn't exist:
+
+```sh
+bunx expo customize src/app/+html.tsx
+```
+
+Add the meta tag to the `<head>`:
+
+```tsx
+import { ScrollViewStyleReset } from "expo-router/html";
+
+export default function Root({ children }: { children: React.ReactNode }) {
+  return (
+    <html lang="en">
+      <head>
+        <meta charSet="utf-8" />
+        <meta httpEquiv="X-UA-Compatible" content="IE=edge" />
+        <meta name="viewport" content="width=device-width, initial-scale=1" />
+        <meta name="apple-itunes-app" content="app-id=6771566491" />
+        <ScrollViewStyleReset />
+      </head>
+      <body>{children}</body>
+    </html>
+  );
+}
+```
+
+To make the website show the App Clip card instead of the install card, use:
+
+```html
+<meta
+  name="apple-itunes-app"
+  content="app-id=6771566491, app-clip-bundle-id=com.bacon.may20.clip, app-clip-display=card"
+/>
+```
+
+## 7. Deploy the website
+
+The AASA file must be live before iOS will trust the association. Use [EAS Hosting](https://docs.expo.dev/eas/hosting/):
+
+```sh
+bunx expo export -p web
+eas deploy --prod
+```
+
+This publishes the site (including `/.well-known/apple-app-site-association`) at `https://<slug>.expo.app`. Verify:
+
+```sh
+curl https://may20.expo.app/.well-known/apple-app-site-association
+```
+
+## 8. Mirror permissions
+
+Inspect the parent app's permissions after prebuild:
+
+```sh
+npx expo config --type introspect
+```
+
+Look at the `infoPlist` object — mirror the permission keys in the App Clip's `Info.plist` so matching APIs can be used from the Clip.
+
+Set `deploymentTarget: "17.6"` in the Clip's target config — App Clips have a higher minimum size limit in iOS 17.6.
+
+If the app uses push notifications or location services, add to the App Clip's `Info.plist` to request the necessary permissions:
+
+```xml
+<key>NSAppClip</key>
+<dict>
+  <key>NSAppClipRequestEphemeralUserNotification</key>
+  <false/>
+  <key>NSAppClipRequestLocationConfirmation</key>
+  <true/>
+</dict>
+```
+
+## 9. Build and submit to TestFlight
+
+```sh
+bunx testflight
+```
+
+This will:
+
+1. Generate an `eas.json` if missing.
+2. Set up credentials for **both** targets (parent + Clip). Each gets its own provisioning profile but can share a single Distribution Certificate.
+3. Sync capabilities — note `Enabled: Associated Domains` for the Clip target.
+4. Build, upload, and schedule a TestFlight submission.
+
+## 10. Configure App Clip metadata
+
+Pull existing App Store metadata to local:
+
+```sh
+eas metadata:pull
+```
+
+Add `apple.appClip` to `store.config.json`. Up to 3 invocation URLs can launch the Clip from a web page:
+
+```json
+{
+  "configVersion": 0,
+  "apple": {
+    "appClip": {
+      "defaultExperience": {
+        "action": "PLAY",
+        "releaseWithAppStoreVersion": true,
+        "reviewDetail": {
+          "invocationUrls": ["https://may20.expo.app/", null, null]
+        },
+        "info": {
+          "en-US": {
+            "subtitle": "Instantly native with Expo",
+            "headerImage": "store/apple/app-clip/en-US/asc-app-clip.png"
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+The `headerImage` must be a 1800x1200 PNG with no opacity.
+
+Push back to the store:
+
+```sh
+eas metadata:push
+```
+
+Apple's recommended App Clip metadata guidelines: https://sosumi.ai/documentation/appclip/configuring-the-launch-experience-of-your-app-clip
+
+## What you get
+
+- Parent app target: `com.bacon.may20`
+- App Clip target: `com.bacon.may20.clip`, lives in `targets/clip/`
+- AASA hosted at `https://may20.expo.app/.well-known/apple-app-site-association`
+- Smart App Banner meta tag on every web route
+- Every route linked to its native counterpart
+- TestFlight build of the parent app with the Clip embedded
+
+Once Apple invokes the Clip from a URL on the domain, iOS opens `targets/clip/`'s entry point which loads the React Native app.
+
+## Native detection (optional)
+
+To let JS detect when it's running inside an App Clip and present an install prompt for the full app, create a local Expo module (`bunx create-expo-module --local`) that exposes `navigator.appClip.prompt()`.
+
+See [./references/native-module.md](./references/native-module.md) for the Swift module, TypeScript interface, and usage.
+
+## References
+
+- ./references/native-module.md — Local Expo module to detect App Clip context and present the SKOverlay install prompt
+
+## 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-app-clip" "<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.
diff --git a/.agents/skills/expo-app-clip/agents/openai.yaml b/.agents/skills/expo-app-clip/agents/openai.yaml
new file mode 100644
index 0000000..41a76e1
--- /dev/null
+++ b/.agents/skills/expo-app-clip/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Expo App Clip"
+  short_description: "Add an iOS App Clip target to an Expo app with AASA, associated domains, and TestFlight setup (needs an Apple Developer account)"
+  default_prompt: "Use $expo-app-clip when adding or reviewing an iOS App Clip target for an Expo app, including bundle IDs, associated domains, AASA files, smart app banners, App Store Connect setup, and TestFlight verification."
diff --git a/.agents/skills/expo-app-clip/references/native-module.md b/.agents/skills/expo-app-clip/references/native-module.md
new file mode 100644
index 0000000..1eeefe0
--- /dev/null
+++ b/.agents/skills/expo-app-clip/references/native-module.md
@@ -0,0 +1,96 @@
+# Native App Clip detection
+
+Create a local Expo module so JS can detect when the app is running inside an App Clip and present the install prompt for the full app.
+
+```sh
+bunx create-expo-module --local
+```
+
+## Swift module
+
+```swift
+import ExpoModulesCore
+import StoreKit
+
+internal class MissingCurrentWindowSceneException: Exception {
+  override var reason: String {
+    "Cannot determine the current window scene in which to present the modal for requesting a review."
+  }
+}
+
+internal class MissingContainerURLException: Exception {
+  override var reason: String {
+    "Cannot determine the container URL."
+  }
+}
+
+public class AppClipModule: Module {
+  private static let isAppClip: Bool = {
+    if let infoPlist = Bundle.main.infoDictionary, let _ = infoPlist["NSAppClip"] as? [String: Any] {
+      return true
+    }
+    return false
+  }()
+
+  public func definition() -> ModuleDefinition {
+    Name("AppClip")
+
+    Constant("isAppClip") {
+      AppClipModule.isAppClip
+    }
+
+    // Display overlay to advertise full app.
+    // https://developer.apple.com/documentation/app_clips/recommending_your_app_to_app_clip_users
+    AsyncFunction("prompt") {
+      if #available(iOS 16, *) {
+        guard let currentScene = UIApplication.shared.connectedScenes.first as? UIWindowScene else {
+          throw MissingCurrentWindowSceneException()
+        }
+
+        let config = SKOverlay.AppClipConfiguration(position: .bottom)
+        let overlay = SKOverlay(configuration: config)
+        overlay.present(in: currentScene)
+      }
+    }.runOnQueue(DispatchQueue.main)
+  }
+}
+```
+
+## TypeScript interface
+
+```ts
+import { NativeModule, requireOptionalNativeModule } from "expo";
+
+declare class AppClipModule extends NativeModule<{}> {
+  prompt(): void;
+  isAppClip?: boolean;
+}
+
+const AppClipNative = requireOptionalNativeModule<AppClipModule>("AppClip");
+
+if (AppClipNative?.isAppClip) {
+  navigator.appClip = {
+    prompt: AppClipNative.prompt,
+  };
+}
+
+declare global {
+  interface Navigator {
+    /**
+     * Only available in an App Clip context.
+     * @expo
+     */
+    appClip?: {
+      /** Open the SKOverlay */
+      prompt: () => void;
+    };
+  }
+}
+
+export {};
+```
+
+## Usage
+
+- Detect App Clip context: `if (navigator.appClip) { ... }`
+- Prompt to install the full app: `navigator.appClip?.prompt()`
diff --git a/.agents/skills/expo-brownfield/SKILL.md b/.agents/skills/expo-brownfield/SKILL.md
new file mode 100644
index 0000000..166b8ab
--- /dev/null
+++ b/.agents/skills/expo-brownfield/SKILL.md
@@ -0,0 +1,62 @@
+---
+name: expo-brownfield
+description: Framework (OSS). Integrate Expo and React Native into an existing native iOS or Android app. Use when the user mentions brownfield, embedding React Native in a native app, AAR/XCFramework, or adding Expo to an existing Kotlin/Swift project. Covers both the isolated approach and the integrated approach.
+---
+
+# Expo Brownfield
+
+A **brownfield** app is an existing native iOS or Android app that adopts React Native incrementally, as opposed to a **greenfield** app that is React Native from day one.
+
+Expo supports two distinct ways to add React Native to a brownfield project:
+
+| Approach       | What ships to the native app                                        | When to choose                                                                   |
+| -------------- | ------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
+| **Isolated**   | Prebuilt AAR / XCFramework                                          | Native team doesn't need Node or RN tooling; RN code can live in a separate repo |
+| **Integrated** | React Native sources added to the existing Gradle / CocoaPods build | One team owns everything; comfortable with RN tooling; wants a single build      |
+
+For the full decision matrix, see [./references/comparison.md](./references/comparison.md).
+
+## Pick an approach
+
+Use these quick rules — fall through to `comparison.md` for anything ambiguous.
+
+- **Choose isolated** if the iOS/Android team must consume RN as a regular library dependency (AAR or XCFramework), without installing Node, Yarn, or the React Native build toolchain.
+- **Choose isolated** if RN code and native code live in separate repositories or release on independent cadences.
+- **Choose integrated** if a single team owns both the native and RN code and is willing to add React Native + Expo to the native project's Gradle and CocoaPods setup.
+- **Choose integrated** if you want hot reload and JS source maps to work seamlessly inside the existing native build process.
+
+## References
+
+- ./references/brownfield-isolated.md -- Build RN as AAR/XCFramework and consume from the native app (BrownfieldActivity, ReactNativeViewController, ReactNativeView)
+- ./references/brownfield-integrated.md -- Add RN and Expo directly to existing Gradle and CocoaPods builds (ReactActivity, RCTRootView, Podfile)
+- ./references/comparison.md -- Decision criteria, trade-offs, and scenario mapping for choosing an approach
+- ./references/troubleshooting.md -- Metro connection, build, signing, and module-resolution issues common to both approaches
+
+More information available at https://docs.expo.dev/brownfield/overview/
+
+## Shared prerequisites
+
+Both approaches require, in the environment that _builds_ the React Native side:
+
+- **Node.js (LTS)** — runs the Expo CLI and JavaScript code.
+- **Yarn** — manages JavaScript dependencies.
+
+The integrated approach additionally requires **CocoaPods** on iOS (`sudo gem install cocoapods`). The isolated approach does **not** require CocoaPods or any RN tooling in the consuming native app.
+
+## Versioning note
+
+**Expo SDK 55 is the minimum supported version for brownfield integration.** Earlier SDKs lack `expo-brownfield`, the required `ExpoReactHostFactory` / `ExpoReactNativeFactory` entry points, and the current autolinking surface. When creating the Expo project, always pin the SDK explicitly:
+
+```sh
+npx create-expo-app@latest my-project --template default@sdk-55
+```
+
+Pin the same Expo SDK across both the RN project and any embedded dependencies.
+
+## 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-brownfield" "<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.
diff --git a/.agents/skills/expo-brownfield/agents/openai.yaml b/.agents/skills/expo-brownfield/agents/openai.yaml
new file mode 100644
index 0000000..79ba49c
--- /dev/null
+++ b/.agents/skills/expo-brownfield/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Expo Brownfield"
+  short_description: "Integrate Expo and React Native into existing native iOS or Android apps"
+  default_prompt: "Use $expo-brownfield when adding Expo or React Native to an existing native app, choosing isolated vs integrated brownfield architecture, embedding AAR/XCFramework outputs, wiring Gradle or CocoaPods, and troubleshooting native integration issues."
diff --git a/.agents/skills/expo-brownfield/references/brownfield-integrated.md b/.agents/skills/expo-brownfield/references/brownfield-integrated.md
new file mode 100644
index 0000000..dcbcbb2
--- /dev/null
+++ b/.agents/skills/expo-brownfield/references/brownfield-integrated.md
@@ -0,0 +1,526 @@
+# Brownfield: Integrated Approach
+
+Add React Native and Expo directly to the existing native project's build system — Gradle on Android, CocoaPods on iOS — the same way you would add any other library. The native project gains React Native capabilities while keeping a single, unified build.
+
+## When to use
+
+- A single team owns both the native and React Native code.
+- The team is comfortable adding React Native and Expo to the native build (Gradle plugin, CocoaPods pods).
+- You want hot reload, JS source maps, and a single Metro instance to "just work" inside the existing build.
+- You prefer one repository and one build pipeline over shipping a prebuilt artifact.
+
+If the native team must not need Node, Yarn, or React Native tooling, use [./brownfield-isolated.md](./brownfield-isolated.md) instead.
+
+## Prerequisites
+
+- **Expo SDK 54 or later** — the `ExpoReactHostFactory`, `ExpoReactNativeFactory`, and `ApplicationLifecycleDispatcher` entry points used below require SDK 54+. Earlier SDKs do not support this setup.
+- **Node.js (LTS)** — runs JavaScript and the Expo CLI.
+- **Yarn** — manages JavaScript dependencies.
+- **CocoaPods** (iOS) — `sudo gem install cocoapods`.
+
+---
+
+## 1) Create an Expo project
+
+Create the Expo project inside (or alongside) the existing native project. **Pin to SDK 55 or later — earlier SDKs do not support brownfield integration:**
+
+```sh
+npx create-expo-app@latest my-project --template default@sdk-55
+```
+
+The new project ships a TypeScript example app. The JS entry point registers a root component under the name `"main"` — this name must match the `moduleName` referenced from the native side later.
+
+## 2) Place native projects under the Expo project
+
+A standard React Native project keeps native code under `android/` and `ios/`. Move the existing native projects in:
+
+```sh
+mkdir my-project/android
+mv /path/to/your/android-project my-project/android/
+# repeat for ios/
+```
+
+### Monorepo alternative
+
+If the native projects cannot be moved, set up a monorepo with the Expo project as a workspace. Create a root `package.json`:
+
+```json
+{
+  "version": "1.0.0",
+  "private": true,
+  "workspaces": ["my-project"]
+}
+```
+
+Run `yarn install` at the root. This installs `node_modules` at the workspace root so Gradle and CocoaPods scripts can resolve React Native and Expo dependencies.
+
+> **Monorepo callout:** with a monorepo, the Expo project is not at `../../` from the native projects. You must set `projectRoot` explicitly in Gradle and pass the project root to CocoaPods so autolinking can find the Expo project.
+
+---
+
+## 3) Configure Android
+
+### `settings.gradle`
+
+Register the React Native Gradle plugin and Expo autolinking. Reference: [bare-minimum template `settings.gradle`](https://github.com/expo/expo/blob/main/templates/expo-template-bare-minimum/android/settings.gradle).
+
+```groovy
+pluginManagement {
+  def reactNativeGradlePlugin = new File(
+    providers.exec {
+      workingDir(rootDir)
+      commandLine("node", "--print", "require.resolve('@react-native/gradle-plugin/package.json', { paths: [require.resolve('react-native/package.json')] })")
+    }.standardOutput.asText.get().trim()
+  ).getParentFile().absolutePath
+  includeBuild(reactNativeGradlePlugin)
+
+  def expoPluginsPath = new File(
+    providers.exec {
+      workingDir(rootDir)
+      commandLine("node", "--print", "require.resolve('expo-modules-autolinking/package.json', { paths: [require.resolve('expo/package.json')] })")
+    }.standardOutput.asText.get().trim(),
+    "../android/expo-gradle-plugin"
+  ).absolutePath
+  includeBuild(expoPluginsPath)
+}
+
+plugins {
+  id("com.facebook.react.settings")
+  id("expo-autolinking-settings")
+}
+
+extensions.configure(com.facebook.react.ReactSettingsExtension) { ex ->
+  ex.autolinkLibrariesFromCommand(expoAutolinking.rnConfigCommand)
+}
+expoAutolinking.useExpoModules()
+expoAutolinking.useExpoVersionCatalog()
+includeBuild(expoAutolinking.reactNativeGradlePlugin)
+```
+
+> **Monorepo:** add an explicit project root before `expoAutolinking.useExpoModules()` so autolinking finds your Expo project's `node_modules`.
+
+### Top-level `build.gradle`
+
+Add the React Native Gradle plugin classpath and the Expo root-project plugin:
+
+```groovy
+buildscript {
+  repositories {
+    google()
+    mavenCentral()
+  }
+  dependencies {
+    classpath('com.android.tools.build:gradle')
+    classpath('com.facebook.react:react-native-gradle-plugin')
+    classpath('org.jetbrains.kotlin:kotlin-gradle-plugin')
+  }
+}
+
+allprojects {
+  repositories {
+    google()
+    mavenCentral()
+    maven { url 'https://www.jitpack.io' }
+  }
+}
+
+apply plugin: "expo-root-project"
+apply plugin: "com.facebook.react.rootproject"
+```
+
+### `app/build.gradle`
+
+Apply the React Native plugin and configure the `react { ... }` block. The full template is at [bare-minimum `app/build.gradle`](https://github.com/expo/expo/blob/main/templates/expo-template-bare-minimum/android/app/build.gradle); the minimum that must change in your existing module:
+
+```groovy
+apply plugin: "com.android.application"
+apply plugin: "org.jetbrains.kotlin.android"
+apply plugin: "com.facebook.react"
+
+def projectRoot = rootDir.getAbsoluteFile().getParentFile().getAbsolutePath()
+
+react {
+  entryFile = file(["node", "-e", "require('expo/scripts/resolveAppEntry')", projectRoot, "android", "absolute"].execute(null, rootDir).text.trim())
+  reactNativeDir = new File(["node", "--print", "require.resolve('react-native/package.json')"].execute(null, rootDir).text.trim()).getParentFile().getAbsoluteFile()
+  codegenDir = new File(["node", "--print", "require.resolve('@react-native/codegen/package.json', { paths: [require.resolve('react-native/package.json')] })"].execute(null, rootDir).text.trim()).getParentFile().getAbsoluteFile()
+  cliFile = new File(["node", "--print", "require.resolve('@expo/cli', { paths: [require.resolve('expo/package.json')] })"].execute(null, rootDir).text.trim())
+  bundleCommand = "export:embed"
+  autolinkLibrariesWithApp()
+}
+```
+
+> **Monorepo:** set `root = file("../../")` (or wherever your Expo project lives) inside the `react { ... }` block.
+
+### `gradle.properties`
+
+```properties
+reactNativeArchitectures=armeabi-v7a,arm64-v8a,x86,x86_64
+newArchEnabled=true
+hermesEnabled=true
+```
+
+`newArchEnabled` and `hermesEnabled` must match across all sub-modules in your build.
+
+### `AndroidManifest.xml`
+
+Add the `INTERNET` permission to your main manifest at `app/src/main/AndroidManifest.xml`:
+
+```xml
+<uses-permission android:name="android.permission.INTERNET" />
+```
+
+In the debug-variant manifest at `app/src/debug/AndroidManifest.xml`, enable cleartext traffic so the app can talk to the local Metro bundler over HTTP:
+
+```xml
+<application
+  android:usesCleartextTraffic="true"
+  tools:targetApi="28"
+  tools:ignore="GoogleAppIndexingWarning">
+  ...
+</application>
+```
+
+### `MainApplication.kt`
+
+Initialize React Native and Expo lifecycle dispatch in your `Application` class:
+
+```kotlin
+package com.example.myapp
+
+import android.app.Application
+import android.content.res.Configuration
+
+import com.facebook.react.PackageList
+import com.facebook.react.ReactApplication
+import com.facebook.react.ReactNativeApplicationEntryPoint.loadReactNative
+import com.facebook.react.ReactHost
+import com.facebook.react.common.ReleaseLevel
+import com.facebook.react.defaults.DefaultNewArchitectureEntryPoint
+
+import expo.modules.ApplicationLifecycleDispatcher
+import expo.modules.ExpoReactHostFactory
+
+class MainApplication : Application(), ReactApplication {
+
+  override val reactHost: ReactHost by lazy {
+    ExpoReactHostFactory.getDefaultReactHost(
+      context = applicationContext,
+      packageList = PackageList(this).packages
+    )
+  }
+
+  override fun onCreate() {
+    super.onCreate()
+    DefaultNewArchitectureEntryPoint.releaseLevel = try {
+      ReleaseLevel.valueOf(BuildConfig.REACT_NATIVE_RELEASE_LEVEL.uppercase())
+    } catch (_: IllegalArgumentException) {
+      ReleaseLevel.STABLE
+    }
+    loadReactNative(this)
+    ApplicationLifecycleDispatcher.onApplicationCreate(this)
+  }
+
+  override fun onConfigurationChanged(newConfig: Configuration) {
+    super.onConfigurationChanged(newConfig)
+    ApplicationLifecycleDispatcher.onConfigurationChanged(this, newConfig)
+  }
+}
+```
+
+### `ReactActivity`
+
+Create an `Activity` that hosts a React Native screen. The `moduleName` returned by `getMainComponentName()` must match the name registered via `AppRegistry.registerComponent(...)` in your JS entry point (`"main"` for the default template).
+
+```kotlin
+package com.example.myapp
+
+import com.facebook.react.ReactActivity
+import com.facebook.react.ReactActivityDelegate
+import com.facebook.react.defaults.DefaultNewArchitectureEntryPoint.fabricEnabled
+import com.facebook.react.defaults.DefaultReactActivityDelegate
+
+import expo.modules.ReactActivityDelegateWrapper
+
+class MyReactActivity : ReactActivity() {
+
+  override fun getMainComponentName(): String = "main"
+
+  override fun createReactActivityDelegate(): ReactActivityDelegate {
+    return ReactActivityDelegateWrapper(
+      this,
+      BuildConfig.IS_NEW_ARCHITECTURE_ENABLED,
+      object : DefaultReactActivityDelegate(this, mainComponentName, fabricEnabled) {}
+    )
+  }
+}
+```
+
+Register the activity in `AndroidManifest.xml` with a non-ActionBar theme:
+
+```xml
+<activity
+  android:name=".MyReactActivity"
+  android:theme="@style/Theme.AppCompat.Light.NoActionBar"
+  android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|screenSize|smallestScreenSize|uiMode"
+/>
+```
+
+Launch it from existing native code:
+
+```kotlin
+startActivity(Intent(this, MyReactActivity::class.java))
+```
+
+---
+
+## 4) Configure iOS
+
+The integrated approach drives iOS through CocoaPods + Expo modules autolinking, exactly like a fresh Expo project. The key difference is that you are integrating into your existing Xcode project rather than starting from the template.
+
+### `ios/Podfile`
+
+Create (or update) `ios/Podfile` based on the [bare-minimum Podfile](https://github.com/expo/expo/blob/main/templates/expo-template-bare-minimum/ios/Podfile). The essential lines:
+
+```ruby
+require File.join(File.dirname(`node --print "require.resolve('expo/package.json')"`), "scripts/autolinking")
+require File.join(File.dirname(`node --print "require.resolve('react-native/package.json')"`), "scripts/react_native_pods")
+
+require 'json'
+podfile_properties = JSON.parse(File.read(File.join(__dir__, 'Podfile.properties.json'))) rescue {}
+
+platform :ios, podfile_properties['ios.deploymentTarget'] || '16.4'
+
+prepare_react_native_project!
+
+target 'MyApp' do
+  use_expo_modules!
+
+  config_command = [
+    'node',
+    '--no-warnings',
+    '--eval',
+    'require(\'expo/bin/autolinking\')',
+    'expo-modules-autolinking',
+    'react-native-config',
+    '--json',
+    '--platform',
+    'ios'
+  ]
+
+  config = use_native_modules!(config_command)
+
+  use_frameworks! :linkage => podfile_properties['ios.useFrameworks'].to_sym if podfile_properties['ios.useFrameworks']
+
+  use_react_native!(
+    :path => config[:reactNativePath],
+    :hermes_enabled => podfile_properties['expo.jsEngine'] == nil || podfile_properties['expo.jsEngine'] == 'hermes',
+    :app_path => "#{Pod::Config.instance.installation_root}/..",
+    :privacy_file_aggregation_enabled => podfile_properties['apple.privacyManifestAggregationEnabled'] != 'false',
+  )
+
+  post_install do |installer|
+    react_native_post_install(installer, config[:reactNativePath], :mac_catalyst_enabled => false)
+  end
+end
+```
+
+Replace `'MyApp'` with the existing Xcode target name. The `:app_path` value tells `use_react_native!` where the JS app lives — set it to the absolute path of your Expo project root if you are in a monorepo.
+
+Create `ios/Podfile.properties.json` alongside the Podfile (defaults are fine):
+
+```json
+{
+  "expo.jsEngine": "hermes",
+  "EX_DEV_CLIENT_NETWORK_INSPECTOR": "true"
+}
+```
+
+Install pods:
+
+```sh
+cd ios && pod install
+```
+
+Open the generated `.xcworkspace` (not the `.xcodeproj`) from now on.
+
+### Xcode project changes
+
+Three Xcode-side adjustments are required before the app can build and run a React Native screen. Skip any one and either CocoaPods scripts fail under sandboxing, the JS bundle never lands in the IPA (release crashes looking for `main.jsbundle`), or the status bar fights React Native at runtime.
+
+#### 1. Disable user script sandboxing
+
+In Xcode, select your project → app target → **Build Settings**, search for `ENABLE_USER_SCRIPT_SANDBOXING`, and set it to **No**. CocoaPods' Hermes scripts need to switch between debug and release engine binaries at build time, which sandboxing blocks.
+
+#### 2. Add a Run Script phase to embed the JS bundle
+
+On the app target's **Build Phases** tab, add a new **Run Script** phase **before** `[CP] Embed Pods Frameworks`. This phase bundles JS for release builds and is skipped automatically in debug (Metro serves the bundle then).
+
+```sh
+if [[ -f "$PODS_ROOT/../.xcode.env" ]]; then
+  source "$PODS_ROOT/../.xcode.env"
+fi
+if [[ -f "$PODS_ROOT/../.xcode.env.local" ]]; then
+  source "$PODS_ROOT/../.xcode.env.local"
+fi
+
+export PROJECT_ROOT="$PROJECT_DIR"/..
+
+if [[ "$CONFIGURATION" = *Debug* ]]; then
+  export SKIP_BUNDLING=1
+fi
+if [[ -z "$ENTRY_FILE" ]]; then
+  export ENTRY_FILE="$("$NODE_BINARY" -e "require('expo/scripts/resolveAppEntry')" "$PROJECT_ROOT" ios absolute | tail -n 1)"
+fi
+if [[ -z "$CLI_PATH" ]]; then
+  export CLI_PATH="$("$NODE_BINARY" --print "require.resolve('@expo/cli', { paths: [require.resolve('expo/package.json')] })")"
+fi
+if [[ -z "$BUNDLE_COMMAND" ]]; then
+  export BUNDLE_COMMAND="export:embed"
+fi
+
+if [[ -f "$PODS_ROOT/../.xcode.env.updates" ]]; then
+  source "$PODS_ROOT/../.xcode.env.updates"
+fi
+if [[ -f "$PODS_ROOT/../.xcode.env.local" ]]; then
+  source "$PODS_ROOT/../.xcode.env.local"
+fi
+
+`"$NODE_BINARY" --print "require('path').dirname(require.resolve('react-native/package.json')) + '/scripts/react-native-xcode.sh'"`
+```
+
+> **Monorepo:** override `PROJECT_ROOT` to point at the Expo project (e.g. `export PROJECT_ROOT="$PROJECT_DIR"/../../my-project`). Without this, bundling looks for `node_modules` in the wrong directory.
+
+This script writes `main.jsbundle` into the app's resources directory in release configurations. Without it, the `bundleURL()` fallback in `ReactNativeDelegate` resolves to `nil` and the React Native screen fails to load whenever Metro is not running.
+
+#### 3. Update `Info.plist`
+
+Set `UIViewControllerBasedStatusBarAppearance` to `NO` so React Native can manage the status bar:
+
+```xml
+<key>UIViewControllerBasedStatusBarAppearance</key>
+<false/>
+```
+
+### `AppDelegate.swift`
+
+Wire React Native into the app delegate via Expo's `ExpoReactNativeFactory`. The delegate's `bundleURL()` selects the Metro dev server in `DEBUG` and the embedded bundle in release.
+
+```swift
+internal import Expo
+import React
+import ReactAppDependencyProvider
+
+@main
+class AppDelegate: ExpoAppDelegate {
+  var window: UIWindow?
+
+  var reactNativeDelegate: ExpoReactNativeFactoryDelegate?
+  var reactNativeFactory: RCTReactNativeFactory?
+
+  public override func application(
+    _ application: UIApplication,
+    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil
+  ) -> Bool {
+    let delegate = ReactNativeDelegate()
+    let factory = ExpoReactNativeFactory(delegate: delegate)
+    delegate.dependencyProvider = RCTAppDependencyProvider()
+
+    reactNativeDelegate = delegate
+    reactNativeFactory = factory
+
+    window = UIWindow(frame: UIScreen.main.bounds)
+    factory.startReactNative(
+      withModuleName: "main",
+      in: window,
+      launchOptions: launchOptions
+    )
+
+    return super.application(application, didFinishLaunchingWithOptions: launchOptions)
+  }
+}
+
+class ReactNativeDelegate: ExpoReactNativeFactoryDelegate {
+  override func sourceURL(for bridge: RCTBridge) -> URL? {
+    bridge.bundleURL ?? bundleURL()
+  }
+
+  override func bundleURL() -> URL? {
+#if DEBUG
+    return RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: ".expo/.virtual-metro-entry")
+#else
+    return Bundle.main.url(forResource: "main", withExtension: "jsbundle")
+#endif
+  }
+}
+```
+
+The module name `"main"` must match what the JS side registers with `AppRegistry.registerComponent("main", () => App)`.
+
+### Embedding RN inside an existing screen (not the root window)
+
+If you do not want React Native to take over the whole window, instantiate the factory the same way but mount the produced root view inside an existing `UIViewController`:
+
+```swift
+import UIKit
+import React
+import Expo
+
+class ReactNativeScreenViewController: UIViewController {
+  private var reactNativeDelegate: ExpoReactNativeFactoryDelegate?
+  private var reactNativeFactory: RCTReactNativeFactory?
+
+  override func viewDidLoad() {
+    super.viewDidLoad()
+
+    let delegate = ReactNativeDelegate()
+    let factory = ExpoReactNativeFactory(delegate: delegate)
+    delegate.dependencyProvider = RCTAppDependencyProvider()
+    self.reactNativeDelegate = delegate
+    self.reactNativeFactory = factory
+
+    let rootView = factory.rootViewFactory.view(
+      withModuleName: "main",
+      initialProperties: nil,
+      launchOptions: nil
+    )
+    rootView.frame = view.bounds
+    rootView.autoresizingMask = [.flexibleWidth, .flexibleHeight]
+    view.addSubview(rootView)
+  }
+}
+```
+
+Present it like any other view controller:
+
+```swift
+navigationController?.pushViewController(ReactNativeScreenViewController(), animated: true)
+```
+
+> **Monorepo iOS:** `pod install` is run from `ios/`, but Node module resolution starts from the Expo project root. Pass `EXPO_PROJECT_ROOT=/absolute/path/to/expo-project` to the `pod install` invocation if autolinking cannot find the Expo project automatically.
+
+---
+
+## 5) Test the integration
+
+Start Metro from the Expo project (or `yarn start` from the monorepo root):
+
+```sh
+yarn start
+```
+
+Build and run the native app normally (Android Studio / Xcode). Navigate to your React Native-powered Activity or screen - it loads JS from the Metro dev server with hot reloading.
+
+### Development vs. production
+
+- **Development** — Metro serves the JS bundle with hot reloading over HTTP. Debug builds use the Metro URL via `RCTBundleURLProvider` (iOS) or the dev server detection in `ReactActivity` (Android).
+- **Production** — Metro is not used. Run `expo export:embed` (invoked automatically by the React Native Gradle plugin and the iOS build phase) to embed the bundle into the APK/IPA.
+
+For Metro connection issues, build failures, missing modules, or arch mismatches, see [./troubleshooting.md](./troubleshooting.md).
+
+---
+
+## Related references
+
+- [./brownfield-isolated.md](./brownfield-isolated.md) — Alternative: ship RN as a prebuilt AAR/XCFramework.
+- [./comparison.md](./comparison.md) — Decide between isolated and integrated.
+- [./troubleshooting.md](./troubleshooting.md) — Common Metro, build, and integration issues.
diff --git a/.agents/skills/expo-brownfield/references/brownfield-isolated.md b/.agents/skills/expo-brownfield/references/brownfield-isolated.md
new file mode 100644
index 0000000..9ef9a2a
--- /dev/null
+++ b/.agents/skills/expo-brownfield/references/brownfield-isolated.md
@@ -0,0 +1,451 @@
+# Brownfield: Isolated Approach
+
+Build the React Native + Expo code as a prebuilt native library, **AAR** on Android and **XCFramework** on iOS, and consume it from the existing native app like any other dependency.
+
+## When to use
+
+- Native and React Native are owned by different teams or release on different cadences.
+- The native team must not be required to install Node.js, Yarn, or React Native tooling.
+- React Native code lives in a separate repo or monorepo from the native app.
+- You want the smallest possible footprint on the existing native build pipeline.
+
+If a single team owns both layers, is comfortable with React Native tooling and needs deep integration, see [./brownfield-integrated.md](./brownfield-integrated.md).
+
+## What you produce
+
+| Platform | Artifact                                                                                                                                                                                                                | Default location                                              |
+| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
+| Android  | `{group}:{libraryName}:{version}` AAR                                                                                                                                                                                   | Local Maven (`~/.m2`) by default; remote Maven also supported |
+| iOS      | Set of `.xcframework`s — see [the iOS section below](#ios) for how `ios.buildReactNativeFromSource` (default `false` on SDK 56+) controls whether you get 5 frameworks or 2 — or a single Swift Package via `--package` | `./artifacts`                                                 |
+
+The JavaScript bundle is **embedded inside the artifact** in release builds, so the native app does not need Metro at runtime in production.
+
+## Prerequisites
+
+- **Expo SDK 55 or later** — brownfield support, `expo-brownfield`, and the required runtime classes are only available on SDK 55+. Earlier SDKs will not work.
+- **Node.js (LTS)** — runs JavaScript and the Expo CLI.
+- **Yarn** — manages JavaScript dependencies.
+
+Node and Yarn are only needed in the environment that _builds_ the artifact. The consuming native app does not need them.
+
+---
+
+## 1) Set up the Expo project
+
+### Create a new Expo project
+
+```sh
+npx create-expo-app@latest my-project --template default@sdk-55
+```
+
+**Pin to SDK 55 or later — earlier SDKs do not support brownfield.** The project can live in a separate repo or alongside the native app in a monorepo; it does not need to be inside the native project.
+
+### Install expo-brownfield
+
+```sh
+cd my-project
+npx expo install expo-brownfield
+```
+
+The plugin self-registers in `app.json` with defaults derived from your app config.
+
+### Check what the host app already ships
+
+Before picking Expo modules, audit the host app's dependencies. The artifact's libraries meet the host's at build time, and version clashes surface as duplicate-class errors or forced upgrades.
+
+- **Jetpack Compose** — `@expo/ui` re-declares recent Compose and Material3 versions, and is pulled transitively by `expo-router`. A host pinned to older Compose gets force-upgraded. Exclude it with `expo.autolinking.android.exclude` if the RN screens don't need it.
+- **OkHttp, Kotlin stdlib, Material Components** — arrive as ordinary Maven dependencies of the artifact; Gradle resolves the highest version, which can bump the host's copies.
+
+When a shared library must stay at the host's version, exclude the Expo module that brings it, or (with fused publishing, below) mark the group as host-provided.
+
+### Configure the plugin (optional)
+
+To override the auto-generated names, expand the plugin entry in `app.json`:
+
+```json
+{
+  "expo": {
+    "plugins": [
+      [
+        "expo-brownfield",
+        {
+          "ios": {
+            "targetName": "MyBrownfield",
+            "bundleIdentifier": "com.example.mybrownfield"
+          },
+          "android": {
+            "libraryName": "mybrownfield",
+            "group": "com.example",
+            "package": "com.example.mybrownfield",
+            "version": "1.0.0"
+          }
+        }
+      ]
+    ]
+  }
+}
+```
+
+**iOS options** — `targetName` (XCFramework target name), `bundleIdentifier` (framework bundle ID).
+
+**Android options** — `libraryName` (AAR name), `group` (Maven group ID), `package` (Android package), `version` (library version), `publishing` (Maven publication targets — see [Publishing the Android AAR](#publishing-the-android-aar)).
+
+### Speed up iOS builds with prebuilt Expo modules
+
+Enable `expo-build-properties`'s `ios.usePrecompiledModules` so `pod install` downloads each Expo module as a prebuilt `.xcframework` instead of compiling it from source. `build:ios` detects those xcframeworks under `ios/Pods/` and bundles them into the Swift Package output alongside the brownfield framework, React, Hermes, and `ReactNativeDependencies`.
+
+```json
+{
+  "expo": {
+    "plugins": [
+      ["expo-build-properties", { "ios": { "usePrecompiledModules": true } }],
+      "expo-brownfield"
+    ]
+  }
+}
+```
+
+When precompiled modules are detected, `build:ios` is pinned to a single flavor (`--debug` or `--release`) per package — Swift Package Manager has no per-configuration overload for `.binaryTarget(path:)`. Build once per flavor and distribute the two packages side by side.
+
+---
+
+## 2) Build the native libraries
+
+### Android
+
+```sh
+npx expo-brownfield build:android
+```
+
+Produces an AAR and publishes it to the local Maven repository at `~/.m2`. The Maven coordinates come from the plugin config — e.g. `com.example:mybrownfield:1.0.0`.
+
+#### Publishing the Android AAR
+
+The plugin's `publishing` option controls where the AAR is published. When unset, it defaults to local Maven. To push to other targets (e.g. a shared CI Maven, an internal Artifactory/Nexus, or a folder pulled into another build), declare the publications explicitly:
+
+```json
+{
+  "expo": {
+    "plugins": [
+      [
+        "expo-brownfield",
+        {
+          "android": {
+            "libraryName": "mybrownfield",
+            "group": "com.example",
+            "version": "1.0.0",
+            "publishing": [
+              { "type": "localMaven" },
+              {
+                "type": "localDirectory",
+                "name": "build",
+                "path": "./out/maven"
+              },
+              {
+                "type": "remotePublic",
+                "name": "company",
+                "url": "https://maven.example.com/releases"
+              },
+              {
+                "type": "remotePrivate",
+                "name": "artifactory",
+                "url": { "variable": "ARTIFACTORY_URL" },
+                "username": { "variable": "ARTIFACTORY_USER" },
+                "password": { "variable": "ARTIFACTORY_TOKEN" }
+              }
+            ]
+          }
+        }
+      ]
+    ]
+  }
+}
+```
+
+Supported `type` values: `localMaven`, `localDirectory`, `remotePublic`, `remotePrivate`. For private repos, credentials and URL accept either inline strings or `{ "variable": "ENV_VAR_NAME" }` to read from the environment at publish time.
+
+By default, `build:android` runs every declared publication. To pick specific publications or repositories from the command line, use the CLI flags:
+
+```sh
+npx expo-brownfield build:android --task publishReleasePublicationToCompanyRepository
+npx expo-brownfield tasks:android   # list available publish tasks and repositories
+```
+
+#### Fused publishing (single fat AAR)
+
+> **Version note:** requires minimum SDK 56. Earlier versions only support the per-module publishing above.
+
+The default publish flow emits one Maven coordinate per autolinked Expo module. For remote distribution, `--fused` collapses everything into one fat AAR per build variant:
+
+```sh
+npx expo-brownfield build:android --fused --repo MavenLocal
+```
+
+This publishes two coordinates — `{group}:{libraryName}-fused-release` and `{group}:{libraryName}-fused-debug`, which the host wires per build type:
+
+```kotlin
+dependencies {
+  releaseImplementation("com.example:mybrownfield-fused-release:1.0.0")
+  debugImplementation("com.example:mybrownfield-fused-debug:1.0.0")
+}
+```
+
+The debug AAR contains debug-compiled modules (dev menu, Metro reload); the release AAR embeds the JS bundle. Published metadata pins the matching React Native variant, so a debug host consuming only the release AAR still resolves release RN correctly.
+
+Not everything is fused: the React Native runtime, Kotlin stdlib, host-common libraries (Material, Guava, OkHttp, Fresco), `androidx.*`, and detected KMP umbrella modules stay external and are declared as ordinary POM dependencies. Gradle properties tune the behavior for unusual dependency graphs:
+
+| Property                              | Effect                                                                                                                               |
+| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `brownfield.fused.skip`               | Gradle project names to leave out of the AAR (pair with `strip-packages`).                                                           |
+| `brownfield.fused.strip-packages`     | Package prefixes to remove from `ExpoModulesPackageList` — avoids `NoClassDefFoundError` for skipped modules.                        |
+| `brownfield.fused.androidx-fuse`      | Extra `androidx.*` groups to fuse instead of keeping external.                                                                       |
+| `brownfield.fused.exclude-transitive` | Extra groups to keep external (still declared in the POM).                                                                           |
+| `brownfield.fused.host-provided`      | Groups the host already ships (e.g. Glide, Compose): excluded from the AAR **and** from the POM, so the host's version is untouched. |
+
+### iOS
+
+```sh
+npx expo-brownfield build:ios
+```
+
+Outputs to `./artifacts`. The set depends on the `ios.buildReactNativeFromSource` flag (set via `expo-build-properties`):
+
+- **`buildReactNativeFromSource: false`** (default on SDK 56+) — React Native is consumed as a prebuilt binary, so `build:ios` emits five xcframeworks side-by-side: `{TargetName}.xcframework`, `React.xcframework`, `ReactNativeDependencies.xcframework`, `ExpoModulesJSI.xcframework`, and `hermesvm.xcframework`.
+- **`buildReactNativeFromSource: true`** (default on SDK 55, opt-in on SDK 56+) — React Native is compiled from source and statically linked into the brownfield framework, leaving two xcframeworks: `{TargetName}.xcframework` and `hermesvm.xcframework`.
+
+To force source builds on SDK 56+, add `expo-build-properties` to `app.json`:
+
+```json
+{
+  "expo": {
+    "plugins": [
+      [
+        "expo-build-properties",
+        { "ios": { "buildReactNativeFromSource": true } }
+      ],
+      "expo-brownfield"
+    ]
+  }
+}
+```
+
+**Every xcframework in the produced set must be embedded in the consuming app** (Embed & Sign). The Swift Package output below (`--package`) wires this for you automatically.
+
+> **iOS deployment target:** the brownfield artifact inherits the Expo project's iOS deployment target (16.4 on SDK 56+). The consuming app's deployment target must be set to 16.4 or higher; otherwise Xcode will refuse to link the embedded frameworks. If the host app is on an older floor (e.g. iOS 14.0), bump its `IPHONEOS_DEPLOYMENT_TARGET` before adding the artifact.
+
+#### Ship as a Swift Package (recommended)
+
+Pass `--package [name]` to bundle the output as a self-contained Swift Package instead of separate `.xcframework` directories. The host iOS app then consumes it via **Add Package Dependencies → Add Local** in Xcode and links every bundled framework automatically — no manual drag-and-drop, no per-framework "Embed & Sign" toggles.
+
+```sh
+npx expo-brownfield build:ios --release --package MyAppPackage
+```
+
+The flag accepts an optional name. If omitted, the package is named `{TargetName}Artifacts`. The resulting directory is a complete Swift Package:
+
+```
+artifacts/MyAppPackage/
+├── Package.swift
+└── xcframeworks/
+    ├── MyAppPackage.xcframework
+    ├── hermesvm.xcframework
+    ├── React.xcframework
+    └── ReactNativeDependencies.xcframework
+```
+
+When `usePrecompiledModules` is enabled, the package directory is suffixed with the build flavor (e.g. `MyAppPackage-release/`) and includes every prebuilt Expo module xcframework. Run `build:ios --debug --package …` and `build:ios --release --package …` separately, and point your host app at the matching package for each build configuration.
+
+### Generate native projects for debugging
+
+To inspect or debug the generated native code, run prebuild:
+
+```sh
+npx expo prebuild
+```
+
+This creates `android/` and `ios/` directories containing the brownfield wrappers:
+
+**Android (Kotlin):** `ReactNativeHostManager`, `BrownfieldActivity`, `ReactNativeFragment`, `ReactNativeViewFactory`, `BrownfieldMessaging`.
+
+**iOS (Swift):** `ReactNativeHostManager`, `ReactNativeViewController`, `ReactNativeView` (SwiftUI), `BrownfieldMessaging`, `ReactNativeDelegate`.
+
+---
+
+## 3) Consume from the native app
+
+### Android
+
+#### Add the Maven dependency
+
+In `app/build.gradle.kts`:
+
+```kotlin
+dependencies {
+  implementation("com.example:mybrownfield:1.0.0")
+}
+```
+
+If consuming from the local Maven repo, register `mavenLocal()` in `settings.gradle.kts`:
+
+```kotlin
+dependencyResolutionManagement {
+  repositories {
+    google()
+    mavenCentral()
+    mavenLocal()
+  }
+}
+```
+
+> **Note:** `mavenLocal()` must be added under `dependencyResolutionManagement`, not the deprecated top-level `allprojects { repositories { ... } }` block.
+
+If the artifact is published to a remote Maven, declare that repository in the same `dependencyResolutionManagement` block instead — credentials follow Gradle's standard `maven { url = uri(...); credentials { username = ...; password = ... } }` form.
+
+#### Host app requirements
+
+- **`minSdk` 24 or higher** — React Native's floor. Hosts below it fail at manifest merge with `uses-sdk:minSdkVersion XX cannot be smaller than version 24`.
+- **Permissions merge in from the Expo modules** (e.g. storage permissions from media modules). Hosts that enforce a permission allowlist can strip unwanted entries in their manifest with `tools:node="remove"` or reconcile attribute conflicts with `tools:replace`.
+- **Native libraries ship for every ABI enabled at publish time.** Left unfiltered, this can multiply the host APK size. Constrain ABIs when publishing (`reactNativeArchitectures=arm64-v8a` in the Expo project's `gradle.properties`) or filter in the host with `ndk.abiFilters` / APK splits.
+
+#### Show a React Native screen
+
+Extend `BrownfieldActivity` and call `showReactNativeFragment()`:
+
+```kotlin
+import android.os.Bundle
+import com.example.mybrownfield.BrownfieldActivity
+import com.example.mybrownfield.showReactNativeFragment
+
+class ExpoActivity : BrownfieldActivity() {
+  override fun onCreate(savedInstanceState: Bundle?) {
+    super.onCreate(savedInstanceState)
+    showReactNativeFragment()
+  }
+}
+```
+
+`BrownfieldActivity` extends `AppCompatActivity` and forwards configuration changes. `showReactNativeFragment()` registers the React Native root fragment and wires native back-button handling automatically.
+
+Register the activity in `AndroidManifest.xml`:
+
+```xml
+<activity
+  android:name=".ExpoActivity"
+  android:theme="@style/Theme.AppCompat.Light.NoActionBar"
+  android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|screenSize|smallestScreenSize|uiMode"
+/>
+```
+
+Launch it from native code:
+
+```kotlin
+startActivity(Intent(this, ExpoActivity::class.java))
+```
+
+### iOS
+
+#### Add the artifacts to the Xcode project
+
+If you built a **Swift Package** (`build:ios --package …`):
+
+- In Xcode, **File → Add Package Dependencies… → Add Local…**, then select the generated package directory (e.g. `artifacts/MyAppPackage/`).
+- Add the package's product to your app target. Xcode links every bundled XCFramework through the aggregate library product — no manual "Embed & Sign" step.
+- If you produced both debug and release packages (because `usePrecompiledModules` is enabled), point the host app at the matching package per build configuration.
+
+If you built **standalone XCFrameworks** (default output):
+
+- Drag **every** `.xcframework` produced under `./artifacts` into the Xcode project navigator.
+- In the import dialog, check **Copy items if needed** and add them to your app target.
+- Under the app target's **General** tab → **Frameworks, Libraries, and Embedded Content**, set **every** framework to **Embed & Sign**. Forgetting one (commonly `hermesvm.xcframework`) is a leading cause of runtime "Library not loaded" crashes — see [./troubleshooting.md](./troubleshooting.md#ios-xcframework-signing-isolated-approach).
+
+#### Initialize React Native at app launch
+
+Call `ReactNativeHostManager.shared.initialize()` from `AppDelegate` **before any React Native view is created**. Initialization is asynchronous-friendly but must precede the first `ReactNativeViewController`/`ReactNativeView` instantiation.
+
+```swift
+import UIKit
+import MyAppBrownfield // Replace with your target name
+
+@main
+class AppDelegate: UIResponder, UIApplicationDelegate {
+  func application(
+    _ application: UIApplication,
+    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
+  ) -> Bool {
+    ReactNativeHostManager.shared.initialize()
+    return true
+  }
+}
+```
+
+#### Present a React Native view (UIKit)
+
+```swift
+import UIKit
+import MyAppBrownfield
+
+class ViewController: UIViewController {
+  @IBAction func openReactNative(_ sender: Any) {
+    let rnViewController = ReactNativeViewController(moduleName: "main")
+    navigationController?.pushViewController(rnViewController, animated: true)
+  }
+}
+```
+
+Pass props and launch options if needed:
+
+```swift
+let rnViewController = ReactNativeViewController(
+  moduleName: "main",
+  initialProps: ["userId": "123"],
+  launchOptions: [:]
+)
+```
+
+> **Note:** `moduleName` must match the name registered via `AppRegistry.registerComponent(...)` in the Expo project's JS entry point. The default Expo template registers `"main"`.
+
+#### Present a React Native view (SwiftUI)
+
+```swift
+import SwiftUI
+import MyAppBrownfield
+
+struct ContentView: View {
+  @State private var showReactNative = false
+
+  var body: some View {
+    Button("Open React Native") {
+      showReactNative = true
+    }
+    .fullScreenCover(isPresented: $showReactNative) {
+      ReactNativeView(moduleName: "main")
+    }
+  }
+}
+```
+
+---
+
+## Development vs. production
+
+### Development (debug builds)
+
+Start Metro in the Expo project:
+
+```sh
+npx expo start
+```
+
+Build and run the native app in debug. React Native screens load JS from the Metro dev server over HTTP with full hot reloading. The device or emulator must be able to reach the dev machine — see [./troubleshooting.md](./troubleshooting.md) if Metro connections fail.
+
+### Production (release builds)
+
+The JS bundle is embedded inside the AAR/XCFramework. Metro is not used. Build the native app in Release configuration and confirm the React Native screen loads.
+
+---
+
+## Related references
+
+- [./brownfield-integrated.md](./brownfield-integrated.md) — Alternative: add RN directly to the native build.
+- [./comparison.md](./comparison.md) — Decide between isolated and integrated.
+- [./troubleshooting.md](./troubleshooting.md) — Common Metro, build, and integration issues.
diff --git a/.agents/skills/expo-brownfield/references/comparison.md b/.agents/skills/expo-brownfield/references/comparison.md
new file mode 100644
index 0000000..8d06840
--- /dev/null
+++ b/.agents/skills/expo-brownfield/references/comparison.md
@@ -0,0 +1,63 @@
+# Brownfield: Isolated vs. Integrated
+
+Use this reference to choose between the two ways of adding React Native + Expo to an existing native app. If the team and constraints are already known, jump to one of:
+
+- [./brownfield-isolated.md](./brownfield-isolated.md) — RN as a prebuilt AAR / XCFramework.
+- [./brownfield-integrated.md](./brownfield-integrated.md) — RN added directly to existing Gradle / CocoaPods.
+
+## Quick decision rules
+
+- **Choose isolated** if the native team must consume React Native as a regular library (AAR or XCFramework) without installing Node, Yarn, or RN tooling.
+- **Choose isolated** if React Native and the native app live in **separate repositories**, or release on **different cadences**.
+- **Choose isolated** if the existing native build is heavily customized (Tuist, Bazel, Buck, custom Gradle plugins) and adding the React Native Gradle plugin or CocoaPods autolinking would be disruptive.
+- **Choose integrated** if a **single team** owns the native and React Native code and is willing to maintain the RN build chain inside the native project.
+- **Choose integrated** if you want **hot reload, JS source maps, and devtools** to "just work" inside the existing native build with no extra orchestration.
+- **Choose integrated** if you expect to add many Expo modules and want them autolinked by the standard Expo tooling rather than rebuilt into a fresh artifact each time.
+
+When in doubt — and especially when the question is "can the native team avoid React Native tooling?" — pick **isolated**.
+
+## Comparison
+
+| Dimension                                            | Isolated                                                                | Integrated                                                            |
+| ---------------------------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------- |
+| What ships to the native app                         | Prebuilt AAR + XCFramework                                              | React Native + Expo sources, autolinked into the existing build       |
+| Native team needs Node / Yarn / RN CLI               | **No**                                                                  | **Yes**                                                               |
+| Build-system footprint                               | Minimal — one Maven dependency, two embedded XCFrameworks               | Pervasive — React Native Gradle plugin, Podfile, autolinking, codegen |
+| Iteration speed for RN devs                          | Fast in isolation; native rebuild needed to pick up new artifact        | Fast end-to-end; one combined build                                   |
+| Dev-time hot reload                                  | Yes (via Metro, when running the consumer app in debug)                 | Yes (native build embeds Metro detection)                             |
+| Production JS bundle location                        | Embedded in the AAR/XCFramework                                         | Embedded in the APK/IPA by the RN Gradle plugin / Xcode build phase   |
+| Maintenance ownership                                | RN team owns the artifact pipeline; native team owns the consumer build | One team owns the unified build                                       |
+| Suitability for incremental adoption                 | High — easy to slot into one screen of an existing app                  | High, but with more setup before the first screen renders             |
+| Suitability for multi-repo / multi-team setups       | High                                                                    | Low — tends to require a monorepo                                     |
+| Risk of build-system conflicts with existing tooling | Low                                                                     | Higher (RN Gradle plugin, codegen, Podfile assumptions)               |
+| Re-publish workflow for RN changes                   | `npx expo-brownfield build:*` then bump the dependency                  | Rebuild the native app                                                |
+
+## Common scenarios
+
+**"React Native code is in `xyz-react` and the native apps are in `xyz-ios` and `xyz-android`. Each ships independently."**
+→ **Isolated.** Build versioned artifacts (`com.xyz:onboarding:1.4.0`, `Onboarding.xcframework`). Native apps pin a version like any other dependency.
+
+**"Our app uses a heavily customized Gradle setup with multiple variants and flavors."**
+→ **Isolated.** The RN Gradle plugin is opinionated about variant naming and bundle output paths; integrating cleanly with non-standard variants is non-trivial.
+
+**"We don't know yet whether RN will stay — we want to be able to remove it cheaply."**
+→ **Isolated.** Removing the dependency removes the framework; the native build is barely touched.
+
+**"Our iOS team uses Tuist and refuses to add Node to the iOS build."**
+→ **Isolated.** Ship an XCFramework. The iOS team adds two `.xcframework` files and one call to `ReactNativeHostManager.shared.initialize()` in `AppDelegate`. No Node, no CocoaPods changes to Expo.
+
+**"We have one repo, one team, and we want to deeply integrate React Native with the onboarding flow to an existing Android app."**
+→ **Integrated.** Move the existing `android-project` into `my-project/android/`, add the React Native Gradle plugin to `settings.gradle`, register `MainApplication`, and host the flow in a `ReactActivity`. One build pipeline.
+
+**"We want to use CNG on the RN code and not worry about manual RN upgrades."**
+→ **Isolated.** The AAR/XCFramework approach decouples the Expo RN version from the native app's build, so you can upgrade Expo and React Native independently of the native app's release cycle. The integrated approach requires more coordination between the RN version and the native app's build.
+
+## What is identical between the approaches
+
+- The React Native + Expo source code itself — the same Expo project, the same `app.json`, the same modules — only differs in **how** it is shipped.
+- The JavaScript module registered with `AppRegistry.registerComponent("main", () => App)` is the same; the native side passes the same `moduleName` string in both flows.
+
+## What is different at runtime
+
+- **Isolated** uses Expo's brownfield runtime wrappers — `ReactNativeHostManager`, `BrownfieldActivity`, `ReactNativeViewController`, `ReactNativeView`. These are generated by `npx expo-brownfield build:*` and bundled into the artifact.
+- **Integrated** uses the standard React Native runtime — `ReactActivity`, `ReactActivityDelegate`, `RCTReactNativeFactory`, `ExpoReactNativeFactory` — exposed by `react-native` and `expo` directly.
diff --git a/.agents/skills/expo-brownfield/references/troubleshooting.md b/.agents/skills/expo-brownfield/references/troubleshooting.md
new file mode 100644
index 0000000..f7725e4
--- /dev/null
+++ b/.agents/skills/expo-brownfield/references/troubleshooting.md
@@ -0,0 +1,88 @@
+# Brownfield Troubleshooting
+
+Cross-cutting issues that apply to both the isolated and integrated approaches. For approach-specific setup, see [./brownfield-isolated.md](./brownfield-isolated.md) or [./brownfield-integrated.md](./brownfield-integrated.md).
+
+## Build failures
+
+**Symptom:** Gradle or Xcode build fails after a config change, dependency upgrade, or Expo SDK bump.
+
+- **Integrated approach** — regenerate native projects from scratch:
+  ```sh
+  npx expo prebuild --clean
+  ```
+  Then `cd ios && pod install` and re-open the `.xcworkspace`.
+- **Isolated approach** — clear the local Maven cache and rebuild the artifact:
+  ```sh
+  rm -rf ~/.m2/repository/<group>/<libraryName>
+  npx expo-brownfield build:android
+  npx expo-brownfield build:ios
+  ```
+- For stubborn iOS issues, also delete `ios/build/`, `ios/Pods/`, and `ios/Podfile.lock`, then re-run `pod install`.
+- For stubborn Android issues, `./gradlew clean` and delete the project's `.gradle/` and `build/` directories.
+
+## Missing autolinked Expo modules
+
+**Symptom:** Compilation succeeds but a module throws "Native module cannot be null" / "Cannot find native module 'X'" at runtime.
+
+- Install with `npx expo install <package>` rather than plain `yarn add` — `expo install` picks the version compatible with the current SDK.
+- After installing a new module, rebuild the native app. Autolinking runs at native build time, not at JS bundle time.
+- For the **isolated approach**, you must re-run `npx expo-brownfield build:android|ios` after adding a module, and republish/re-embed the new artifact.
+
+## Metro connection
+
+**Symptom:** "Could not connect to development server" / red screen on launch in debug.
+
+- Ensure the device or emulator can reach the dev machine. The Android emulator can talk to the host via `10.0.2.2`; physical devices need a reachable LAN IP.
+- For physical Android devices on USB: `adb reverse tcp:8081 tcp:8081`.
+- Confirm Metro is actually running: `npx expo start` from the Expo project (or `yarn start` from the workspace root).
+- Verify the debug `AndroidManifest.xml` enables cleartext traffic — Android 9+ blocks HTTP by default. The debug variant should include `android:usesCleartextTraffic="true"` on `<application>`, or a `network_security_config` allowing the dev server.
+- iOS simulator: Metro should be reachable at `localhost:8081`. If it is not, check that ATS exceptions are still in place in `Info.plist` for `localhost` (the Expo template ships this by default).
+
+## iOS XCFramework signing (isolated approach)
+
+**Symptom:** App launches but immediately crashes with "Library not loaded" or codesign errors during archive.
+
+- **Every** xcframework produced by `build:ios` must be set to **Embed & Sign** in the app target's **Frameworks, Libraries, and Embedded Content** section. On SDK 56+ this is five frameworks: `{TargetName}.xcframework`, `React.xcframework`, `ReactNativeDependencies.xcframework`, `ExpoModulesJSI.xcframework`, and `hermesvm.xcframework`. On SDK 55 it's two: `{TargetName}.xcframework` and `hermesvm.xcframework`. Missing any of them is a common cause of runtime crashes.
+- The frameworks must be added to the _app target_, not a framework or extension target.
+- Prefer the Swift Package output (`build:ios --package`) — it links every bundled xcframework through one aggregate product, so you cannot forget one.
+
+## iOS architecture / simulator mismatch
+
+**Symptom:** "Building for iOS Simulator, but the linked library was built for iOS" or "Undefined symbols for architecture arm64".
+
+- The XCFramework includes both device and simulator slices. If a slice is missing, rebuild on the missing platform. The `expo-brownfield build:ios` command produces both by default.
+- On Apple Silicon simulators, do **not** set `EXCLUDED_ARCHS = arm64` for the simulator configuration — Apple Silicon simulators require `arm64`. The classic Rosetta-only exclusion is no longer correct.
+
+## Android `mavenLocal()` not found (isolated approach)
+
+**Symptom:** Gradle reports "Could not find com.example:mybrownfield:1.0.0" even after a successful `expo-brownfield build:android`.
+
+- `mavenLocal()` must be declared under `dependencyResolutionManagement { repositories { ... } }` in `settings.gradle.kts`, not the deprecated top-level `allprojects { repositories { ... } }` block. The deprecated form is silently ignored when `dependencyResolutionManagement` is present.
+- Confirm the artifact actually landed in `~/.m2`:
+  ```sh
+  find ~/.m2/repository -name "mybrownfield*"
+  ```
+- Verify the `group` and `libraryName` in the consumer's dependency line match what the plugin config emitted.
+
+## Module name mismatch
+
+**Symptom:** The native view loads but renders a blank screen, with "Application 'X' has not been registered" in the JS logs.
+
+- The `moduleName` passed to `ReactNativeViewController(moduleName: "main")` (iOS) or returned from `getMainComponentName()` (Android) must equal the name passed to `AppRegistry.registerComponent("main", () => App)` in the JS entry point.
+- The default Expo template registers `"main"`. If you changed the registration, update every native call site.
+
+## Monorepo: autolinking can't find the Expo project
+
+**Symptom:** Gradle or CocoaPods fails resolving Expo modules even though they are installed.
+
+- **Android (integrated):** set `root = file("../../my-project")` (or the correct relative path) inside the `react { ... }` block in `app/build.gradle`, and explicitly set the project root in `settings.gradle` before `expoAutolinking.useExpoModules()`.
+- **iOS (integrated):** set `:app_path` in `use_react_native!` to the absolute path of the Expo project root. Optionally pass `EXPO_PROJECT_ROOT=/abs/path` to `pod install`.
+- Confirm `node_modules/` is installed at the workspace root (`yarn install` from the monorepo root, not from the Expo project subdirectory).
+
+## After upgrading Expo SDK
+
+If the brownfield setup stops building after an SDK upgrade:
+
+- Re-run `npx expo install --fix` in the Expo project to align native module versions.
+- Rebuild the artifact (isolated) or run `npx expo prebuild --clean` (integrated).
+- Compare the new `templates/expo-template-bare-minimum` for the target SDK against your customized native files — Expo occasionally changes Gradle plugin names, Podfile helpers, or AppDelegate entry points across SDKs.
diff --git a/.agents/skills/expo-data-fetching/SKILL.md b/.agents/skills/expo-data-fetching/SKILL.md
new file mode 100644
index 0000000..4d5d0fc
--- /dev/null
+++ b/.agents/skills/expo-data-fetching/SKILL.md
@@ -0,0 +1,457 @@
+---
+name: expo-data-fetching
+description: Framework (OSS). Use when implementing or debugging ANY network request, API call, or data fetching. Covers fetch API, React Query, SWR, error handling, caching, offline support, and Expo Router data loaders (`useLoaderData`).
+version: 1.0.0
+license: MIT
+---
+
+# Expo Networking
+
+**You MUST use this skill for ANY networking work including API requests, data fetching, caching, or network debugging.**
+
+## References
+
+Consult these resources as needed:
+
+```
+references/
+  expo-router-loaders.md        Route-level data loading with Expo Router loaders (web, SDK 55+)
+  offline-and-cancellation.md   NetInfo network status, offline-first React Query, AbortController
+```
+
+## When to Use
+
+Use this skill when:
+
+- Implementing API requests
+- Setting up data fetching (React Query, SWR)
+- Using Expo Router data loaders (`useLoaderData`, web SDK 55+)
+- Debugging network failures
+- Implementing caching strategies
+- Handling offline scenarios
+- Authentication/token management
+- Configuring API URLs and environment variables
+
+## Preferences
+
+- Avoid axios, prefer expo/fetch
+
+## Common Issues & Solutions
+
+### 1. Basic Fetch Usage
+
+**Simple GET request**:
+
+```tsx
+const fetchUser = async (userId: string) => {
+  const response = await fetch(`https://api.example.com/users/${userId}`);
+
+  if (!response.ok) {
+    throw new Error(`HTTP error! status: ${response.status}`);
+  }
+
+  return response.json();
+};
+```
+
+**POST request with body**:
+
+```tsx
+const createUser = async (userData: UserData) => {
+  const response = await fetch("https://api.example.com/users", {
+    method: "POST",
+    headers: {
+      "Content-Type": "application/json",
+      Authorization: `Bearer ${token}`,
+    },
+    body: JSON.stringify(userData),
+  });
+
+  if (!response.ok) {
+    const error = await response.json();
+    throw new Error(error.message);
+  }
+
+  return response.json();
+};
+```
+
+---
+
+### 2. React Query (TanStack Query)
+
+**Setup**:
+
+```tsx
+// app/_layout.tsx
+import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
+
+const queryClient = new QueryClient({
+  defaultOptions: {
+    queries: {
+      staleTime: 1000 * 60 * 5, // 5 minutes
+      retry: 2,
+    },
+  },
+});
+
+export default function RootLayout() {
+  return (
+    <QueryClientProvider client={queryClient}>
+      <Stack />
+    </QueryClientProvider>
+  );
+}
+```
+
+**Fetching data**:
+
+```tsx
+import { useQuery } from "@tanstack/react-query";
+
+function UserProfile({ userId }: { userId: string }) {
+  const { data, isLoading, error, refetch } = useQuery({
+    queryKey: ["user", userId],
+    queryFn: () => fetchUser(userId),
+  });
+
+  if (isLoading) return <Loading />;
+  if (error) return <Error message={error.message} />;
+
+  return <Profile user={data} />;
+}
+```
+
+**Mutations**:
+
+```tsx
+import { useMutation, useQueryClient } from "@tanstack/react-query";
+
+function CreateUserForm() {
+  const queryClient = useQueryClient();
+
+  const mutation = useMutation({
+    mutationFn: createUser,
+    onSuccess: () => {
+      // Invalidate and refetch
+      queryClient.invalidateQueries({ queryKey: ["users"] });
+    },
+  });
+
+  const handleSubmit = (data: UserData) => {
+    mutation.mutate(data);
+  };
+
+  return <Form onSubmit={handleSubmit} isLoading={mutation.isPending} />;
+}
+```
+
+---
+
+### 3. Error Handling
+
+**Comprehensive error handling**:
+
+```tsx
+class ApiError extends Error {
+  constructor(message: string, public status: number, public code?: string) {
+    super(message);
+    this.name = "ApiError";
+  }
+}
+
+const fetchWithErrorHandling = async (url: string, options?: RequestInit) => {
+  try {
+    const response = await fetch(url, options);
+
+    if (!response.ok) {
+      const error = await response.json().catch(() => ({}));
+      throw new ApiError(
+        error.message || "Request failed",
+        response.status,
+        error.code
+      );
+    }
+
+    return response.json();
+  } catch (error) {
+    if (error instanceof ApiError) {
+      throw error;
+    }
+    // Network error (no internet, timeout, etc.)
+    throw new ApiError("Network error", 0, "NETWORK_ERROR");
+  }
+};
+```
+
+**Retry logic**:
+
+```tsx
+const fetchWithRetry = async (
+  url: string,
+  options?: RequestInit,
+  retries = 3
+) => {
+  for (let i = 0; i < retries; i++) {
+    try {
+      return await fetchWithErrorHandling(url, options);
+    } catch (error) {
+      if (i === retries - 1) throw error;
+      // Exponential backoff
+      await new Promise((r) => setTimeout(r, Math.pow(2, i) * 1000));
+    }
+  }
+};
+```
+
+---
+
+### 4. Authentication
+
+**Token management**:
+
+```tsx
+import * as SecureStore from "expo-secure-store";
+
+const TOKEN_KEY = "auth_token";
+
+export const auth = {
+  getToken: () => SecureStore.getItemAsync(TOKEN_KEY),
+  setToken: (token: string) => SecureStore.setItemAsync(TOKEN_KEY, token),
+  removeToken: () => SecureStore.deleteItemAsync(TOKEN_KEY),
+};
+
+// Authenticated fetch wrapper
+const authFetch = async (url: string, options: RequestInit = {}) => {
+  const token = await auth.getToken();
+
+  return fetch(url, {
+    ...options,
+    headers: {
+      ...options.headers,
+      Authorization: token ? `Bearer ${token}` : "",
+    },
+  });
+};
+```
+
+**Token refresh**:
+
+```tsx
+let isRefreshing = false;
+let refreshPromise: Promise<string> | null = null;
+
+const getValidToken = async (): Promise<string> => {
+  const token = await auth.getToken();
+
+  if (!token || isTokenExpired(token)) {
+    if (!isRefreshing) {
+      isRefreshing = true;
+      refreshPromise = refreshToken().finally(() => {
+        isRefreshing = false;
+        refreshPromise = null;
+      });
+    }
+    return refreshPromise!;
+  }
+
+  return token;
+};
+```
+
+---
+
+### 5. Offline Support
+
+Network-status detection with NetInfo and offline-first React Query setup: see [./references/offline-and-cancellation.md](./references/offline-and-cancellation.md).
+
+---
+
+### 6. Environment Variables
+
+**Using environment variables for API configuration**:
+
+Expo supports environment variables with the `EXPO_PUBLIC_` prefix. These are inlined at build time and available in your JavaScript code.
+
+```tsx
+// .env
+EXPO_PUBLIC_API_URL=https://api.example.com
+EXPO_PUBLIC_API_VERSION=v1
+
+// Usage in code
+const API_URL = process.env.EXPO_PUBLIC_API_URL;
+
+const fetchUsers = async () => {
+  const response = await fetch(`${API_URL}/users`);
+  return response.json();
+};
+```
+
+**Environment-specific configuration**:
+
+```tsx
+// .env.development
+EXPO_PUBLIC_API_URL=http://localhost:3000
+
+// .env.production
+EXPO_PUBLIC_API_URL=https://api.production.com
+```
+
+**Creating an API client with environment config**:
+
+```tsx
+// api/client.ts
+const BASE_URL = process.env.EXPO_PUBLIC_API_URL;
+
+if (!BASE_URL) {
+  throw new Error("EXPO_PUBLIC_API_URL is not defined");
+}
+
+export const apiClient = {
+  get: async <T,>(path: string): Promise<T> => {
+    const response = await fetch(`${BASE_URL}${path}`);
+    if (!response.ok) throw new Error(`HTTP ${response.status}`);
+    return response.json();
+  },
+
+  post: async <T,>(path: string, body: unknown): Promise<T> => {
+    const response = await fetch(`${BASE_URL}${path}`, {
+      method: "POST",
+      headers: { "Content-Type": "application/json" },
+      body: JSON.stringify(body),
+    });
+    if (!response.ok) throw new Error(`HTTP ${response.status}`);
+    return response.json();
+  },
+};
+```
+
+**Important notes**:
+
+- Only variables prefixed with `EXPO_PUBLIC_` are exposed to the client bundle
+- Never put secrets (API keys with write access, database passwords) in `EXPO_PUBLIC_` variables—they're visible in the built app
+- Environment variables are inlined at **build time**, not runtime
+- Restart the dev server after changing `.env` files
+- For server-side secrets in API routes, use variables without the `EXPO_PUBLIC_` prefix
+
+**TypeScript support**:
+
+```tsx
+// types/env.d.ts
+declare global {
+  namespace NodeJS {
+    interface ProcessEnv {
+      EXPO_PUBLIC_API_URL: string;
+      EXPO_PUBLIC_API_VERSION?: string;
+    }
+  }
+}
+
+export {};
+```
+
+---
+
+### 7. Request Cancellation
+
+AbortController on unmount (React Query cancels automatically): see [./references/offline-and-cancellation.md](./references/offline-and-cancellation.md).
+
+---
+
+## Decision Tree
+
+```
+User asks about networking
+  |-- Route-level data loading (web, SDK 55+)?
+  |   \-- Expo Router loaders — see references/expo-router-loaders.md
+  |
+  |-- Basic fetch?
+  |   \-- Use fetch API with error handling
+  |
+  |-- Need caching/state management?
+  |   |-- Complex app -> React Query (TanStack Query)
+  |   \-- Simpler needs -> SWR or custom hooks
+  |
+  |-- Authentication?
+  |   |-- Token storage -> expo-secure-store
+  |   \-- Token refresh -> Implement refresh flow
+  |
+  |-- Error handling?
+  |   |-- Network errors -> Check connectivity first
+  |   |-- HTTP errors -> Parse response, throw typed errors
+  |   \-- Retries -> Exponential backoff
+  |
+  |-- Offline support?
+  |   |-- Check status -> NetInfo
+  |   \-- Queue requests -> React Query persistence
+  |
+  |-- Environment/API config?
+  |   |-- Client-side URLs -> EXPO_PUBLIC_ prefix in .env
+  |   |-- Server secrets -> Non-prefixed env vars (API routes only)
+  |   \-- Multiple environments -> .env.development, .env.production
+  |
+  \-- Performance?
+      |-- Caching -> React Query with staleTime
+      |-- Deduplication -> React Query handles this
+      \-- Cancellation -> AbortController or React Query
+```
+
+## Common Mistakes
+
+**Wrong: No error handling**
+
+```tsx
+const data = await fetch(url).then((r) => r.json());
+```
+
+**Right: Check response status**
+
+```tsx
+const response = await fetch(url);
+if (!response.ok) throw new Error(`HTTP ${response.status}`);
+const data = await response.json();
+```
+
+**Wrong: Storing tokens in AsyncStorage**
+
+```tsx
+await AsyncStorage.setItem("token", token); // Not secure!
+```
+
+**Right: Use SecureStore for sensitive data**
+
+```tsx
+await SecureStore.setItemAsync("token", token);
+```
+
+## Example Invocations
+
+User: "How do I make API calls in React Native?"
+-> Use fetch, wrap with error handling
+
+User: "Should I use React Query or SWR?"
+-> React Query for complex apps, SWR for simpler needs
+
+User: "My app needs to work offline"
+-> Use NetInfo for status, React Query persistence for caching
+
+User: "How do I handle authentication tokens?"
+-> Store in expo-secure-store, implement refresh flow
+
+User: "API calls are slow"
+-> Check caching strategy, use React Query staleTime
+User: "How do I configure different API URLs for dev and prod?"
+-> Use `EXPO_PUBLIC_` env vars with .env.development and .env.production files
+User: "Where should I put my API key?"
+-> Client-safe keys: `EXPO_PUBLIC_` in .env. Secret keys: non-prefixed env vars in API routes only
+
+User: "How do I load data for a page in Expo Router?"
+-> See references/expo-router-loaders.md for route-level loaders (web, SDK 55+). For native, use React Query or fetch.
+
+## 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-data-fetching" "<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.
diff --git a/.agents/skills/expo-data-fetching/agents/openai.yaml b/.agents/skills/expo-data-fetching/agents/openai.yaml
new file mode 100644
index 0000000..8e942bc
--- /dev/null
+++ b/.agents/skills/expo-data-fetching/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Expo Data Fetching"
+  short_description: "Implement and debug Expo network requests, caching, auth, offline support, and Expo Router data loaders"
+  default_prompt: "Use $expo-data-fetching for Expo data fetching work: fetch wrappers, React Query or SWR setup, error handling, retry/cancellation, authenticated requests, environment-based API URLs, offline behavior, and Expo Router loaders."
diff --git a/.agents/skills/expo-data-fetching/references/expo-router-loaders.md b/.agents/skills/expo-data-fetching/references/expo-router-loaders.md
new file mode 100644
index 0000000..ca3942c
--- /dev/null
+++ b/.agents/skills/expo-data-fetching/references/expo-router-loaders.md
@@ -0,0 +1,341 @@
+# Expo Router Data Loaders
+
+Route-level data loading for web apps using Expo SDK 55+. Loaders are async functions exported from route files that load data before the route renders, following the Remix/React Router loader model.
+
+**Dual execution model:**
+
+- **Initial page load (SSR):** The loader runs server-side. Its return value is serialized as JSON and embedded in the HTML response.
+- **Client-side navigation:** The browser fetches the loader data from the server via HTTP. The route renders once the data arrives.
+
+You write one function and the framework manages when and how it executes.
+
+## Configuration
+
+**Requirements:** Expo SDK 55+, web output mode (`npx expo serve` or `npx expo export --platform web`) set in `app.json` or `app.config.js`.
+
+**Server rendering:**
+
+```json
+{
+  "expo": {
+    "web": {
+      "output": "server"
+    },
+    "plugins": [
+      ["expo-router", {
+        "unstable_useServerDataLoaders": true,
+        "unstable_useServerRendering": true
+      }]
+    ]
+  }
+}
+```
+
+**Static/SSG:**
+
+```json
+{
+  "expo": {
+    "web": {
+      "output": "static"
+    },
+    "plugins": [
+      ["expo-router", {
+        "unstable_useServerDataLoaders": true
+      }]
+    ]
+  }
+}
+```
+
+| | `"server"` | `"static"` |
+|---|-----------|------------|
+| `unstable_useServerDataLoaders` | Required | Required |
+| `unstable_useServerRendering` | Required | Not required |
+| Loader runs on | Live server (every request) | Build time (static generation) |
+| `request` object | Full access (headers, cookies) | Not available |
+| Hosting | Node.js server (EAS Hosting) | Any static host (Netlify, Vercel, S3) |
+
+## Imports
+
+Loaders use two packages:
+
+- **`expo-router`** — `useLoaderData` hook
+- **`expo-server`** — `LoaderFunction` type, `StatusError`, `setResponseHeaders`. Always available (dependency of `expo-router`), no install needed.
+
+## Basic Loader
+
+For loaders without params, a plain async function works:
+
+```tsx
+// app/posts/index.tsx
+import { Suspense } from "react";
+import { useLoaderData } from "expo-router";
+import { ActivityIndicator, View, Text } from "react-native";
+
+export async function loader() {
+  const response = await fetch("https://api.example.com/posts");
+  const posts = await response.json();
+  return { posts };
+}
+
+function PostList() {
+  const { posts } = useLoaderData<typeof loader>();
+
+  return (
+    <View>
+      {posts.map((post) => (
+        <Text key={post.id}>{post.title}</Text>
+      ))}
+    </View>
+  );
+}
+
+export default function Posts() {
+  return (
+    <Suspense fallback={<ActivityIndicator size="large" />}>
+      <PostList />
+    </Suspense>
+  );
+}
+```
+
+`useLoaderData` is typed via `typeof loader` — the generic parameter infers the return type.
+
+## Dynamic Routes
+
+For loaders with params, use the `LoaderFunction<T>` type from `expo-server`. The first argument is the request (an immutable `Request`-like object, or `undefined` in static mode). The second is `params` (`Record<string, string | string[]>`), which contains **path parameters only**. Access individual params with a cast like `params.id as string`. For query parameters, use `new URL(request.url).searchParams`:
+
+```tsx
+// app/posts/[id].tsx
+import { Suspense } from "react";
+import { useLoaderData } from "expo-router";
+import { StatusError, type LoaderFunction } from "expo-server";
+import { ActivityIndicator, View, Text } from "react-native";
+
+type Post = {
+  id: number;
+  title: string;
+  body: string;
+};
+
+export const loader: LoaderFunction<{ post: Post }> = async (
+  request,
+  params,
+) => {
+  const id = params.id as string;
+  const response = await fetch(`https://api.example.com/posts/${id}`);
+
+  if (!response.ok) {
+    throw new StatusError(404, `Post ${id} not found`);
+  }
+
+  const post: Post = await response.json();
+  return { post };
+};
+
+function PostContent() {
+  const { post } = useLoaderData<typeof loader>();
+
+  return (
+    <View>
+      <Text>{post.title}</Text>
+      <Text>{post.body}</Text>
+    </View>
+  );
+}
+
+export default function PostDetail() {
+  return (
+    <Suspense fallback={<ActivityIndicator size="large" />}>
+      <PostContent />
+    </Suspense>
+  );
+}
+```
+
+Catch-all routes access `params.slug` the same way:
+
+```tsx
+// app/docs/[...slug].tsx
+import { type LoaderFunction } from "expo-server";
+
+type Doc = { title: string; content: string };
+
+export const loader: LoaderFunction<{ doc: Doc }> = async (request, params) => {
+  const slug = params.slug as string[];
+  const path = slug.join("/");
+  const doc = await fetchDoc(path);
+  return { doc };
+};
+```
+
+Query parameters are available via the `request` object (server output mode only):
+
+```tsx
+// app/search.tsx
+import { type LoaderFunction } from "expo-server";
+
+export const loader: LoaderFunction<{ results: any[]; query: string }> = async (request) => {
+  // Assuming request.url is `/search?q=expo&page=2`
+  const url = new URL(request!.url);
+  const query = url.searchParams.get("q") ?? "";
+  const page = Number(url.searchParams.get("page") ?? "1");
+
+  const results = await fetchSearchResults(query, page);
+  return { results, query };
+};
+```
+
+## Server-Side Secrets & Request Access
+
+Loaders run on the server, so you can access secrets and server-only resources directly:
+
+```tsx
+// app/dashboard.tsx
+import { type LoaderFunction } from "expo-server";
+
+export const loader: LoaderFunction<{ balance: any; isAuthenticated: boolean }> = async (
+  request,
+  params,
+) => {
+  const data = await fetch("https://api.stripe.com/v1/balance", {
+    headers: {
+      Authorization: `Bearer ${process.env.STRIPE_SECRET_KEY}`,
+    },
+  });
+
+  const sessionToken = request?.headers.get("cookie")?.match(/session=([^;]+)/)?.[1];
+
+  const balance = await data.json();
+  return { balance, isAuthenticated: !!sessionToken };
+};
+```
+
+The `request` object is available in server output mode. In static output mode, `request` is always `undefined`.
+
+## Response Utilities
+
+### Setting Response Headers
+
+```tsx
+// app/products.tsx
+import { setResponseHeaders } from "expo-server";
+
+export async function loader() {
+  setResponseHeaders({
+    "Cache-Control": "public, max-age=300",
+  });
+
+  const products = await fetchProducts();
+  return { products };
+}
+```
+
+### Throwing HTTP Errors
+
+```tsx
+// app/products/[id].tsx
+import { StatusError, type LoaderFunction } from "expo-server";
+
+export const loader: LoaderFunction<{ product: Product }> = async (request, params) => {
+  const id = params.id as string;
+  const product = await fetchProduct(id);
+
+  if (!product) {
+    throw new StatusError(404, "Product not found");
+  }
+
+  return { product };
+};
+```
+
+## Suspense & Error Boundaries
+
+### Loading States with Suspense
+
+`useLoaderData()` suspends during client-side navigation. Push it into a child component and wrap with `<Suspense>`:
+
+```tsx
+// app/posts/index.tsx
+import { Suspense } from "react";
+import { useLoaderData } from "expo-router";
+import { ActivityIndicator, View, Text } from "react-native";
+
+export async function loader() {
+  const response = await fetch("https://api.example.com/posts");
+  return { posts: await response.json() };
+}
+
+function PostList() {
+  const { posts } = useLoaderData<typeof loader>();
+
+  return (
+    <View>
+      {posts.map((post) => (
+        <Text key={post.id}>{post.title}</Text>
+      ))}
+    </View>
+  );
+}
+
+export default function Posts() {
+  return (
+    <Suspense
+      fallback={
+        <View style={{ flex: 1, justifyContent: "center", alignItems: "center" }}>
+          <ActivityIndicator size="large" />
+        </View>
+      }
+    >
+      <PostList />
+    </Suspense>
+  );
+}
+```
+
+The `<Suspense>` boundary must be above the component calling `useLoaderData()`. On initial page load the data is already in the HTML, suspension only occurs during client-side navigation.
+
+### Error Boundaries
+
+```tsx
+// app/posts/[id].tsx
+export function ErrorBoundary({ error }: { error: Error }) {
+  return (
+    <View style={{ flex: 1, justifyContent: "center", alignItems: "center" }}>
+      <Text>Error: {error.message}</Text>
+    </View>
+  );
+}
+```
+
+When a loader throws (including `StatusError`), the nearest `ErrorBoundary` catches it.
+
+## Static vs Server Rendering
+
+| | Server (`"server"`) | Static (`"static"`) |
+|---|---|---|
+| **When loader runs** | Every request (live) | At build time (`npx expo export`) |
+| **Data freshness** | Fresh on initial server request | Stale until next build |
+| **`request` object** | Full access | Not available |
+| **Hosting** | Node.js server (EAS Hosting) | Any static host |
+| **Use case** | Personalized/dynamic content | Marketing pages, blogs, docs |
+
+**Choose server** when data changes frequently or content is personalized (cookies, auth, headers).
+
+**Choose static** when content is the same for all users and changes infrequently.
+
+## Best Practices
+
+- Loaders are web-only; use client-side fetching (React Query, fetch) for native
+- Loaders cannot be used in `_layout` files — only in route files
+- Use `LoaderFunction<T>` from `expo-server` to type loaders that use params
+- The request object is immutable — use optional chaining (`request?.headers`) as it may be `undefined` in static mode
+- Return only JSON-serializable values (no `Date`, `Map`, `Set`, class instances, functions)
+- Use non-prefixed `process.env` vars for secrets in loaders, not `EXPO_PUBLIC_` (which is embedded in the client bundle)
+- Use `StatusError` from `expo-server` for HTTP error responses
+- Use `setResponseHeaders` from `expo-server` to set headers
+- Export `ErrorBoundary` from route files to handle loader failures gracefully
+- Validate and sanitize user input (params, query strings) before using in database queries or API calls
+- Handle errors gracefully with try/catch; log server-side for debugging
+- Loader data is currently cached for the session. This is a known limitation that will be lifted in a future release
diff --git a/.agents/skills/expo-data-fetching/references/offline-and-cancellation.md b/.agents/skills/expo-data-fetching/references/offline-and-cancellation.md
new file mode 100644
index 0000000..596bbed
--- /dev/null
+++ b/.agents/skills/expo-data-fetching/references/offline-and-cancellation.md
@@ -0,0 +1,68 @@
+# Offline Support & Request Cancellation
+
+Companion reference for `expo-data-fetching`.
+
+## Offline Support
+
+**Check network status**:
+
+```tsx
+import NetInfo from "@react-native-community/netinfo";
+
+// Hook for network status
+function useNetworkStatus() {
+  const [isOnline, setIsOnline] = useState(true);
+
+  useEffect(() => {
+    return NetInfo.addEventListener((state) => {
+      setIsOnline(state.isConnected ?? true);
+    });
+  }, []);
+
+  return isOnline;
+}
+```
+
+**Offline-first with React Query**:
+
+```tsx
+import { onlineManager } from "@tanstack/react-query";
+import NetInfo from "@react-native-community/netinfo";
+
+// Sync React Query with network status
+onlineManager.setEventListener((setOnline) => {
+  return NetInfo.addEventListener((state) => {
+    setOnline(state.isConnected ?? true);
+  });
+});
+
+// Queries will pause when offline and resume when online
+```
+
+## Request Cancellation
+
+**Cancel on unmount**:
+
+```tsx
+useEffect(() => {
+  const controller = new AbortController();
+
+  fetch(url, { signal: controller.signal })
+    .then((response) => response.json())
+    .then(setData)
+    .catch((error) => {
+      if (error.name !== "AbortError") {
+        setError(error);
+      }
+    });
+
+  return () => controller.abort();
+}, [url]);
+```
+
+**With React Query** (automatic):
+
+```tsx
+// React Query automatically cancels requests when queries are invalidated
+// or components unmount
+```
diff --git a/.agents/skills/expo-design-system/SKILL.md b/.agents/skills/expo-design-system/SKILL.md
new file mode 100644
index 0000000..9fc4f1e
--- /dev/null
+++ b/.agents/skills/expo-design-system/SKILL.md
@@ -0,0 +1,356 @@
+---
+name: expo-design-system
+description: 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/size/state 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 / theme/), 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/CSS setup use expo-tailwind-setup; for folder layout of a new app use expo-project-structure.
+version: 1.0.0
+license: MIT
+---
+
+# Expo Design Systems
+
+Make 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.
+
+Sibling skills own the layers around this one:
+
+- `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**.
+- `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.
+- `expo-project-structure` - folder skeleton for new apps.
+
+## References
+
+Consult these resources as needed:
+
+```
+references/
+  audit.md      Audit an existing app for design-system drift: grep checks,
+                scoring rubric, incremental adoption plan, and templates for
+                documenting or extending components
+```
+
+## Adopt Before You Build
+
+In an app that already has screens, the first move is detection, not construction. Before writing any token file:
+
+1. **Look for a declared system.** Check `package.json` for a styling library - NativeWind/Tailwind (use `expo-tailwind-setup`), Tamagui, Restyle, Unistyles, styled-components. Then look for a token file: `theme.ts`, `src/theme/`, `constants/theme.ts`, or `constants/Colors.ts` (the create-expo-app default).
+2. **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.
+3. **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/audit.md` §5).
+4. **Never introduce a second system beside an existing one.** A fresh `src/theme/` next to a Tamagui config is design-system drift, not adoption.
+
+Only when nothing exists do the defaults below apply as written.
+
+## The Theme
+
+In an app without an existing system, all design tokens live under `src/theme/`. In a project without a `src/` folder (the default `create-expo-app` template has `app/`, `components/`, and `constants/` at the root), use the equivalent top-level location - typically `theme/` or the existing `constants/` - and keep the same file layout. Start small and split by token class as it grows:
+
+```
+src/theme/
+  colors.ts       # see expo-native-ui "Colors" for the palette pattern
+  spacing.ts
+  typography.ts
+  radius.ts
+  shadows.ts
+  motion.ts
+  index.ts        # re-exports everything: import { spacing, type } from "@/theme"
+```
+
+A brand-new app can begin with a single `src/theme.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.
+
+Rules that make a theme worth having:
+
+- **Every repeated visual value is a token.** A literal that appears twice belongs in the theme.
+- **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.
+- **Never hardcode** hex colors, font sizes, or spacing multiples outside `src/theme/`. One-off values that are genuinely local (an icon's 17px optical nudge) may stay inline - with a comment saying why.
+
+### Colors
+
+Build the palette from platform semantic colors: `Color` from `expo-router` wrapped in `Platform.select`, centralized in `theme/colors.ts`. Semantic colors resolve on-device and adapt to light/dark automatically - prefer them for backgrounds, labels, and separators. (`expo-native-ui` "Colors" covers the full palette and rationale; the minimal version is:)
+
+```tsx
+// theme/colors.ts
+import { Platform } from "react-native";
+import { Color } from "expo-router";
+
+export const colors = {
+  label: Platform.select({
+    ios: Color.ios.label,
+    android: Color.android.dynamic.onSurface,
+    default: "#000000",
+  })!,
+  secondaryLabel: Platform.select({
+    ios: Color.ios.secondaryLabel,
+    android: Color.android.dynamic.onSurfaceVariant,
+    default: "#3c3c43",
+  })!,
+  separator: Platform.select({
+    ios: Color.ios.separator,
+    android: Color.android.dynamic.outlineVariant,
+    default: "#c6c6c8",
+  })!,
+  systemBackground: Platform.select({
+    ios: Color.ios.systemBackground,
+    android: Color.android.dynamic.surface,
+    default: "#ffffff",
+  })!,
+  systemBlue: Platform.select({
+    ios: Color.ios.systemBlue,
+    android: Color.android.dynamic.primary,
+    default: "#007aff",
+  })!,
+  // Deliberately fixed: text on a tinted (accent) surface stays white in both modes.
+  onTint: "#ffffff",
+};
+```
+
+Add brand colors as explicit light/dark pairs only when the brand requires values the platform doesn't provide:
+
+```tsx
+// theme/colors.ts (brand additions)
+import { useColorScheme } from "react-native";
+
+const brandPalette = {
+  light: { accent: "#5B21B6", accentContrast: "#FFFFFF" },
+  dark: { accent: "#A78BFA", accentContrast: "#1E1B4B" },
+} as const;
+
+export function useBrandColors() {
+  const scheme = useColorScheme();
+  return brandPalette[scheme === "dark" ? "dark" : "light"];
+}
+```
+
+Keep the brand set tiny (accent, accentContrast, maybe a tint per feature). Everything else stays semantic.
+
+**Static-safe vs hook-only.** The two patterns above have different reach - keep the boundary explicit:
+
+- Semantic/platform colors (`colors` above) are **static-safe**: they resolve on-device, so plain token files like `theme/typography.ts` can import them at module scope.
+- Brand light/dark 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.
+- 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.
+
+### Spacing
+
+One scale, based on a 4-point grid. Name steps by size, not by use:
+
+```tsx
+// theme/spacing.ts
+export const spacing = {
+  xs: 4,
+  sm: 8,
+  md: 16,
+  lg: 24,
+  xl: 32,
+  xxl: 48,
+} as const;
+```
+
+- Use `gap` with spacing tokens for layout rhythm (`expo-native-ui` prefers gap over margin).
+- Screen edge padding is `spacing.md` unless the design says otherwise - pick one and keep it.
+- If a layout needs a value between steps, use the nearest step. The grid is the point.
+- 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.
+
+### Typography
+
+Define named text styles, not raw font sizes. Mirror the platform ramp (Apple text styles) so sizes feel native:
+
+```tsx
+// theme/typography.ts
+import { TextStyle } from "react-native";
+import { colors } from "./colors";
+
+export const type = {
+  largeTitle: { fontSize: 34, fontWeight: "700", color: colors.label },
+  title: { fontSize: 22, fontWeight: "600", color: colors.label },
+  headline: { fontSize: 17, fontWeight: "600", color: colors.label },
+  body: { fontSize: 17, fontWeight: "400", color: colors.label },
+  subhead: { fontSize: 15, fontWeight: "400", color: colors.secondaryLabel },
+  caption: { fontSize: 12, fontWeight: "400", color: colors.secondaryLabel },
+} as const satisfies Record<string, TextStyle>;
+```
+
+If 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:
+
+```tsx
+headline: { fontSize: 17, fontFamily: "SFProRounded-Semibold", color: colors.label },
+```
+
+Expose them through one component so screens never touch `fontSize`:
+
+```tsx
+// components/themed-text.tsx
+import { Text, TextProps } from "react-native";
+import { type } from "@/theme";
+
+export function ThemedText({
+  variant = "body",
+  style,
+  ...props
+}: TextProps & { variant?: keyof typeof type }) {
+  return <Text style={[type[variant], style]} {...props} />;
+}
+```
+
+Screen titles still come from the navigation stack header (`expo-native-ui` rule), so `largeTitle` is mostly for non-stack contexts.
+
+### Radius
+
+```tsx
+// theme/radius.ts
+export const radius = {
+  sm: 8,
+  md: 12,
+  lg: 16,
+  full: 9999, // capsules
+} as const;
+```
+
+Pair every non-capsule radius with `borderCurve: "continuous"` (per `expo-native-ui`).
+
+### Shadows
+
+Shadows are `boxShadow` strings (never legacy shadow/elevation props - see `expo-native-ui`). Two or three elevation levels are enough:
+
+```tsx
+// theme/shadows.ts
+export const shadows = {
+  card: "0 1px 2px rgba(0, 0, 0, 0.05)",
+  raised: "0 4px 12px rgba(0, 0, 0, 0.10)",
+  overlay: "0 8px 24px rgba(0, 0, 0, 0.18)",
+} as const;
+```
+
+### Motion
+
+Durations and shared spring/easing configs, so animations across the app feel related:
+
+```tsx
+// theme/motion.ts
+export const motion = {
+  fast: 150, // state feedback: press, toggle
+  base: 250, // element transitions: enter/exit
+  slow: 400, // large surfaces: sheets, screens
+} as const;
+```
+
+Reanimated caveat: don't pass `Color`/`PlatformColor` token values into Reanimated styles - use static colors there (see `expo-native-ui`).
+
+## Reusable Components
+
+The theme controls values; components control structure. Shared primitives live in `src/components/` (see `expo-project-structure`).
+
+### The component contract
+
+Every design-system primitive defines, explicitly:
+
+- **Variants** - visual intent: `primary`, `secondary`, `ghost`, `destructive`. Add a variant only when a real screen needs it.
+- **Sizes** - `sm`, `md`, `lg`. Default `md`. Sizes map to spacing/typography tokens, never to fresh numbers.
+- **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.
+- **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.
+
+```tsx
+// components/button.tsx
+import { Pressable, ActivityIndicator, ViewStyle, StyleProp } from "react-native";
+import { colors, spacing, radius } from "@/theme";
+import { ThemedText } from "./themed-text";
+
+const variants = {
+  primary: { backgroundColor: colors.systemBlue, color: colors.onTint },
+  secondary: { backgroundColor: colors.separator, color: colors.label },
+} as const;
+
+const sizes = {
+  sm: { paddingVertical: spacing.xs, paddingHorizontal: spacing.sm },
+  md: { paddingVertical: spacing.sm, paddingHorizontal: spacing.md },
+} as const;
+
+export function Button({
+  variant = "primary",
+  size = "md",
+  title,
+  loading,
+  disabled,
+  style,
+  onPress,
+}: {
+  variant?: keyof typeof variants;
+  size?: keyof typeof sizes;
+  title: string;
+  loading?: boolean;
+  disabled?: boolean;
+  style?: StyleProp<ViewStyle>;
+  onPress?: () => void;
+}) {
+  return (
+    <Pressable
+      accessibilityRole="button"
+      disabled={disabled || loading}
+      onPress={onPress}
+      style={({ pressed }) => [
+        {
+          backgroundColor: variants[variant].backgroundColor,
+          borderRadius: radius.md,
+          borderCurve: "continuous",
+          alignItems: "center",
+          opacity: disabled ? 0.4 : pressed ? 0.7 : 1,
+          ...sizes[size],
+        },
+        style, // caller overrides merge last
+      ]}
+    >
+      {loading ? (
+        <ActivityIndicator color={variants[variant].color as string} />
+      ) : (
+        <ThemedText variant="headline" style={{ color: variants[variant].color }}>
+          {title}
+        </ThemedText>
+      )}
+    </Pressable>
+  );
+}
+```
+
+### Composition over configuration
+
+When 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.
+
+### When to extract - and when not to
+
+Promote a view into `src/components/` when **all** of these hold:
+
+1. It appears (or is about to appear) in **two or more screens**. Until then it stays colocated in `screens/<name>/` (see `expo-project-structure`).
+2. It has a **nameable role** ("Card", "EmptyState", "Badge") - not "the thing on the profile screen".
+3. 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.
+
+Promotion path: inline JSX → component in `screens/<name>/` → `src/components/`. 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.
+
+Do **not** wrap platform components that already carry the design language (`Switch`, `DateTimePicker`, stack headers, `@expo/ui` views) just to route them through the system. Native styling *is* the design system for those.
+
+## Where Decisions Live
+
+| Decision | Lives in | Example |
+|---|---|---|
+| A visual value used anywhere twice | `src/theme/` | brand accent, spacing step |
+| Structure + variants of a reused element | `src/components/` | Button, Card, EmptyState |
+| One screen's private composition | `screens/<name>/` | profile header layout |
+| One-off local adjustment | inline, with a comment | optical nudge on an icon |
+| Screen titles, top-level chrome | navigation stack options | header title, large title |
+
+## Self-Critique Pass
+
+After building or changing a screen, screenshot it and check it against these principles (from [Expo's design-principles guide](https://expo.dev/blog/how-to-apply-professional-design-principles-in-ai-app-development)). Each one maps to a system fix, not a local tweak:
+
+- **Hierarchy / contrast** - is the most important element obviously first? Fix with `type` ramp steps, not ad-hoc font sizes.
+- **Proximity / white space** - do related items sit closer than unrelated ones? Fix with `gap` + spacing tokens.
+- **Repetition / unity** - do all corners, shadows, and accents match? If not, a value escaped the theme - move it in.
+- **Alignment** - do edges share axes? Fix with consistent screen edge padding.
+
+The 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.
+
+## Auditing an Existing App
+
+To measure drift in an app that already has screens - hardcoded hex values, arbitrary spacing, inconsistent component APIs - follow `./references/audit.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.
+
+## 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-design-system" "<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.
diff --git a/.agents/skills/expo-design-system/agents/openai.yaml b/.agents/skills/expo-design-system/agents/openai.yaml
new file mode 100644
index 0000000..2322f6e
--- /dev/null
+++ b/.agents/skills/expo-design-system/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Expo Design Systems"
+  short_description: "Build a design system in an Expo app: a token theme (color, spacing, typography, radius, shadow, motion), reusable component conventions, and audits for design-system drift (hardcoded style values)"
+  default_prompt: "Use $expo-design-system to set up or maintain the app's design system: create the src/theme token files, shape reusable components with variant/size/state props, decide when a repeated view becomes a shared component, and audit screens for design-system drift (hardcoded style values)."
diff --git a/.agents/skills/expo-design-system/references/audit.md b/.agents/skills/expo-design-system/references/audit.md
new file mode 100644
index 0000000..9de37e8
--- /dev/null
+++ b/.agents/skills/expo-design-system/references/audit.md
@@ -0,0 +1,185 @@
+# Design System Audit
+
+Measure how far an existing Expo app has drifted from a single visual source of truth, then document or extend components with a consistent template.
+
+Run the audit **before** proposing changes. Report findings first; apply fixes only when asked.
+
+## 0. Locate the directories first
+
+Do **not** assume a `src/` folder. The default `create-expo-app` template puts `app/`, `components/`, and `constants/` at the repo root, and running the checks below against a nonexistent `src/` returns zero hits - a false clean bill.
+
+Before any grep, identify and record:
+
+- **Source directories** - every directory holding app code (`src`, or e.g. `app components constants hooks`).
+- **Theme location** - the token directory or file (`src/theme`, `theme`, `constants`, or a single `theme.ts`). If none exists yet, note that as the first finding.
+- **The existing system, if any** - a styling library in `package.json` (NativeWind, Tamagui, Restyle, Unistyles, styled-components) per `SKILL.md` "Adopt Before You Build". Record which one. The checks below assume this skill's defaults - plain `StyleSheet`, `boxShadow` strings, one `src/theme` entry point. An app on a styling library fails several of them while being perfectly consistent in its own idiom. Audit such an app against its own system: its token names, its scale, its config file as the single entry point. Adapt or skip a check rather than reporting a false violation.
+
+Substitute them into the shell variables below; every check uses them.
+
+```bash
+SRC="app components constants"   # this project's source directories
+THEME="constants"                # this project's theme directory (excluded from hits)
+```
+
+## 1. Token coverage checks
+
+Run from the repo root. Each hit outside the theme directory is a candidate for tokenization - not automatically a violation (check for the "one-off, with a comment" exemption in `SKILL.md`).
+
+```bash
+# Hardcoded hex colors outside the theme
+grep -rEn '#[0-9a-fA-F]{3,8}\b' $SRC --include='*.tsx' --include='*.ts' | grep -v "^$THEME/"
+
+# Raw fontSize (should come from the type ramp / ThemedText)
+grep -rn 'fontSize:' $SRC --include='*.tsx' | grep -v "^$THEME/"
+
+# Spacing values outside the named steps of the scale.
+# The whitelist is the project's actual scale (here: the example scale from
+# SKILL.md) - substitute the project's steps before running. Multiples of 4
+# that are not named steps (12, 20, 40, ...) are flagged on purpose: the rule
+# is "use the nearest step". If one keeps recurring, the fix is to add it to
+# the scale and to this whitelist, not to ignore the hits.
+grep -rEn '(padding|margin|gap)[A-Za-z]*:\s*[0-9]+' $SRC --include='*.tsx' \
+  | grep -vE ':\s*(0|4|8|16|24|32|48)\b' | grep -v "^$THEME/"
+
+# Raw borderRadius (should use radius tokens)
+grep -rn 'borderRadius:' $SRC --include='*.tsx' | grep -v "^$THEME/"
+
+# Legacy shadows (banned by expo-native-ui - must be boxShadow)
+grep -rEn 'shadow(Color|Offset|Opacity|Radius)|elevation:' $SRC --include='*.tsx'
+
+# Multiple theme entry points (there must be exactly one)
+ls src/theme.ts src/theme/index.ts theme.ts theme/index.ts constants/theme.ts 2>/dev/null
+```
+
+For a Tailwind project (`expo-tailwind-setup`), also check for values that bypass `global.css` variables: arbitrary-value classes like `p-[13px]` or `text-[#5B21B6]`.
+
+```bash
+grep -rEn 'className="[^"]*\[[^"]*\]' $SRC --include='*.tsx'
+```
+
+## 2. Scoring
+
+Turn raw hit counts into a comparable score so runs can be tracked over time:
+
+```bash
+# Source lines of code (the denominator)
+find $SRC -name '*.tsx' -o -name '*.ts' | xargs wc -l | tail -1
+```
+
+For each category: **score = escapes per 100 source lines** (hits ÷ SLOC × 100, one decimal).
+
+| Score per category | Reading |
+|---|---|
+| < 0.5 | Healthy - fix opportunistically |
+| 0.5 - 2.0 | Drifting - schedule cleanup for the worst files |
+| > 2.0 | Systemic - the token or component for this category is missing or unused; fix the system first (see §5) |
+
+Report the per-category scores in the summary. The overall priority order falls out of the scores: the highest-scoring category is usually the first migration target.
+
+## 3. Component completeness
+
+For each component in the shared components directory (`src/components/`, or `components/` in a root-level layout), check it against the contract in `SKILL.md`:
+
+| Check | Pass condition |
+|---|---|
+| Variants | Visual intent is a `variant` prop, not boolean soup (`isPrimary`, `isGhost`) |
+| Sizes | Sizes map to spacing/typography tokens |
+| Pressed state | Tappable components give pressed feedback via a `Pressable` style function |
+| Disabled / loading | Handled, and disabled blocks `onPress` |
+| Style override | Accepts `style`, merged last |
+| Accessibility | `accessibilityRole` set; touch target ≥ 44pt |
+| Tokens only | No literals that duplicate a theme value |
+
+## 4. Report format
+
+```markdown
+## Design System Audit
+
+### Summary
+Screens reviewed: [X] | Components reviewed: [X] | Issues: [X]
+
+### Token coverage
+| Category | Tokens defined | Escapes found | Score (per 100 SLOC) | Worst offenders |
+|---|---|---|---|---|
+| Colors | [X] | [X] hardcoded hex | [X.X] | [files] |
+| Spacing | [X] | [X] non-step values | [X.X] | [files] |
+| Typography | [X] | [X] raw fontSize | [X.X] | [files] |
+| Radius / shadows / motion | [X] | [X] | [X.X] | [files] |
+
+### Component completeness
+| Component | Variants | States | Overrides | Tokens | Notes |
+|---|---|---|---|---|---|
+| Button | OK | missing pressed | OK | OK | ... |
+
+### Extraction candidates
+Views repeated across ≥2 screens that are still colocated or duplicated:
+1. [view] - appears in [screens] - suggested name: [Component]
+
+### Priority actions
+1. [Highest-leverage fix - usually the most-duplicated escaped value]
+2. ...
+```
+
+## 5. Adopting incrementally
+
+An app with dozens of escapes is migrated in order, never big-bang. A big-bang conversion produces one huge unreviewable diff and usually stalls half-done.
+
+1. **Create the tokens first.** Derive the scales from the values the audit found most often, snapped to the grid. A theme built from the app's real values gets adopted; an aspirational one gets bypassed.
+2. **Typography before spacing.** Convert raw `fontSize` to the `type` ramp + `ThemedText` first: it is the highest-visibility win and touches the fewest layout decisions. Then spacing, then colors, then radius/shadows.
+3. **Convert one worst-offender file completely** and use it as the reference pattern for the rest of the migration.
+4. **Then convert per-screen**, one screen per commit, using the audit greps scoped to that screen to verify it comes out clean.
+5. **Re-run the audit after each phase** and record the scores from §2 - they should fall monotonically.
+
+## 6. Documenting an existing component
+
+```markdown
+## Component: [Name]
+
+[What it is and when to use it - one paragraph.]
+
+### Variants
+| Variant | Use when |
+|---|---|
+| primary | The screen's single main action |
+
+### Props
+| Prop | Type | Default | Notes |
+|---|---|---|---|
+
+### States
+default / pressed / disabled / loading - visual + behavior for each.
+
+### Accessibility
+Role, touch target, screen reader label.
+
+### Do / Don't
+| Do | Don't |
+|---|---|
+| [best practice] | [anti-pattern seen in this repo] |
+```
+
+## 7. Proposing a new component
+
+Before designing a new primitive, prove the existing set can't cover it:
+
+```markdown
+## Proposed: [Name]
+
+### Problem
+[The repeated need, and the ≥2 screens that have it.]
+
+### Why existing components aren't enough
+| Closest component | What's shared | What's missing |
+|---|---|---|
+
+### API
+Props table (variant / size / state / style only - content via children).
+
+### Tokens used
+Colors: [...] Spacing: [...] Typography: [...] Radius: [...]
+
+### Open questions
+[Decisions that need a human, e.g. does this need a destructive variant?]
+```
+
+If the "what's missing" column is empty for any row, extend that component's variants instead of adding a new one.
diff --git a/.agents/skills/expo-dev-client/SKILL.md b/.agents/skills/expo-dev-client/SKILL.md
index 84a1cf0..03607c0 100644
--- a/.agents/skills/expo-dev-client/SKILL.md
+++ b/.agents/skills/expo-dev-client/SKILL.md
@@ -1,22 +1,24 @@
 ---
 name: expo-dev-client
-description: Build and distribute Expo development clients locally or via TestFlight
-version: 1.0.0
+description: Framework (OSS). Build and distribute Expo development clients locally or via TestFlight for internal testing. For production TestFlight releases and store submission, use the eas-app-stores skill.
+version: 1.1.0
 license: MIT
 ---
 
 Use EAS Build to create development clients for testing native code changes on physical devices. Use this for creating custom Expo Go clients for testing branches of your app.
 
+> **Free locally; cloud builds are paid.** `expo-dev-client` itself is open source and building locally is free. Building or distributing via EAS Build/TestFlight uses your EAS plan's build minutes and needs a paid Apple Developer account for device/TestFlight distribution. See https://expo.dev/pricing.
+
 ## Important: When Development Clients Are Needed
 
-**Only create development clients when your app requires custom native code.** Most apps work fine in Expo Go.
+**Development clients are the recommended setup for any real or production app.** Expo Go is a playground for learning and quick experiments with the native libraries it bundles; most apps outgrow it and move to a development client. See [Expo Go vs. development builds](https://docs.expo.dev/develop/development-builds/introduction/) for the full reasoning.
 
 You need a dev client ONLY when using:
+
 - Local Expo modules (custom native code)
 - Apple targets (widgets, app clips, extensions)
 - Third-party native modules not in Expo Go
-
-**Try Expo Go first** with `npx expo start`. If everything works, you don't need a dev client.
+- Config plugins, or testing remote push notifications and App/Universal Links
 
 ## EAS Configuration
 
@@ -45,6 +47,7 @@ Ensure `eas.json` has a development profile:
 ```
 
 Key settings:
+
 - `developmentClient: true` - Bundles expo-dev-client for development builds
 - `autoIncrement: true` - Automatically increments build numbers
 - `appVersionSource: "remote"` - Uses EAS as the source of truth for version numbers
@@ -58,11 +61,13 @@ eas build -p ios --profile development --submit
 ```
 
 This will:
+
 1. Build the development client in the cloud
 2. Automatically submit to App Store Connect
 3. Send you an email when the build is ready in TestFlight
 
 After receiving the TestFlight email:
+
 1. Download the build from TestFlight on your device
 2. Launch the app to see the expo-dev-client UI
 3. Connect to your local Metro bundler or scan a QR code
@@ -80,6 +85,7 @@ eas build -p android --profile development --local
 ```
 
 Local builds output:
+
 - iOS: `.ipa` file
 - Android: `.apk` or `.aab` file
 
@@ -132,6 +138,7 @@ eas build:view
 ## Using the Dev Client
 
 Once installed, the dev client provides:
+
 - **Development server connection** - Enter your Metro bundler URL or scan QR
 - **Build information** - View native build details
 - **Launcher UI** - Switch between development servers
@@ -148,17 +155,28 @@ npx expo start --dev-client
 ## Troubleshooting
 
 **Build fails with signing errors:**
+
 ```bash
 eas credentials
 ```
 
 **Clear build cache:**
+
 ```bash
 eas build -p ios --profile development --clear-cache
 ```
 
 **Check EAS CLI version:**
+
 ```bash
 eas --version
 eas update
 ```
+
+## 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-dev-client" "<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.
diff --git a/.agents/skills/expo-dom/SKILL.md b/.agents/skills/expo-dom/SKILL.md
new file mode 100644
index 0000000..796906e
--- /dev/null
+++ b/.agents/skills/expo-dom/SKILL.md
@@ -0,0 +1,425 @@
+---
+name: expo-dom
+description: Framework (OSS). Use Expo DOM components to run web code in a webview on native and as-is on web. Migrate web code to native incrementally. For the end-to-end migration of a whole web app, use the expo-web-to-native skill.
+version: 1.0.0
+license: MIT
+---
+
+## What are DOM Components?
+
+DOM components allow web code to run verbatim in a webview on native platforms while rendering as-is on web. This enables using web-only libraries like `recharts`, `react-syntax-highlighter`, or any React web library in your Expo app without modification.
+
+## When to Use DOM Components
+
+Use DOM components when you need:
+
+- **Web-only libraries** — Charts (recharts, chart.js), syntax highlighters, rich text editors, or any library that depends on DOM APIs
+- **Migrating web code** — Bring existing React web components to native without rewriting
+- **Complex HTML/CSS layouts** — When CSS features aren't available in React Native
+- **iframes or embeds** — Embedding external content that requires a browser context
+- **Canvas or WebGL** — Web graphics APIs not available natively
+
+## When NOT to Use DOM Components
+
+Avoid DOM components when:
+
+- **Native performance is critical** — Webviews add overhead
+- **Simple UI** — React Native components are more efficient for basic layouts
+- **Deep native integration** — Use local modules instead for native APIs
+- **Layout routes** — `_layout` files cannot be DOM components
+
+## Basic DOM Component
+
+Create a new file with the `'use dom';` directive at the top:
+
+```tsx
+// components/WebChart.tsx
+"use dom";
+
+export default function WebChart({
+  data,
+}: {
+  data: number[];
+  dom: import("expo/dom").DOMProps;
+}) {
+  return (
+    <div style={{ padding: 20 }}>
+      <h2>Chart Data</h2>
+      <ul>
+        {data.map((value, i) => (
+          <li key={i}>{value}</li>
+        ))}
+      </ul>
+    </div>
+  );
+}
+```
+
+## Rules for DOM Components
+
+1. **Must have `'use dom';` directive** at the top of the file
+2. **Single default export** — One React component per file
+3. **Own file** — Cannot be defined inline or combined with native components
+4. **Serializable props only** — Strings, numbers, booleans, arrays, plain objects
+5. **Include CSS in the component file** — DOM components run in isolated context
+
+## The `dom` Prop
+
+Every DOM component receives a special `dom` prop for webview configuration. Always type it in your props:
+
+```tsx
+"use dom";
+
+interface Props {
+  content: string;
+  dom: import("expo/dom").DOMProps;
+}
+
+export default function MyComponent({ content }: Props) {
+  return <div>{content}</div>;
+}
+```
+
+### Common `dom` Prop Options
+
+```tsx
+// Disable body scrolling
+<DOMComponent dom={{ scrollEnabled: false }} />
+
+// Flow under the notch (disable safe area insets)
+<DOMComponent dom={{ contentInsetAdjustmentBehavior: "never" }} />
+
+// Control size manually
+<DOMComponent dom={{ style: { width: 300, height: 400 } }} />
+
+// Combine options
+<DOMComponent
+  dom={{
+    scrollEnabled: false,
+    contentInsetAdjustmentBehavior: "never",
+    style: { width: '100%', height: 500 }
+  }}
+/>
+```
+
+## Exposing Native Actions to the Webview
+
+Pass async functions as props to expose native functionality to the DOM component:
+
+```tsx
+// app/index.tsx (native)
+import { Alert } from "react-native";
+import DOMComponent from "@/components/dom-component";
+
+export default function Screen() {
+  return (
+    <DOMComponent
+      showAlert={async (message: string) => {
+        Alert.alert("From Web", message);
+      }}
+      saveData={async (data: { name: string; value: number }) => {
+        // Save to native storage, database, etc.
+        console.log("Saving:", data);
+        return { success: true };
+      }}
+    />
+  );
+}
+```
+
+```tsx
+// components/dom-component.tsx
+"use dom";
+
+interface Props {
+  showAlert: (message: string) => Promise<void>;
+  saveData: (data: {
+    name: string;
+    value: number;
+  }) => Promise<{ success: boolean }>;
+  dom?: import("expo/dom").DOMProps;
+}
+
+export default function DOMComponent({ showAlert, saveData }: Props) {
+  const handleClick = async () => {
+    await showAlert("Hello from the webview!");
+    const result = await saveData({ name: "test", value: 42 });
+    console.log("Save result:", result);
+  };
+
+  return <button onClick={handleClick}>Trigger Native Action</button>;
+}
+```
+
+## Using Web Libraries
+
+DOM components can use any web library:
+
+```tsx
+// components/syntax-highlight.tsx
+"use dom";
+
+import SyntaxHighlighter from "react-syntax-highlighter";
+import { docco } from "react-syntax-highlighter/dist/esm/styles/hljs";
+
+interface Props {
+  code: string;
+  language: string;
+  dom?: import("expo/dom").DOMProps;
+}
+
+export default function SyntaxHighlight({ code, language }: Props) {
+  return (
+    <SyntaxHighlighter language={language} style={docco}>
+      {code}
+    </SyntaxHighlighter>
+  );
+}
+```
+
+```tsx
+// components/chart.tsx
+"use dom";
+
+import {
+  LineChart,
+  Line,
+  XAxis,
+  YAxis,
+  CartesianGrid,
+  Tooltip,
+} from "recharts";
+
+interface Props {
+  data: Array<{ name: string; value: number }>;
+  dom: import("expo/dom").DOMProps;
+}
+
+export default function Chart({ data }: Props) {
+  return (
+    <LineChart width={400} height={300} data={data}>
+      <CartesianGrid strokeDasharray="3 3" />
+      <XAxis dataKey="name" />
+      <YAxis />
+      <Tooltip />
+      <Line type="monotone" dataKey="value" stroke="#8884d8" />
+    </LineChart>
+  );
+}
+```
+
+## CSS in DOM Components
+
+CSS imports must be in the DOM component file since they run in isolated context:
+
+```tsx
+// components/styled-component.tsx
+"use dom";
+
+import "@/styles.css"; // CSS file in same directory
+
+export default function StyledComponent({
+  dom,
+}: {
+  dom: import("expo/dom").DOMProps;
+}) {
+  return (
+    <div className="container">
+      <h1 className="title">Styled Content</h1>
+    </div>
+  );
+}
+```
+
+Or use inline styles / CSS-in-JS:
+
+```tsx
+"use dom";
+
+const styles = {
+  container: {
+    padding: 20,
+    backgroundColor: "#f0f0f0",
+  },
+  title: {
+    fontSize: 24,
+    color: "#333",
+  },
+};
+
+export default function StyledComponent({
+  dom,
+}: {
+  dom: import("expo/dom").DOMProps;
+}) {
+  return (
+    <div style={styles.container}>
+      <h1 style={styles.title}>Styled Content</h1>
+    </div>
+  );
+}
+```
+
+## Expo Router in DOM Components
+
+The expo-router `<Link />` component and router API work inside DOM components:
+
+```tsx
+"use dom";
+
+import { Link, useRouter } from "expo-router";
+
+export default function Navigation({
+  dom,
+}: {
+  dom: import("expo/dom").DOMProps;
+}) {
+  const router = useRouter();
+
+  return (
+    <nav>
+      <Link href="/about">About</Link>
+      <button onClick={() => router.push("/settings")}>Settings</button>
+    </nav>
+  );
+}
+```
+
+### Router APIs That Require Props
+
+These hooks don't work directly in DOM components because they need synchronous access to native routing state:
+
+- `useLocalSearchParams()`
+- `useGlobalSearchParams()`
+- `usePathname()`
+- `useSegments()`
+- `useRootNavigation()`
+- `useRootNavigationState()`
+
+**Solution:** Read these values in the native parent and pass as props:
+
+```tsx
+// app/[id].tsx (native)
+import { useLocalSearchParams, usePathname } from "expo-router";
+import DOMComponent from "@/components/dom-component";
+
+export default function Screen() {
+  const { id } = useLocalSearchParams();
+  const pathname = usePathname();
+
+  return <DOMComponent id={id as string} pathname={pathname} />;
+}
+```
+
+```tsx
+// components/dom-component.tsx
+"use dom";
+
+interface Props {
+  id: string;
+  pathname: string;
+  dom?: import("expo/dom").DOMProps;
+}
+
+export default function DOMComponent({ id, pathname }: Props) {
+  return (
+    <div>
+      <p>Current ID: {id}</p>
+      <p>Current Path: {pathname}</p>
+    </div>
+  );
+}
+```
+
+## Detecting DOM Environment
+
+Check if code is running in a DOM component:
+
+```tsx
+"use dom";
+
+import { IS_DOM } from "expo/dom";
+
+export default function Component({
+  dom,
+}: {
+  dom?: import("expo/dom").DOMProps;
+}) {
+  return <div>{IS_DOM ? "Running in DOM component" : "Running natively"}</div>;
+}
+```
+
+## Assets
+
+Prefer requiring assets instead of using the public directory:
+
+```tsx
+"use dom";
+
+// Good - bundled with the component
+const logo = require("../assets/logo.png");
+
+export default function Component({
+  dom,
+}: {
+  dom: import("expo/dom").DOMProps;
+}) {
+  return <img src={logo} alt="Logo" />;
+}
+```
+
+## Usage from Native Components
+
+Import and use DOM components like regular components:
+
+```tsx
+// app/index.tsx
+import { View, Text } from "react-native";
+import WebChart from "@/components/web-chart";
+import CodeBlock from "@/components/code-block";
+
+export default function HomeScreen() {
+  return (
+    <View style={{ flex: 1 }}>
+      <Text>Native content above</Text>
+
+      <WebChart data={[10, 20, 30, 40, 50]} dom={{ style: { height: 300 } }} />
+
+      <CodeBlock
+        code="const x = 1;"
+        language="javascript"
+        dom={{ scrollEnabled: true }}
+      />
+
+      <Text>Native content below</Text>
+    </View>
+  );
+}
+```
+
+## Platform Behavior
+
+| Platform | Behavior                            |
+| -------- | ----------------------------------- |
+| iOS      | Rendered in WKWebView               |
+| Android  | Rendered in WebView                 |
+| Web      | Rendered as-is (no webview wrapper) |
+
+On web, the `dom` prop is ignored since no webview is needed.
+
+## Tips
+
+- DOM components hot reload during development
+- Keep DOM components focused — don't put entire screens in webviews
+- Use native components for navigation chrome, DOM components for specialized content
+- Test on all platforms — web rendering may differ slightly from native webviews
+- Large DOM components may impact performance — profile if needed
+- The webview has its own JavaScript context — cannot directly share state with native
+
+## 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-dom" "<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.
diff --git a/.agents/skills/expo-dom/agents/openai.yaml b/.agents/skills/expo-dom/agents/openai.yaml
new file mode 100644
index 0000000..ed8c91c
--- /dev/null
+++ b/.agents/skills/expo-dom/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Expo DOM Components"
+  short_description: "Use Expo DOM components to run web React code in native webviews and unchanged on web"
+  default_prompt: "Use $expo-dom to migrate web components into Expo via 'use dom', configure DOM props, expose native actions safely, use web-only libraries, and keep DOM components separate from native routes."
diff --git a/.agents/skills/expo-examples/SKILL.md b/.agents/skills/expo-examples/SKILL.md
index 8b1cebc..2cfb7ba 100644
--- a/.agents/skills/expo-examples/SKILL.md
+++ b/.agents/skills/expo-examples/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: expo-examples
-description: Expo's official example projects — the expo/examples repo of ~70 `with-*` integrations (Stripe, Clerk, Supabase, OpenAI, maps, Reanimated, SQLite, Skia, NativeWind, and more). Use when integrating a third-party library or service into an existing Expo app and you want the canonical, version-matched pattern to adapt, or when scaffolding a new project from one with `npx create-expo --example`.
+description: Framework (OSS). Expo's official example projects - the expo/examples repo of ~70 `with-*` integrations (Stripe, Clerk, Supabase, OpenAI, maps, Reanimated, SQLite, Skia, NativeWind, and more). Use when integrating a third-party library or service into an existing Expo app and you want the canonical, version-matched pattern to adapt, or when scaffolding a new project from one with `npx create-expo --example`.
 allowed-tools: "Read,Bash(gh api:*),Bash(git clone:*),Bash(npx create-expo:*),Bash(npx degit:*),Bash(bun create:*)"
 version: 1.0.0
 license: MIT
@@ -88,10 +88,20 @@ When the user already has an app, **add only what the example introduces; never
 ## Related skills
 
 - Tailwind / NativeWind styling → `expo-tailwind-setup`
-- Native UI components → `building-native-ui`
+- Native UI components (@expo/ui package) → `expo-ui`
+- Styling and native-feeling screens → `expo-native-ui`
+- Navigation and routing → `expo-router`
 - Authoring a native module → `expo-module`
-- Upgrade the SDK before adopting a latest-SDK example → `upgrading-expo`
+- Upgrade the SDK before adopting a latest-SDK example → `expo-upgrade`
 
 ## References
 
 - `./references/catalog.md` — categorized snapshot of the example library for fast triage.
+
+## 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-examples" "<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.
diff --git a/.agents/skills/expo-examples/agents/openai.yaml b/.agents/skills/expo-examples/agents/openai.yaml
new file mode 100644
index 0000000..d68fe29
--- /dev/null
+++ b/.agents/skills/expo-examples/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Expo Examples"
+  short_description: "Adapt or scaffold from the expo/examples repo of with-* integrations (Stripe, Clerk, Supabase, maps, SQLite, and more)"
+  default_prompt: "Use $expo-examples when integrating a third-party library or service into an Expo app to find the canonical with-* example to adapt, or to scaffold a new project with npx create-expo --example."
diff --git a/.agents/skills/expo-migrate-module/SKILL.md b/.agents/skills/expo-migrate-module/SKILL.md
new file mode 100644
index 0000000..32cd105
--- /dev/null
+++ b/.agents/skills/expo-migrate-module/SKILL.md
@@ -0,0 +1,113 @@
+---
+name: expo-migrate-module
+description: Framework (OSS). Migrate an existing Apple/Swift Expo native module from the Expo Modules API 1.0 definition DSL to the 2.0 macro API (sometimes called v2) while preserving its JavaScript and TypeScript contract. Use when converting or incrementally adopting @ExpoModule, @JS, @Event, @SharedObject, or @Record in an existing module. Do not use for creating a new module, general Expo SDK upgrades, or Android/Kotlin migrations.
+version: 1.0.0
+license: MIT
+---
+
+# Migrate an Expo Module
+
+Migrate the Swift side of an existing Expo module without changing its observable JS API. Treat the current JS/TypeScript surface and tests as the compatibility contract. Leave Kotlin on the 1.0 DSL unless the user explicitly expands the task.
+
+## Prerequisite
+
+The Expo Modules API 2.0 macros require `expo` `57.0.7` or newer. Before editing, check the target's installed version (`expo` in `package.json`/lockfile, or `npm ls expo`). If it is older, stop and tell the user to upgrade first; do not attempt the migration against an unsupported version. This is a floor, not a guarantee: the exact macro and core surface still varies within `57.x`, so step 2 must still verify the checked-out source.
+
+## References
+
+- Read `references/migration-map.md` before changing source. It contains the 1.0-to-2.0 mappings, semantic traps, and mixed-mode rules.
+- Read `references/example.md` for a full before/after walkthrough of one module through mixed mode to a complete migration. Consult it when you need to see how the per-member rules compose.
+- Read `references/compatibility.md` when the checked-out `expo-modules-core` version or branch is not known to support every requested macro. It explains how to verify the actual compile-time and runtime surface instead of guessing from an SDK number.
+
+## Workflow
+
+### 1. Establish the contract
+
+Inspect repository instructions and the worktree before editing. Locate the Swift module classes, records, shared objects, native views, JS/TS bindings, tests, example app, podspec, and installed or checked-out `expo-modules-core`.
+
+Inventory every exported item before rewriting it:
+
+- module and shared-object JS names
+- function names, arity, labels, defaults, nullability, sync/async behavior, errors, and queue semantics
+- property names, mutability, and constant caching behavior
+- event wire names and payload shapes
+- record field names, defaults, requiredness, and nullability
+- shared-object constructors and instance/static placement
+- lifecycle hooks and views
+
+Use the TypeScript declarations and JS call sites to resolve ambiguity. Do not silently "improve" requiredness, rename an event, or change sync behavior during a syntax migration.
+
+### 2. Verify the available 2.0 surface
+
+Inspect the macro declarations and matching core hooks in the dependency actually used by the target. Do not assume that all items in the 2.0 design are present because one macro compiles.
+
+Classify each 1.0 item as:
+
+- **Migrate:** both its macro and required core runtime support exist.
+- **Keep in DSL:** mixed mode preserves it safely, or 2.0 lacks an equivalent.
+- **Blocked:** migration would alter the JS contract or requires unavailable runtime support.
+
+Prefer an incremental mixed-mode result over speculative generated code. Keep `definition()` for any remaining DSL elements; delete it only when it is empty and the resolved module name is preserved by `@ExpoModule`.
+
+### 3. Apply the migration
+
+Migrate one semantic group at a time: module naming, functions, properties/constants, events, shared objects, then records. Keep the diff narrow.
+
+Follow these invariants:
+
+- Preserve every existing JS-visible name explicitly when Swift naming rules or macro defaults differ.
+- Keep original optional/default behavior. An optional 1.0 record field must not become required merely because 2.0 can express required fields.
+- Do not migrate same-JS-name overloads unless the checked-out macro groups and dispatches them.
+- Do not migrate queue-pinned DSL functions as-is; restructure onto Swift Concurrency or dispatch to the original queue via a continuation, per the async-function rules in `references/migration-map.md`.
+- Do not migrate views, unions, synchronous events, or shared-object static functions without verified support.
+- Do not change Kotlin, JS wrappers, or public `.d.ts` files unless the user requested an API change.
+
+After each group, search for old DSL entries and call sites that should have moved. Avoid broad formatting or unrelated cleanup.
+
+### When a 2.0 equivalent is missing or a group fails
+
+When step 2 classified an item as **Blocked**, or a migrated group fails to build or breaks the contract, do not force it. Stop on that group and:
+
+1. **Ask the user how to proceed** for that item, with two options:
+   - **Co-exist:** keep the item in the 1.0 `definition()` DSL alongside the migrated `@ExpoModule` (mixed mode) and continue with the other groups.
+   - **Revert:** back out the group's edits, leaving it untouched on 1.0, and move on.
+
+   Default to co-existence when mixed mode is verified safe, since it preserves the most progress. Revert when the half-applied change left the module in a non-building state and cannot be salvaged incrementally.
+
+2. **Open a tracking issue on `expo/expo`** noting the functionality that 2.0 does not yet cover, so the gap is recorded rather than silently worked around. Use `gh issue create --repo expo/expo` and confirm with the user before posting (per repo conventions, do not post outward-facing comments without approval). Include:
+   - the 1.0 member and its JS contract
+   - the specific macro or core hook that is missing (cite the evidence gap from `references/compatibility.md`)
+   - the `expo-modules-core` version/branch checked out
+
+   Reference the issue in the handoff so the remaining DSL entry is traceable to a known limitation.
+
+Keep going with the groups that do migrate cleanly; one blocked member does not block the rest.
+
+### 4. Verify behavior
+
+Run the narrowest available checks first, then the real integration surface:
+
+1. Build or type-check the Apple module against the target `expo-modules-core`.
+2. Run native unit tests and JS/TS tests.
+3. Build and launch the example app when the repository provides one.
+4. Compare the final exported surface with the inventory from step 1.
+5. Search for stale `Name`, migrated `Function`/`Property`/`Constant`/`Events` entries, old `sendEvent` calls, `@Field`, and duplicate registrations.
+
+Expansion tests alone are insufficient: generated macro code can look correct while failing against mismatched core symbols. If dependencies changed or macro plugin flags are missing, reinstall JS dependencies as appropriate, run the repository's CocoaPods installation workflow, and restart Xcode before diagnosing plugin communication failures.
+
+## Handoff
+
+Report:
+
+- which members moved to 2.0
+- which members intentionally remain in the 1.0 DSL and why
+- any compatibility-sensitive choices, especially event names, record requiredness, constants, and queues
+- the commands run and any verification not completed
+
+## 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-migrate-module" "<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.
diff --git a/.agents/skills/expo-migrate-module/agents/openai.yaml b/.agents/skills/expo-migrate-module/agents/openai.yaml
new file mode 100644
index 0000000..437b12c
--- /dev/null
+++ b/.agents/skills/expo-migrate-module/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Migrate Expo Module"
+  short_description: "Migrate Swift Expo modules from 1.0 DSL to 2.0"
+  default_prompt: "Use $expo-migrate-module to migrate this Expo module's Swift implementation from the 1.0 definition DSL to the 2.0 macro API without changing its JavaScript contract."
diff --git a/.agents/skills/expo-migrate-module/references/compatibility.md b/.agents/skills/expo-migrate-module/references/compatibility.md
new file mode 100644
index 0000000..5397dac
--- /dev/null
+++ b/.agents/skills/expo-migrate-module/references/compatibility.md
@@ -0,0 +1,73 @@
+# Expo Modules API 2.0 Compatibility Checks
+
+The Expo Modules API 2.0 design and implementation evolve across the macros plugin and `expo-modules-core`. Verify the checked-out dependency instead of relying on an SDK-number claim.
+
+## Find the actual declarations
+
+Locate `ExpoModulesMacros.swift` in the target repository or installed dependencies (use your search tool, or portable shell commands - do not assume `rg` is installed):
+
+```bash
+find . -name 'ExpoModulesMacros.swift' -not -path '*/node_modules/.cache/*'
+```
+
+Inspect the declarations that the user's source can import:
+
+```bash
+grep -nE 'public macro (ExpoModule|JS|Event|SharedObject|Record|Union|ViewProps|ExpoView)' <path-to-ExpoModulesMacros.swift>
+```
+
+A declaration proves only that Swift recognizes the attribute. Also inspect the corresponding macro implementation and core runtime hooks.
+
+## Check paired core support
+
+Search the actual core source for the feature being migrated:
+
+```bash
+grep -rnE '_decorateModule|_decorateSharedObject|_constructSharedObject|_jsName|EventEmitter|emitSync|StaticProperty|AnyViewProps|PropsDiff|_updateViewProps|didCreate|__expo_onStartListeningToEvent' <expo-modules-core>
+```
+
+Use compile errors and symbol call sites to confirm signatures. The macros plugin and core can drift independently; a successful macro expansion does not prove the generated code compiles or is called at runtime.
+
+## Capability gates
+
+Treat these as independent capabilities:
+
+| Capability | Evidence required before migration |
+| --- | --- |
+| Module functions/properties | `@ExpoModule`/`@JS`, generated `_decorateModule`, and the core call site |
+| Module name | generated `_jsName` and core registration/name lookup that reads it |
+| Records | `@Record`, coding conformance/assertions, and field decode/encode support |
+| Async events | `@Event`, `EventEmitter`, and `BaseModule`/`SharedObject` conformance |
+| Shared-object instances | `_decorateSharedObject`, construction hook, and core invocation |
+| Shared-object static functions | constructor object passed to decoration and static function routing |
+| Synchronous events | `@Event(sync:)` plus core `emitSync` overloads |
+| Task-returning functions | `JavaScriptEncodable` conformance for `Task` in core (encode-only) |
+| Views | `@ViewProps`/`@ExpoView` plus the complete typed props update and event runtime |
+| Module lifecycle methods | `AnyModule` requirements/base implementations and holder call sites |
+
+If any required evidence is absent, keep that item in the 1.0 DSL.
+
+## Known migration hazards in the July 2026 plan
+
+Use this only as a warning list; checked-out source wins.
+
+- Same-JS-name `@JS` overload grouping/dispatch was designed but not built; duplicate bindings could silently overwrite each other.
+- `@Union` was not built.
+- Decode errors lacked the 1.0 argument-index wrapper. This affects diagnostics rather than call semantics, but tests asserting exact messages may fail.
+- `@ViewProps` had only an initial pure-macro slice; the UIKit typed props runtime and `@ExpoView` contract were still gated on core.
+- Shared-object instance functions, properties, setters, construction, and static properties were implemented; verify constructor-side routing before migrating static functions.
+- `@Event(sync: true)` macro generation existed, but core `emitSync` was still required.
+- Default asynchronous `@Event` was supported after core added `EventEmitter` to modules and shared objects.
+- `@JS` functions/properties, range-based arity, default/optional-aware calls, `@Record` field synthesis, async `@JavaScriptActor`, and instance shared-object decoration had landed in the macros work.
+
+## Integration verification
+
+Use the target project's own commands. A robust sequence is:
+
+1. Run macro/unit tests if working inside the macros package.
+2. Compile the migrated native module against the paired core checkout.
+3. Re-run CocoaPods installation when plugin dependencies or injection changed.
+4. Restart Xcode after swapping a macro plugin binary; cleaning DerivedData alone may not reload it.
+5. Build the example app and execute existing JS/TS behavior tests.
+
+Do not report a migration complete based only on textual expansion tests.
diff --git a/.agents/skills/expo-migrate-module/references/example.md b/.agents/skills/expo-migrate-module/references/example.md
new file mode 100644
index 0000000..b09c860
--- /dev/null
+++ b/.agents/skills/expo-migrate-module/references/example.md
@@ -0,0 +1,212 @@
+# Worked Example: Full Module Migration
+
+This walks a single small module from the 1.0 DSL through mixed mode to a fully migrated 2.0 form. Every per-member rule lives in `migration-map.md`; this shows how they compose and how mixed mode is an intermediate state, not a failure.
+
+The module below is representative: a name, a sync function, two async functions (one that suspends, one that blocks), a settable property, a constant, an event with observing hooks, and a record.
+
+## Starting point: 1.0 DSL
+
+```swift
+import ExpoModulesCore
+
+@Record
+struct DownloadOptions {
+  var url: URL              // required
+  var retries: Int = 3      // omittable, default 3
+  var label: String?        // omittable and nullable
+}
+
+public final class DownloaderModule: Module {
+  private var volume: Double = 1
+
+  public func definition() -> ModuleDefinition {
+    Name("Downloader")
+
+    Events("onProgress")
+
+    OnStartObserving {
+      self.beginProgressUpdates()
+    }
+
+    OnStopObserving {
+      self.stopProgressUpdates()
+    }
+
+    Constant("buildInfo") { computeBuildInfo() }
+
+    Function("clamp") { (value: Double) -> Double in
+      return min(max(value, 0), 1)
+    }
+
+    Property("volume") { self.volume }
+      .set { self.volume = $0 }
+
+    AsyncFunction("download") { (options: DownloadOptions) -> String in
+      return try await self.performDownload(options)
+    }
+
+    AsyncFunction("clearCache") {
+      try FileManager.default.removeItem(at: self.cacheDirectory)
+    }
+  }
+
+  private func report(percent: Double) {
+    sendEvent("onProgress", ["percent": percent])
+  }
+}
+```
+
+The observable contract to preserve:
+
+| Member | JS name | Contract |
+| --- | --- | --- |
+| Module | `Downloader` | `requireNativeModule("Downloader")` |
+| `clamp` | `clamp` | sync, 1 arg, returns number |
+| `volume` | `volume` | read/write number |
+| `buildInfo` | `buildInfo` | read-only constant |
+| `download` | `download` | async, 1 record arg, returns string |
+| `clearCache` | `clearCache` | async, no args, blocking work runs off the JS thread |
+| `onProgress` | `onProgress` | event, payload `{ percent }` |
+| observing hooks | n/a | progress updates start/stop with the listener count |
+| `DownloadOptions` | n/a | `url` required; `retries` default 3; `label` nullable |
+
+## Intermediate: mixed mode
+
+Suppose the checked-out core supports everything used above: `@ExpoModule`, `@JS` functions/properties/constants, async `@JavaScriptActor`, `@Record`, default async `@Event`, and the module lifecycle hooks. One member is still blocked, by semantics rather than support: `clearCache` has a body that blocks and never suspends, and a 1.0 `AsyncFunction` runs it on a background queue automatically, while a 2.0 async member starts on the JS actor. Migrating it as-is would move blocking I/O onto the JS thread, so it stays in the DSL.
+
+The record migrates first because it is a pure data type and the function that consumes it depends on it. Its shape is already correct, so migration is just verifying each field decodes: `url`, `retries`, `label` all map cleanly, so `@Record` stays as-is (it was already using the macro here).
+
+```swift
+import ExpoModulesCore
+
+@Record
+struct DownloadOptions {
+  var url: URL
+  var retries: Int = 3
+  var label: String?
+}
+
+@ExpoModule("Downloader")
+public final class DownloaderModule: Module {
+  // Explicit wire name: default @Event would strip "on" and emit "progress".
+  @Event("onProgress")
+  var onProgress: (ProgressEvent) -> Void
+
+  @JS("clamp")
+  func clamp(value: Double) -> Double {
+    return min(max(value, 0), 1)
+  }
+
+  // Stored var -> JS getter + setter, matching the 1.0 get/set pair.
+  @JS
+  var volume: Double = 1
+
+  // A let is a natural constant: read-only from JS.
+  @JS
+  let buildInfo = computeBuildInfo()
+
+  @JS
+  func download(options: DownloadOptions) async throws -> String {
+    return try await performDownload(options)
+  }
+
+  // override: the hooks are inherited from the Module base class.
+  override func didStartListening(event: String) {
+    beginProgressUpdates()
+  }
+
+  override func didStopListening(event: String) {
+    stopProgressUpdates()
+  }
+
+  // Kept on the DSL: the body blocks without suspending, and a 2.0 async
+  // member would start it on the JS actor instead of a background queue.
+  public func definition() -> ModuleDefinition {
+    AsyncFunction("clearCache") {
+      try FileManager.default.removeItem(at: self.cacheDirectory)
+    }
+  }
+
+  private func report(percent: Double) {
+    onProgress(ProgressEvent(percent: percent))
+  }
+}
+
+@Record
+struct ProgressEvent {
+  var percent: Double
+}
+```
+
+Notes on the choices, each traceable to `migration-map.md`:
+
+- `Name("Downloader")` moved into `@ExpoModule("Downloader")`; the custom name is carried explicitly, never dropped.
+- `@Event("onProgress")` uses the explicit wire name to avoid the `on`-stripping default; the untyped dictionary became a typed `ProgressEvent`.
+- The duplicate `private var volume` field was removed once `@JS var volume` became the single source of truth. Watch for this: a 1.0 backing field plus a migrated `@JS var` of the same name is a double-declaration.
+- `Constant("buildInfo")` became `@JS let buildInfo`. Evaluation moves from the lazy 1.0 closure to module initialization, acceptable here because `computeBuildInfo()` is cheap; an expensive value would keep lazy storage behind a getter-only computed `@JS var`.
+- `OnStartObserving`/`OnStopObserving` became the `didStartListening(event:)`/`didStopListening(event:)` hooks, with `override` because the class inherits `Module`. The 1.0 hooks were module-wide, so the event argument is ignored.
+- `definition()` remains but now holds only the queue-sensitive `clearCache`. It is not deleted because it is non-empty.
+
+## Fully migrated (after explicitly moving the blocking work off the JS actor)
+
+The DSL entry for `clearCache` was the semantics-preserving default. To finish the migration, replace the implicit background queue with an explicit hop so the blocking work still never runs on the JS thread, then delete the empty `definition()`.
+
+```swift
+import ExpoModulesCore
+
+@Record
+struct DownloadOptions {
+  var url: URL
+  var retries: Int = 3
+  var label: String?
+}
+
+@Record
+struct ProgressEvent {
+  var percent: Double
+}
+
+@ExpoModule("Downloader")
+public final class DownloaderModule: Module {
+  @Event("onProgress")
+  var onProgress: (ProgressEvent) -> Void
+
+  @JS("clamp")
+  func clamp(value: Double) -> Double {
+    return min(max(value, 0), 1)
+  }
+
+  @JS
+  var volume: Double = 1
+
+  @JS
+  let buildInfo = computeBuildInfo()
+
+  @JS
+  func download(options: DownloadOptions) async throws -> String {
+    return try await performDownload(options)
+  }
+
+  @JS
+  func clearCache() async throws {
+    // Explicit hop: the body blocks, so it must not run on the JS actor.
+    try await Task.detached {
+      try FileManager.default.removeItem(at: self.cacheDirectory)
+    }.value
+  }
+
+  override func didStartListening(event: String) {
+    beginProgressUpdates()
+  }
+
+  override func didStopListening(event: String) {
+    stopProgressUpdates()
+  }
+
+  private func report(percent: Double) {
+    onProgress(ProgressEvent(percent: percent))
+  }
+}
+```
+
+`definition()` is gone only because it was empty and `@ExpoModule("Downloader")` preserves the resolved name. If any member had stayed blocked or unverified, the mixed-mode form above is the correct place to stop, not a broken end state.
diff --git a/.agents/skills/expo-migrate-module/references/migration-map.md b/.agents/skills/expo-migrate-module/references/migration-map.md
new file mode 100644
index 0000000..fed8157
--- /dev/null
+++ b/.agents/skills/expo-migrate-module/references/migration-map.md
@@ -0,0 +1,306 @@
+# 1.0 to 2.0 Migration Map
+
+Use this reference while editing. Preserve behavior first; macro adoption is secondary.
+
+## Module and naming
+
+Convert the module class and remove `Name(...)` only when the paired core reads the macro-synthesized name:
+
+```swift
+// 1.0
+public final class CameraModule: Module {
+  public func definition() -> ModuleDefinition {
+    Name("Camera")
+  }
+}
+
+// 2.0
+@ExpoModule("Camera")
+public final class CameraModule: Module {}
+```
+
+Always carry a custom 1.0 name into `@ExpoModule("...")`. A stale `Name(...)` can override or conflict with the 2.0 name depending on the core revision. In mixed mode, remove `Name(...)` only after verifying the installed `_jsName` contract.
+
+## Functions
+
+Move a DSL closure into a real method and use `@JS("wireName")` when the Swift method name is different:
+
+```swift
+// 1.0
+Function("sum") { (a: Double, b: Double) -> Double in
+  return a + b
+}
+
+// 2.0
+@JS("sum")
+func add(a: Double, b: Double) -> Double {
+  return a + b
+}
+```
+
+Preserve:
+
+- the JS name
+- positional arity
+- optional arguments and Swift defaults
+- thrown errors and return type
+- whether the result is synchronous or a Promise
+
+Do not migrate functions that resolve to the same JS name unless the checked-out macro has overload grouping and collision diagnostics. Older 2.0 implementations install one property per declaration, so the last overload silently wins.
+
+Reject or keep in DSL any unsupported signature such as variadics, `inout`, unresolved generics, or closure parameters without verified callback support. A `Promise` parameter is also unsupported; refactor it as described under Async functions.
+
+### Async functions
+
+A `Promise` parameter is not supported in a `@JS` signature; 2.0 drops the trailing-`Promise` argument entirely. A Promise-returning function has three shapes in 2.0. Pick by how the underlying work produces its result.
+
+**1. Standard `async` method.** The common case. Swift `async` maps to a JS Promise:
+
+```swift
+// 1.0
+AsyncFunction("load") { (url: URL) -> String in
+  return try loadSynchronously(url)
+}
+
+// 2.0
+@JS
+func load(url: URL) async throws -> String {
+  return try await loadResource(url)
+}
+```
+
+**2. Checked continuation.** When the result arrives through a delegate or completion handler that fires once, wrap it with `withCheckedThrowingContinuation` (or `withCheckedContinuation` for non-throwing callbacks, or an `AsyncStream` for repeated values). This is the usual refactor for a 1.0 `AsyncFunction` that took a trailing `Promise` instance:
+
+```swift
+// 1.0
+AsyncFunction("start") { (promise: Promise) in
+  scanner.start(
+    onSuccess: { result in promise.resolve(result) },
+    onFailure: { error in promise.reject(error) }
+  )
+}
+
+// 2.0
+@JS
+func start() async throws -> ScanResult {
+  return try await withCheckedThrowingContinuation { continuation in
+    scanner.start(
+      onSuccess: { result in continuation.resume(returning: result) },
+      onFailure: { error in continuation.resume(throwing: error) }
+    )
+  }
+}
+```
+
+Resume the continuation exactly once on every path. If the callback API cannot guarantee that, or the refactor is otherwise unsafe, keep the function on the DSL instead of forcing it.
+
+**3. Synchronous method returning a `Task`.** The `Task` encodes to a promise that settles with its result. Use it when the work is naturally a `Task`, or when a promise is needed as a value nested inside another encoded result rather than as the function's own return:
+
+```swift
+// 2.0
+@JS
+func download(url: URL) -> Task<DownloadResult, any Error> {
+  return Task {
+    try await self.downloader.download(url)
+  }
+}
+```
+
+This shape requires the `JavaScriptEncodable` conformance for `Task` in the checked-out core (encode-only; a JS promise does not decode back into a `Task`). Verify it exists before using this shape; prefer shape 1 or 2 when it is absent.
+
+Do not assume scheduling is unchanged. 2.0 async members are `@JavaScriptActor`-isolated and begin on the JS thread until their first real suspension. A 1.0 `.runOnQueue(...)` function or a workload that relied on automatic background execution must not be migrated as-is. Never move blocking I/O directly onto the JS actor.
+
+For a queue-pinned 1.0 function, prefer restructuring the work onto the Swift Concurrency model (structured concurrency, an actor, or a detached task for blocking work). When that is not feasible because the queue itself is the contract, for example a library that must be called from one serial queue, convert to an `async` method that dispatches to that queue inside a checked continuation:
+
+```swift
+// 1.0
+AsyncFunction("process") { (input: String) -> String in
+  return try self.processor.process(input)
+}
+.runOnQueue(processingQueue)
+
+// 2.0
+@JS
+func process(input: String) async throws -> String {
+  return try await withCheckedThrowingContinuation { continuation in
+    processingQueue.async {
+      do {
+        continuation.resume(returning: try self.processor.process(input))
+      } catch {
+        continuation.resume(throwing: error)
+      }
+    }
+  }
+}
+```
+
+## Properties and constants
+
+Map a getter to a getter-only `@JS var`; map a getter/setter pair to a settable stored or computed `@JS var`:
+
+```swift
+// 1.0
+Property("volume") { self.volume }
+  .set { self.volume = $0 }
+
+// 2.0
+@JS
+var volume: Double = 1
+```
+
+Access control does not define JS mutability. Verify whether the declaration is syntactically settable; a stored `var` normally produces a JS setter.
+
+Map a 1.0 `Constant` to a `@JS let`; a `let` property is a natural constant and produces a read-only JS property:
+
+```swift
+// 1.0
+Constant("apiVersion") { 3 }
+
+// 2.0
+@JS
+let apiVersion = 3
+```
+
+Evaluation timing shifts: a 1.0 `Constant` closure runs lazily, while a `let` initializes with the module instance. When the value is expensive and must stay deferred, keep private lazy storage and expose a getter-only computed property (a `var` with a `{ }` getter body and no storage of its own), not a stored `lazy var`:
+
+```swift
+private lazy var cachedInfo = computeInfo()
+
+@JS
+var info: Info {  // computed: recomputes nothing, just returns the cached value
+  return cachedInfo
+}
+```
+
+Do not expose a cached value as a settable `lazy @JS var`.
+
+## Events
+
+Replace `Events(...)` plus `sendEvent(...)` with a typed function property:
+
+```swift
+@Record
+struct ProgressEvent {
+  var percent: Double
+}
+
+// Explicit string preserves the old wire name.
+@Event("onProgress")
+var onProgress: (ProgressEvent) -> Void
+
+func report(percent: Double) {
+  onProgress(ProgressEvent(percent: percent))
+}
+```
+
+The default `@Event` wire name strips a leading `on` and decapitalizes the remainder: Swift `onProgress` emits `progress`. 1.0 modules commonly expose `onProgress`. During migration, pass the original wire name explicitly unless an intentional JS breaking change was approved.
+
+Use `() -> Void` for no-payload events. For payloads, create or reuse a `JavaScriptEncodable` type instead of preserving an untyped dictionary. Migrate `OnStartObserving` and `OnStopObserving` to the `didStartListening(event:)`/`didStopListening(event:)` lifecycle hooks (see Views and lifecycle).
+
+Default `@Event` dispatch schedules onto the JS thread and is callable from other isolation contexts. Do not use `sync: true` unless core provides the matching `emitSync` overloads.
+
+## Shared objects
+
+Move instance behavior from a `Class(...)` block onto the `SharedObject` subclass:
+
+```swift
+// 2.0
+@SharedObject
+final class Download: SharedObject {
+  @JS
+  init(url: URL) {
+    self.url = url
+  }
+
+  @JS
+  func pause() {}
+
+  @JS
+  var progress: Double { currentProgress }
+
+  // Installs on the JS class (constructor) object, not the prototype.
+  @JS
+  static let maxConcurrent = 4
+}
+
+@ExpoModule(classes: [Download.self])
+final class DownloadModule: Module {}
+```
+
+Drop the leading owner argument used by instance DSL closures; use `self` in the real instance method. Preserve constructor arity and JS member names.
+
+Migrate only when the checked-out core supplies the shared-object decoration and construction hooks. Static properties migrate as Swift `static` or `class` properties and install on the JS class (constructor) object rather than the prototype; verify constructor-side routing for static functions before migrating them, since instance support does not imply static-function support. Never create both a 1.0 `Class(...)` entry and a 2.0 registration for the same class without confirming that core intentionally merges them.
+
+Static members belong to shared objects, not modules: a module is exported to JS as an instance, so Swift `static` members on a `Module` class are not useful there. Keep module-level values as instance `@JS` members.
+
+## Records
+
+Attach `@Record`, remove field wrappers, and encode requiredness in the declaration:
+
+```swift
+@Record
+struct Options {
+  var source: URL       // required
+  var retries: Int = 3  // omittable; default applies
+  var label: String?    // omittable and nullable
+}
+```
+
+Rules:
+
+- non-optional with no default: required
+- any property with a default: omittable
+- optional type: omittable and nullable
+
+Preserve the 1.0 contract exactly. For example, migrate `@Field var source: URL? = nil` to `var source: URL?`, not to `var source: URL`, unless the user approved a breaking change.
+
+Every stored property is part of the 2.0 record surface. If the old type contains stored bookkeeping that was not a 1.0 field, move it out of the record or leave the type on 1.0; there is no field opt-out. Verify that each field supports the required `JavaScriptDecodable`/`JavaScriptEncodable` direction.
+
+Do not adopt `@Union` until that macro and its coding witnesses exist in the target.
+
+## Views and lifecycle
+
+Keep UIKit `View`, `Prop`, view `Events`, and `OnViewDidUpdateProps` DSL entries until the target includes the complete `@ViewProps`/`@ExpoView` core contract. Macro declarations or expansion tests alone do not prove the runtime update path exists.
+
+Module lifecycle is core-owned rather than macro-generated. The DSL components map to hook methods with no-op defaults:
+
+| 1.0 | 2.0 |
+| --- | --- |
+| `OnCreate` | `didCreate()` |
+| `OnDestroy` | `willDestroy()` |
+| `OnStartObserving` | `didStartListening(event:)` |
+| `OnStopObserving` | `didStopListening(event:)` |
+
+Rules:
+
+- Use the `override` keyword when the class inherits `Module`/`BaseModule`; define the hooks directly (no `override`) when the conformance comes only from `@ExpoModule`. Hooks added only in a subclass of a macro module are not called; keep them on the class that declares the conformance.
+- The listening hooks receive the event name. A module-wide 1.0 `OnStartObserving` ignores the argument; a per-event `OnStartObserving("name")` becomes a comparison on it.
+- `didCreate()` runs after the module is registered, slightly later than 1.0 `OnCreate`, which fires before registration; `willDestroy()` runs at holder teardown. Verify nothing depends on the earlier timing before migrating `OnCreate`.
+- DSL lifecycle components can remain during an incremental migration and each fires exactly once, but do not implement a DSL component and its hook for the same behavior, or the work runs twice.
+
+There is no 2.0 replacement for every lifecycle component; for example, retain app-context teardown handling when no matching hook exists.
+
+## Mixed mode
+
+`@ExpoModule` may coexist with a non-empty `definition()` when the paired core supports merging the two surfaces. Keep only unsupported entries in the DSL and avoid duplicate names across macro and DSL registrations.
+
+Before deleting `definition()`, verify that it contains no:
+
+- views or view events
+- lifecycle or app-context listeners
+- queue-pinned functions
+- shared-object static functions or other unsupported definitions
+
+## Contract checklist
+
+For every migrated member compare before and after:
+
+| Concern | Must remain stable |
+| --- | --- |
+| Module | registration name and `requireNativeModule` key |
+| Function | JS name, accepted arity, omitted/default behavior, sync/Promise result |
+| Property | JS name, read/write behavior, evaluation/caching |
+| Event | listener string, payload shape, timing |
+| Record | field names, requiredness, nullability, defaults |
+| Shared object | constructor shape, prototype vs constructor placement, identity |
+| Execution | JS actor, main actor, background queue, ordering |
diff --git a/.agents/skills/expo-module/SKILL.md b/.agents/skills/expo-module/SKILL.md
index dbd2f29..e1db7d0 100644
--- a/.agents/skills/expo-module/SKILL.md
+++ b/.agents/skills/expo-module/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: expo-module
-description: Guide for creating and writing Expo native modules and views using the Expo Modules API (Swift, Kotlin, TypeScript). Covers module definition DSL, native views, shared objects, config plugins, lifecycle hooks, autolinking, and type system. Use when building or modifying native modules for Expo.
+description: Framework (OSS). Guide for creating and writing Expo native modules and views using the Expo Modules API (Swift, Kotlin, TypeScript). Covers module definition DSL, native views, shared objects, config plugins, lifecycle hooks, autolinking, and type system. Use when building or modifying native modules for Expo. Not for migrating an existing Swift module from the definition DSL to the Expo Modules API 2.0 macros; use expo-migrate-module (from the expo-experiments plugin) for that.
 version: 1.0.0
 license: MIT
 ---
@@ -18,6 +18,8 @@ Complete reference for building native modules and views using the Expo Modules
 - Adding Android, Apple, or web support to an existing Expo module
 - Editing `expo-module.config.json`, config plugins, or lifecycle hooks
 
+To migrate an existing Swift module from the definition DSL to the Expo Modules API 2.0 macros (`@ExpoModule`, `@JS`, `@Event`), use the `expo-migrate-module` skill (from the `expo-experiments` plugin) instead.
+
 ## References
 
 Consult these resources as needed:
@@ -139,3 +141,11 @@ export function hello(name: string): string {
 ```
 
 Note: iOS uses just the class name; Android uses the fully-qualified class name (package + class). See `references/module-config.md` for all fields.
+
+## 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-module" "<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.
diff --git a/.agents/skills/expo-native-ui/SKILL.md b/.agents/skills/expo-native-ui/SKILL.md
new file mode 100644
index 0000000..d080e80
--- /dev/null
+++ b/.agents/skills/expo-native-ui/SKILL.md
@@ -0,0 +1,189 @@
+---
+name: expo-native-ui
+description: Framework (OSS). Build beautiful, native-feeling Expo screens. Covers Apple HIG styling, semantic colors, native controls, SF Symbols, media, animations, visual effects, gradients, storage, and responsive layout. For routing and navigation, use the expo-router skill.
+version: 1.1.1
+license: MIT
+---
+
+# Expo Native UI Guidelines
+
+For routes, links, stacks, tabs, modals, sheets, and headers, use the `expo-router` skill.
+
+## References
+
+Consult these resources as needed:
+
+```
+references/
+  animations.md          Reanimated: entering, exiting, layout, scroll-driven, gestures
+  controls.md            Native iOS: Switch, Slider, SegmentedControl, DateTimePicker, Picker
+  gradients.md           CSS gradients via experimental_backgroundImage (New Arch only)
+  icons.md               SF Symbols via expo-image (sf: source), names, animations, weights
+  media.md               Camera, audio, video, and file saving
+  storage.md             SQLite, AsyncStorage, SecureStore
+  visual-effects.md      Blur (expo-blur) and liquid glass (expo-glass-effect)
+  webgpu-three.md        3D graphics, games, GPU visualizations with WebGPU and Three.js
+```
+
+## Running the App
+
+**CRITICAL: Always try Expo Go first before creating custom builds.**
+
+Most Expo apps work in Expo Go without any custom native code. Before running `npx expo run:ios` or `npx expo run:android`:
+
+1. **Start with Expo Go**: Run `npx expo start` and scan the QR code with Expo Go
+2. **Check if features work**: Test your app thoroughly in Expo Go
+3. **Only create custom builds when required** - see below
+
+### When Custom Builds Are Required
+
+You need `npx expo run:ios/android` or `eas build` ONLY when using:
+
+- **Local Expo modules** (custom native code in `modules/`)
+- **Apple targets** (widgets, app clips, extensions via `@bacons/apple-targets`)
+- **Third-party native modules** not included in Expo Go
+- **Custom native configuration** that can't be expressed in `app.json`
+
+### When Expo Go Works
+
+Expo Go supports a huge range of features out of the box:
+
+- All `expo-*` packages (camera, location, notifications, etc.)
+- Expo Router navigation
+- Most UI libraries (reanimated, gesture handler, etc.)
+- Push notifications, deep links, and more
+
+**If you're unsure, try Expo Go first.** Creating custom builds adds complexity, slower iteration, and requires Xcode/Android Studio setup.
+
+## Code Style
+
+- Be cautious of unterminated strings. Ensure nested backticks are escaped; never forget to escape quotes correctly.
+- Always use import statements at the top of the file.
+- Always use kebab-case for file names, e.g. `comment-card.tsx`
+- Never use special characters in file names
+- Configure tsconfig.json with path aliases, and prefer aliases over relative imports for refactors.
+
+## Library Preferences
+
+- Never use modules removed from React Native such as Picker, WebView, SafeAreaView, or AsyncStorage
+- Never use legacy expo-permissions
+- `expo-audio` not `expo-av`
+- `expo-video` not `expo-av`
+- `expo-image` with `source="sf:name"` for SF Symbols, not `expo-symbols` or `@expo/vector-icons`
+- `react-native-safe-area-context` not react-native SafeAreaView
+- `process.env.EXPO_OS` not `Platform.OS`
+- `React.use` not `React.useContext`
+- `expo-image` Image component instead of intrinsic element `img`
+- `expo-glass-effect` for liquid glass backdrops
+- `Color` from `expo-router` for native semantic colors, not raw `PlatformColor` (type-safe, auto-adapts to light/dark)
+- In SDK 56+, never import from `@react-navigation/*` directly — use `expo-router/react-navigation` instead (covers `@react-navigation/native`, `/core`, `/elements`, `/routers`)
+
+## Responsiveness
+
+- Always wrap root component in a scroll view for responsiveness
+- Use `<ScrollView contentInsetAdjustmentBehavior="automatic" />` instead of `<SafeAreaView>` for smarter safe area insets
+- `contentInsetAdjustmentBehavior="automatic"` should be applied to FlatList and SectionList as well
+- Use flexbox instead of Dimensions API
+- ALWAYS prefer `useWindowDimensions` over `Dimensions.get()` to measure screen size
+
+## Behavior
+
+- Use expo-haptics conditionally on iOS to make more delightful experiences
+- Use views with built-in haptics like `<Switch />` from React Native and `@react-native-community/datetimepicker`
+- When a route belongs to a Stack, its first child should almost always be a ScrollView with `contentInsetAdjustmentBehavior="automatic"` set
+- When adding a `ScrollView` to the page it should almost always be the first component inside the route component
+- Use the `<Text selectable />` prop on text containing data that could be copied
+- Consider formatting large numbers like 1.4M or 38k
+- Never use intrinsic elements like 'img' or 'div' unless in a webview or Expo DOM component
+
+# Styling
+
+Follow Apple Human Interface Guidelines.
+
+## General Styling Rules
+
+- Prefer flex gap over margin and padding styles
+- Prefer padding over margin where possible
+- Always account for safe area, either with stack headers, tabs, or ScrollView/FlatList `contentInsetAdjustmentBehavior="automatic"`
+- Ensure both top and bottom safe area insets are accounted for
+- Inline styles not StyleSheet.create unless reusing styles is faster
+- Add entering and exiting animations for state changes
+- Use `{ borderCurve: 'continuous' }` for rounded corners unless creating a capsule shape
+- ALWAYS use a navigation stack title instead of a custom text element on the page
+- When padding a ScrollView, use `contentContainerStyle` padding and gap instead of padding on the ScrollView itself (reduces clipping)
+- CSS and Tailwind are not supported - use inline styles
+
+## Colors
+
+Use the `Color` API from `expo-router` for native semantic colors. It is a type-safe wrapper over `PlatformColor` that exposes iOS UIKit colors through `Color.ios.*` and Android Material 3 colors through `Color.android.material.*` (static) or `Color.android.dynamic.*` (adapts to the user's wallpaper on Android 12+). These resolve on-device and automatically adapt to light/dark mode and accessibility settings, so you no longer maintain separate light/dark hex tables or a `colors.web.ts` file.
+
+`Color` is platform-specific, so wrap each value in `Platform.select` with a `default` hex fallback for web. Centralize the palette in `theme/colors.ts` and import `colors` everywhere:
+
+```tsx
+// theme/colors.ts
+import { Platform } from "react-native";
+import { Color } from "expo-router";
+
+export const colors = {
+  label: Platform.select({
+    ios: Color.ios.label,
+    android: Color.android.dynamic.onSurface,
+    default: "#000000",
+  })!,
+  secondaryLabel: Platform.select({
+    ios: Color.ios.secondaryLabel,
+    android: Color.android.dynamic.onSurfaceVariant,
+    default: "#3c3c43",
+  })!,
+  separator: Platform.select({
+    ios: Color.ios.separator,
+    android: Color.android.dynamic.outlineVariant,
+    default: "#c6c6c8",
+  })!,
+  systemBackground: Platform.select({
+    ios: Color.ios.systemBackground,
+    android: Color.android.dynamic.surface,
+    default: "#ffffff",
+  })!,
+  systemBlue: Platform.select({
+    ios: Color.ios.systemBlue,
+    android: Color.android.dynamic.primary,
+    default: "#007aff",
+  })!,
+};
+```
+
+```tsx
+import { colors } from "@/theme/colors";
+
+<View style={{ backgroundColor: colors.systemBackground }}>
+  <Text style={{ color: colors.label }}>Title</Text>
+</View>;
+```
+
+- iOS re-resolves these colors automatically when the system theme changes. On Android, call `useColorScheme()` inside any component that renders them so it re-renders when the theme flips (required when React Compiler memoizes the component).
+- Don't pass `Color` / `PlatformColor` values into Reanimated styles — use static colors there (see `references/animations.md`).
+- `Platform.select({...})!` returns `string | OpaqueColorValue`. Most React Native style props accept `ColorValue` (`string | OpaqueColorValue`) so this works fine. But some third-party props only accept `string` (e.g. `tintColor` on `expo-image`). Cast when needed: `colors.label as string`.
+
+## Text Styling
+
+- Add the `selectable` prop to every `<Text/>` element displaying important data or error messages
+- Counters should use `{ fontVariant: 'tabular-nums' }` for alignment
+
+## Shadows
+
+Use CSS `boxShadow` style prop. NEVER use legacy React Native shadow or elevation styles.
+
+```tsx
+<View style={{ boxShadow: "0 1px 2px rgba(0, 0, 0, 0.05)" }} />
+```
+
+'inset' shadows are supported.
+
+## 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-native-ui" "<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.
diff --git a/.agents/skills/expo-native-ui/agents/openai.yaml b/.agents/skills/expo-native-ui/agents/openai.yaml
new file mode 100644
index 0000000..bcd8e32
--- /dev/null
+++ b/.agents/skills/expo-native-ui/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Expo Native UI"
+  short_description: "Build beautiful, native-feeling Expo screens: HIG styling, semantic colors, controls, SF Symbols, media, animation, and visual effects"
+  default_prompt: "Use $expo-native-ui to style native-feeling Expo screens, choose semantic colors and native controls, add media, animations, and visual effects, and decide when Expo Go is enough before creating native builds."
diff --git a/.agents/skills/expo-native-ui/references/animations.md b/.agents/skills/expo-native-ui/references/animations.md
new file mode 100644
index 0000000..30cfa6d
--- /dev/null
+++ b/.agents/skills/expo-native-ui/references/animations.md
@@ -0,0 +1,220 @@
+# Animations
+
+Use Reanimated v4. Avoid React Native's built-in Animated API.
+
+## Entering and Exiting Animations
+
+Use Animated.View with entering and exiting animations. Layout animations can animate state changes.
+
+```tsx
+import Animated, {
+  FadeIn,
+  FadeOut,
+  LinearTransition,
+} from "react-native-reanimated";
+
+function App() {
+  return (
+    <Animated.View
+      entering={FadeIn}
+      exiting={FadeOut}
+      layout={LinearTransition}
+    />
+  );
+}
+```
+
+## On-Scroll Animations
+
+Create high-performance scroll animations using Reanimated's hooks:
+
+```tsx
+import Animated, {
+  useAnimatedRef,
+  useScrollViewOffset,
+  useAnimatedStyle,
+  interpolate,
+} from "react-native-reanimated";
+
+function Page() {
+  const ref = useAnimatedRef();
+  const scroll = useScrollViewOffset(ref);
+
+  const style = useAnimatedStyle(() => ({
+    opacity: interpolate(scroll.value, [0, 30], [0, 1], "clamp"),
+  }));
+
+  return (
+    <Animated.ScrollView ref={ref}>
+      <Animated.View style={style} />
+    </Animated.ScrollView>
+  );
+}
+```
+
+## Common Animation Presets
+
+### Entering Animations
+
+- `FadeIn`, `FadeInUp`, `FadeInDown`, `FadeInLeft`, `FadeInRight`
+- `SlideInUp`, `SlideInDown`, `SlideInLeft`, `SlideInRight`
+- `ZoomIn`, `ZoomInUp`, `ZoomInDown`
+- `BounceIn`, `BounceInUp`, `BounceInDown`
+
+### Exiting Animations
+
+- `FadeOut`, `FadeOutUp`, `FadeOutDown`, `FadeOutLeft`, `FadeOutRight`
+- `SlideOutUp`, `SlideOutDown`, `SlideOutLeft`, `SlideOutRight`
+- `ZoomOut`, `ZoomOutUp`, `ZoomOutDown`
+- `BounceOut`, `BounceOutUp`, `BounceOutDown`
+
+### Layout Animations
+
+- `LinearTransition` — Smooth linear interpolation
+- `SequencedTransition` — Sequenced property changes
+- `FadingTransition` — Fade between states
+
+## Customizing Animations
+
+```tsx
+<Animated.View
+  entering={FadeInDown.duration(500).delay(200)}
+  exiting={FadeOut.duration(300)}
+/>
+```
+
+### Modifiers
+
+```tsx
+// Duration in milliseconds
+FadeIn.duration(300);
+
+// Delay before starting
+FadeIn.delay(100);
+
+// Spring physics
+FadeIn.springify();
+FadeIn.springify().damping(15).stiffness(100);
+
+// Easing curves
+FadeIn.easing(Easing.bezier(0.25, 0.1, 0.25, 1));
+
+// Chaining
+FadeInDown.duration(400).delay(200).springify();
+```
+
+## Shared Value Animations
+
+For imperative control over animations:
+
+```tsx
+import {
+  useSharedValue,
+  withSpring,
+  withTiming,
+} from "react-native-reanimated";
+
+const offset = useSharedValue(0);
+
+// Spring animation
+offset.value = withSpring(100);
+
+// Timing animation
+offset.value = withTiming(100, { duration: 300 });
+
+// Use in styles
+const style = useAnimatedStyle(() => ({
+  transform: [{ translateX: offset.value }],
+}));
+```
+
+## Gesture Animations
+
+Combine with React Native Gesture Handler:
+
+```tsx
+import { Gesture, GestureDetector } from "react-native-gesture-handler";
+import Animated, {
+  useSharedValue,
+  useAnimatedStyle,
+  withSpring,
+} from "react-native-reanimated";
+
+function DraggableBox() {
+  const translateX = useSharedValue(0);
+  const translateY = useSharedValue(0);
+
+  const gesture = Gesture.Pan()
+    .onUpdate((e) => {
+      translateX.value = e.translationX;
+      translateY.value = e.translationY;
+    })
+    .onEnd(() => {
+      translateX.value = withSpring(0);
+      translateY.value = withSpring(0);
+    });
+
+  const style = useAnimatedStyle(() => ({
+    transform: [
+      { translateX: translateX.value },
+      { translateY: translateY.value },
+    ],
+  }));
+
+  return (
+    <GestureDetector gesture={gesture}>
+      <Animated.View style={[styles.box, style]} />
+    </GestureDetector>
+  );
+}
+```
+
+## Keyboard Animations
+
+Animate with keyboard height changes:
+
+```tsx
+import Animated, {
+  useAnimatedKeyboard,
+  useAnimatedStyle,
+} from "react-native-reanimated";
+
+function KeyboardAwareView() {
+  const keyboard = useAnimatedKeyboard();
+
+  const style = useAnimatedStyle(() => ({
+    paddingBottom: keyboard.height.value,
+  }));
+
+  return <Animated.View style={style}>{/* content */}</Animated.View>;
+}
+```
+
+## Staggered List Animations
+
+Animate list items with delays:
+
+```tsx
+{
+  items.map((item, index) => (
+    <Animated.View
+      key={item.id}
+      entering={FadeInUp.delay(index * 50)}
+      exiting={FadeOutUp}
+    >
+      <ListItem item={item} />
+    </Animated.View>
+  ));
+}
+```
+
+## Best Practices
+
+- Add entering and exiting animations for state changes
+- Use layout animations when items are added/removed from lists
+- Use `useAnimatedStyle` for scroll-driven animations
+- Prefer `interpolate` with "clamp" for bounded values
+- You can't pass `Color` (from expo-router) or `PlatformColor` values to reanimated views or styles; use static colors instead
+- Keep animations under 300ms for responsive feel
+- Use spring animations for natural movement
+- Avoid animating layout properties (width, height) when possible — prefer transforms
diff --git a/.agents/skills/expo-native-ui/references/controls.md b/.agents/skills/expo-native-ui/references/controls.md
new file mode 100644
index 0000000..762fe20
--- /dev/null
+++ b/.agents/skills/expo-native-ui/references/controls.md
@@ -0,0 +1,270 @@
+# Native Controls
+
+Native iOS controls provide built-in haptics, accessibility, and platform-appropriate styling.
+
+## Switch
+
+Use for binary on/off settings. Has built-in haptics.
+
+```tsx
+import { Switch } from "react-native";
+import { useState } from "react";
+
+const [enabled, setEnabled] = useState(false);
+
+<Switch value={enabled} onValueChange={setEnabled} />;
+```
+
+### Customization
+
+```tsx
+<Switch
+  value={enabled}
+  onValueChange={setEnabled}
+  trackColor={{ false: "#767577", true: "#81b0ff" }}
+  thumbColor={enabled ? "#f5dd4b" : "#f4f3f4"}
+  ios_backgroundColor="#3e3e3e"
+/>
+```
+
+## Segmented Control
+
+Use for non-navigational tabs or mode selection. Avoid changing default colors.
+
+```tsx
+import SegmentedControl from "@react-native-segmented-control/segmented-control";
+import { useState } from "react";
+
+const [index, setIndex] = useState(0);
+
+<SegmentedControl
+  values={["All", "Active", "Done"]}
+  selectedIndex={index}
+  onChange={({ nativeEvent }) => setIndex(nativeEvent.selectedSegmentIndex)}
+/>;
+```
+
+### Rules
+
+- Maximum 4 options — use a picker for more
+- Keep labels short (1-2 words)
+- Avoid custom colors — native styling adapts to dark mode
+
+### With Icons (iOS 14+)
+
+```tsx
+<SegmentedControl
+  values={[
+    { label: "List", icon: "list.bullet" },
+    { label: "Grid", icon: "square.grid.2x2" },
+  ]}
+  selectedIndex={index}
+  onChange={({ nativeEvent }) => setIndex(nativeEvent.selectedSegmentIndex)}
+/>
+```
+
+## Slider
+
+Continuous value selection.
+
+```tsx
+import Slider from "@react-native-community/slider";
+import { useState } from "react";
+
+const [value, setValue] = useState(0.5);
+
+<Slider
+  value={value}
+  onValueChange={setValue}
+  minimumValue={0}
+  maximumValue={1}
+/>;
+```
+
+### Customization
+
+```tsx
+<Slider
+  value={value}
+  onValueChange={setValue}
+  minimumValue={0}
+  maximumValue={100}
+  step={1}
+  minimumTrackTintColor="#007AFF"
+  maximumTrackTintColor="#E5E5EA"
+  thumbTintColor="#007AFF"
+/>
+```
+
+### Discrete Steps
+
+```tsx
+<Slider
+  value={value}
+  onValueChange={setValue}
+  minimumValue={0}
+  maximumValue={10}
+  step={1}
+/>
+```
+
+## Date/Time Picker
+
+Compact pickers with popovers. Has built-in haptics.
+
+```tsx
+import DateTimePicker from "@react-native-community/datetimepicker";
+import { useState } from "react";
+
+const [date, setDate] = useState(new Date());
+
+<DateTimePicker
+  value={date}
+  onChange={(event, selectedDate) => {
+    if (selectedDate) setDate(selectedDate);
+  }}
+  mode="datetime"
+/>;
+```
+
+### Modes
+
+- `date` — Date only
+- `time` — Time only
+- `datetime` — Date and time
+
+### Display Styles
+
+```tsx
+// Compact inline (default)
+<DateTimePicker value={date} mode="date" />
+
+// Spinner wheel
+<DateTimePicker
+  value={date}
+  mode="date"
+  display="spinner"
+  style={{ width: 200, height: 150 }}
+/>
+
+// Full calendar
+<DateTimePicker value={date} mode="date" display="inline" />
+```
+
+### Time Intervals
+
+```tsx
+<DateTimePicker
+  value={date}
+  mode="time"
+  minuteInterval={15}
+/>
+```
+
+### Min/Max Dates
+
+```tsx
+<DateTimePicker
+  value={date}
+  mode="date"
+  minimumDate={new Date(2020, 0, 1)}
+  maximumDate={new Date(2030, 11, 31)}
+/>
+```
+
+## Stepper
+
+Increment/decrement numeric values.
+
+```tsx
+import { Stepper } from "react-native";
+import { useState } from "react";
+
+const [count, setCount] = useState(0);
+
+<Stepper
+  value={count}
+  onValueChange={setCount}
+  minimumValue={0}
+  maximumValue={10}
+/>;
+```
+
+## TextInput
+
+Native text input with various keyboard types.
+
+```tsx
+import { TextInput } from "react-native";
+
+<TextInput
+  placeholder="Enter text..."
+  placeholderTextColor="#999"
+  style={{
+    padding: 12,
+    fontSize: 16,
+    borderRadius: 8,
+    backgroundColor: "#f0f0f0",
+  }}
+/>
+```
+
+### Keyboard Types
+
+```tsx
+// Email
+<TextInput keyboardType="email-address" autoCapitalize="none" />
+
+// Phone
+<TextInput keyboardType="phone-pad" />
+
+// Number
+<TextInput keyboardType="numeric" />
+
+// Password
+<TextInput secureTextEntry />
+
+// Search
+<TextInput
+  returnKeyType="search"
+  enablesReturnKeyAutomatically
+/>
+```
+
+### Multiline
+
+```tsx
+<TextInput
+  multiline
+  numberOfLines={4}
+  textAlignVertical="top"
+  style={{ minHeight: 100 }}
+/>
+```
+
+## Picker (Wheel)
+
+For selection from many options (5+ items).
+
+```tsx
+import { Picker } from "@react-native-picker/picker";
+import { useState } from "react";
+
+const [selected, setSelected] = useState("js");
+
+<Picker selectedValue={selected} onValueChange={setSelected}>
+  <Picker.Item label="JavaScript" value="js" />
+  <Picker.Item label="TypeScript" value="ts" />
+  <Picker.Item label="Python" value="py" />
+  <Picker.Item label="Go" value="go" />
+</Picker>;
+```
+
+## Best Practices
+
+- **Haptics**: Switch and DateTimePicker have built-in haptics — don't add extra
+- **Accessibility**: Native controls have proper accessibility labels by default
+- **Dark Mode**: Avoid custom colors — native styling adapts automatically
+- **Spacing**: Use consistent padding around controls (12-16pt)
+- **Labels**: Place labels above or to the left of controls
+- **Grouping**: Group related controls in sections with headers
diff --git a/.agents/skills/expo-native-ui/references/gradients.md b/.agents/skills/expo-native-ui/references/gradients.md
new file mode 100644
index 0000000..329600d
--- /dev/null
+++ b/.agents/skills/expo-native-ui/references/gradients.md
@@ -0,0 +1,106 @@
+# CSS Gradients
+
+> **New Architecture Only**: CSS gradients require React Native's New Architecture (Fabric). They are not available in the old architecture or Expo Go.
+
+Use CSS gradients with the `experimental_backgroundImage` style property.
+
+## Linear Gradients
+
+```tsx
+// Top to bottom
+<View style={{
+  experimental_backgroundImage: 'linear-gradient(to bottom, rgba(0, 0, 0, 0) 0%, rgba(0, 0, 0, 1) 100%)'
+}} />
+
+// Left to right
+<View style={{
+  experimental_backgroundImage: 'linear-gradient(to right, #ff0000 0%, #0000ff 100%)'
+}} />
+
+// Diagonal
+<View style={{
+  experimental_backgroundImage: 'linear-gradient(45deg, #ff0000 0%, #00ff00 50%, #0000ff 100%)'
+}} />
+
+// Using degrees
+<View style={{
+  experimental_backgroundImage: 'linear-gradient(135deg, transparent 0%, black 100%)'
+}} />
+```
+
+## Radial Gradients
+
+```tsx
+// Circle at center
+<View style={{
+  experimental_backgroundImage: 'radial-gradient(circle at center, rgba(255, 0, 0, 1) 0%, rgba(0, 0, 255, 1) 100%)'
+}} />
+
+// Ellipse
+<View style={{
+  experimental_backgroundImage: 'radial-gradient(ellipse at center, #fff 0%, #000 100%)'
+}} />
+
+// Positioned
+<View style={{
+  experimental_backgroundImage: 'radial-gradient(circle at top left, #ff0000 0%, transparent 70%)'
+}} />
+```
+
+## Multiple Gradients
+
+Stack multiple gradients by comma-separating them:
+
+```tsx
+<View style={{
+  experimental_backgroundImage: `
+    linear-gradient(to bottom, transparent 0%, black 100%),
+    radial-gradient(circle at top right, rgba(255, 0, 0, 0.5) 0%, transparent 50%)
+  `
+}} />
+```
+
+## Common Patterns
+
+### Overlay on Image
+
+```tsx
+<View style={{ position: 'relative' }}>
+  <Image source={{ uri: '...' }} style={{ width: '100%', height: 200 }} />
+  <View style={{
+    position: 'absolute',
+    inset: 0,
+    experimental_backgroundImage: 'linear-gradient(to top, rgba(0, 0, 0, 0.8) 0%, transparent 50%)'
+  }} />
+</View>
+```
+
+### Frosted Glass Effect
+
+```tsx
+<View style={{
+  experimental_backgroundImage: 'linear-gradient(135deg, rgba(255, 255, 255, 0.1) 0%, rgba(255, 255, 255, 0.05) 100%)',
+  backdropFilter: 'blur(10px)',
+}} />
+```
+
+### Button Gradient
+
+```tsx
+<Pressable style={{
+  experimental_backgroundImage: 'linear-gradient(to bottom, #4CAF50 0%, #388E3C 100%)',
+  padding: 16,
+  borderRadius: 8,
+}}>
+  <Text style={{ color: 'white', textAlign: 'center' }}>Submit</Text>
+</Pressable>
+```
+
+## Important Notes
+
+- Do NOT use `expo-linear-gradient` — use CSS gradients instead
+- Gradients are strings, not objects
+- Use `rgba()` for transparency, or `transparent` keyword
+- Color stops use percentages (0%, 50%, 100%)
+- Direction keywords: `to top`, `to bottom`, `to left`, `to right`, `to top left`, etc.
+- Degree values: `45deg`, `90deg`, `135deg`, etc.
diff --git a/.agents/skills/expo-native-ui/references/icons.md b/.agents/skills/expo-native-ui/references/icons.md
new file mode 100644
index 0000000..744d169
--- /dev/null
+++ b/.agents/skills/expo-native-ui/references/icons.md
@@ -0,0 +1,213 @@
+# Icons (SF Symbols)
+
+Use SF Symbols for native feel. Never use FontAwesome or Ionicons.
+
+## Basic Usage
+
+```tsx
+import { SymbolView } from "expo-symbols";
+import { colors } from "@/theme/colors";
+
+<SymbolView
+  tintColor={colors.label}
+  resizeMode="scaleAspectFit"
+  name="square.and.arrow.down"
+  style={{ width: 16, height: 16 }}
+/>;
+```
+
+## Props
+
+```tsx
+<SymbolView
+  name="star.fill"                    // SF Symbol name (required)
+  tintColor={colors.label}            // Icon color
+  size={24}                           // Shorthand for width/height
+  resizeMode="scaleAspectFit"         // How to scale
+  weight="regular"                    // thin | ultraLight | light | regular | medium | semibold | bold | heavy | black
+  scale="medium"                      // small | medium | large
+  style={{ width: 16, height: 16 }}   // Standard style props
+/>
+```
+
+## Common Icons
+
+### Navigation & Actions
+- `house.fill` - home
+- `gear` - settings
+- `magnifyingglass` - search
+- `plus` - add
+- `xmark` - close
+- `chevron.left` - back
+- `chevron.right` - forward
+- `arrow.left` - back arrow
+- `arrow.right` - forward arrow
+
+### Media
+- `play.fill` - play
+- `pause.fill` - pause
+- `stop.fill` - stop
+- `backward.fill` - rewind
+- `forward.fill` - fast forward
+- `speaker.wave.2.fill` - volume
+- `speaker.slash.fill` - mute
+
+### Camera
+- `camera` - camera
+- `camera.fill` - camera filled
+- `arrow.triangle.2.circlepath` - flip camera
+- `photo` - gallery/photos
+- `bolt` - flash
+- `bolt.slash` - flash off
+
+### Communication
+- `message` - message
+- `message.fill` - message filled
+- `envelope` - email
+- `envelope.fill` - email filled
+- `phone` - phone
+- `phone.fill` - phone filled
+- `video` - video call
+- `video.fill` - video call filled
+
+### Social
+- `heart` - like
+- `heart.fill` - liked
+- `star` - favorite
+- `star.fill` - favorited
+- `hand.thumbsup` - thumbs up
+- `hand.thumbsdown` - thumbs down
+- `person` - profile
+- `person.fill` - profile filled
+- `person.2` - people
+- `person.2.fill` - people filled
+
+### Content Actions
+- `square.and.arrow.up` - share
+- `square.and.arrow.down` - download
+- `doc.on.doc` - copy
+- `trash` - delete
+- `pencil` - edit
+- `folder` - folder
+- `folder.fill` - folder filled
+- `bookmark` - bookmark
+- `bookmark.fill` - bookmarked
+
+### Status & Feedback
+- `checkmark` - success/done
+- `checkmark.circle.fill` - completed
+- `xmark.circle.fill` - error/failed
+- `exclamationmark.triangle` - warning
+- `info.circle` - info
+- `questionmark.circle` - help
+- `bell` - notification
+- `bell.fill` - notification filled
+
+### Misc
+- `ellipsis` - more options
+- `ellipsis.circle` - more in circle
+- `line.3.horizontal` - menu/hamburger
+- `slider.horizontal.3` - filters
+- `arrow.clockwise` - refresh
+- `location` - location
+- `location.fill` - location filled
+- `map` - map
+- `mappin` - pin
+- `clock` - time
+- `calendar` - calendar
+- `link` - link
+- `nosign` - block/prohibited
+
+## Animated Symbols
+
+```tsx
+<SymbolView
+  name="checkmark.circle"
+  animationSpec={{
+    effect: {
+      type: "bounce",
+      direction: "up",
+    },
+  }}
+/>
+```
+
+### Animation Effects
+
+- `bounce` - Bouncy animation
+- `pulse` - Pulsing effect
+- `variableColor` - Color cycling
+- `scale` - Scale animation
+
+```tsx
+// Bounce with direction
+animationSpec={{
+  effect: { type: "bounce", direction: "up" }  // up | down
+}}
+
+// Pulse
+animationSpec={{
+  effect: { type: "pulse" }
+}}
+
+// Variable color (multicolor symbols)
+animationSpec={{
+  effect: {
+    type: "variableColor",
+    cumulative: true,
+    reversing: true
+  }
+}}
+```
+
+## Symbol Weights
+
+```tsx
+// Lighter weights
+<SymbolView name="star" weight="ultraLight" />
+<SymbolView name="star" weight="thin" />
+<SymbolView name="star" weight="light" />
+
+// Default
+<SymbolView name="star" weight="regular" />
+
+// Heavier weights
+<SymbolView name="star" weight="medium" />
+<SymbolView name="star" weight="semibold" />
+<SymbolView name="star" weight="bold" />
+<SymbolView name="star" weight="heavy" />
+<SymbolView name="star" weight="black" />
+```
+
+## Symbol Scales
+
+```tsx
+<SymbolView name="star" scale="small" />
+<SymbolView name="star" scale="medium" />  // default
+<SymbolView name="star" scale="large" />
+```
+
+## Multicolor Symbols
+
+Some symbols support multiple colors:
+
+```tsx
+<SymbolView
+  name="cloud.sun.rain.fill"
+  type="multicolor"
+/>
+```
+
+## Finding Symbol Names
+
+1. Use the SF Symbols app on macOS (free from Apple)
+2. Search at https://developer.apple.com/sf-symbols/
+3. Symbol names use dot notation: `square.and.arrow.up`
+
+## Best Practices
+
+- Always use SF Symbols over vector icon libraries
+- Match symbol weight to nearby text weight
+- Use `.fill` variants for selected/active states
+- Use the cross-platform `colors` helper (see SKILL.md "Colors") for tint to support dark mode
+- Keep icons at consistent sizes (16, 20, 24, 32)
diff --git a/.agents/skills/expo-native-ui/references/media.md b/.agents/skills/expo-native-ui/references/media.md
new file mode 100644
index 0000000..4962d07
--- /dev/null
+++ b/.agents/skills/expo-native-ui/references/media.md
@@ -0,0 +1,198 @@
+# Media
+
+## Camera
+
+- Hide navigation headers when there's a full screen camera
+- Ensure to flip the camera with `mirror` to emulate social apps
+- Use liquid glass buttons on cameras
+- Icons: `arrow.triangle.2.circlepath` (flip), `photo` (gallery), `bolt` (flash)
+- Eagerly request camera permission
+- Lazily request media library permission
+
+```tsx
+import React, { useRef, useState } from "react";
+import { View, TouchableOpacity, Text, Alert } from "react-native";
+import { CameraView, CameraType, useCameraPermissions } from "expo-camera";
+import * as MediaLibrary from "expo-media-library";
+import * as ImagePicker from "expo-image-picker";
+import * as Haptics from "expo-haptics";
+import { SymbolView } from "expo-symbols";
+import { colors } from "@/theme/colors";
+import { GlassView } from "expo-glass-effect";
+import { useSafeAreaInsets } from "react-native-safe-area-context";
+
+function Camera({ onPicture }: { onPicture: (uri: string) => Promise<void> }) {
+  const [permission, requestPermission] = useCameraPermissions();
+  const cameraRef = useRef<CameraView>(null);
+  const [type, setType] = useState<CameraType>("back");
+  const { bottom } = useSafeAreaInsets();
+
+  if (!permission?.granted) {
+    return (
+      <View style={{ flex: 1, justifyContent: "center", alignItems: "center", backgroundColor: colors.systemBackground }}>
+        <Text style={{ color: colors.label, padding: 16 }}>Camera access is required</Text>
+        <GlassView isInteractive tintColor={colors.systemBlue} style={{ borderRadius: 12 }}>
+          <TouchableOpacity onPress={requestPermission} style={{ padding: 12, borderRadius: 12 }}>
+            <Text style={{ color: "white" }}>Grant Permission</Text>
+          </TouchableOpacity>
+        </GlassView>
+      </View>
+    );
+  }
+
+  const takePhoto = async () => {
+    await Haptics.selectionAsync();
+    if (!cameraRef.current) return;
+    const photo = await cameraRef.current.takePictureAsync({ quality: 0.8 });
+    await onPicture(photo.uri);
+  };
+
+  const selectPhoto = async () => {
+    await Haptics.selectionAsync();
+    const result = await ImagePicker.launchImageLibraryAsync({
+      mediaTypes: "images",
+      allowsEditing: false,
+      quality: 0.8,
+    });
+    if (!result.canceled && result.assets?.[0]) {
+      await onPicture(result.assets[0].uri);
+    }
+  };
+
+  return (
+    <View style={{ flex: 1, backgroundColor: "black" }}>
+      <CameraView ref={cameraRef} mirror style={{ flex: 1 }} facing={type} />
+      <View style={{ position: "absolute", left: 0, right: 0, bottom: bottom, gap: 16, alignItems: "center" }}>
+        <GlassView isInteractive style={{ padding: 8, borderRadius: 99 }}>
+          <TouchableOpacity onPress={takePhoto} style={{ width: 64, height: 64, borderRadius: 99, backgroundColor: "white" }} />
+        </GlassView>
+        <View style={{ flexDirection: "row", justifyContent: "space-around", paddingHorizontal: 8 }}>
+          <GlassButton onPress={selectPhoto} icon="photo" />
+          <GlassButton onPress={() => setType(t => t === "back" ? "front" : "back")} icon="arrow.triangle.2.circlepath" />
+        </View>
+      </View>
+    </View>
+  );
+}
+```
+
+## Audio Playback
+
+Use `expo-audio` not `expo-av`:
+
+```tsx
+import { useAudioPlayer } from 'expo-audio';
+
+const player = useAudioPlayer({ uri: 'https://stream.nightride.fm/rektory.mp3' });
+
+<Button title="Play" onPress={() => player.play()} />
+```
+
+## Audio Recording (Microphone)
+
+```tsx
+import {
+  useAudioRecorder,
+  AudioModule,
+  RecordingPresets,
+  setAudioModeAsync,
+  useAudioRecorderState,
+} from 'expo-audio';
+import { useEffect } from 'react';
+import { Alert, Button } from 'react-native';
+
+function App() {
+  const audioRecorder = useAudioRecorder(RecordingPresets.HIGH_QUALITY);
+  const recorderState = useAudioRecorderState(audioRecorder);
+
+  const record = async () => {
+    await audioRecorder.prepareToRecordAsync();
+    audioRecorder.record();
+  };
+
+  const stop = () => audioRecorder.stop();
+
+  useEffect(() => {
+    (async () => {
+      const status = await AudioModule.requestRecordingPermissionsAsync();
+      if (status.granted) {
+        setAudioModeAsync({ playsInSilentMode: true, allowsRecording: true });
+      } else {
+        Alert.alert('Permission to access microphone was denied');
+      }
+    })();
+  }, []);
+
+  return (
+    <Button
+      title={recorderState.isRecording ? 'Stop' : 'Start'}
+      onPress={recorderState.isRecording ? stop : record}
+    />
+  );
+}
+```
+
+## Video Playback
+
+Use `expo-video` not `expo-av`:
+
+```tsx
+import { useVideoPlayer, VideoView } from 'expo-video';
+import { useEvent } from 'expo';
+
+const videoSource = 'https://example.com/video.mp4';
+
+const player = useVideoPlayer(videoSource, player => {
+  player.loop = true;
+  player.play();
+});
+
+const { isPlaying } = useEvent(player, 'playingChange', { isPlaying: player.playing });
+
+<VideoView player={player} fullscreenOptions={{}} allowsPictureInPicture />
+```
+
+VideoView options:
+- `allowsPictureInPicture`: boolean
+- `contentFit`: 'contain' | 'cover' | 'fill'
+- `nativeControls`: boolean
+- `playsInline`: boolean
+- `startsPictureInPictureAutomatically`: boolean
+
+## Saving Media
+
+```tsx
+import * as MediaLibrary from "expo-media-library";
+
+const { granted } = await MediaLibrary.requestPermissionsAsync();
+if (granted) {
+  await MediaLibrary.saveToLibraryAsync(uri);
+}
+```
+
+### Saving Base64 Images
+
+`MediaLibrary.saveToLibraryAsync` only accepts local file paths. Save base64 strings to disk first:
+
+```tsx
+import { File, Paths } from "expo-file-system/next";
+
+function base64ToLocalUri(base64: string, filename?: string) {
+  if (!filename) {
+    const match = base64.match(/^data:(image\/[a-zA-Z]+);base64,/);
+    const ext = match ? match[1].split("/")[1] : "jpg";
+    filename = `generated-${Date.now()}.${ext}`;
+  }
+
+  if (base64.startsWith("data:")) base64 = base64.split(",")[1];
+  const binaryString = atob(base64);
+  const len = binaryString.length;
+  const bytes = new Uint8Array(new ArrayBuffer(len));
+  for (let i = 0; i < len; i++) bytes[i] = binaryString.charCodeAt(i);
+
+  const f = new File(Paths.cache, filename);
+  f.create({ overwrite: true });
+  f.write(bytes);
+  return f.uri;
+}
+```
diff --git a/.agents/skills/expo-native-ui/references/storage.md b/.agents/skills/expo-native-ui/references/storage.md
new file mode 100644
index 0000000..c084f12
--- /dev/null
+++ b/.agents/skills/expo-native-ui/references/storage.md
@@ -0,0 +1,121 @@
+# Storage
+
+## Key-Value Storage
+
+Use the localStorage polyfill for key-value storage. **Never use AsyncStorage**
+
+```tsx
+import "expo-sqlite/localStorage/install";
+
+// Simple get/set
+localStorage.setItem("key", "value");
+localStorage.getItem("key");
+
+// Store objects as JSON
+localStorage.setItem("user", JSON.stringify({ name: "John", id: 1 }));
+const user = JSON.parse(localStorage.getItem("user") ?? "{}");
+```
+
+## When to Use What
+
+| Use Case                                             | Solution                |
+| ---------------------------------------------------- | ----------------------- |
+| Simple key-value (settings, preferences, small data) | `localStorage` polyfill |
+| Large datasets, complex queries, relational data     | Full `expo-sqlite`      |
+| Sensitive data (tokens, passwords)                   | `expo-secure-store`     |
+
+## Storage with React State
+
+Create a storage utility with subscriptions for reactive updates:
+
+```tsx
+// utils/storage.ts
+import "expo-sqlite/localStorage/install";
+
+type Listener = () => void;
+const listeners = new Map<string, Set<Listener>>();
+
+export const storage = {
+  get<T>(key: string, defaultValue: T): T {
+    const value = localStorage.getItem(key);
+    return value ? JSON.parse(value) : defaultValue;
+  },
+
+  set<T>(key: string, value: T): void {
+    localStorage.setItem(key, JSON.stringify(value));
+    listeners.get(key)?.forEach((fn) => fn());
+  },
+
+  subscribe(key: string, listener: Listener): () => void {
+    if (!listeners.has(key)) listeners.set(key, new Set());
+    listeners.get(key)!.add(listener);
+    return () => listeners.get(key)?.delete(listener);
+  },
+};
+```
+
+## React Hook for Storage
+
+```tsx
+// hooks/use-storage.ts
+import { useSyncExternalStore } from "react";
+import { storage } from "@/utils/storage";
+
+export function useStorage<T>(
+  key: string,
+  defaultValue: T
+): [T, (value: T) => void] {
+  const value = useSyncExternalStore(
+    (cb) => storage.subscribe(key, cb),
+    () => storage.get(key, defaultValue)
+  );
+
+  return [value, (newValue: T) => storage.set(key, newValue)];
+}
+```
+
+Usage:
+
+```tsx
+function Settings() {
+  const [theme, setTheme] = useStorage("theme", "light");
+
+  return (
+    <Switch
+      value={theme === "dark"}
+      onValueChange={(dark) => setTheme(dark ? "dark" : "light")}
+    />
+  );
+}
+```
+
+## Full SQLite for Complex Data
+
+For larger datasets or complex queries, use expo-sqlite directly:
+
+```tsx
+import * as SQLite from "expo-sqlite";
+
+const db = await SQLite.openDatabaseAsync("app.db");
+
+// Create table
+await db.execAsync(`
+  CREATE TABLE IF NOT EXISTS events (
+    id INTEGER PRIMARY KEY AUTOINCREMENT,
+    title TEXT NOT NULL,
+    date TEXT NOT NULL,
+    location TEXT
+  )
+`);
+
+// Insert
+await db.runAsync("INSERT INTO events (title, date) VALUES (?, ?)", [
+  "Meeting",
+  "2024-01-15",
+]);
+
+// Query
+const events = await db.getAllAsync("SELECT * FROM events WHERE date > ?", [
+  "2024-01-01",
+]);
+```
diff --git a/.agents/skills/expo-native-ui/references/visual-effects.md b/.agents/skills/expo-native-ui/references/visual-effects.md
new file mode 100644
index 0000000..09e9fa4
--- /dev/null
+++ b/.agents/skills/expo-native-ui/references/visual-effects.md
@@ -0,0 +1,197 @@
+# Visual Effects
+
+## Backdrop Blur
+
+Use `expo-blur` for blur effects. Prefer systemMaterial tints as they adapt to dark mode.
+
+```tsx
+import { BlurView } from "expo-blur";
+
+<BlurView tint="systemMaterial" intensity={100} />;
+```
+
+### Tint Options
+
+```tsx
+// System materials (adapt to dark mode)
+<BlurView tint="systemMaterial" />
+<BlurView tint="systemThinMaterial" />
+<BlurView tint="systemUltraThinMaterial" />
+<BlurView tint="systemThickMaterial" />
+<BlurView tint="systemChromeMaterial" />
+
+// Basic tints
+<BlurView tint="light" />
+<BlurView tint="dark" />
+<BlurView tint="default" />
+
+// Prominent (more visible)
+<BlurView tint="prominent" />
+
+// Extra light/dark
+<BlurView tint="extraLight" />
+```
+
+### Intensity
+
+Control blur strength with `intensity` (0-100):
+
+```tsx
+<BlurView tint="systemMaterial" intensity={50} />  // Subtle
+<BlurView tint="systemMaterial" intensity={100} /> // Full
+```
+
+### Rounded Corners
+
+BlurView requires `overflow: 'hidden'` to clip rounded corners:
+
+```tsx
+<BlurView
+  tint="systemMaterial"
+  intensity={100}
+  style={{
+    borderRadius: 16,
+    overflow: 'hidden',
+  }}
+/>
+```
+
+### Overlay Pattern
+
+Common pattern for overlaying blur on content:
+
+```tsx
+<View style={{ position: 'relative' }}>
+  <Image source={{ uri: '...' }} style={{ width: '100%', height: 200 }} />
+  <BlurView
+    tint="systemUltraThinMaterial"
+    intensity={80}
+    style={{
+      position: 'absolute',
+      bottom: 0,
+      left: 0,
+      right: 0,
+      padding: 16,
+    }}
+  >
+    <Text style={{ color: 'white' }}>Caption</Text>
+  </BlurView>
+</View>
+```
+
+## Glass Effects (iOS 26+)
+
+Use `expo-glass-effect` for liquid glass backdrops on iOS 26+.
+
+```tsx
+import { GlassView } from "expo-glass-effect";
+
+<GlassView style={{ borderRadius: 16, padding: 16 }}>
+  <Text>Content inside glass</Text>
+</GlassView>
+```
+
+### Interactive Glass
+
+Add `isInteractive` for buttons and pressable glass:
+
+```tsx
+import { GlassView } from "expo-glass-effect";
+import { SymbolView } from "expo-symbols";
+import { colors } from "@/theme/colors";
+
+<GlassView isInteractive style={{ borderRadius: 50 }}>
+  <Pressable style={{ padding: 12 }} onPress={handlePress}>
+    <SymbolView name="plus" tintColor={colors.label} size={36} />
+  </Pressable>
+</GlassView>
+```
+
+### Glass Buttons
+
+Create liquid glass buttons:
+
+```tsx
+function GlassButton({ icon, onPress }) {
+  return (
+    <GlassView isInteractive style={{ borderRadius: 50 }}>
+      <Pressable style={{ padding: 12 }} onPress={onPress}>
+        <SymbolView name={icon} tintColor={colors.label} size={24} />
+      </Pressable>
+    </GlassView>
+  );
+}
+
+// Usage
+<GlassButton icon="plus" onPress={handleAdd} />
+<GlassButton icon="gear" onPress={handleSettings} />
+```
+
+### Glass Card
+
+```tsx
+<GlassView style={{ borderRadius: 20, padding: 20 }}>
+  <Text style={{ fontSize: 18, fontWeight: '600', color: colors.label }}>
+    Card Title
+  </Text>
+  <Text style={{ color: colors.secondaryLabel, marginTop: 8 }}>
+    Card content goes here
+  </Text>
+</GlassView>
+```
+
+### Checking Availability
+
+```tsx
+import { isLiquidGlassAvailable } from "expo-glass-effect";
+
+if (isLiquidGlassAvailable()) {
+  // Use GlassView
+} else {
+  // Fallback to BlurView or solid background
+}
+```
+
+### Fallback Pattern
+
+```tsx
+import { GlassView, isLiquidGlassAvailable } from "expo-glass-effect";
+import { BlurView } from "expo-blur";
+
+function AdaptiveGlass({ children, style }) {
+  if (isLiquidGlassAvailable()) {
+    return <GlassView style={style}>{children}</GlassView>;
+  }
+
+  return (
+    <BlurView tint="systemMaterial" intensity={80} style={style}>
+      {children}
+    </BlurView>
+  );
+}
+```
+
+## Sheet with Glass Background
+
+Make sheet backgrounds liquid glass on iOS 26+:
+
+```tsx
+<Stack.Screen
+  name="sheet"
+  options={{
+    presentation: "formSheet",
+    sheetGrabberVisible: true,
+    sheetAllowedDetents: [0.5, 1.0],
+    contentStyle: { backgroundColor: "transparent" },
+  }}
+/>
+```
+
+## Best Practices
+
+- Use `systemMaterial` tints for automatic dark mode support
+- Always set `overflow: 'hidden'` on BlurView for rounded corners
+- Use `isInteractive` on GlassView for buttons and pressables
+- Check `isLiquidGlassAvailable()` and provide fallbacks
+- Avoid nesting blur views (performance impact)
+- Keep blur intensity reasonable (50-100) for readability
diff --git a/.agents/skills/expo-native-ui/references/webgpu-three.md b/.agents/skills/expo-native-ui/references/webgpu-three.md
new file mode 100644
index 0000000..58b5ce8
--- /dev/null
+++ b/.agents/skills/expo-native-ui/references/webgpu-three.md
@@ -0,0 +1,605 @@
+# WebGPU & Three.js for Expo
+
+**Use this skill for ANY 3D graphics, games, GPU compute, or Three.js features in React Native.**
+
+## Locked Versions (Tested & Working)
+
+```json
+{
+  "react-native-wgpu": "^0.4.1",
+  "three": "0.172.0",
+  "@react-three/fiber": "^9.4.0",
+  "wgpu-matrix": "^3.0.2",
+  "@types/three": "0.172.0"
+}
+```
+
+**Critical:** These versions are tested together. Mismatched versions cause type errors and runtime issues.
+
+## Installation
+
+```bash
+npm install react-native-wgpu@^0.4.1 three@0.172.0 @react-three/fiber@^9.4.0 wgpu-matrix@^3.0.2 @types/three@0.172.0 --legacy-peer-deps
+```
+
+**Note:** `--legacy-peer-deps` may be required due to peer dependency conflicts with canary Expo versions.
+
+## Metro Configuration
+
+Create `metro.config.js` in project root:
+
+```js
+const { getDefaultConfig } = require("expo/metro-config");
+
+const config = getDefaultConfig(__dirname);
+
+config.resolver.resolveRequest = (context, moduleName, platform) => {
+  // Force 'three' to webgpu build
+  if (moduleName.startsWith("three")) {
+    moduleName = "three/webgpu";
+  }
+
+  // Use standard react-three/fiber instead of React Native version
+  if (platform !== "web" && moduleName.startsWith("@react-three/fiber")) {
+    return context.resolveRequest(
+      {
+        ...context,
+        unstable_conditionNames: ["module"],
+        mainFields: ["module"],
+      },
+      moduleName,
+      platform
+    );
+  }
+  return context.resolveRequest(context, moduleName, platform);
+};
+
+module.exports = config;
+```
+
+## Required Lib Files
+
+Create these files in `src/lib/`:
+
+### 1. make-webgpu-renderer.ts
+
+```ts
+import type { NativeCanvas } from "react-native-wgpu";
+import * as THREE from "three/webgpu";
+
+export class ReactNativeCanvas {
+  constructor(private canvas: NativeCanvas) {}
+
+  get width() {
+    return this.canvas.width;
+  }
+  get height() {
+    return this.canvas.height;
+  }
+  set width(width: number) {
+    this.canvas.width = width;
+  }
+  set height(height: number) {
+    this.canvas.height = height;
+  }
+  get clientWidth() {
+    return this.canvas.width;
+  }
+  get clientHeight() {
+    return this.canvas.height;
+  }
+  set clientWidth(width: number) {
+    this.canvas.width = width;
+  }
+  set clientHeight(height: number) {
+    this.canvas.height = height;
+  }
+
+  addEventListener(_type: string, _listener: EventListener) {}
+  removeEventListener(_type: string, _listener: EventListener) {}
+  dispatchEvent(_event: Event) {}
+  setPointerCapture() {}
+  releasePointerCapture() {}
+}
+
+export const makeWebGPURenderer = (
+  context: GPUCanvasContext,
+  { antialias = true }: { antialias?: boolean } = {}
+) =>
+  new THREE.WebGPURenderer({
+    antialias,
+    // @ts-expect-error
+    canvas: new ReactNativeCanvas(context.canvas),
+    context,
+  });
+```
+
+### 2. fiber-canvas.tsx
+
+```tsx
+import * as THREE from "three/webgpu";
+import React, { useEffect, useRef } from "react";
+import type { ReconcilerRoot, RootState } from "@react-three/fiber";
+import {
+  extend,
+  createRoot,
+  unmountComponentAtNode,
+  events,
+} from "@react-three/fiber";
+import type { ViewProps } from "react-native";
+import { PixelRatio } from "react-native";
+import { Canvas, type CanvasRef } from "react-native-wgpu";
+
+import {
+  makeWebGPURenderer,
+  ReactNativeCanvas,
+} from "@/lib/make-webgpu-renderer";
+
+// Extend THREE namespace for R3F - add all components you use
+extend({
+  AmbientLight: THREE.AmbientLight,
+  DirectionalLight: THREE.DirectionalLight,
+  PointLight: THREE.PointLight,
+  SpotLight: THREE.SpotLight,
+  Mesh: THREE.Mesh,
+  Group: THREE.Group,
+  Points: THREE.Points,
+  BoxGeometry: THREE.BoxGeometry,
+  SphereGeometry: THREE.SphereGeometry,
+  CylinderGeometry: THREE.CylinderGeometry,
+  ConeGeometry: THREE.ConeGeometry,
+  DodecahedronGeometry: THREE.DodecahedronGeometry,
+  BufferGeometry: THREE.BufferGeometry,
+  BufferAttribute: THREE.BufferAttribute,
+  MeshStandardMaterial: THREE.MeshStandardMaterial,
+  MeshBasicMaterial: THREE.MeshBasicMaterial,
+  PointsMaterial: THREE.PointsMaterial,
+  PerspectiveCamera: THREE.PerspectiveCamera,
+  Scene: THREE.Scene,
+});
+
+interface FiberCanvasProps {
+  children: React.ReactNode;
+  style?: ViewProps["style"];
+  camera?: THREE.PerspectiveCamera;
+  scene?: THREE.Scene;
+}
+
+export const FiberCanvas = ({
+  children,
+  style,
+  scene,
+  camera,
+}: FiberCanvasProps) => {
+  const root = useRef<ReconcilerRoot<OffscreenCanvas>>(null!);
+  const canvasRef = useRef<CanvasRef>(null);
+
+  useEffect(() => {
+    const context = canvasRef.current!.getContext("webgpu")!;
+    const renderer = makeWebGPURenderer(context);
+
+    // @ts-expect-error - ReactNativeCanvas wraps native canvas
+    const canvas = new ReactNativeCanvas(context.canvas) as HTMLCanvasElement;
+    canvas.width = canvas.clientWidth * PixelRatio.get();
+    canvas.height = canvas.clientHeight * PixelRatio.get();
+    const size = {
+      top: 0,
+      left: 0,
+      width: canvas.clientWidth,
+      height: canvas.clientHeight,
+    };
+
+    if (!root.current) {
+      root.current = createRoot(canvas);
+    }
+    root.current.configure({
+      size,
+      events,
+      scene,
+      camera,
+      gl: renderer,
+      frameloop: "always",
+      dpr: 1,
+      onCreated: async (state: RootState) => {
+        // @ts-expect-error - WebGPU renderer has init method
+        await state.gl.init();
+        const renderFrame = state.gl.render.bind(state.gl);
+        state.gl.render = (s: THREE.Scene, c: THREE.Camera) => {
+          renderFrame(s, c);
+          context?.present();
+        };
+      },
+    });
+    root.current.render(children);
+    return () => {
+      if (canvas != null) {
+        unmountComponentAtNode(canvas!);
+      }
+    };
+  });
+
+  return <Canvas ref={canvasRef} style={style} />;
+};
+```
+
+## Basic 3D Scene
+
+```tsx
+import * as THREE from "three/webgpu";
+import { View } from "react-native";
+import { useRef } from "react";
+import { useFrame, useThree } from "@react-three/fiber";
+import { FiberCanvas } from "@/lib/fiber-canvas";
+
+function RotatingBox() {
+  const ref = useRef<THREE.Mesh>(null!);
+
+  useFrame((_, delta) => {
+    ref.current.rotation.x += delta;
+    ref.current.rotation.y += delta * 0.5;
+  });
+
+  return (
+    <mesh ref={ref}>
+      <boxGeometry args={[1, 1, 1]} />
+      <meshStandardMaterial color="hotpink" />
+    </mesh>
+  );
+}
+
+function Scene() {
+  const { camera } = useThree();
+
+  useEffect(() => {
+    camera.position.set(0, 2, 5);
+    camera.lookAt(0, 0, 0);
+  }, [camera]);
+
+  return (
+    <>
+      <ambientLight intensity={0.5} />
+      <directionalLight position={[10, 10, 5]} intensity={1} />
+      <RotatingBox />
+    </>
+  );
+}
+
+export default function App() {
+  return (
+    <View style={{ flex: 1 }}>
+      <FiberCanvas style={{ flex: 1 }}>
+        <Scene />
+      </FiberCanvas>
+    </View>
+  );
+}
+```
+
+## Lazy Loading (Recommended)
+
+Use React.lazy to code-split Three.js for better loading:
+
+```tsx
+import React, { Suspense } from "react";
+import { ActivityIndicator, View } from "react-native";
+
+const Scene = React.lazy(() => import("@/components/scene"));
+
+export default function Page() {
+  return (
+    <View style={{ flex: 1 }}>
+      <Suspense fallback={<ActivityIndicator size="large" />}>
+        <Scene />
+      </Suspense>
+    </View>
+  );
+}
+```
+
+## Common Geometries
+
+```tsx
+// Box
+<mesh>
+  <boxGeometry args={[width, height, depth]} />
+  <meshStandardMaterial color="red" />
+</mesh>
+
+// Sphere
+<mesh>
+  <sphereGeometry args={[radius, widthSegments, heightSegments]} />
+  <meshStandardMaterial color="blue" />
+</mesh>
+
+// Cylinder
+<mesh>
+  <cylinderGeometry args={[radiusTop, radiusBottom, height, segments]} />
+  <meshStandardMaterial color="green" />
+</mesh>
+
+// Cone
+<mesh>
+  <coneGeometry args={[radius, height, segments]} />
+  <meshStandardMaterial color="yellow" />
+</mesh>
+```
+
+## Lighting
+
+```tsx
+// Ambient (uniform light everywhere)
+<ambientLight intensity={0.5} />
+
+// Directional (sun-like)
+<directionalLight position={[10, 10, 5]} intensity={1} />
+
+// Point (light bulb)
+<pointLight position={[0, 5, 0]} intensity={2} distance={10} />
+
+// Spot (flashlight)
+<spotLight position={[0, 10, 0]} angle={0.3} penumbra={1} intensity={2} />
+```
+
+## Animation with useFrame
+
+```tsx
+import { useFrame } from "@react-three/fiber";
+import { useRef } from "react";
+import * as THREE from "three/webgpu";
+
+function AnimatedMesh() {
+  const ref = useRef<THREE.Mesh>(null!);
+
+  // Runs every frame - delta is time since last frame
+  useFrame((state, delta) => {
+    // Rotate
+    ref.current.rotation.y += delta;
+
+    // Oscillate position
+    ref.current.position.y = Math.sin(state.clock.elapsedTime) * 2;
+  });
+
+  return (
+    <mesh ref={ref}>
+      <boxGeometry />
+      <meshStandardMaterial color="orange" />
+    </mesh>
+  );
+}
+```
+
+## Particle Systems
+
+```tsx
+import * as THREE from "three/webgpu";
+import { useRef, useEffect } from "react";
+import { useFrame } from "@react-three/fiber";
+
+function Particles({ count = 500 }) {
+  const ref = useRef<THREE.Points>(null!);
+  const positions = useRef<Float32Array>(new Float32Array(count * 3));
+
+  useEffect(() => {
+    for (let i = 0; i < count; i++) {
+      positions.current[i * 3] = (Math.random() - 0.5) * 50;
+      positions.current[i * 3 + 1] = (Math.random() - 0.5) * 50;
+      positions.current[i * 3 + 2] = (Math.random() - 0.5) * 50;
+    }
+  }, [count]);
+
+  useFrame((_, delta) => {
+    // Animate particles
+    for (let i = 0; i < count; i++) {
+      positions.current[i * 3 + 1] -= delta * 2;
+      if (positions.current[i * 3 + 1] < -25) {
+        positions.current[i * 3 + 1] = 25;
+      }
+    }
+    ref.current.geometry.attributes.position.needsUpdate = true;
+  });
+
+  return (
+    <points ref={ref}>
+      <bufferGeometry>
+        <bufferAttribute
+          attach="attributes-position"
+          args={[positions.current, 3]}
+        />
+      </bufferGeometry>
+      <pointsMaterial color="#ffffff" size={0.2} sizeAttenuation />
+    </points>
+  );
+}
+```
+
+## Touch Controls (Orbit)
+
+See the full `orbit-controls.tsx` implementation in the lib files. Usage:
+
+```tsx
+import { View } from "react-native";
+import { FiberCanvas } from "@/lib/fiber-canvas";
+import useControls from "@/lib/orbit-controls";
+
+function Scene() {
+  const [OrbitControls, events] = useControls();
+
+  return (
+    <View style={{ flex: 1 }} {...events}>
+      <FiberCanvas style={{ flex: 1 }}>
+        <OrbitControls />
+        {/* Your 3D content */}
+      </FiberCanvas>
+    </View>
+  );
+}
+```
+
+## Common Issues & Solutions
+
+### 1. "X is not part of the THREE namespace"
+
+**Problem:** Error like `AmbientLight is not part of the THREE namespace`
+
+**Solution:** Add the missing component to the `extend()` call in fiber-canvas.tsx:
+
+```tsx
+extend({
+  AmbientLight: THREE.AmbientLight,
+  // Add other missing components...
+});
+```
+
+### 2. TypeScript Errors with Three.js
+
+**Problem:** Type mismatches between three.js and R3F
+
+**Solution:** Use `@ts-expect-error` comments where needed:
+
+```tsx
+// @ts-expect-error - WebGPU renderer types don't match
+await state.gl.init();
+```
+
+### 3. Blank Screen
+
+**Problem:** Canvas renders but nothing visible
+
+**Solution:**
+
+1. Ensure camera is positioned correctly and looking at scene
+2. Add lighting (objects are black without light)
+3. Check that `extend()` includes all components used
+
+### 4. Performance Issues
+
+**Problem:** Low frame rate or stuttering
+
+**Solution:**
+
+- Reduce polygon count in geometries
+- Use `useMemo` for static data
+- Limit particle count
+- Use `instancedMesh` for many identical objects
+
+### 5. Peer Dependency Errors
+
+**Problem:** npm install fails with ERESOLVE
+
+**Solution:** Use `--legacy-peer-deps`:
+
+```bash
+npm install <packages> --legacy-peer-deps
+```
+
+## Building
+
+WebGPU requires a custom build:
+
+```bash
+npx expo prebuild
+npx expo run:ios
+```
+
+**Note:** WebGPU does NOT work in Expo Go.
+
+## File Structure
+
+```
+src/
+├── app/
+│   └── index.tsx           # Entry point with lazy loading
+├── components/
+│   ├── scene.tsx           # Main 3D scene
+│   └── game.tsx            # Game logic
+└── lib/
+    ├── fiber-canvas.tsx    # R3F canvas wrapper
+    ├── make-webgpu-renderer.ts  # WebGPU renderer
+    └── orbit-controls.tsx  # Touch controls
+```
+
+## Decision Tree
+
+```
+Need 3D graphics?
+├── Simple shapes → mesh + geometry + material
+├── Animated objects → useFrame + refs
+├── Many objects → instancedMesh
+├── Particles → Points + BufferGeometry
+│
+Need interaction?
+├── Orbit camera → useControls hook
+├── Touch objects → onClick on mesh
+├── Gestures → react-native-gesture-handler
+│
+Performance critical?
+├── Static geometry → useMemo
+├── Many instances → InstancedMesh
+└── Complex scenes → LOD (Level of Detail)
+```
+
+## Example: Complete Game Scene
+
+```tsx
+import * as THREE from "three/webgpu";
+import { View, Text, Pressable } from "react-native";
+import { useRef, useState, useCallback } from "react";
+import { useFrame, useThree } from "@react-three/fiber";
+import { FiberCanvas } from "@/lib/fiber-canvas";
+
+function Player({ position }: { position: THREE.Vector3 }) {
+  const ref = useRef<THREE.Mesh>(null!);
+
+  useFrame(() => {
+    ref.current.position.copy(position);
+  });
+
+  return (
+    <mesh ref={ref}>
+      <coneGeometry args={[0.5, 1, 8]} />
+      <meshStandardMaterial color="#00ffff" />
+    </mesh>
+  );
+}
+
+function GameScene({ playerX }: { playerX: number }) {
+  const { camera } = useThree();
+  const playerPos = useRef(new THREE.Vector3(0, 0, 0));
+
+  playerPos.current.x = playerX;
+
+  useEffect(() => {
+    camera.position.set(0, 10, 15);
+    camera.lookAt(0, 0, 0);
+  }, [camera]);
+
+  return (
+    <>
+      <ambientLight intensity={0.5} />
+      <directionalLight position={[5, 10, 5]} />
+      <Player position={playerPos.current} />
+    </>
+  );
+}
+
+export default function Game() {
+  const [playerX, setPlayerX] = useState(0);
+
+  return (
+    <View style={{ flex: 1, backgroundColor: "#000" }}>
+      <FiberCanvas style={{ flex: 1 }}>
+        <GameScene playerX={playerX} />
+      </FiberCanvas>
+
+      <View style={{ position: "absolute", bottom: 40, flexDirection: "row" }}>
+        <Pressable onPress={() => setPlayerX((x) => x - 1)}>
+          <Text style={{ color: "#fff", fontSize: 32 }}>◀</Text>
+        </Pressable>
+        <Pressable onPress={() => setPlayerX((x) => x + 1)}>
+          <Text style={{ color: "#fff", fontSize: 32 }}>▶</Text>
+        </Pressable>
+      </View>
+    </View>
+  );
+}
+```
diff --git a/.agents/skills/expo-project-structure/SKILL.md b/.agents/skills/expo-project-structure/SKILL.md
new file mode 100644
index 0000000..f5a4499
--- /dev/null
+++ b/.agents/skills/expo-project-structure/SKILL.md
@@ -0,0 +1,114 @@
+---
+name: expo-project-structure
+description: Framework (OSS). Folder structure for a new Expo app. Use when scaffolding or laying out a new Expo project with Expo Router, or deciding where a file should live in one. For new projects only — never restructure an existing app to match.
+version: 1.0.0
+license: MIT
+---
+
+# Expo Project Structure
+
+A starting skeleton for a **new** Expo app — one with no committed folder structure yet.
+
+**Apply only to new projects.** If the app already has a layout, follow its existing conventions and leave files where they are — a default to start from, never a standard to enforce or migrate toward. When unsure whether a project is new, ask before moving anything.
+
+The whole layout, assembled from the rules below:
+
+```
+├── assets/
+├── scripts/
+├── src/
+│   ├── app/                       # Expo Router routes ONLY — every file is a route
+│   │   ├── api/                   #   server API routes, grouped here
+│   │   │   ├── user+api.ts
+│   │   │   └── settings+api.ts
+│   │   ├── _layout.tsx
+│   │   ├── _layout.web.tsx         #   platform-specific layout
+│   │   ├── index.tsx
+│   │   └── settings.tsx
+│   ├── components/                 # reusable UI: button, card, table…
+│   │   ├── table/                  #   complex component → folder + index.tsx
+│   │   │   ├── cell.tsx
+│   │   │   └── index.tsx
+│   │   ├── bar-chart.tsx
+│   │   ├── bar-chart.web.tsx        #   platform-specific variant
+│   │   └── button.tsx
+│   ├── screens/                    # screen bodies that route files render
+│   │   ├── home/
+│   │   │   ├── card.tsx            #   used only by Home — not shared
+│   │   │   └── index.tsx           #   rendered by src/app/index.tsx
+│   │   └── settings.tsx
+│   ├── server/                     # server-only helpers used by app/api
+│   │   ├── auth.ts
+│   │   └── db.ts
+│   ├── utils/                      # standalone helpers + colocated tests
+│   │   ├── format-date.ts
+│   │   └── format-date.test.ts
+│   ├── hooks/                      # reusable hooks: use-theme.ts…
+│   ├── constants.ts
+│   └── theme.ts
+├── app.json
+├── eas.json
+└── package.json
+```
+
+## `src/` and `src/app`
+
+Keep app code under `src/` to separate it from config files. Expo Router supports both `app/` and `src/app/` out of the box — to switch, move the folder and restart the bundler. The default template aliases `@/*` to `./src/*` in `tsconfig.json`.
+
+`src/app` is **routes-only**: every file there becomes a route, so nothing else belongs in it. Everything below lives in sibling folders.
+
+## components/ — reusable UI
+
+Generic, reused UI (button, card, table) with one named export each. Name files in **kebab-case** (`bar-chart.tsx`), matching the default `create-expo-app` template. When a component grows, give it its own folder with the root in `index.tsx` and **colocate** its private sub-components beside it — the import path (`@/components/table`) stays unchanged.
+
+## screens/ — screen bodies
+
+Because `app/` files must be routes, complex screen UI that isn't reused has no home there. Once a screen grows big enough to need breaking out to separate components, put it in `screens/` and let each route just render its screen:
+
+```tsx
+import { Home } from "@/screens/home";
+
+export default function HomeScreen() {
+  // route-specific concerns only — e.g. read url params here
+  return <Home />;
+}
+```
+
+**Colocate** a screen's private components inside its folder (`screens/home/components/`). A bonus: the same screen can render under multiple routes.
+
+## server/ + app/api/ — separate server code
+
+Appending `+api` to a file in `app/` makes it a server **API route**. Server code is different from frontend code — it runs in a Node-like server environment (deployed with EAS Hosting or on [third-party services](https://docs.expo.dev/router/web/api-routes/#hosting-on-third-party-services)) and can read secret env vars (`process.env.X`, not just `EXPO_PUBLIC_*`). Keep it apart:
+
+- Group all routes under `app/api/` → `/api/user`, `/api/settings`. This colocates them and avoids collisions (e.g. a `/user` screen and a `/user` route).
+- Put shared server-only helpers in `src/server/`.
+- Consider ESLint rules that fence `+api` files and `server/` off from frontend-only checks.
+
+## Platform-specific code
+
+Small differences: use `Platform.select` / `Platform.OS`. For larger ones, split into platform files instead of inline `if/else` — `bar-chart.tsx` + `bar-chart.web.tsx`, imported extension-free (`@/components/bar-chart`); Metro picks the right file per target.
+
+- Props must be identical across variants.
+- A default file (no platform extension) is always required — make it a no-op if the component is single-platform.
+- Supported extensions: `.ios`, `.android`, `.native`, `.web`.
+
+## Colocate styles and tests
+
+- **Styles:** keep the `StyleSheet.create({ ... })` object at the bottom of the component file rather than in a separate `.styles` file.
+- **Tests:** put `format-date.test.ts` next to `format-date.ts` (preferred over a separate `__tests__/` folder) so tested files are obvious at a glance.
+
+## AI and config files
+
+Agent instructions live at the repo root — `AGENTS.md` / `CLAUDE.md`, with project skills under `.claude/`. Other config and assets stay outside `src/`: `app.json` / `app.config.ts`, `eas.json`, `package.json`, `assets/`, and `scripts/`.
+
+---
+
+Based on [Expo app folder structure best practices](https://expo.dev/blog/expo-app-folder-structure-best-practices) by Kadi Kraman. For `src/` precedence and alias mechanics, see the [Expo docs](https://docs.expo.dev/router/reference/src-directory/).
+
+## 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-project-structure" "<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.
diff --git a/.agents/skills/expo-project-structure/agents/openai.yaml b/.agents/skills/expo-project-structure/agents/openai.yaml
new file mode 100644
index 0000000..a4b9ce5
--- /dev/null
+++ b/.agents/skills/expo-project-structure/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Expo Project Structure"
+  short_description: "Recommended folder structure for new Expo apps"
+  default_prompt: "Use $expo-project-structure to lay out a new Expo app: the src/ layout, routes-only app/ directory, screens, components, server code separation, and platform-specific files."
diff --git a/.agents/skills/expo-router/SKILL.md b/.agents/skills/expo-router/SKILL.md
new file mode 100644
index 0000000..b7b703d
--- /dev/null
+++ b/.agents/skills/expo-router/SKILL.md
@@ -0,0 +1,238 @@
+---
+name: expo-router
+description: Framework (OSS). Navigation and routing for Expo Router. Covers file-based routes, groups and dynamic routes, folder organization, Link with previews and context menus, native Stack, page titles, modals and form sheets, NativeTabs, headers and toolbars, and header search bars.
+version: 1.0.1
+license: MIT
+---
+
+# Expo Router Navigation
+
+Navigation and routing for Expo Router apps. For screen styling, colors, controls, animations, media, and visual effects, use the `expo-native-ui` skill.
+
+## References
+
+Consult these resources as needed:
+
+```
+references/
+  route-structure.md     Route conventions, dynamic routes, groups, folder organization
+  tabs.md                NativeTabs, migration from JS tabs, iOS 26 features
+  toolbar-and-headers.md Stack headers and toolbar buttons, menus, search (iOS only)
+  form-sheet.md          Form sheets in expo-router: configuration, footers and background interaction.
+  search.md              Search bar with headers, useSearch hook, filtering patterns
+  zoom-transitions.md    Apple Zoom: fluid zoom transitions with Link.AppleZoom (iOS 18+)
+```
+
+## Code Style
+
+- Always use kebab-case for file names, e.g. `comment-card.tsx`
+- Always remove old route files when moving or restructuring navigation
+- Never use special characters in file names
+- Configure tsconfig.json with path aliases, and prefer aliases over relative imports for refactors.
+
+## Routes
+
+See `./references/route-structure.md` for detailed route conventions.
+
+- Routes belong in the `app` directory.
+- Never co-locate components, types, or utilities in the app directory. This is an anti-pattern.
+- Ensure the app always has a route that matches "/", it may be inside a group route.
+
+## Library Preferences
+
+- `Color` from `expo-router` for native semantic colors, not raw `PlatformColor` (type-safe, auto-adapts to light/dark). See `expo-native-ui` for the full color palette pattern.
+- In SDK 56+, never import from `@react-navigation/*` directly — use `expo-router/react-navigation` instead (covers `@react-navigation/native`, `/core`, `/elements`, `/routers`)
+
+## Behavior
+
+- Prefer `Stack.SearchBar` to add a search bar to a screen
+
+# Navigation
+
+## Link
+
+Use `<Link href="/path" />` from 'expo-router' for navigation between routes.
+
+```tsx
+import { Link } from 'expo-router';
+
+// Basic link
+<Link href="/path" />
+
+// Wrapping custom components
+<Link href="/path" asChild>
+  <Pressable>...</Pressable>
+</Link>
+```
+
+Whenever possible, include a `<Link.Preview>` to follow iOS conventions. Add context menus and previews frequently to enhance navigation.
+
+## Stack
+
+- ALWAYS use `_layout.tsx` files to define stacks
+- Use Stack from 'expo-router/stack' for native navigation stacks
+
+### Page Title
+
+Set the page title with `Stack.Title`:
+
+```tsx
+<Stack.Title>Home</Stack.Title>
+```
+
+## Context Menus
+
+Add long press context menus to Link components:
+
+```tsx
+import { Link } from "expo-router";
+
+<Link href="/settings" asChild>
+  <Link.Trigger>
+    <Pressable>
+      <Card />
+    </Pressable>
+  </Link.Trigger>
+  <Link.Menu>
+    <Link.MenuAction
+      title="Share"
+      icon="square.and.arrow.up"
+      onPress={handleSharePress}
+    />
+    <Link.MenuAction
+      title="Block"
+      icon="nosign"
+      destructive
+      onPress={handleBlockPress}
+    />
+    <Link.Menu title="More" icon="ellipsis">
+      <Link.MenuAction title="Copy" icon="doc.on.doc" onPress={() => {}} />
+      <Link.MenuAction
+        title="Delete"
+        icon="trash"
+        destructive
+        onPress={() => {}}
+      />
+    </Link.Menu>
+  </Link.Menu>
+</Link>;
+```
+
+## Link Previews
+
+Use link previews frequently to enhance navigation:
+
+```tsx
+<Link href="/settings">
+  <Link.Trigger>
+    <Pressable>
+      <Card />
+    </Pressable>
+  </Link.Trigger>
+  <Link.Preview />
+</Link>
+```
+
+Link preview can be used with context menus.
+
+## Modal
+
+Present a screen as a modal:
+
+```tsx
+<Stack.Screen name="modal" options={{ presentation: "modal" }} />
+```
+
+Prefer this to building a custom modal component.
+
+## Sheet
+
+Present a screen as a dynamic form sheet:
+
+```tsx
+<Stack.Screen
+  name="sheet"
+  options={{
+    presentation: "formSheet",
+    sheetGrabberVisible: true,
+    sheetAllowedDetents: [0.5, 1.0],
+    contentStyle: { backgroundColor: "transparent" },
+  }}
+/>
+```
+
+- Using `contentStyle: { backgroundColor: "transparent" }` makes the background liquid glass on iOS 26+.
+
+## Common route structure
+
+A standard app layout with tabs and stacks inside each tab:
+
+```
+app/
+  _layout.tsx — <NativeTabs />
+  (index,search)/
+    _layout.tsx — <Stack />
+    index.tsx — Main list
+    search.tsx — Search view
+```
+
+```tsx
+// app/_layout.tsx
+import { NativeTabs } from "expo-router/unstable-native-tabs";
+import { ThemeProvider, DarkTheme, DefaultTheme } from "expo-router/react-navigation";
+import { useColorScheme } from "react-native";
+
+export default function Layout() {
+  const colorScheme = useColorScheme();
+  return (
+    <ThemeProvider value={colorScheme === "dark" ? DarkTheme : DefaultTheme}>
+      <NativeTabs>
+        <NativeTabs.Trigger name="(index)">
+          <NativeTabs.Trigger.Icon sf="list.dash" md="list" />
+          <NativeTabs.Trigger.Label>Items</NativeTabs.Trigger.Label>
+        </NativeTabs.Trigger>
+        <NativeTabs.Trigger name="(search)" role="search" />
+      </NativeTabs>
+    </ThemeProvider>
+  );
+}
+```
+
+Create a shared group route so both tabs can push common screens:
+
+```tsx
+// app/(index,search)/_layout.tsx
+import { Stack } from "expo-router/stack";
+import { colors } from "@/theme/colors";
+
+export default function Layout({ segment }) {
+  const screen = segment.match(/\((.*)\)/)?.[1]!;
+  const titles: Record<string, string> = { index: "Items", search: "Search" };
+
+  return (
+    <Stack
+      screenOptions={{
+        headerTransparent: true,
+        headerShadowVisible: false,
+        headerLargeTitleShadowVisible: false,
+        headerLargeStyle: { backgroundColor: "transparent" },
+        headerTitleStyle: { color: colors.label },
+        headerLargeTitle: true,
+        headerBlurEffect: "none",
+        headerBackButtonDisplayMode: "minimal",
+      }}
+    >
+      <Stack.Screen name={screen} options={{ title: titles[screen] }} />
+      <Stack.Screen name="i/[id]" options={{ headerLargeTitle: false }} />
+    </Stack>
+  );
+}
+```
+
+## 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-router" "<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.
diff --git a/.agents/skills/expo-router/agents/openai.yaml b/.agents/skills/expo-router/agents/openai.yaml
new file mode 100644
index 0000000..a314bc8
--- /dev/null
+++ b/.agents/skills/expo-router/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Expo Router"
+  short_description: "Navigate and structure Expo Router apps: file-based routes, links, native stacks, modals, sheets, native tabs, headers, and search"
+  default_prompt: "Use $expo-router to structure file-based routes, wire up navigation with Link previews and context menus, configure native Stack screens, modals, form sheets, NativeTabs, headers, toolbars, and search bars."
diff --git a/.agents/skills/expo-router/references/form-sheet.md b/.agents/skills/expo-router/references/form-sheet.md
new file mode 100644
index 0000000..1ed80fb
--- /dev/null
+++ b/.agents/skills/expo-router/references/form-sheet.md
@@ -0,0 +1,253 @@
+# Form Sheets in Expo Router
+
+This skill covers implementing form sheets with footers using Expo Router's Stack navigator and react-native-screens.
+
+## Overview
+
+Form sheets are modal presentations that appear as a card sliding up from the bottom of the screen. They're ideal for:
+
+- Quick actions and confirmations
+- Settings panels
+- Login/signup flows
+- Action sheets with custom content
+
+**Requirements:**
+
+- Expo Router Stack navigator
+
+## Basic Usage
+
+### Form Sheet with Footer
+
+Configure the Stack.Screen with transparent backgrounds and sheet presentation:
+
+```tsx
+// app/_layout.tsx
+import { Stack } from "expo-router";
+
+export default function Layout() {
+  return (
+    <Stack>
+      <Stack.Screen name="index" />
+      <Stack.Screen
+        name="about"
+        options={{
+          presentation: "formSheet",
+          sheetAllowedDetents: [0.25],
+          headerTransparent: true,
+          contentStyle: { backgroundColor: "transparent" },
+          sheetGrabberVisible: true,
+        }}
+      >
+        <Stack.Header style={{ backgroundColor: "transparent" }}></Stack.Header>
+      </Stack.Screen>
+    </Stack>
+  );
+}
+```
+
+### Form Sheet Screen Content
+
+> Requires Expo SDK 55 or later.
+
+Use `flex: 1` to allow the content to fill available space, enabling footer positioning:
+
+```tsx
+// app/about.tsx
+import { View, Text, StyleSheet } from "react-native";
+
+export default function AboutSheet() {
+  return (
+    <View style={styles.container}>
+      {/* Main content */}
+      <View style={styles.content}>
+        <Text>Sheet Content</Text>
+      </View>
+
+      {/* Footer - stays at bottom */}
+      <View style={styles.footer}>
+        <Text>Footer Content</Text>
+      </View>
+    </View>
+  );
+}
+
+const styles = StyleSheet.create({
+  container: {
+    flex: 1,
+  },
+  content: {
+    flex: 1,
+    padding: 16,
+  },
+  footer: {
+    padding: 16,
+  },
+});
+```
+
+### Formsheet with interactive content below
+
+Use `sheetLargestUndimmedDetentIndex` (zero-indexed) to keep content behind the form sheet interactive — e.g. letting users pan a map beneath it. Setting it to `1` allows interaction at the first two detents but dims on the third.
+
+```tsx
+// app/_layout.tsx
+import { Stack } from 'expo-router';
+
+export default function Layout() {
+  return (
+    <Stack screenOptions={{ headerShown: false }}>
+      <Stack.Screen name="index" />
+      <Stack.Screen
+        name="info-sheet"
+        options={{
+          presentation: "formSheet",
+          sheetAllowedDetents: [0.2, 0.5, 1.0],
+          sheetLargestUndimmedDetentIndex: 1,
+          /* other options */
+        }}
+      />
+    </Stack>
+  )
+}
+```
+
+## Key Options
+
+| Option                | Type       | Description                                                 |
+| --------------------- | ---------- | ----------------------------------------------------------- |
+| `presentation`        | `string`   | Set to `'formSheet'` for sheet presentation                 |
+| `sheetGrabberVisible` | `boolean`  | Shows the drag handle at the top of the sheet               |
+| `sheetAllowedDetents` | `number[]` | Array of detent heights (0-1 range, e.g., `[0.25]` for 25%) |
+| `headerTransparent`   | `boolean`  | Makes header background transparent                         |
+| `contentStyle`        | `object`   | Style object for the screen content container               |
+| `title`               | `string`   | Screen title (set to `''` for no title)                     |
+
+## Common Detent Values
+
+- `[0.25]` - Quarter sheet (compact actions)
+- `[0.5]` - Half sheet (medium content)
+- `[0.75]` - Three-quarter sheet (detailed forms)
+- `[0.25, 0.5, 1]` - Multiple stops (expandable sheet)
+
+## Complete Example
+
+```tsx
+// _layout.tsx
+import { Stack } from "expo-router";
+
+export default function Layout() {
+  return (
+    <Stack>
+      <Stack.Screen name="index" options={{ title: "Home" }} />
+      <Stack.Screen
+        name="confirm"
+        options={{
+          contentStyle: { backgroundColor: "transparent" },
+          presentation: "formSheet",
+          title: "",
+          sheetGrabberVisible: true,
+          sheetAllowedDetents: [0.25],
+          headerTransparent: true,
+        }}
+      >
+        <Stack.Header style={{ backgroundColor: "transparent" }}>
+          <Stack.Header.Right />
+        </Stack.Header>
+      </Stack.Screen>
+    </Stack>
+  );
+}
+```
+
+```tsx
+// app/confirm.tsx
+import { View, Text, Pressable, StyleSheet } from "react-native";
+import { router } from "expo-router";
+
+export default function ConfirmSheet() {
+  return (
+    <View style={styles.container}>
+      <View style={styles.content}>
+        <Text style={styles.title}>Confirm Action</Text>
+        <Text style={styles.description}>
+          Are you sure you want to proceed?
+        </Text>
+      </View>
+
+      <View style={styles.footer}>
+        <Pressable style={styles.cancelButton} onPress={() => router.back()}>
+          <Text style={styles.cancelText}>Cancel</Text>
+        </Pressable>
+        <Pressable style={styles.confirmButton} onPress={() => router.back()}>
+          <Text style={styles.confirmText}>Confirm</Text>
+        </Pressable>
+      </View>
+    </View>
+  );
+}
+
+const styles = StyleSheet.create({
+  container: {
+    flex: 1,
+  },
+  content: {
+    flex: 1,
+    padding: 20,
+    alignItems: "center",
+    justifyContent: "center",
+  },
+  title: {
+    fontSize: 18,
+    fontWeight: "600",
+    marginBottom: 8,
+  },
+  description: {
+    fontSize: 14,
+    color: "#666",
+    textAlign: "center",
+  },
+  footer: {
+    flexDirection: "row",
+    padding: 16,
+    gap: 12,
+  },
+  cancelButton: {
+    flex: 1,
+    padding: 14,
+    borderRadius: 10,
+    backgroundColor: "#f0f0f0",
+    alignItems: "center",
+  },
+  cancelText: {
+    fontSize: 16,
+    fontWeight: "500",
+  },
+  confirmButton: {
+    flex: 1,
+    padding: 14,
+    borderRadius: 10,
+    backgroundColor: "#007AFF",
+    alignItems: "center",
+  },
+  confirmText: {
+    fontSize: 16,
+    fontWeight: "500",
+    color: "white",
+  },
+});
+```
+
+## Troubleshooting
+
+### Content not filling sheet
+
+Make sure the root View uses `flex: 1`:
+
+```tsx
+<View style={{ flex: 1 }}>{/* content */}</View>
+```
+
+### Sheet background showing through
+
+Set `contentStyle: { backgroundColor: 'transparent' }` in options and style your content container with the desired background color instead.
diff --git a/.agents/skills/expo-router/references/route-structure.md b/.agents/skills/expo-router/references/route-structure.md
new file mode 100644
index 0000000..b552729
--- /dev/null
+++ b/.agents/skills/expo-router/references/route-structure.md
@@ -0,0 +1,229 @@
+# Route Structure
+
+## File Conventions
+
+- Routes belong in the `app` directory
+- Use `[]` for dynamic routes, e.g. `[id].tsx`
+- Routes can never be named `(foo).tsx` - use `(foo)/index.tsx` instead
+- Use `(group)` routes to simplify the public URL structure
+- NEVER co-locate components, types, or utilities in the app directory - these should be in separate directories like `components/`, `utils/`, etc.
+- The app directory should only contain route and `_layout` files; every file should export a default component
+- Ensure the app always has a route that matches "/" so the app is never blank
+- ALWAYS use `_layout.tsx` files to define stacks
+
+## Dynamic Routes
+
+Use square brackets for dynamic segments:
+
+```
+app/
+  users/
+    [id].tsx        # Matches /users/123, /users/abc
+    [id]/
+      posts.tsx     # Matches /users/123/posts
+```
+
+### Catch-All Routes
+
+Use `[...slug]` for catch-all routes:
+
+```
+app/
+  docs/
+    [...slug].tsx   # Matches /docs/a, /docs/a/b, /docs/a/b/c
+```
+
+## Query Parameters
+
+Access query parameters with the `useLocalSearchParams` hook:
+
+```tsx
+import { useLocalSearchParams } from "expo-router";
+
+function Page() {
+  const { id } = useLocalSearchParams<{ id: string }>();
+}
+```
+
+For dynamic routes, the parameter name matches the file name:
+
+- `[id].tsx` → `useLocalSearchParams<{ id: string }>()`
+- `[slug].tsx` → `useLocalSearchParams<{ slug: string }>()`
+
+## Pathname
+
+Access the current pathname with the `usePathname` hook:
+
+```tsx
+import { usePathname } from "expo-router";
+
+function Component() {
+  const pathname = usePathname(); // e.g. "/users/123"
+}
+```
+
+## Group Routes
+
+Use parentheses for groups that don't affect the URL:
+
+```
+app/
+  (auth)/
+    login.tsx       # URL: /login
+    register.tsx    # URL: /register
+  (main)/
+    index.tsx       # URL: /
+    settings.tsx    # URL: /settings
+```
+
+Groups are useful for:
+
+- Organizing related routes
+- Applying different layouts to route groups
+- Keeping URLs clean
+
+## Stacks and Tabs Structure
+
+When an app has tabs, the header and title should be set in a Stack that is nested INSIDE each tab. This allows tabs to have their own headers and distinct histories. The root layout should often not have a header.
+
+- Set the 'headerShown' option to false on the tab layout
+- Use (group) routes to simplify the public URL structure
+- You may need to delete or refactor existing routes to fit this structure
+
+Example structure:
+
+```
+app/
+  _layout.tsx — <Tabs />
+  (home)/
+    _layout.tsx — <Stack />
+    index.tsx — <ScrollView />
+  (settings)/
+    _layout.tsx — <Stack />
+    index.tsx — <ScrollView />
+  (home,settings)/
+    info.tsx — <ScrollView /> (shared across tabs)
+```
+
+## Array Routes for Multiple Stacks
+
+Use array routes '(index,settings)' to create multiple stacks. This is useful for tabs that need to share screens across stacks.
+
+```
+app/
+  _layout.tsx — <Tabs />
+  (index,settings)/
+    _layout.tsx — <Stack />
+    index.tsx — <ScrollView />
+    settings.tsx — <ScrollView />
+```
+
+This requires a specialized layout with explicit anchor routes:
+
+```tsx
+// app/(index,settings)/_layout.tsx
+import { useMemo } from "react";
+import Stack from "expo-router/stack";
+
+export const unstable_settings = {
+  index: { anchor: "index" },
+  settings: { anchor: "settings" },
+};
+
+export default function Layout({ segment }: { segment: string }) {
+  const screen = segment.match(/\((.*)\)/)?.[1]!;
+
+  const options = useMemo(() => {
+    switch (screen) {
+      case "index":
+        return { headerRight: () => <></> };
+      default:
+        return {};
+    }
+  }, [screen]);
+
+  return (
+    <Stack>
+      <Stack.Screen name={screen} options={options} />
+    </Stack>
+  );
+}
+```
+
+## Complete App Structure Example
+
+```
+app/
+  _layout.tsx — <NativeTabs />
+  (index,search)/
+    _layout.tsx — <Stack />
+    index.tsx — Main list
+    search.tsx — Search view
+    i/[id].tsx — Detail page
+components/
+  theme.tsx
+  list.tsx
+utils/
+  storage.ts
+  use-search.ts
+```
+
+## Layout Files
+
+Every directory can have a `_layout.tsx` file that wraps all routes in that directory:
+
+```tsx
+// app/_layout.tsx
+import { Stack } from "expo-router/stack";
+
+export default function RootLayout() {
+  return <Stack />;
+}
+```
+
+```tsx
+// app/(tabs)/_layout.tsx
+import { NativeTabs, Icon, Label } from "expo-router/unstable-native-tabs";
+
+export default function TabLayout() {
+  return (
+    <NativeTabs>
+      <NativeTabs.Trigger name="index">
+        <Label>Home</Label>
+        <Icon sf="house.fill" />
+      </NativeTabs.Trigger>
+    </NativeTabs>
+  );
+}
+```
+
+## Route Settings
+
+Export `unstable_settings` to configure route behavior:
+
+```tsx
+export const unstable_settings = {
+  anchor: "index",
+};
+```
+
+- `initialRouteName` was renamed to `anchor` in v4
+
+## Not Found Routes
+
+Create a `+not-found.tsx` file to handle unmatched routes:
+
+```tsx
+// app/+not-found.tsx
+import { Link } from "expo-router";
+import { View, Text } from "react-native";
+
+export default function NotFound() {
+  return (
+    <View>
+      <Text>Page not found</Text>
+      <Link href="/">Go home</Link>
+    </View>
+  );
+}
+```
diff --git a/.agents/skills/expo-router/references/search.md b/.agents/skills/expo-router/references/search.md
new file mode 100644
index 0000000..9ca13bd
--- /dev/null
+++ b/.agents/skills/expo-router/references/search.md
@@ -0,0 +1,248 @@
+# Search
+
+## Header Search Bar
+
+Add a search bar to the stack header with `headerSearchBarOptions`:
+
+```tsx
+<Stack.Screen
+  name="index"
+  options={{
+    headerSearchBarOptions: {
+      placeholder: "Search",
+      onChangeText: (event) => console.log(event.nativeEvent.text),
+    },
+  }}
+/>
+```
+
+### Options
+
+```tsx
+headerSearchBarOptions: {
+  // Placeholder text
+  placeholder: "Search items...",
+
+  // Auto-capitalize behavior
+  autoCapitalize: "none",
+
+  // Input type
+  inputType: "text", // "text" | "phone" | "number" | "email"
+
+  // Cancel button text (iOS)
+  cancelButtonText: "Cancel",
+
+  // Hide when scrolling (iOS)
+  hideWhenScrolling: true,
+
+  // Hide navigation bar during search (iOS)
+  hideNavigationBar: true,
+
+  // Obscure background during search (iOS)
+  obscureBackground: true,
+
+  // Placement
+  placement: "automatic", // "automatic" | "inline" | "stacked"
+
+  // Callbacks
+  onChangeText: (event) => {},
+  onSearchButtonPress: (event) => {},
+  onCancelButtonPress: (event) => {},
+  onFocus: () => {},
+  onBlur: () => {},
+}
+```
+
+## useSearch Hook
+
+Reusable hook for search state management:
+
+```tsx
+import { useEffect, useState } from "react";
+import { useNavigation } from "expo-router";
+
+export function useSearch(options: any = {}) {
+  const [search, setSearch] = useState("");
+  const navigation = useNavigation();
+
+  useEffect(() => {
+    navigation.setOptions({
+      headerShown: true,
+      headerSearchBarOptions: {
+        ...options,
+        onChangeText(e: any) {
+          setSearch(e.nativeEvent.text);
+          options.onChangeText?.(e);
+        },
+        onSearchButtonPress(e: any) {
+          setSearch(e.nativeEvent.text);
+          options.onSearchButtonPress?.(e);
+        },
+        onCancelButtonPress(e: any) {
+          setSearch("");
+          options.onCancelButtonPress?.(e);
+        },
+      },
+    });
+  }, [options, navigation]);
+
+  return search;
+}
+```
+
+### Usage
+
+```tsx
+function SearchScreen() {
+  const search = useSearch({ placeholder: "Search items..." });
+
+  const filteredItems = items.filter(item =>
+    item.name.toLowerCase().includes(search.toLowerCase())
+  );
+
+  return (
+    <FlatList
+      data={filteredItems}
+      renderItem={({ item }) => <ItemRow item={item} />}
+    />
+  );
+}
+```
+
+## Filtering Patterns
+
+### Simple Text Filter
+
+```tsx
+const filtered = items.filter(item =>
+  item.name.toLowerCase().includes(search.toLowerCase())
+);
+```
+
+### Multiple Fields
+
+```tsx
+const filtered = items.filter(item => {
+  const query = search.toLowerCase();
+  return (
+    item.name.toLowerCase().includes(query) ||
+    item.description.toLowerCase().includes(query) ||
+    item.tags.some(tag => tag.toLowerCase().includes(query))
+  );
+});
+```
+
+### Debounced Search
+
+For expensive filtering or API calls:
+
+```tsx
+import { useState, useEffect, useMemo } from "react";
+
+function useDebounce<T>(value: T, delay: number): T {
+  const [debounced, setDebounced] = useState(value);
+
+  useEffect(() => {
+    const timer = setTimeout(() => setDebounced(value), delay);
+    return () => clearTimeout(timer);
+  }, [value, delay]);
+
+  return debounced;
+}
+
+function SearchScreen() {
+  const search = useSearch();
+  const debouncedSearch = useDebounce(search, 300);
+
+  const filteredItems = useMemo(() =>
+    items.filter(item =>
+      item.name.toLowerCase().includes(debouncedSearch.toLowerCase())
+    ),
+    [debouncedSearch]
+  );
+
+  return <FlatList data={filteredItems} />;
+}
+```
+
+## Search with Native Tabs
+
+When using NativeTabs with a search role, the search bar integrates with the tab bar:
+
+```tsx
+// app/_layout.tsx
+<NativeTabs>
+  <NativeTabs.Trigger name="(home)">
+    <Label>Home</Label>
+    <Icon sf="house.fill" />
+  </NativeTabs.Trigger>
+  <NativeTabs.Trigger name="(search)" role="search">
+    <Label>Search</Label>
+  </NativeTabs.Trigger>
+</NativeTabs>
+```
+
+```tsx
+// app/(search)/_layout.tsx
+<Stack>
+  <Stack.Screen
+    name="index"
+    options={{
+      headerSearchBarOptions: {
+        placeholder: "Search...",
+        onChangeText: (e) => setSearch(e.nativeEvent.text),
+      },
+    }}
+  />
+</Stack>
+```
+
+## Empty States
+
+Show appropriate UI when search returns no results:
+
+```tsx
+function SearchResults({ search, items }) {
+  const filtered = items.filter(/* ... */);
+
+  if (search && filtered.length === 0) {
+    return (
+      <View style={{ flex: 1, justifyContent: "center", alignItems: "center" }}>
+        <Text style={{ color: colors.secondaryLabel }}>
+          No results for "{search}"
+        </Text>
+      </View>
+    );
+  }
+
+  return <FlatList data={filtered} />;
+}
+```
+
+## Search Suggestions
+
+Show recent searches or suggestions:
+
+```tsx
+function SearchScreen() {
+  const search = useSearch();
+  const [recentSearches, setRecentSearches] = useState<string[]>([]);
+
+  if (!search && recentSearches.length > 0) {
+    return (
+      <View>
+        <Text style={{ color: colors.secondaryLabel }}>
+          Recent Searches
+        </Text>
+        {recentSearches.map((term) => (
+          <Pressable key={term} onPress={() => /* apply search */}>
+            <Text>{term}</Text>
+          </Pressable>
+        ))}
+      </View>
+    );
+  }
+
+  return <SearchResults search={search} />;
+}
+```
diff --git a/.agents/skills/expo-router/references/tabs.md b/.agents/skills/expo-router/references/tabs.md
new file mode 100644
index 0000000..987eabb
--- /dev/null
+++ b/.agents/skills/expo-router/references/tabs.md
@@ -0,0 +1,433 @@
+# Native Tabs
+
+Always prefer NativeTabs from 'expo-router/unstable-native-tabs' for the best iOS experience.
+
+**SDK 54+. SDK 55 recommended.**
+
+## SDK Compatibility
+
+| Aspect        | SDK 54                                                  | SDK 55+                                                     |
+| ------------- | ------------------------------------------------------- | ----------------------------------------------------------- |
+| Import        | `import { NativeTabs, Icon, Label, Badge, VectorIcon }` | `import { NativeTabs }` only                                |
+| Icon          | `<Icon sf="house.fill" />`                              | `<NativeTabs.Trigger.Icon sf="house.fill" />`               |
+| Label         | `<Label>Home</Label>`                                   | `<NativeTabs.Trigger.Label>Home</NativeTabs.Trigger.Label>` |
+| Badge         | `<Badge>9+</Badge>`                                     | `<NativeTabs.Trigger.Badge>9+</NativeTabs.Trigger.Badge>`   |
+| Android icons | `drawable` prop                                         | `md` prop (Material Symbols)                                |
+
+All examples below use SDK 55 syntax. For SDK 54, replace `NativeTabs.Trigger.Icon/Label/Badge` with standalone `Icon`, `Label`, `Badge` imports.
+
+## Basic Usage
+
+```tsx
+import { NativeTabs } from "expo-router/unstable-native-tabs";
+
+export default function TabLayout() {
+  return (
+    <NativeTabs minimizeBehavior="onScrollDown">
+      <NativeTabs.Trigger name="index">
+        <NativeTabs.Trigger.Icon sf="house.fill" md="home" />
+        <NativeTabs.Trigger.Label>Home</NativeTabs.Trigger.Label>
+        <NativeTabs.Trigger.Badge>9+</NativeTabs.Trigger.Badge>
+      </NativeTabs.Trigger>
+      <NativeTabs.Trigger name="settings">
+        <NativeTabs.Trigger.Icon sf="gear" md="settings" />
+        <NativeTabs.Trigger.Label>Settings</NativeTabs.Trigger.Label>
+      </NativeTabs.Trigger>
+      <NativeTabs.Trigger name="(search)" role="search">
+        <NativeTabs.Trigger.Label>Search</NativeTabs.Trigger.Label>
+      </NativeTabs.Trigger>
+    </NativeTabs>
+  );
+}
+```
+
+## Rules
+
+- You must include a trigger for each tab
+- The `NativeTabs.Trigger` 'name' must match the route name, including parentheses (e.g. `<NativeTabs.Trigger name="(search)">`)
+- Prefer search tab to be last in the list so it can combine with the search bar
+- Use the 'role' prop for common tab types
+- Tabs must be static — no dynamic addition/removal at runtime (remounts navigator, loses state)
+
+## Platform Features
+
+Native Tabs use platform-specific tab bar implementations:
+
+- **iOS 26+**: Liquid glass effects with system-native appearance
+- **Android**: Material 3 bottom navigation
+- Better performance and native feel
+
+## Icon Component
+
+```tsx
+// SF Symbol (iOS) + Material Symbol (Android)
+<NativeTabs.Trigger.Icon sf="house.fill" md="home" />
+
+// State variants
+<NativeTabs.Trigger.Icon sf={{ default: "house", selected: "house.fill" }} md="home" />
+
+// Custom image
+<NativeTabs.Trigger.Icon src={require('./icon.png')} />
+
+// Xcode asset catalog — iOS only (SDK 55+)
+<NativeTabs.Trigger.Icon xcasset="home-icon" />
+<NativeTabs.Trigger.Icon xcasset={{ default: "home-outline", selected: "home-filled" }} />
+
+// Rendering mode — iOS only (SDK 55+)
+<NativeTabs.Trigger.Icon src={require('./icon.png')} renderingMode="template" />
+<NativeTabs.Trigger.Icon src={require('./gradient.png')} renderingMode="original" />
+```
+
+`renderingMode`: `"template"` applies tint color (single-color icons), `"original"` preserves source colors (gradients). Android always uses original.
+
+## Label & Badge
+
+```tsx
+// Label
+<NativeTabs.Trigger.Label>Home</NativeTabs.Trigger.Label>
+<NativeTabs.Trigger.Label hidden>Home</NativeTabs.Trigger.Label>  {/* icon-only tab */}
+
+// Badge
+<NativeTabs.Trigger.Badge>9+</NativeTabs.Trigger.Badge>
+<NativeTabs.Trigger.Badge />  {/* dot indicator */}
+```
+
+## iOS 26 Features
+
+### Liquid Glass Tab Bar
+
+The tab bar automatically adopts liquid glass appearance on iOS 26+.
+
+### Minimize on Scroll
+
+```tsx
+<NativeTabs minimizeBehavior="onScrollDown">
+```
+
+### Search Tab
+
+```tsx
+<NativeTabs.Trigger name="(search)" role="search">
+  <NativeTabs.Trigger.Label>Search</NativeTabs.Trigger.Label>
+</NativeTabs.Trigger>
+```
+
+**Note**: Place search tab last for best UX.
+
+### Role Prop
+
+Use semantic roles for special tab types:
+
+```tsx
+<NativeTabs.Trigger name="search" role="search" />
+<NativeTabs.Trigger name="favorites" role="favorites" />
+<NativeTabs.Trigger name="more" role="more" />
+```
+
+Available roles: `search` | `more` | `favorites` | `bookmarks` | `contacts` | `downloads` | `featured` | `history` | `mostRecent` | `mostViewed` | `recents` | `topRated`
+
+## Customization
+
+### Tint Color
+
+```tsx
+<NativeTabs tintColor="#007AFF">
+```
+
+### Dynamic Colors (iOS)
+
+Use DynamicColorIOS for colors that adapt to liquid glass:
+
+```tsx
+import { DynamicColorIOS, Platform } from 'react-native';
+
+const adaptiveBlue = Platform.select({
+  ios: DynamicColorIOS({ light: '#007AFF', dark: '#0A84FF' }),
+  default: '#007AFF',
+});
+
+<NativeTabs tintColor={adaptiveBlue}>
+```
+
+## Conditional Tabs
+
+```tsx
+<NativeTabs.Trigger name="admin" hidden={!isAdmin}>
+  <NativeTabs.Trigger.Label>Admin</NativeTabs.Trigger.Label>
+  <NativeTabs.Trigger.Icon sf="shield.fill" md="shield" />
+</NativeTabs.Trigger>
+```
+
+**Don't hide the tabs when they are visible - toggling visibility remounts the navigator; Do it only during the initial render.**
+
+**Note**: Hidden tabs cannot be navigated to!
+
+## Behavior Options
+
+```tsx
+<NativeTabs.Trigger
+  name="home"
+  disablePopToTop           // Don't pop stack when tapping active tab
+  disableScrollToTop        // Don't scroll to top when tapping active tab
+  disableAutomaticContentInsets  // Opt out of automatic safe area insets (SDK 55+)
+>
+```
+
+## Hidden Tab Bar (SDK 55+)
+
+Use `hidden` prop on `NativeTabs` to hide the entire tab bar dynamically:
+
+```tsx
+<NativeTabs hidden={isTabBarHidden}>{/* triggers */}</NativeTabs>
+```
+
+## Bottom Accessory (SDK 55+)
+
+`NativeTabs.BottomAccessory` renders content above the tab bar (iOS 26+). Uses `usePlacement()` to adapt between `'regular'` and `'inline'` layouts.
+
+**Important**: Two instances render simultaneously — store state outside the component (props, context, or external store).
+
+```tsx
+import { NativeTabs } from "expo-router/unstable-native-tabs";
+import { useState } from "react";
+import { Pressable, Text, View } from "react-native";
+
+function MiniPlayer({
+  isPlaying,
+  onToggle,
+}: {
+  isPlaying: boolean;
+  onToggle: () => void;
+}) {
+  const placement = NativeTabs.BottomAccessory.usePlacement();
+  if (placement === "inline") {
+    return (
+      <Pressable onPress={onToggle}>
+        <SymbolView name={isPlaying ? "pause.fill" : "play.fill"} />
+      </Pressable>
+    );
+  }
+  return <View>{/* full player UI */}</View>;
+}
+
+export default function TabLayout() {
+  const [isPlaying, setIsPlaying] = useState(false);
+  return (
+    <NativeTabs>
+      <NativeTabs.BottomAccessory>
+        <MiniPlayer
+          isPlaying={isPlaying}
+          onToggle={() => setIsPlaying(!isPlaying)}
+        />
+      </NativeTabs.BottomAccessory>
+      <NativeTabs.Trigger name="index">
+        <NativeTabs.Trigger.Icon sf="house.fill" md="home" />
+        <NativeTabs.Trigger.Label>Home</NativeTabs.Trigger.Label>
+      </NativeTabs.Trigger>
+    </NativeTabs>
+  );
+}
+```
+
+## Safe Area Handling (SDK 55+)
+
+SDK 55 handles safe areas automatically:
+
+- **Android**: Content wrapped in SafeAreaView (bottom inset)
+- **iOS**: First ScrollView gets automatic `contentInsetAdjustmentBehavior`
+
+To opt out per-tab, use `disableAutomaticContentInsets` and manage manually:
+
+```tsx
+<NativeTabs.Trigger name="index" disableAutomaticContentInsets>
+  <NativeTabs.Trigger.Label>Home</NativeTabs.Trigger.Label>
+</NativeTabs.Trigger>
+```
+
+```tsx
+// In the screen
+import { SafeAreaView } from "react-native-screens/experimental";
+
+export default function HomeScreen() {
+  return (
+    <SafeAreaView edges={{ bottom: true }} style={{ flex: 1 }}>
+      {/* content */}
+    </SafeAreaView>
+  );
+}
+```
+
+## Using Vector Icons
+
+If you must use @expo/vector-icons instead of SF Symbols:
+
+```tsx
+import { NativeTabs } from "expo-router/unstable-native-tabs";
+import Ionicons from "@expo/vector-icons/Ionicons";
+
+<NativeTabs.Trigger name="home">
+  <NativeTabs.Trigger.VectorIcon vector={Ionicons} name="home" />
+  <NativeTabs.Trigger.Label>Home</NativeTabs.Trigger.Label>
+</NativeTabs.Trigger>
+```
+
+**Prefer SF Symbols + `md` prop over vector icons for native feel.**
+
+If you are using SDK 55 and later **use the md prop to specify Material Symbols used on Android**.
+
+## Structure with Stacks
+
+Native tabs don't render headers. Nest Stacks inside each tab for navigation headers:
+
+```tsx
+// app/(tabs)/_layout.tsx
+import { NativeTabs } from "expo-router/unstable-native-tabs";
+
+export default function TabLayout() {
+  return (
+    <NativeTabs>
+      <NativeTabs.Trigger name="(home)">
+        <NativeTabs.Trigger.Label>Home</NativeTabs.Trigger.Label>
+        <NativeTabs.Trigger.Icon sf="house.fill" md="home" />
+      </NativeTabs.Trigger>
+    </NativeTabs>
+  );
+}
+
+// app/(tabs)/(home)/_layout.tsx
+import Stack from "expo-router/stack";
+
+export default function HomeStack() {
+  return (
+    <Stack>
+      <Stack.Screen
+        name="index"
+        options={{ title: "Home", headerLargeTitle: true }}
+      />
+      <Stack.Screen name="details" options={{ title: "Details" }} />
+    </Stack>
+  );
+}
+```
+
+## Custom Web Layout
+
+Use platform-specific files for separate native and web tab layouts:
+
+```
+app/
+  _layout.tsx          # NativeTabs for iOS/Android
+  _layout.web.tsx      # Headless tabs for web (expo-router/ui)
+```
+
+Or extract to a component: `components/app-tabs.tsx` + `components/app-tabs.web.tsx`.
+
+## Migration from JS Tabs
+
+### Before (JS Tabs)
+
+```tsx
+import { Tabs } from "expo-router";
+
+<Tabs>
+  <Tabs.Screen
+    name="index"
+    options={{
+      title: "Home",
+      tabBarIcon: ({ color }) => <IconSymbol name="house.fill" color={color} />,
+      tabBarBadge: 3,
+    }}
+  />
+</Tabs>;
+```
+
+### After (Native Tabs)
+
+```tsx
+import { NativeTabs } from "expo-router/unstable-native-tabs";
+
+<NativeTabs>
+  <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>;
+```
+
+### Key Differences
+
+| JS Tabs                    | Native Tabs                  |
+| -------------------------- | ---------------------------- |
+| `<Tabs.Screen>`            | `<NativeTabs.Trigger>`       |
+| `options={{ title }}`      | `<NativeTabs.Trigger.Label>` |
+| `options={{ tabBarIcon }}` | `<NativeTabs.Trigger.Icon>`  |
+| `tabBarBadge` option       | `<NativeTabs.Trigger.Badge>` |
+| Props-based API            | Component-based API          |
+| Headers built-in           | Nest `<Stack>` for headers   |
+
+## Limitations
+
+- **Android**: Maximum 5 tabs (Material Design constraint)
+- **Nesting**: Native tabs cannot nest inside other native tabs
+- **Tab bar height**: Cannot be measured programmatically
+- **FlatList transparency**: Use `disableTransparentOnScrollEdge` to fix issues
+- **Dynamic tabs**: Tabs must be static; changes remount navigator and lose state
+
+## Keyboard Handling (Android)
+
+Configure in app.json:
+
+```json
+{
+  "expo": {
+    "android": {
+      "softwareKeyboardLayoutMode": "resize"
+    }
+  }
+}
+```
+
+## Common Issues
+
+1. **Icons not showing on Android**: Add `md` prop (SDK 55) or use VectorIcon
+2. **Headers missing**: Nest a Stack inside each tab group
+3. **Trigger name mismatch**: `name` must match exact route name including parentheses
+4. **Badge not visible**: Badge must be a child of Trigger, not a prop
+5. **Tab bar transparent on iOS 18 and earlier**: If the screen uses a `ScrollView` or `FlatList`, make sure it is the first opaque child of the screen component. If it needs to be wrapped in another `View`, ensure the wrapper uses `collapsable={false}`. If the screen does not use a `ScrollView` or `FlatList`, set `disableTransparentOnScrollEdge` to `true` in the `NativeTabs.Trigger` options, to make the tab bar opaque.
+6. **Scroll to top not working**: Ensure `disableScrollToTop` is not set on the active tab's Trigger and `ScrollView` is the first child of the screen component.
+7. **Header buttons flicker when navigating between tabs**: Make sure the app is wrapped in a `ThemeProvider`
+
+```tsx
+import {
+  ThemeProvider,
+  DarkTheme,
+  DefaultTheme,
+} from "@react-navigation/native";
+import { useColorScheme } from "react-native";
+import { Stack } from "expo-router";
+
+export default function Layout() {
+  const colorScheme = useColorScheme();
+  return (
+    <ThemeProvider theme={colorScheme === "dark" ? DarkTheme : DefaultTheme}>
+      <Stack />
+    </ThemeProvider>
+  );
+}
+```
+
+If the app only uses a light or dark theme, you can directly pass `DarkTheme` or `DefaultTheme` to `ThemeProvider` without checking the color scheme.
+
+```tsx
+import { ThemeProvider, DarkTheme } from "@react-navigation/native";
+import { Stack } from "expo-router";
+
+export default function Layout() {
+  return (
+    <ThemeProvider theme={DarkTheme}>
+      <Stack />
+    </ThemeProvider>
+  );
+}
+```
diff --git a/.agents/skills/expo-router/references/toolbar-and-headers.md b/.agents/skills/expo-router/references/toolbar-and-headers.md
new file mode 100644
index 0000000..9706b8d
--- /dev/null
+++ b/.agents/skills/expo-router/references/toolbar-and-headers.md
@@ -0,0 +1,284 @@
+# Toolbars and headers
+
+Add native iOS toolbar items to Stack screens. Items can be placed in the header (left/right) or in a bottom toolbar area.
+
+**Important:** iOS only. Available in Expo SDK 55+.
+
+## Notes app example
+
+```tsx
+import { Stack } from "expo-router";
+import { ScrollView } from "react-native";
+
+export default function FoldersScreen() {
+  return (
+    <>
+      {/* ScrollView must be the first child of the screen */}
+      <ScrollView
+        style={{ flex: 1 }}
+        contentInsetAdjustmentBehavior="automatic"
+      >
+        {/* Screen content */}
+      </ScrollView>
+      <Stack.Screen.Title large>Folders</Stack.Screen.Title>
+      <Stack.SearchBar placeholder="Search" onChangeText={() => {}} />
+      {/* Header toolbar - right side */}
+      <Stack.Toolbar placement="right">
+        <Stack.Toolbar.Button icon="folder.badge.plus" onPress={() => {}} />
+        <Stack.Toolbar.Button onPress={() => {}}>Edit</Stack.Toolbar.Button>
+      </Stack.Toolbar>
+
+      {/* Bottom toolbar */}
+      <Stack.Toolbar placement="bottom">
+        <Stack.Toolbar.SearchBarSlot />
+        <Stack.Toolbar.Button
+          icon="square.and.pencil"
+          onPress={() => {}}
+          separateBackground
+        />
+      </Stack.Toolbar>
+    </>
+  );
+}
+```
+
+## Mail inbox example
+
+```tsx
+import { Color, Stack } from "expo-router";
+import { useState } from "react";
+import { ScrollView, Text, View } from "react-native";
+
+export default function InboxScreen() {
+  const [isFilterOpen, setIsFilterOpen] = useState(false);
+  return (
+    <>
+      <ScrollView
+        style={{ flex: 1 }}
+        contentInsetAdjustmentBehavior="automatic"
+        contentContainerStyle={{ paddingHorizontal: 16 }}
+      >
+        {/* Screen content */}
+      </ScrollView>
+      <Stack.Screen options={{ headerTransparent: true }} />
+      <Stack.Screen.Title>Inbox</Stack.Screen.Title>
+      <Stack.SearchBar placeholder="Search" onChangeText={() => {}} />
+      {/* Header toolbar - right side */}
+      <Stack.Toolbar placement="right">
+        <Stack.Toolbar.Button onPress={() => {}}>Select</Stack.Toolbar.Button>
+        <Stack.Toolbar.Menu icon="ellipsis">
+          <Stack.Toolbar.Menu inline>
+            <Stack.Toolbar.Menu inline title="Sort By">
+              <Stack.Toolbar.MenuAction isOn>
+                Categories
+              </Stack.Toolbar.MenuAction>
+              <Stack.Toolbar.MenuAction>List</Stack.Toolbar.MenuAction>
+            </Stack.Toolbar.Menu>
+            <Stack.Toolbar.MenuAction icon="info.circle">
+              About categories
+            </Stack.Toolbar.MenuAction>
+          </Stack.Toolbar.Menu>
+          <Stack.Toolbar.MenuAction icon="person.circle">
+            Show Contact Photos
+          </Stack.Toolbar.MenuAction>
+        </Stack.Toolbar.Menu>
+      </Stack.Toolbar>
+
+      {/* Bottom toolbar */}
+      <Stack.Toolbar placement="bottom">
+        <Stack.Toolbar.Button
+          icon="line.3.horizontal.decrease"
+          selected={isFilterOpen}
+          onPress={() => setIsFilterOpen((prev) => !prev)}
+        />
+        <Stack.Toolbar.View hidden={!isFilterOpen}>
+          <View style={{ width: 70, height: 32, justifyContent: "center" }}>
+            <Text style={{ fontSize: 12, fontWeight: 700 }}>Filter by</Text>
+            <Text
+              style={{
+                fontSize: 12,
+                fontWeight: 700,
+                color: Color.ios.systemBlue,
+              }}
+            >
+              Unread
+            </Text>
+          </View>
+        </Stack.Toolbar.View>
+        <Stack.Toolbar.Spacer />
+        <Stack.Toolbar.SearchBarSlot />
+        <Stack.Toolbar.Button
+          icon="square.and.pencil"
+          onPress={() => {}}
+          separateBackground
+        />
+      </Stack.Toolbar>
+    </>
+  );
+}
+```
+
+## Placement
+
+- `"left"` - Header left
+- `"right"` - Header right
+- `"bottom"` (default) - Bottom toolbar
+
+## Components
+
+### Button
+
+- Icon button: `<Stack.Toolbar.Button icon="star.fill" onPress={() => {}} />`
+- Text button: `<Stack.Toolbar.Button onPress={() => {}}>Done</Stack.Toolbar.Button>`
+
+**Props:** `icon`, `image`, `onPress`, `disabled`, `hidden`, `variant` (`"plain"` | `"done"` | `"prominent"`), `tintColor`
+
+### Menu
+
+Dropdown menu for grouping actions.
+
+```tsx
+<Stack.Toolbar.Menu icon="ellipsis">
+  <Stack.Toolbar.Menu inline>
+    <Stack.Toolbar.MenuAction>Sort by Recently Added</Stack.Toolbar.MenuAction>
+    <Stack.Toolbar.MenuAction isOn>
+      Sort by Date Captured
+    </Stack.Toolbar.MenuAction>
+  </Stack.Toolbar.Menu>
+  <Stack.Toolbar.Menu title="Filter">
+    <Stack.Toolbar.Menu inline>
+      <Stack.Toolbar.MenuAction isOn icon="square.grid.2x2">
+        All Items
+      </Stack.Toolbar.MenuAction>
+    </Stack.Toolbar.Menu>
+    <Stack.Toolbar.MenuAction icon="heart">Favorites</Stack.Toolbar.MenuAction>
+    <Stack.Toolbar.MenuAction icon="photo">Photos</Stack.Toolbar.MenuAction>
+    <Stack.Toolbar.MenuAction icon="video">Videos</Stack.Toolbar.MenuAction>
+  </Stack.Toolbar.Menu>
+</Stack.Toolbar.Menu>
+```
+
+**Menu Props:** All Button props plus `title`, `inline`, `palette`, `elementSize` (`"small"` | `"medium"` | `"large"`)
+
+**MenuAction Props:** `icon`, `onPress`, `isOn`, `destructive`, `disabled`, `subtitle`
+
+When creating a palette with dividers, use `inline` combined with `elementSize="small"`. `palette` will not apply dividers on iOS 26.
+
+### Spacer
+
+```tsx
+<Stack.Toolbar.Spacer />           // Bottom toolbar - flexible
+<Stack.Toolbar.Spacer width={16} /> // Header - requires explicit width
+```
+
+### View
+
+Embed custom React Native components. When adding a custom view make sure that there is only a single child with **explicit width and height**.
+
+```tsx
+<Stack.Toolbar.View>
+  <View style={{ width: 70, height: 32, justifyContent: "center" }}>
+    <Text style={{ fontSize: 12, fontWeight: 700 }}>Filter by</Text>
+  </View>
+</Stack.Toolbar.View>
+```
+
+You can pass custom components to views as well:
+
+```tsx
+function CustomFilterView() {
+  return (
+    <View style={{ width: 70, height: 32, justifyContent: "center" }}>
+      <Text style={{ fontSize: 12, fontWeight: 700 }}>Filter by</Text>
+    </View>
+  );
+}
+...
+<Stack.Toolbar.View>
+  <CustomFilterView />
+</Stack.Toolbar.View>
+```
+
+## Recommendations
+
+- When creating more complex headers, extract them to a single component
+
+```tsx
+export default function Page() {
+  return (
+    <>
+      <ScrollView>{/* Screen content */}</ScrollView>
+      <InboxHeader />
+    </>
+  );
+}
+
+function InboxHeader() {
+  return (
+    <>
+      <Stack.Screen.Title>Inbox</Stack.Screen.Title>
+      <Stack.SearchBar placeholder="Search" onChangeText={() => {}} />
+      <Stack.Toolbar placement="right">{/* Toolbar buttons */}</Stack.Toolbar>
+    </>
+  );
+}
+```
+
+- When using `Stack.Toolbar`, make sure that all `Stack.Toolbar.*` components are wrapped inside `Stack.Toolbar` component.
+
+This will **not work**:
+
+```tsx
+function Buttons() {
+  return (
+    <>
+      <Stack.Toolbar.Button icon="star.fill" onPress={() => {}} />
+      <Stack.Toolbar.Button onPress={() => {}}>Done</Stack.Toolbar.Button>
+    </>
+  );
+}
+
+function Page() {
+  return (
+    <>
+      <ScrollView>{/* Screen content */}</ScrollView>
+      <Stack.Toolbar placement="right">
+        <Buttons /> {/* ❌ This will NOT work */}
+      </Stack.Toolbar>
+    </>
+  );
+}
+```
+
+This will work:
+
+```tsx
+function ToolbarWithButtons() {
+  return (
+    <Stack.Toolbar>
+      <Stack.Toolbar.Button icon="star.fill" onPress={() => {}} />
+      <Stack.Toolbar.Button onPress={() => {}}>Done</Stack.Toolbar.Button>
+    </Stack.Toolbar>
+  );
+}
+
+function Page() {
+  return (
+    <>
+      <ScrollView>{/* Screen content */}</ScrollView>
+      <ToolbarWithButtons /> {/* ✅ This will work */}
+    </>
+  );
+}
+```
+
+## Limitations
+
+- iOS only
+- `placement="bottom"` can only be used inside screen components (not in layout files)
+- `Stack.Toolbar.Badge` only works with `placement="left"` or `"right"`
+- Header Spacers require explicit `width`
+
+## Reference
+
+Docs https://docs.expo.dev/versions/unversioned/sdk/router - read to see the full API.
diff --git a/.agents/skills/expo-router/references/zoom-transitions.md b/.agents/skills/expo-router/references/zoom-transitions.md
new file mode 100644
index 0000000..27e00a8
--- /dev/null
+++ b/.agents/skills/expo-router/references/zoom-transitions.md
@@ -0,0 +1,158 @@
+# Apple Zoom Transitions
+
+Fluid zoom transitions for navigating between screens. iOS 18+, Expo SDK 55+, Stack navigator only.
+
+```tsx
+import { Link } from "expo-router";
+```
+
+## Basic Zoom
+
+Use `withAppleZoom` on `Link.Trigger` to zoom the entire trigger element into the destination screen:
+
+```tsx
+<Link href="/photo" asChild>
+  <Link.Trigger withAppleZoom>
+    <Pressable>
+      <Image
+        source={{ uri: "https://example.com/thumb.jpg" }}
+        style={{ width: 120, height: 120, borderRadius: 12 }}
+      />
+    </Pressable>
+  </Link.Trigger>
+</Link>
+```
+
+## Targeted Zoom with `Link.AppleZoom`
+
+Wrap only the element that should animate. Siblings outside `Link.AppleZoom` are not part of the transition:
+
+```tsx
+<Link href="/photo" asChild>
+  <Link.Trigger>
+    <Pressable style={{ alignItems: "center" }}>
+      <Link.AppleZoom>
+        <Image
+          source={{ uri: "https://example.com/thumb.jpg" }}
+          style={{ width: 200, aspectRatio: 4 / 3 }}
+        />
+      </Link.AppleZoom>
+      <Text>Caption text (not zoomed)</Text>
+    </Pressable>
+  </Link.Trigger>
+</Link>
+```
+
+`Link.AppleZoom` accepts only a single child element.
+
+## Destination Target
+
+Use `Link.AppleZoomTarget` on the destination screen to align the zoom animation to a specific element:
+
+```tsx
+// Destination screen (e.g., app/photo.tsx)
+import { Link } from "expo-router";
+
+export default function PhotoScreen() {
+  return (
+    <View style={{ flex: 1 }}>
+      <Link.AppleZoomTarget>
+        <Image
+          source={{ uri: "https://example.com/full.jpg" }}
+          style={{ width: "100%", aspectRatio: 4 / 3 }}
+        />
+      </Link.AppleZoomTarget>
+      <Text>Photo details below</Text>
+    </View>
+  );
+}
+```
+
+Without a target, the zoom animates to fill the entire destination screen.
+
+## Custom Alignment Rectangle
+
+For manual control over where the zoom lands on the destination, use `alignmentRect` instead of `Link.AppleZoomTarget`:
+
+```tsx
+<Link.AppleZoom alignmentRect={{ x: 0, y: 0, width: 200, height: 300 }}>
+  <Image source={{ uri: "https://example.com/thumb.jpg" }} />
+</Link.AppleZoom>
+```
+
+Coordinates are in the destination screen's coordinate space. Prefer `Link.AppleZoomTarget` when possible — use `alignmentRect` only when the target element isn't available as a React component.
+
+## Controlling Dismissal
+
+Zoom screens support interactive dismissal gestures by default (pinch, swipe down when scrolled to top, swipe from leading edge). Use `usePreventZoomTransitionDismissal` on the destination screen to control this.
+
+### Disable all dismissal gestures
+
+```tsx
+import { usePreventZoomTransitionDismissal } from "expo-router";
+
+export default function PhotoScreen() {
+  usePreventZoomTransitionDismissal();
+  return <Image source={{ uri: "https://example.com/full.jpg" }} />;
+}
+```
+
+### Restrict dismissal to a specific area
+
+Use `unstable_dismissalBoundsRect` to prevent conflicts with scrollable content:
+
+```tsx
+usePreventZoomTransitionDismissal({
+  unstable_dismissalBoundsRect: {
+    minX: 0,
+    minY: 0,
+    maxX: 300,
+    maxY: 300,
+  },
+});
+```
+
+This is useful when the destination contains a zoomable scroll view — the system gives that scroll view precedence over the dismiss gesture.
+
+## Combining with Link.Preview
+
+Zoom transitions work alongside long-press previews:
+
+```tsx
+<Link href="/photo" asChild>
+  <Link.Trigger withAppleZoom>
+    <Pressable>
+      <Image
+        source={{ uri: "https://example.com/thumb.jpg" }}
+        style={{ width: 120, height: 120 }}
+      />
+    </Pressable>
+  </Link.Trigger>
+  <Link.Preview />
+</Link>
+```
+
+## Best Practices
+
+**Good use cases:**
+- Thumbnail → full image (gallery, profile photos)
+- Card → detail screen with similar visual content
+- Source and destination with similar aspect ratios
+
+**Avoid:**
+- Skinny full-width list rows as zoom sources — the transition looks unnatural
+- Mismatched aspect ratios between source and destination without `alignmentRect`
+- Using zoom with sheets or popovers — only works in Stack navigator
+- Hiding the navigation bar — known issues with header visibility during transitions
+
+**Tips:**
+- Always provide a close or back button — dismissal gestures are not discoverable
+- If the destination has a zoomable scroll view, use `unstable_dismissalBoundsRect` to avoid gesture conflicts
+- Source view doesn't need to match the tap target — only the `Link.AppleZoom` wrapped element animates
+- When source is unavailable (e.g., scrolled off screen), the transition zooms from the center of the screen
+
+## References
+
+- Expo Router Zoom Transitions: https://docs.expo.dev/router/advanced/zoom-transition/
+- Link.AppleZoom API: https://docs.expo.dev/versions/v55.0.0/sdk/router/#linkapplezoom
+- Apple UIKit Fluid Transitions: https://developer.apple.com/documentation/uikit/enhancing-your-app-with-fluid-transitions
diff --git a/.agents/skills/expo-skill-eval/SKILL.md b/.agents/skills/expo-skill-eval/SKILL.md
new file mode 100644
index 0000000..4ea45bd
--- /dev/null
+++ b/.agents/skills/expo-skill-eval/SKILL.md
@@ -0,0 +1,314 @@
+---
+name: expo-skill-eval
+description: Evaluate Expo skills in this repo end-to-end - trigger accuracy, generated code quality, and runtime screenshots on iOS simulator and Android emulator via Expo Go (web optional). Use when the user wants to eval an Expo skill, test that a skill produces working code, benchmark a skill with device screenshots, or verify a skill's output renders correctly.
+version: 1.0.0
+license: MIT
+allowed-tools: "Read(~/.cache/expo-skill-eval/**), Read(/tmp/expo-skill-eval-*/**), Read(/private/tmp/expo-skill-eval-*/**), Write(/tmp/expo-skill-eval-*/**), Write(/private/tmp/expo-skill-eval-*/**), Edit(/tmp/expo-skill-eval-*/**), Edit(/private/tmp/expo-skill-eval-*/**), Bash(python3 /tmp/expo-skill-eval-*), Bash(python3 /private/tmp/expo-skill-eval-*), Bash(python3 *expo-skill-eval/scripts/*), Bash(tee /tmp/expo-skill-eval-*), Bash(tee /private/tmp/expo-skill-eval-*), Bash(bash *expo-skill-eval/scripts/*)"
+---
+
+# Expo Skill Eval
+
+Evaluates skills in `plugins/expo/skills/` for trigger accuracy, generated code quality, and/or runtime rendering in Expo Go.
+
+Requirements: macOS with Xcode (iOS simulators), Android SDK with at least one AVD, and `bun`. No other device tooling is assumed.
+
+Workspace root: `/private/tmp/expo-skill-eval-<skill-name>/iteration-N/` (e.g. `/private/tmp/expo-skill-eval-expo-ui/iteration-4/`).
+
+## Before starting — clarify scope
+
+**Confirm all of the following up front, before any pipeline work — don't skip any** (only skip a given item if the request already states that choice). Batch them into `AskUserQuestion` calls of ≤4 questions each, in this order:
+
+1. **Which skill** to eval (if not clear from the request).
+2. **Prompts** — which prompts drive the eval. Built-in prompts (from the skill's eval cases) are **pre-selected all**; drop any, add a custom text prompt, or **build from an uploaded screenshot** (a target UI the skill must reproduce). See **Prompts** below.
+3. **What to verify** — one multi-select of three options: Runtime + screenshots / Trigger accuracy / Code checks (no device). See *What to verify* below.
+4. **Expo SDK** — latest (default, auto-detected) or a pinned version.
+5. **Runner** — Expo Go (default) or development build.
+6. **Platforms** — iOS / Android / web (always offer all three).
+7. **Permission flag** for `claude -p` — skip-permissions (default) or accept-edits.
+8. **Viewer delivery** — local only (default) or publish a shareable Artifact.
+9. **If trigger accuracy is selected** — confirm the published `expo` plugin is disabled (or not installed).
+
+Each is detailed below. Items 4–6 (SDK, runner, platforms) fit naturally in one `AskUserQuestion` call.
+
+**If the skill to eval is not clear from the request**, list available skills from `plugins/expo/skills/` and ask which one to evaluate.
+
+**How the skill under test is loaded — two mechanisms, one per phase** (don't pick one globally): executor runs reference it by **file path** (`SKILL_PATH = plugins/expo/skills/<skill>/SKILL.md`, read explicitly), while the trigger eval loads it as a **plugin** (`--plugin-dir plugins/expo`, so the model can auto-select it from its description). Both point at the *local, in-repo* version — that's what you're evaluating. You do **not** need any special flag to *launch* the harness session itself (the harness finds the skill by repo path); the mechanisms apply to the `claude -p` subprocesses it spawns. See steps 1 and 3 for why each phase differs. **One pre-run check (required when the trigger eval is in scope):** if the *published* `expo` plugin is installed/enabled, disable it (via `/plugin`) **before launching** the harness and re-enable after. A single disable is a global-config change that both this session and the spawned `claude -p` subprocesses inherit. Why it's required for the trigger eval: that phase loads the local skill via `--plugin-dir`, and a second installed `expo` collides with it — the model may trigger the *published* `expo:expo-ui`, and since detection only sees the tool-call name you'd silently score the published description instead of your local edits (the collision could also just error). The **executor / runtime / static** phases are *not* affected — they read the skill under test by its local `SKILL_PATH` with no `--plugin-dir` — so a run with no trigger eval can skip the disable. Disabling `expo` does **not** disable `expo-skill-eval` (a standalone project skill, not part of the `expo` plugin), so the harness stays available.
+
+**Surface this to the user as an explicit up-front confirmation** — the same way you confirm which skill to eval. When the trigger eval is in scope, ask the user to confirm the published `expo` plugin is disabled (or not installed) *before* you start step 1; if it's still enabled, pause and have them disable it via `/plugin`. Don't run the trigger eval until they confirm — the harness can't reliably detect installed plugins on its own (reading the global plugin config or `claude plugin list` would prompt), so this is a manual confirmation, not an auto-check.
+
+**Pick the prompts — built-in, custom, or a target screenshot.** The prompts are the *inputs* that drive the executor (with-skill and without-skill); they are separate from what you *verify*. Confirm them with `AskUserQuestion` (skip if the request already names a prompt):
+
+- **Built-in prompts** — representative prompts you generate by reading the skill under test (its `SKILL.md` + `references/`) and `references/runtime-matrix.md`, covering the skill's standard use cases. (If the skill already ships eval cases under `evals/evals.json`, fold their `prompt` fields in too — but most skills don't, so you usually derive them.) **Pre-select all** so the default run exercises the skill's standard cases; let the user deselect any.
+- **Custom text prompt** — a one-off prompt the user types. Don't spend a dedicated option slot on this: `AskUserQuestion` auto-adds a **"Type something"** / Other entry, and anything typed there becomes a custom text case.
+- **Build from an uploaded screenshot** — the user gives the path to a **target screenshot** (a UI to reproduce). The executor is told to open it — `claude -p` reads PNGs with its Read tool — and build an app matching it; the case records the path as `reference_image`, and grading compares the generated app to that target (step 6). This is the strongest visual test for a UI skill: "build *this*."
+
+**Respect `AskUserQuestion`'s 4-option-per-question cap with this priority** (the bug to avoid: the upload option silently dropped once the four slots fill up):
+
+1. **Always reserve a slot for "Build from an uploaded screenshot."** It's the whole point of the visual eval and must never be the option that gets dropped.
+2. **Don't add an explicit "Custom text prompt" option** — the auto "Type something" / Other entry already covers it.
+3. Fill the remaining ≤3 slots with the built-in/representative prompts, **pre-selected**. If there are more than 3, collapse them into one pre-selected **"All built-in prompts (default)"** option and offer subset-picking in a short follow-up, so the upload option still fits.
+
+Present it as a **multi-select**. When "Build from an uploaded screenshot" is picked, ask for the target image path in a follow-up. Each selected prompt (built-in, typed, or image) becomes one eval case (run with-skill and without-skill).
+
+**Always confirm what to verify** unless the request makes it unambiguous. Present these options and let the user pick one or more (defaults in bold based on the skill's `references/runtime-matrix.md` entry):
+
+| Option | What it does | When to suggest as default |
+|--------|-------------|---------------------------|
+| **Runtime + screenshots** | Full pipeline: fixture → executor → static gate → run the app on iOS/Android and screenshot it. The runner (Expo Go or dev build) is a separate question — don't name it here. | **Default** for any skill that renders an app screen (the `expo-go`/`dev-build` rows in `references/runtime-matrix.md`). Requires a booted simulator/emulator. |
+| **Trigger accuracy** | Run realistic prompts via `claude -p`, check whether the skill is read. Measures recall (should-trigger queries only). | Always useful as a standalone check. |
+| **Code checks (no device)** | `tsc --noEmit` + diff-aware lint + `expo export`, plus the grader checks the generated code against any custom expectations you provide. No device. | **Default** for `static-only` and `n/a` skills, and whenever you want to verify code patterns (correct import path, a `Host` wrapper, …) without running the app. |
+**Present these as ONE multi-select question — *"What do you want to verify?"*** These are *grading dimensions* (how to judge what gets built) — distinct from the **Prompts** phase (what to build). The user may pick any combination. When a prompt is an **uploaded screenshot** (see **Prompts**), include **"Runtime + screenshots"** so the harness captures the generated app and the grader can score it against the target.
+
+Read `references/runtime-matrix.md` to find the skill's default mode before suggesting. If the request already specifies a mode (e.g. "just check if it triggers", "run it on device"), skip the question and proceed.
+
+**Pick the Expo SDK version — once, up front.** Detect the latest with `bash /abs/path/expo-skill-eval/scripts/latest-sdk.sh` (it prints the major, e.g. `56`; internally it uses `bun` to run `npm view expo dist-tags --json` and read the major via `JSON.parse`/`semver`, and it's covered by the bash-scripts rule — so don't run the registry query inline yourself, which would prompt). Then confirm with `AskUserQuestion`: default to that latest SDK, or let the user pin an older one (e.g. to reproduce a version-specific issue). Use the chosen version everywhere the fixture is built — pass it as the `<sdk>` arg to `make-fixture.sh` and write it into each eval case's `runtime.sdk`. If the request already names a version ("eval on SDK 54"), skip detection and use it.
+
+**Default to the latest** — it stays compatible with the Expo Go that `expo start` installs on the device. Pinning an SDK *older* than the device's installed Expo Go makes `expo start` try to prompt "Install the recommended Expo Go version?"; with no TTY (the snapshot scripts read stdin from `/dev/null`) it dies with `Input is required, but 'npx expo' is in non-interactive mode` and **every snapshot fails**. So only pin an older SDK when you also pre-install a matching Expo Go on the simulator/emulator — otherwise stick with latest.
+
+**Pick the runner — Expo Go (default) or a development build.** Ask with `AskUserQuestion` (skip if the request already says which):
+
+- **Expo Go (default)** — the snapshot scripts run the app with `expo start --ios` / `expo start --android` as-is. Fast (no native compile), and it runs anything Expo Go bundles (including `@expo/ui` on SDK 56+). Cannot run custom native code (expo-modules, config plugins, native deps not in Expo Go).
+- **Development build** — the snapshot scripts run `expo run:ios` / `expo run:android` instead, compiling a native dev client per fixture. Use this for skills whose output needs custom native code (the cases that would otherwise be `static-only`). Much slower — `expo run` prebuilds and natively compiles each fixture (minutes, especially the first), and needs the full iOS/Android build toolchain — so only choose it when the skill actually requires native code. **Disk-heavy:** each fixture's native build is multi-GB. The snapshot phase runs `clean-fixture.sh` after each fixture to keep peak usage to ~one build, but still prefer fewer eval cases and a **single platform** for dev-build runs, and keep a few GB free. `clean-fixture.sh` removes the per-fixture build *output* (`node_modules`, `ios`, `android`, `.expo`, `dist`, and the fixture's iOS DerivedData) and keeps the app source + git. The lever for dev-build disk is **fewer eval cases + one platform** — it only reclaims per-fixture build output and never touches shared dependency caches, so nothing gets re-downloaded.
+
+Pass the choice to the snapshot scripts via the `EXPO_SKILL_EVAL_RUNNER` env var (`expo-go` default, or `dev-build`), and reflect it in each eval case's `runtime.mode` (`expo-go` or `dev-build`). See step 5.
+
+**Pick the platforms — always ask, regardless of skill.** Offer iOS / Android / web (multi-select) with `AskUserQuestion`; default to iOS + Android, but always present web as an option — don't pre-filter by skill. **Web is a valid choice for most skills**: `@expo/ui`'s *universal* components (`Host`, `Row`, `Column`, `Button`, `List`, …) render on web, as do `expo-dom`, NativeWind/Tailwind, API routes, and plain React Native. The only thing that won't show on web is a *platform-specific* native tree (`@expo/ui/swift-ui` or `@expo/ui/jetpack-compose`), which renders blank there — and that blank is itself a useful signal, so it's still the user's call. Web runs via `snapshot-web.sh` (`expo start --web` + Playwright/Chromium) **regardless of the runner** (`expo run` is native-only; there's no web dev build), and it's the least-exercised path. Write the chosen set into each eval case's `runtime.platforms` and have `run_snapshots.py` loop them.
+
+**Confirm how `claude -p` subprocesses run — once, before starting.** Ask with `AskUserQuestion` whether they may run with `--dangerously-skip-permissions`, then apply the same answer to every subprocess this run (never re-prompt mid-run):
+
+- **Skip permissions (recommended)** — pass `--dangerously-skip-permissions`. Each subprocess runs unattended inside a throwaway fixture under `/private/tmp/expo-skill-eval-*` and can write files and run setup commands without prompting.
+- **Accept edits only** — pass `--permission-mode acceptEdits` instead. Bash/installs are auto-denied (no TTY), so some evals may produce partial output.
+
+A bare `claude -p` with neither flag can't write files at all. If the request already states a preference ("skip permissions", "don't use the dangerous flag"), skip the question.
+
+**Confirm how to deliver the results viewer — once, up front.** Publishing to claude.ai is outward-facing, so never do it mid-run by surprise; ask in the same up-front `AskUserQuestion` (alongside the permission flag):
+
+- **Local only (default)** — `generate_viewer.py` writes `viewer.html` and opens it in the local browser. Nothing leaves the machine.
+- **Publish a shareable Artifact** — additionally render the viewer to a claude.ai Artifact (a default-private web page the user can share with teammates) at the very end. Only do this if the user opts in here.
+
+If the request already says whether to share/publish, skip the question. See the **Viewer** section for the publish mechanics.
+
+## Eval case schema
+
+You generate the run's eval cases — one per chosen prompt — and write them to `<workspace>/iteration-N/evals.json` (the viewer reads them from there). Each case extends the standard skill-creator eval-case shape with a `runtime` block and visual expectations:
+
+```json
+{
+  "id": 1,
+  "prompt": "Build me a settings screen with a dark mode toggle and a list of options",
+  "expected_output": "Working Expo Router screen",
+  "expectations": [
+    "Uses Expo Router file-based routing",
+    "TypeScript compiles with no errors"
+  ],
+  "runtime": {
+    "mode": "expo-go",
+    "platforms": ["ios", "android"],
+    "sdk": "56"
+  },
+  "visual_expectations": [
+    "No red error screen or Expo Go error overlay on any platform",
+    "A settings screen with a visible toggle control is rendered"
+  ]
+}
+```
+
+- `runtime.mode`: how the eval runs after the static gate —
+  - `"expo-go"`: run in Expo Go (`expo start --<platform>`) and screenshot. Fast, JS-only. **Default.**
+  - `"dev-build"`: build a native dev client (`expo run:<platform>`) and screenshot. For skills whose output uses custom native code; much slower (native compile per fixture).
+  - `"static-only"`: stop after the static gate — for skills that produce no UI, or when you don't want to run a device at all (CI).
+
+  Consult `references/runtime-matrix.md` for which repo skills support which mode. (`dev-build` lets you actually run skills that previously had to be `static-only` for needing native code.)
+- `runtime.platforms`: subset of `ios`, `android`, `web` — chosen up front (always offered, not gated on the skill; see **Before starting**). Defaults to `["ios", "android"]`.
+- `runtime.sdk`: Expo SDK major for the fixture app — set it to the version chosen up front (see **Before starting — clarify scope**). Omit to use the latest template.
+- `reference_image` (optional — **image prompt**): absolute path to a **target screenshot** the skill must reproduce. When set, the executor is told to open it (via its Read tool) and build a matching app, and the grader scores how closely the generated app reproduces it (step 6) on top of the usual expectations. Set in the **Prompts** phase via "build from an uploaded screenshot."
+
+An image-prompt case is a normal case with `reference_image` set; enable "Runtime + screenshots" so the harness captures the result to compare against the target:
+
+```json
+{
+  "prompt": "Build an app whose UI matches the attached reference screenshot.",
+  "reference_image": "/abs/path/to/target.png",
+  "runtime": { "mode": "expo-go", "platforms": ["ios"], "sdk": "56" },
+  "visual_expectations": ["Matches the reference's layout, components, and color treatment"]
+}
+```
+
+## Pipeline per eval case
+
+**Orchestration model — on the main thread you run `python3 <orchestrator>` and almost nothing else.** Every phase is driven by a small Python orchestrator you `Write` into the workspace and run with `python3 /private/tmp/expo-skill-eval-<skill>/<phase>.py` (covered by the `python3` rule). The orchestrators are the **only** place the `scripts/*.sh` files are invoked — always via `subprocess.run(["bash", "<scripts>/<name>.sh", …])`, which runs as a child of `python3` and needs no rule of its own — and the only place parallelism, logging, and directory creation live. So on the main thread you only ever: **Write** orchestrators, **run** them with `python3`, **inspect** outputs with the `Read`/`Glob`/`Grep` tools, and **spawn the grader subagent**. Never put a command inside a chained/backgrounded/piped shell construct, and never run ad-hoc `mkdir`/`ls`/`cat`/`tail`/`echo` — that is what prompts. (A single standalone `bash …/scripts/<name>.sh …` is fine for one-off manual debugging, e.g. re-running one flaky snapshot, but the pipeline itself goes through the orchestrators.) **Run each orchestrator in the foreground** — let the tool call block until it finishes; the orchestrators already parallelize *within* a phase, so you don't need to overlap phases. Do **not** shell-background a phase with `… & echo "$!"` / `wait` (the `&`, `echo`, and `wait` segments have no rule and prompt). If you genuinely must run a phase while continuing other work, use the **Bash tool's `run_in_background` parameter** on a plain `python3 <orchestrator> 2>&1 | tee <ws>/…log` call — never hand-rolled shell `&`. **Expect exactly one permission prompt at the very start:** the first `Write` into the workspace. `allowed-tools` can suppress `Bash`/`Read` but not `Write`/`Edit`, so choose **"allow all edits in this directory for the session"** on that first prompt — it covers every orchestrator, `evals.json`, and viewer file for the whole run.
+
+### 0. Workspace setup
+
+Create the run's directory tree once, with the workspace script — **never with ad-hoc `mkdir`** (a raw `mkdir` prompts: there is no `mkdir` rule, and a `"$WORKSPACE/…"` variable can't match a path glob anyway):
+
+```bash
+bash /abs/path/expo-skill-eval/scripts/make-workspace.sh /private/tmp/expo-skill-eval-<skill> iteration-N <num-evals>
+```
+
+This creates `trigger-evals/scratch` and `iteration-N/eval-<i>/{with_skill,without_skill}/outputs` for every eval. It is covered by `Bash(bash *expo-skill-eval/scripts/*)`, and the `mkdir`s inside run as children of the script (no rule of their own). After this, every other directory is made by the scripts/orchestrators that need it (`make-fixture.sh`, the executor orchestrator's `os.makedirs`, the snapshot scripts) or by the `Write` tool auto-creating parents — so you never need another `mkdir`.
+
+### 1. Trigger eval (should-trigger only)
+
+Write a `run_trigger_eval_real.py` script under the workspace's `trigger-evals/` directory. Use **only `"should_trigger": true` queries** — the expo plugin is a family of complementary skills, so multiple skills triggering on the same prompt is not a failure. Measure recall only: realistic prompts that should use the skill, scored by trigger rate.
+
+The script should run `claude -p <query>` per query (with `--output-format=stream-json --verbose --include-partial-messages`, `CLAUDECODE` stripped from the env, and the permission flag confirmed up front in **Before starting — clarify scope**) and detect whether the target skill was triggered by watching for its `Skill` or `Read` tool call in the stream. Note: `--include-partial-messages` requires both `--output-format=stream-json` and `--verbose` — omitting either causes an immediate CLI error.
+
+**Load the skill under test — pass `--plugin-dir` to every trigger subprocess.** The trigger eval measures whether the skill's *description* makes the model reach for it, so the subprocess must have the **local** skill (the version with your edits) loaded. A `claude -p` subprocess does **not** inherit the parent session's `--plugin-dir`, so add it explicitly: `--plugin-dir <plugin-root>`, where `<plugin-root>` is the **absolute** path to the plugin directory that owns the skill — the `plugins/expo` ancestor containing `.claude-plugin/plugin.json` (e.g. `--plugin-dir /Users/.../skills/plugins/expo`). It must be absolute: the subprocess runs from the throwaway `scratch/` cwd, so a relative `plugins/expo` won't resolve — and a missing plugin dir silently loads nothing, which masquerades as a 0% trigger rate. Then watch for the skill triggering under its plugin-qualified name (`<plugin>:<skill>`, e.g. `expo:expo-ui`). Two caveats: (1) if the **published** `expo` plugin is also installed globally, disable it (via `/plugin`) for the run and re-enable after — otherwise two copies of `expo` collide in the subprocess and the model may trigger the *published* `expo:expo-ui`, silently scoring its description instead of your local edits (trigger detection only sees the tool-call name, so it can't tell the copies apart; dev checkouts usually don't have it installed). (2) Never make a synthetic duplicate of the skill — a real loaded copy always wins, so the synthetic harness scores 0%. (Executors are unaffected by an installed plugin: they read the local `SKILL_PATH` directly and pass no `--plugin-dir`.)
+
+Run each query's subprocess from an empty throwaway cwd (e.g. `trigger-evals/scratch/`), not the repo root. A should-trigger prompt like "build me a settings screen" can make the subprocess write files, and with `--dangerously-skip-permissions` those writes would otherwise land in the skills repo. Trigger detection only needs the skill's `Skill`/`Read` call to appear in the stream — it doesn't need a fixture — so any incidental writes are throwaway.
+
+Set a per-query subprocess timeout of at least **300 seconds**. A 180s limit is too short — some queries cause the model to start generating code before triggering the skill, which pushes total runtime past 3 minutes.
+
+Run trigger evals once per skill, not per code eval case.
+
+### 2. Fixture
+
+Each executor run gets a fresh Expo app, created by `scripts/make-fixture.sh <app-path> <sdk> [clean|full]`:
+
+```bash
+scripts/make-fixture.sh <workspace>/iteration-N/eval-X/<config>/app <sdk>          # blank app (default)
+scripts/make-fixture.sh <workspace>/iteration-N/eval-X/<config>/app <sdk> full     # keep example tabs
+```
+
+The script creates the app with `bunx create-expo-app -t default@sdk-<version>` (or the latest template when no version is given) once per SDK version + variant, caches it under `~/.cache/expo-skill-eval/fixtures/`, and clones the cache with APFS copy-on-write — so the first run per variant pays the install cost and every later run is near-instant. The default `clean` variant runs the template's `reset-project` script, so executors start from a blank app and every screen in the output is theirs — a much cleaner grading signal. Use `full` only when the eval prompt assumes an existing app (e.g. "I have an app with two tabs..."). The script also resets git inside the clone, so `git diff` in the app shows exactly what the executor changed (useful evidence for the grader).
+
+**Build fixtures sequentially, then fan out executors — never create fixtures concurrently.** `make-fixture.sh` shares a cache under `~/.cache/expo-skill-eval/fixtures/` keyed by SDK+variant. If two runs both find the cache cold and call `bunx create-expo-app` at the same time, bun's link step collides and one fails with `EEXIST` / "could not determine executable to run for package create-expo-app". So in the executor orchestrator (step 3), create **all** fixtures one at a time first — a plain Python loop calling `subprocess.run(["bash", "<scripts>/make-fixture.sh", app, sdk, variant])` (where `sdk` is the version chosen up front) — *then* fan out the `claude -p` executors with a `ThreadPoolExecutor`. Sequential creation is cheap: only the first fixture per SDK+variant pays the install cost; the rest are ~1s APFS clones. (And never fan fixtures out with ad-hoc shell like `make-fixture.sh A & make-fixture.sh B & wait` — the `&`/`wait` segments prompt; the sequential Python loop avoids both the race and the prompt.)
+
+### 3. Generate (executor subagents)
+
+Run executors as `claude -p` subprocess calls from a Python script, **not** via the `Agent` tool. The `Agent` tool spawns subagents with their own permission context — file edits inside the fixture app will prompt the user. A `claude -p` subprocess is a separate process outside the permission system entirely (the same pattern the trigger eval harness uses).
+
+Write a Python script to `/private/tmp/expo-skill-eval-<skill>/run_executors.py`. **First create every run's fixture in a sequential loop** — `subprocess.run(["bash", "<scripts>/make-fixture.sh", app, sdk, variant], …)` one at a time (concurrent creation races the shared bun cache — see step 2). **Then** run the with-skill and without-skill `claude -p` calls in parallel via a `ThreadPoolExecutor`. Both phases live inside Python (covered by the `python3` rule), so nothing runs as ad-hoc shell on the main thread. Each executor prompt must include:
+
+- The skill path (with-skill runs only) and the eval prompt.
+- **Image-prompt cases (`reference_image` set):** the absolute path to the target screenshot plus an instruction like "Open the reference screenshot at `<path>` with your Read tool and build an app whose UI matches it as closely as you can — layout, components, spacing, and colors." (`claude -p` renders PNGs read this way, so the executor can actually see the target.)
+- The fixture app path: "Make your changes inside `<app-path>`. The project already exists and has dependencies installed. Use absolute paths for all file operations."
+- "Before writing any files, inspect the project layout — run `ls`, read `package.json` and `app.json` — to find the correct routes directory. Recent SDK default templates place Expo Router routes in `src/app/`; older ones use `app/` at the project root — inspect to confirm which this fixture uses."
+- "Do NOT start the dev server, boot simulators, or take screenshots — the harness does that after you finish."
+- Where to save a short summary of what was built.
+
+Flags for the `claude -p` subprocess:
+- Strip `CLAUDECODE` from the environment (`env = {k: v for k, v in os.environ.items() if k != "CLAUDECODE"}`) — otherwise `claude -p` hangs silently when nested inside a running Claude Code session.
+- A permission flag, confirmed with the user up front (see **Before starting — clarify scope**): either `--dangerously-skip-permissions` or `--permission-mode acceptEdits`. Bake the chosen flag into the generated script. A bare `claude -p` with neither flag can't write files — it has no TTY to approve the edit and emits code as text instead.
+- **Do NOT pass `--plugin-dir` to executors** (unlike the trigger eval). The with-skill run already reads the skill by its absolute `SKILL_PATH`, so it tests the local content directly; and the without-skill run must have **no** skill available at all — loading the plugin would let the skill auto-trigger and contaminate the baseline. Keeping executors path-based also cleanly separates the two questions: the executor measures *content quality* (is the skill useful once read?), the trigger eval measures *triggering* (does the description get it picked?).
+
+Capture stdout/stderr per run to a log file next to the fixture for grading evidence. Set timeout to 900s per executor — with-skill runs read multiple reference files before coding and regularly take 5–10 minutes.
+
+### 4. Static gate
+
+Write `run_static.py` and run it with `python3`. For each eval/config app it calls `subprocess.run(["bash", "<scripts>/check-static.sh", app, "ios,android"], capture_output=True, …)` across a `ThreadPoolExecutor` (static gates are independent — run them concurrently *inside Python*, never with shell `&`/`wait`), and writes each result to `eval-<i>/<config>/static.json` (exit code + captured output) for the grader.
+
+`check-static.sh` runs `tsc --noEmit`, `expo lint`, and `expo export` for the listed platforms. A passing export catches most import/syntax/missing-module failures without touching a device; a failing export short-circuits step 5 with a clean FAIL — record it and have the snapshot orchestrator skip that app.
+
+### 5. Run + screenshot (serial across evals)
+
+Write `run_snapshots.py` and run it with `python3`. Simulators and emulators are shared resources, so this orchestrator runs **serially** (no thread pool): for each app that passed the static gate, and each platform, it `os.makedirs` the `outputs/` dir and calls `subprocess.run(["bash", "<scripts>/snapshot-<platform>.sh", app, f"{outputs}/<platform>.png", port], env={**os.environ, "EXPO_SKILL_EVAL_RUNNER": runner}, …)`. Pass the port as a positional argument: use `8081` for iOS and `8082` for Android — `expo run:ios/android --port N` is supported and using separate ports lets you run both platforms without port collisions if you ever parallelize. Screenshots land in the run's `outputs/` directory so the viewer renders them inline.
+
+**Reclaim disk after each fixture — essential for `dev-build` runs.** Once all selected platforms for an app are captured (and *before* the next fixture builds), call `subprocess.run(["bash", "<scripts>/clean-fixture.sh", app])`. Each `expo run:<platform>` leaves multi-GB native build output (iOS Pods + DerivedData, Android Gradle build); without this, evals × configs × iterations pile up and fill the disk mid-run (the instability you'll see is the disk filling). `clean-fixture.sh` removes the heavy regenerable dirs (`node_modules`, `ios`, `android`, `.expo`, `dist`) and the fixture's iOS DerivedData, keeping the app source + git so the grader's `git diff` still works. With serial snapshots + per-fixture cleanup, peak disk stays at ~one fixture's build instead of all of them. (Harmless for `expo-go` runs too — they just have little to reclaim.)
+
+`runner` is the up-front choice (`expo-go` default, or `dev-build`). The snapshot scripts honor `EXPO_SKILL_EVAL_RUNNER`: `expo-go` launches with `expo start --<platform>` (and the Expo Go install/deep-link dance); `dev-build` launches with `expo run:<platform> --port <port>`, which compiles+installs a native dev client and skips the Expo Go steps. The scripts already default the `dev-build` timeout to 900s, but bump `EXPO_SKILL_EVAL_BUNDLE_TIMEOUT` higher if the first native compile needs it. `make-fixture.sh` pre-installs `expo-dev-client` in every fixture so the dev-client URL scheme is registered before `expo run` tries to deep-link the app open.
+
+**Snapshot scripts always capture the initial route `/`.** They open the app via a deep link and take one screenshot — they cannot tap or navigate. Design eval prompts so the feature under test renders at the root route. If the executor places the main UI behind a navigation action (e.g. an "Open Settings" button on the index), the snapshot will miss the feature entirely and all visual expectations will fail.
+
+Each `snapshot-<platform>.sh` **frees its Metro port on startup** (kills any stale process left on it by a crashed prior run) and tears Metro down on exit — so you never need to run `lsof`/`kill`/`pkill` yourself to clear ports (that would prompt, and it's already handled). It then starts Metro, waits for the "Bundled" line in the Metro log, settles, captures a screenshot, and tears Metro down. iOS boots the newest available iPhone simulator if none is booted; Android boots the first AVD if no device is attached (the slow path — boot once and reuse across the whole iteration). Android first **recycles a wedged/`offline` emulator** (graceful `adb emu kill`, then force-kill + adb reset) so a half-dead instance can't poison the run, and boots with **hardware GPU** (`-gpu host`, Metal-accelerated on Apple Silicon). If `host` self-aborts the emulator on a given machine (qemu `SIGABRT` deep in gfxstream/Metal — possible on Apple Silicon under load), edit `GPU_MODE` in `snapshot-android.sh` to a software mode (`guest` renders reliably but slowly — bump the settle; avoid `swiftshader_indirect`, which **hangs at boot** on arm64). `snapshot-web.sh` runs only when `platforms` includes web. Each script writes a Metro log next to the screenshot (`<name>.metro.log`) — include it in the grader's inputs. If a script exits non-zero it still attempts a best-effort screenshot (an error screen is evidence too). **dev-build relaunch:** after Metro is up, the scripts relaunch the app via `xcrun simctl launch` (iOS) and `adb shell am start -n <pkg>/.MainActivity` (Android) — both avoid the "Open in X?" system dialog that a URL-scheme deep link triggers on first launch.
+
+After all screenshots for the iteration are captured, always generate the viewer — pass the workspace root to the checked-in script:
+
+```bash
+python3 /abs/path/expo-skill-eval/scripts/generate_viewer.py /private/tmp/expo-skill-eval-<skill>
+```
+
+It writes `viewer.html` into the workspace root (one level above `iteration-N/`) and opens it in the browser itself (via `webbrowser.open`) — so no separate `open` command (and no `Bash(open:*)` rule) is needed. See the **Viewer** section below.
+
+### 6. Grade
+
+Spawn a grader subagent in the foreground. Its prompt must include:
+
+- The eval prompt, expectations list, and visual_expectations from the eval case.
+- The instructions in `agents/visual-grader.md` (screenshot grading, redbox detection).
+- The screenshot files, Metro logs, and the step-4 `static.json` as inputs.
+- **Image-prompt cases** (case has `reference_image`): also include the **target screenshot** (`reference_image`), `references/design-rubric.md`, and the fixture's `git diff`. Tell the grader to compare the generated screenshot(s) to the target and emit the `reference_match` + `quality` blocks below.
+
+The grader writes `grading.json` next to the outputs with this shape:
+```json
+{
+  "score": 8.5,
+  "max_score": 9,
+  "expectations": [
+    {"text": "...", "passed": true, "evidence": "..."}
+  ],
+  "reference_match": {
+    "score": 7, "max": 10,
+    "evidence": "ios.png vs target.png: same two-section grouped list + toggle; accent color differs (blue vs target's green); row spacing tighter than target"
+  },
+  "quality": {
+    "dimensions": [
+      {"name": "Layout & hierarchy", "score": 2, "max": 3, "evidence": "ios.png: …"}
+    ],
+    "subtotal": 17,
+    "max": 24,
+    "summary": "…"
+  },
+  "user_notes_summary": {"needs_review": false, "notes": ""}
+}
+```
+Visual expectations go into the same `expectations` array with evidence naming the screenshot file and describing what is visible. The `reference_match` block (how closely the generated app reproduces the target screenshot) and the `quality` block (design-rubric scores from `references/design-rubric.md`) are emitted **only for image-prompt cases** — or when a quality grade is explicitly requested. Omit both for plain text-prompt runs.
+
+## Rollout phases
+
+Build out and debug the pipeline in this order — each phase is independently useful:
+
+1. **Static**: steps 1–4 only (`runtime.mode: "static-only"` for everything). No devices needed; CI-friendly.
+2. **iOS**: add `snapshot-ios.sh` to the loop. `simctl` is the most scriptable target.
+3. **Android**: add `snapshot-android.sh`. Emulator boot is the slowest part — keep one emulator running for the whole session.
+4. **Web**: add `snapshot-web.sh` for skills that target web (uses Playwright via `bunx`; first run downloads Chromium).
+
+## Practical notes
+
+- **Temp locations**: all eval workspaces go under `/private/tmp/expo-skill-eval-<skill-name>/iteration-N/`. Everything in this run — `Read`, `Write`, `Edit`, and `Bash` — is covered by the `allowed-tools` frontmatter, so a correctly-loaded skill runs prompt-free.
+- **Permission rule forms (why this skill stays prompt-free)**: the rule *syntax* matters and the two tool families behave differently:
+  - **`Bash(...)` rules — path-scoped to the skill's own code (no broad interpreters).** `Bash(python3 /private/tmp/expo-skill-eval-*)` (plus the `/tmp` alias) runs the Python orchestrators you generate under the workspace; `Bash(python3 *expo-skill-eval/scripts/*)` runs the checked-in `scripts/generate_viewer.py`; `Bash(tee /private/tmp/expo-skill-eval-*)` (+ `/tmp`) lets `python3 … 2>&1 | tee <workspace>/…log` write a log without prompting; `Bash(bash *expo-skill-eval/scripts/*)` runs only this skill's `scripts/*.sh`. Because every path is pinned, the escape hatches stay denied: `python3 -c …`, `bash -c …`, `tee /etc/…`, and running code anywhere else do **not** match (verified empirically — a scoped rule allows `bash <dir>/run.sh` but blocks `bash -c …` and any other path). Commands the scripts call internally — `bunx`, `xcrun simctl`, `adb`, `git`, `mkdir`, `expo` — are children of the script, not Bash tool calls, so they need no rule. Do **not** run ad-hoc `mkdir`/`ls`/`find`/`cat`/`grep` from the main thread (they have no rule and prompt — and a raw `mkdir "$WORKSPACE/…"` can't match a path glob because the path is an unexpanded variable): create the directory tree with `make-workspace.sh` (step 0), let orchestrators create their own dirs (`os.makedirs`), and **inspect results with the `Read`/`Glob`/`Grep` tools** (no Bash rule needed).
+  - **Bash rule matching (tested, non-obvious):** a Bash rule is a gitignore-style glob over the command string. `*` matches any run of characters **including `/` and spaces** and works **mid-pattern** — so `Bash(python3 /private/tmp/expo-skill-eval-*)` matches `python3 /private/tmp/expo-skill-eval-x/run.py 2>&1`, and `Bash(bash *expo-skill-eval/scripts/*)` matches `bash /any/abs/path/expo-skill-eval/scripts/foo.sh args`. Two gotchas that burned earlier attempts: `**` is matched **literally** (never use it in a Bash rule), and the `:*` suffix only works right after the command token (`Bash(python3:*)`) — **not** after a partial path (`Bash(python3 /path-:*)` does not match). Compound commands split on `|`, `&&`, `||`, `;`, `&` and each segment needs its own matching rule.
+  - **`Read` rules suppress prompts; `Write`/`Edit` rules do *not*.** This is a Claude Code asymmetry (not a pattern bug, and not reload — in a session where the `Bash`/`Read` rules from this same frontmatter are clearly working, `Write` still prompts): file creation/editing always goes through Claude Code's edit-approval flow regardless of `allowed-tools`. The frontmatter still scopes `Read`/`Write`/`Edit` to `…/expo-skill-eval-*/**` (both the `/tmp` and `/private/tmp` forms, since macOS doesn't auto-resolve the symlink) as documentation and a guardrail, but those `Write`/`Edit` entries won't silence the prompt on their own. **Practical consequence:** at the start of a run you get **one** Write prompt for the workspace — choose **"Yes, allow all edits in this directory for the session"** and every later orchestrator / `evals.json` / viewer write under that workspace goes through silently. That single directory approval, not a rule, is what makes file-writing prompt-free.
+  - **Reload after editing frontmatter — a full restart, not `/reload-skills`.** `allowed-tools` is read once when the skill loads at session start; `/reload-skills` reloads the skill *body* but does **not** reliably refresh the permission rules. After editing this file, **quit Claude Code entirely and start a new session**, then re-run the skill — otherwise a stale (cached) ruleset keeps prompting even though the file on disk is correct.
+  - **Grader subagents** run with their own permission context and will still prompt for file access — that is expected and separate from the main thread's rules.
+- **Calling eval scripts — one standalone command, never chained.** Invoke each script as its own Bash call with an absolute path: `bash /abs/path/expo-skill-eval/scripts/snapshot-ios.sh arg1 arg2` (covered by `Bash(bash *expo-skill-eval/scripts/*)`). Do **not** combine it with `&`, `&&`, `||`, `;`, `wait`, `tail`, `head`, or `echo` — compound commands are checked per segment, and those extra segments have no rule, so the whole thing prompts even though the `bash …/scripts/…` part is allowed. (The one allowed pipe is `… 2>&1 | tee <workspace>/…log`, since the scoped `tee` rule covers it.) Need parallelism or output trimming? Put it in a Python orchestrator (covered by `python3 /…/expo-skill-eval-*`), which runs scripts via `subprocess` across a `ThreadPoolExecutor`. Inspect results with the `Read`/`Glob`/`Grep` tools, not `cat`/`ls`/`grep`. **General rule: under this skill's tight scoping, any ad-hoc shell the agent improvises will prompt — the fix is to move it into a script/orchestrator (or use the scoped `tee`), never to broaden a rule.**
+- **Inspecting outputs (screenshots, logs, files) — use tools, not shell.** To find files use the **Glob** tool (e.g. `/private/tmp/expo-skill-eval-<skill>/iteration-N/**/ios.png`); to view them use the **Read** tool — Read renders PNGs visually, which is exactly what you need to confirm a screenshot rendered. To search file contents use **Grep**. Never use `find`/`ls`/`cat` for this: they prompt, and `find … -exec …` is deliberately *not* allowed because its `-exec` can run anything (e.g. `-exec rm`). These tools are scoped and prompt-free; reach for them every time you'd otherwise type `find`/`ls`/`cat`.
+- **Generated Python scripts**: write orchestration/aggregation scripts under the workspace (e.g. `/private/tmp/expo-skill-eval-<skill>/aggregate.py`) and run them with `python3` (covered by `Bash(python3 /private/tmp/expo-skill-eval-*)`). The viewer is the exception — it's the checked-in `scripts/generate_viewer.py`, run via `Bash(python3 *expo-skill-eval/scripts/*)`. `Write` auto-creates parent dirs but prompts the first time — approve the workspace directory once (see the `Write`/`Edit` note above). Capture output either by having the script write its own log or via `python3 … 2>&1 | tee <workspace>/…log` (covered by the scoped `tee` rule); read logs back with the `Read` tool. Don't use `python3 -c …` for setup (the scoped rule only matches a workspace script *path*, so a bare `-c` prompts).
+
+- **Trigger evals vs installed plugin**: detect the real installed skill name (e.g. `expo:expo-ui`) in the stream — a synthetic-duplicate harness always scores 0% when the real plugin is installed because the model picks the genuine skill over the synthetic copy.
+- **Benchmark aggregation**: save each run's `grading.json` + `timing.json` under `eval-<N>/<config>/run-1/`. Write a Python aggregation script under the workspace and run it with `python3`.
+- **Expo Go ceiling**: anything requiring custom native code (expo-module, App Clips, brownfield) cannot run in Expo Go. Use `static-only` mode for those — see `references/runtime-matrix.md` before writing eval cases for a skill (note: `@expo/ui` *does* run in Expo Go on SDK 56+).
+- **API-route skills**: instead of a screenshot, verify with `curl` against the route while Metro is up; record the response as an output file for grading.
+- **Timing data**: capture token counts and duration into `timing.json` immediately after each executor run — it is not recoverable later. To capture token counts, add `--output-format=stream-json --verbose` to the executor `claude -p` call and parse the `message_start` / `message_delta` events from the log. Without these flags the log only contains prose and elapsed seconds are the only recoverable metric.
+- **First-launch dialogs**: Expo Go occasionally shows a one-time prompt on a fresh simulator. If a screenshot captures a dialog instead of the app, re-run the snapshot script (it reopens the URL) and re-capture.
+
+## Viewer
+
+After taking screenshots, always generate and open the HTML viewer so the user can see results immediately without being asked. The viewer is the checked-in `scripts/generate_viewer.py` — run it with the workspace root as its argument:
+
+```bash
+python3 /abs/path/expo-skill-eval/scripts/generate_viewer.py /private/tmp/expo-skill-eval-<skill>
+```
+
+It writes a self-contained `/private/tmp/expo-skill-eval-<skill>/viewer.html` and opens it in the browser itself (`webbrowser.open`). What it renders:
+- A tab per iteration (`iteration-*` under the workspace root; remembers the last active tab in `localStorage`).
+- For each eval case (read from `<iteration>/evals.json`): side-by-side with_skill / without_skill columns, each showing static-gate status, score, the platform screenshots (click to zoom; embedded as base64 `data:` URIs so the file is self-contained), the expectation list with PASS/FAIL badges, and reviewer notes.
+- For **image-prompt cases** (a `grading.json` with `reference_match` / `quality`): the **target screenshot** beside the generated ones, the `reference_match` score (generated vs target), the `quality` rubric per config (one bar per dimension with its score/max plus the subtotal), and the **quality delta** (with_skill − without_skill subtotal) in the summary bar alongside the correctness delta.
+- A summary bar with with_skill %, without_skill %, and delta.
+- A trigger accuracy table when `trigger-evals/trigger_results.json` exists.
+- A dark background with color-coded scores (green ≥85%, amber ≥65%, red below).
+
+### Publishing the viewer (only if opted in up front)
+
+The local `viewer.html` is always generated. **Only when the user chose "Publish a shareable Artifact"** in the up-front confirmation, additionally render it to a claude.ai Artifact at the very end — never publish without that opt-in (it's outward-facing and a published page can be cached/indexed). Mechanics:
+
+- The `Artifact` tool wraps the file in its own `<!doctype html>…<head></head><body>` skeleton, so the file you hand it must be **page content only** — inline `<style>`/`<script>`, base64 `data:` images, and a `<title>`, but **no** `<!DOCTYPE>/<html>/<head>/<body>` tags of its own (a full standalone document gets double-wrapped and renders wrong).
+- The script emits an Artifact-friendly variant when you add `--artifact`: `python3 /abs/path/expo-skill-eval/scripts/generate_viewer.py /private/tmp/expo-skill-eval-<skill> --artifact` writes `viewer_artifact.html` (same content, skeleton stripped, no browser open). Pass that file to the `Artifact` tool (`favicon: "📊"`), not the standalone one.
+- The viewer is already self-contained (base64 screenshots, inline CSS/JS), so it satisfies the Artifact CSP (no external hosts).
+
+## References
+
+- `references/runtime-matrix.md` — per-skill runtime applicability (expo-go vs static-only, platform notes).
+- `agents/visual-grader.md` — screenshot grading instructions for the grader subagent.
diff --git a/.agents/skills/expo-skill-eval/agents/visual-grader.md b/.agents/skills/expo-skill-eval/agents/visual-grader.md
new file mode 100644
index 0000000..db2a10a
--- /dev/null
+++ b/.agents/skills/expo-skill-eval/agents/visual-grader.md
@@ -0,0 +1,52 @@
+# Visual Grader Instructions
+
+Grading instructions for an eval run that produced device/web screenshots. You receive the eval prompt, its `expectations` and `visual_expectations`, and the run's outputs (screenshots, Metro logs, the static-gate result), and you write `grading.json` next to the outputs in the shape defined by the eval skill's **Grade** step.
+
+Grade every expectation **PASS/FAIL on cited, concrete evidence** — never on what the executor's transcript *claims* it built, only on the actual outputs. Quote or name the evidence for each verdict. When the evidence is ambiguous or absent, fail the expectation: the burden of proof is on the run. The sections below add the screenshot-specific process on top of that.
+
+## Extra inputs
+
+- `outputs/<platform>.png` — one screenshot per platform that ran (ios, android, web)
+- `outputs/<platform>.metro.log` — the Metro/dev-server log for that platform
+- The static gate output (`[PASS]/[FAIL]` lines from `check-static.sh`)
+
+## Process additions
+
+1. **Read every screenshot with the Read tool.** Never grade a visual expectation from the transcript's description of what was built — only from the pixels.
+
+2. **Check failure signatures first**, on every screenshot, regardless of the listed expectations:
+   - A red error screen / redbox, or Expo Go's "Something went wrong" page
+   - The Expo Go home/project-list screen (the app never opened)
+   - A blank white or black screen (bundle loaded but nothing rendered)
+   - A system permission dialog or Expo Go first-launch prompt covering the app
+   If any of these appear, every visual expectation for that platform fails, with the signature as evidence. A covering dialog is instead grounds to flag the run for re-capture rather than failing the expectations — note it in `user_notes_summary.needs_review`.
+
+3. **Cross-check with the Metro log.** Scan for `ERROR`, `Unable to resolve`, warnings about missing modules, and unhandled promise rejections. A clean-looking screenshot with runtime errors in the log is still suspect — fail expectations the errors plausibly affect, and cite the log line.
+
+4. **Grade each visual expectation per platform.** If `runtime.platforms` lists ios and android, an expectation like "a settings toggle is visible" must hold on **both** screenshots to pass. Evidence must name the screenshot file and describe what is actually visible, e.g. `ios.png: tab bar with Home/Explore tabs at bottom, toggle rendered in the first list row`.
+
+5. **Static gate is upstream of visuals.** If `check-static.sh` failed and the device stage was skipped, mark all visual expectations failed with evidence pointing at the failed gate's log, and do not speculate about what would have rendered.
+
+## Judgment calibration
+
+- Platform-appropriate rendering differences (status bar, fonts, safe areas, scroll bar styling) are not failures.
+- Be strict about the substance of the expectation: "tab bar with 3 tabs" means exactly three visible tabs, not "some tab bar exists".
+- When a screenshot is ambiguous (mid-animation, partially loaded), say so in the evidence and fail the expectation — the burden of proof is on the run, and the harness can re-capture with a longer settle.
+
+## Image-prompt cases (`reference_image` present in the eval case)
+
+When the case has a `reference_image`, the prompt was "build an app matching this target screenshot," so grade **fidelity to the target** on top of the usual expectations:
+
+1. **Read the target with the Read tool**, then read each generated screenshot, and compare them directly. Score `reference_match` (0–10): how faithfully the generated app reproduces the target's layout, component set, grouping, typography, spacing, and color treatment. Evidence must name both files and call out concrete matches and divergences, e.g. `ios.png vs target.png: same grouped list + header, but accent is blue not green and the avatar is square not round`.
+2. **Apply `references/design-rubric.md`** for absolute quality, plus the code-quality dimension from the fixture's `git diff`; emit it as the `quality` block.
+3. **Failure signatures still cap the score.** A redbox, blank screen, or wrong-screen capture means `reference_match` is 0 for that platform (evidence: the signature) — a crashed app reproduces nothing.
+4. **Per platform, take the worst** when the case ran more than one platform (as in the rubric).
+5. **Emit both blocks** in `grading.json` — `reference_match` and `quality` — alongside `expectations`; they're additive, so keep the `expectations`/`visual_expectations` grading as before.
+   ```json
+   "reference_match": {"score": 7, "max": 10, "evidence": "ios.png vs target.png: …"},
+   "quality": {
+     "dimensions": [{"name": "Layout & hierarchy", "score": 2, "max": 3, "evidence": "ios.png: …"}],
+     "subtotal": 17, "max": 24, "summary": "one-line overall read"
+   }
+   ```
+   `quality.subtotal` is the sum of dimension scores; `quality.max` is the sum of their maxes (24 for the built-ins).
diff --git a/.agents/skills/expo-skill-eval/references/design-rubric.md b/.agents/skills/expo-skill-eval/references/design-rubric.md
new file mode 100644
index 0000000..9f688ff
--- /dev/null
+++ b/.agents/skills/expo-skill-eval/references/design-rubric.md
@@ -0,0 +1,45 @@
+# Design-quality rubric
+
+Applied by the grader when scoring an app's visual quality — primarily for **image-prompt cases** (`reference_image`), and any time a quality grade is requested — on top of the pass/fail expectations, not instead of them. It answers "how *good* is this app?", scored from the captured screenshots and the implementation diff. Combine it with the failure-signature checks in `agents/visual-grader.md`: a redbox, blank screen, or wrong-screen capture caps every visual dimension at 0 for that platform regardless of intent.
+
+## How to score
+
+- **Judge visuals only from the pixels.** Read every screenshot with the Read tool; never infer a visual score from the transcript or from what the code *intended* to render.
+- **Grade per platform, then take the worst.** If the case ran ios + android, a dimension's score is the lower of the two — unless the gap is a legitimate platform difference (see *Platform conventions*).
+- Each dimension is **0–3**. The seven visual dimensions sum to a max of 21; with the code-quality dimension (also 0–3) the built-in rubric max is **24**.
+- If a config/platform screenshot is **missing**, score only the platforms present, note the gap, and do **not** penalize for the absence.
+- Cite concrete evidence per dimension, naming the file: e.g. `ios.png: 16px gutters, consistent 12px row spacing, large-title nav bar`.
+
+### Score anchors (apply to every dimension)
+
+- **0** — broken/absent: the dimension fails outright (overlapping or clipped text, unreadable contrast, no hierarchy, content off-screen).
+- **1** — below bar: present but with clear problems a designer would reject.
+- **2** — solid: clean and conventional, no notable problems; what a competent dev ships.
+- **3** — polished: deliberate and refined; App-Store quality for this dimension.
+
+## Visual dimensions
+
+1. **Layout & hierarchy** — clear primary/secondary structure, alignment, logical grouping, balanced composition; nothing clipped or pushed off-screen.
+2. **Spacing & density** — consistent padding/margins and vertical rhythm; not cramped, not sparse; respects safe areas, the notch, and the home indicator.
+3. **Typography** — readable sizes, a sensible type scale (title vs body vs caption), consistent weights, no truncation/overflow/orphaned text.
+4. **Color & contrast** — coherent, limited palette; sufficient text/background contrast for legibility; sensible light/dark handling.
+5. **Platform conventions** — feels native to the platform it's shown on:
+   - **iOS** — large titles / nav bars, grouped/inset lists, SF-style controls, standard tab bars, system spacing.
+   - **Android** — Material surfaces, app bar, FAB where appropriate, ripple/elevation cues, Material controls.
+   - **web** — sensible responsive layout, real cursor/hover affordances, no mobile-only chrome stranded on a wide canvas.
+   A genuine platform difference (status bar, system fonts, control styling, safe areas) is **not** a defect; shipping an iOS-only pattern verbatim on Android **is**.
+6. **Polish & states** — pixel alignment, crisp icons/images at the correct density, no stray debug text or placeholder lorem, sensible empty/loading states where the screen implies them.
+7. **Visual accessibility** — tap targets look ≥44pt, text isn't clipped at default scale, contrast meets a rough WCAG-AA bar, interactive elements are visually distinguishable from static content.
+
+## Code-quality dimension (0–3, from the diff)
+
+Scored from the fixture's `git diff`, not the screenshots:
+
+- Idiomatic Expo/RN: correct import paths and current APIs (e.g. the `@expo/ui` `Host` wrapper, Expo Router file conventions), no deprecated patterns.
+- Reasonable structure: componentized where it helps, no copy-paste duplication, styles organized (not a wall of inline objects), TypeScript types where the template uses them.
+- No dead code, leftover `console.log` noise, or unused scaffolding left from the template.
+- Anchors: **0** broken/anti-patterns, **1** works but messy, **2** clean and idiomatic, **3** exemplary.
+
+## Extra criteria
+
+If the eval case lists `visual_expectations`, grade each as an **additional 0–3 dimension** with the same anchors, appended to the `dimensions` array and folded into `subtotal`/`max` (`max` grows by 3 per extra criterion). Cite evidence for each just like the built-ins.
diff --git a/.agents/skills/expo-skill-eval/references/runtime-matrix.md b/.agents/skills/expo-skill-eval/references/runtime-matrix.md
new file mode 100644
index 0000000..752569a
--- /dev/null
+++ b/.agents/skills/expo-skill-eval/references/runtime-matrix.md
@@ -0,0 +1,34 @@
+# Runtime applicability matrix
+
+Which `plugins/expo/skills/*` skills can be evaluated at which level. Consult this before writing eval cases — putting `runtime.mode: "expo-go"` on a skill that needs custom native code wastes a device cycle and produces a misleading FAIL.
+
+Modes:
+
+- **expo-go** — generated code runs in Expo Go on simulator/emulator; screenshot grading applies.
+- **static-only** — stop after the static gate (`tsc` / lint / `expo export`). Used when the output needs custom native code, a dev build, or produces no UI at all.
+- **n/a** — the skill's output is not app code (config, CI YAML, CLI workflows); code evals don't apply, or apply only as file-content assertions without a fixture app.
+
+| Skill | Mode | Platforms | Notes |
+|-------|------|-----------|-------|
+| expo-router | expo-go | ios, android | Navigation/routing target: routes, links, native stacks, modals, sheets, headers. Native tabs sections may need a dev build — verify per case. |
+| expo-native-ui | expo-go | ios, android | Core target for visual evals. RN primitives + styling/controls/media/animations all work in Expo Go. |
+| expo-tailwind-setup | expo-go | ios, android, web | NativeWind v5 / react-native-css are JS-level; works in Expo Go. Good web candidate too. |
+| expo-data-fetching | expo-go | ios, android | Fetch/React Query/SWR are pure JS. Mock or use stable public endpoints so evals are deterministic. |
+| expo-dom | expo-go | ios, android, web | DOM components run in a webview on native (Expo Go, SDK 52+) and as-is on web. Allow extra settle time for the webview to paint. |
+| eas-hosting | static-only + HTTP | — | No screenshot: while Metro runs, `curl` the route and save the response as an output file for grading. |
+| expo-ui (merged swift-ui + jetpack-compose) | expo-go | ios, android, web | `@expo/ui` ships in the SDK 56 default template (~56.0.17) and its native code is included in Expo Go 56 — verified rendering 2026-06: a SwiftUI Form renders in Expo Go on the iOS simulator. The **universal** components (`Host`, `Row`, `Column`, `Button`, `List`, …) also render on **web**; only the platform-specific `@expo/ui/swift-ui` (SwiftUI) and `@expo/ui/jetpack-compose` (Compose) trees are native-only and render blank on web. Pick platforms by what the eval case uses. |
+| expo-module | static-only | — | Custom native modules can't load in Expo Go. Gate on TS compile of the module API; native compilation (prebuild + xcodebuild/gradle) is possible but expensive — out of scope for now. |
+| expo-app-clip | static-only | — | App Clip targets require prebuild + Xcode. Assert on config-plugin output instead. |
+| expo-brownfield | static-only | — | Brownfield integration has no Expo Go story. Assert on generated integration files. |
+| expo-dev-client | n/a | — | Output is build/distribution workflow, not renderable app code. |
+| eas-app-stores | n/a | — | Deployment guidance; assert on transcript/config content only. |
+| eas-workflows | n/a | — | Output is `.eas/workflows/` YAML; assert on YAML content (and `workflow_validate` via the Expo MCP if available). |
+| expo-upgrade | static-only | — | An upgrade eval can run the static gate on the upgraded fixture — a strong signal. Needs a fixture pinned to an *older* SDK (pass e.g. `55` to make-fixture.sh). |
+| eas-update-insights | n/a | — | CLI/metrics interpretation; no app code output. |
+| eas-observe | expo-go (verify) | ios, android | `expo-observe` instrumentation is JS-level, but confirm the package works in Expo Go before relying on screenshots; fall back to static-only. |
+
+Entries marked "verify" haven't been validated against a real run yet — confirm on first use and update this table.
+
+## Image-prompt (clone-this) candidates
+
+Image prompts (`reference_image` — build an app to match a target screenshot, graded by `reference_match` + `references/design-rubric.md`) are most informative for the **visual** skills — `expo-router`, `expo-ui`, `expo-tailwind-setup`, `expo-dom` — where reproducing a specific UI is the point. Pair them with "Runtime + screenshots" so the harness captures the generated app to compare against the target. They add nothing for `n/a` skills (no app UI).
diff --git a/.agents/skills/expo-skill-eval/scripts/check-static.sh b/.agents/skills/expo-skill-eval/scripts/check-static.sh
new file mode 100755
index 0000000..bd087ab
--- /dev/null
+++ b/.agents/skills/expo-skill-eval/scripts/check-static.sh
@@ -0,0 +1,64 @@
+#!/usr/bin/env bash
+# Static gate for a generated Expo app: typecheck, lint, bundle.
+#
+# Usage: check-static.sh <project-path> [platforms-csv]
+#   platforms-csv  Platforms to bundle-check with `expo export`,
+#                  e.g. "ios,android" (default) or "ios,android,web".
+#
+# Prints [PASS]/[FAIL] per gate and exits non-zero if any gate fails.
+# A passing export catches most import/syntax/missing-module errors
+# without needing a device.
+set -uo pipefail
+
+PROJECT_PATH="${1:?usage: check-static.sh <project-path> [platforms-csv]}"
+PLATFORMS="${2:-ios,android}"
+
+cd "$PROJECT_PATH"
+FAILED=0
+LOG_DIR=".eval-static"
+mkdir -p "$LOG_DIR"
+
+run_gate() {
+  local name="$1"
+  shift
+  if "$@" >"$LOG_DIR/$name.log" 2>&1; then
+    echo "[PASS] $name"
+  else
+    echo "[FAIL] $name (log: $PROJECT_PATH/$LOG_DIR/$name.log)"
+    tail -20 "$LOG_DIR/$name.log" | sed 's/^/        /'
+    FAILED=1
+  fi
+}
+
+run_gate tsc bunx tsc --noEmit
+
+# Lint only files changed since the fixture commit - the pristine template has
+# pre-existing lint errors that aren't the executor's fault. Falls back to a
+# full `expo lint` when the project isn't a git repo.
+if git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
+  CHANGED_FILES=()
+  while IFS= read -r f; do
+    [[ -f "$f" ]] && CHANGED_FILES+=("$f")
+  done < <(
+    {
+      git diff --name-only HEAD -- '*.ts' '*.tsx' '*.js' '*.jsx'
+      git ls-files --others --exclude-standard -- '*.ts' '*.tsx' '*.js' '*.jsx'
+    } | sort -u
+  )
+  if ((${#CHANGED_FILES[@]})); then
+    run_gate lint env CI=1 bunx eslint "${CHANGED_FILES[@]}"
+  else
+    echo "[SKIP] lint (no changed JS/TS files)"
+  fi
+else
+  run_gate lint env CI=1 bunx expo lint
+fi
+
+EXPORT_ARGS=(export --output-dir "$LOG_DIR/export")
+IFS=',' read -ra PLATFORM_LIST <<<"$PLATFORMS"
+for p in "${PLATFORM_LIST[@]}"; do
+  EXPORT_ARGS+=(--platform "$p")
+done
+run_gate export env CI=1 bunx expo "${EXPORT_ARGS[@]}"
+
+exit "$FAILED"
diff --git a/.agents/skills/expo-skill-eval/scripts/clean-fixture.sh b/.agents/skills/expo-skill-eval/scripts/clean-fixture.sh
new file mode 100755
index 0000000..0bfb962
--- /dev/null
+++ b/.agents/skills/expo-skill-eval/scripts/clean-fixture.sh
@@ -0,0 +1,56 @@
+#!/usr/bin/env bash
+# Reclaim disk after a fixture's screenshots are captured. Essential for
+# dev-build runs, where each `expo run:<platform>` leaves multi-GB native build
+# output (iOS Pods + DerivedData, Android Gradle build). Removes the heavy,
+# regenerable artifacts and keeps the app source + git history, so the grader's
+# `git diff` still works.
+#
+# Usage: clean-fixture.sh <project-path>
+#
+# Env: EXPO_SKILL_EVAL_KEEP_DERIVEDDATA=1 skips the iOS DerivedData sweep (set it
+#   only if you keep a real Xcode project literally named "fixture").
+set -uo pipefail
+
+APP="${1:?usage: clean-fixture.sh <project-path>}"
+
+# Safety guard: only ever clean inside an expo-skill-eval workspace.
+case "$APP" in
+  *expo-skill-eval-*) : ;;
+  *) echo "clean-fixture: refusing to clean '$APP' (not an expo-skill-eval fixture)" >&2; exit 1 ;;
+esac
+[[ -d "$APP" ]] || { echo "clean-fixture: $APP not found, skipping"; exit 0; }
+
+# Stop any Metro / Expo dev server that may still be running for this fixture.
+# The snapshot scripts' EXIT trap normally handles this, but cleaning up here
+# catches leftover processes from crashes or interrupted runs.
+# Ports 8081 (iOS) and 8082 (Android) are the two ports the eval harness
+# reserves — freeing them here is safe because clean-fixture.sh only runs after
+# all screenshots for this fixture have been captured.
+#
+# `-sTCP:LISTEN` is REQUIRED, not a refinement: without it, `lsof -ti tcp:8082`
+# also matches the *established* connection the adb daemon holds from the
+# `adb reverse tcp:8082` tunnel, and SIGKILLing the adb daemon crashes the
+# emulator with a gfxstream gRPC SIGABRT (std::bad_function_call). Keep the flag
+# so only the Metro listener is killed.
+lsof -ti tcp:8081 -sTCP:LISTEN 2>/dev/null | xargs kill -9 2>/dev/null || true
+lsof -ti tcp:8082 -sTCP:LISTEN 2>/dev/null | xargs kill -9 2>/dev/null || true
+
+# Per-fixture heavy dirs — all gitignored / regenerable (node_modules, the
+# prebuilt native projects incl. iOS Pods and Android Gradle output, caches).
+rm -rf \
+  "$APP/node_modules" \
+  "$APP/ios" \
+  "$APP/android" \
+  "$APP/.expo" \
+  "$APP/dist" \
+  "$APP/web-build" 2>/dev/null || true
+
+# iOS DerivedData for fixture builds. create-expo-app names the project
+# "fixture", so its build output lives under DerivedData/fixture-<hash>. This is
+# a cache (worst case a rebuild), so it's safe to drop between fixtures.
+if [[ "${EXPO_SKILL_EVAL_KEEP_DERIVEDDATA:-0}" != "1" ]]; then
+  DD="$HOME/Library/Developer/Xcode/DerivedData"
+  [[ -d "$DD" ]] && rm -rf "$DD"/fixture-* 2>/dev/null || true
+fi
+
+echo "cleaned fixture: $APP"
diff --git a/.agents/skills/expo-skill-eval/scripts/generate_viewer.py b/.agents/skills/expo-skill-eval/scripts/generate_viewer.py
new file mode 100644
index 0000000..a7b6370
--- /dev/null
+++ b/.agents/skills/expo-skill-eval/scripts/generate_viewer.py
@@ -0,0 +1,450 @@
+#!/usr/bin/env python3
+"""Generate the self-contained HTML viewer for an expo-skill-eval run.
+
+Usage: generate_viewer.py <workspace-root> [--artifact]
+  <workspace-root>  Run root, e.g. /private/tmp/expo-skill-eval-expo-ui.
+                    Iteration dirs (iteration-*) and trigger-evals/ live under it;
+                    viewer.html is written there and opened in the browser.
+  --artifact        Emit viewer_artifact.html (page-content only, no
+                    <!DOCTYPE>/<html>/<head>/<body>) for the Artifact tool, and
+                    do NOT open a browser. The standalone viewer.html is still
+                    written on a normal (non-artifact) run.
+
+Reads, per iteration, <iter>/evals.json plus each eval's
+eval-<id>/<config>/{grading.json,static.json,outputs/<platform>.png}. Screenshots
+are embedded as base64 data: URIs so the file is fully self-contained (and
+satisfies the Artifact CSP). Self-paced by argv so it can be a checked-in script
+rather than regenerated each run.
+"""
+
+import base64
+import json
+import sys
+import webbrowser
+from pathlib import Path
+
+
+def b64_img(path):
+    if not path:
+        return None
+    p = Path(path)
+    if not p.exists() or not p.is_file():
+        return None
+    with open(p, "rb") as f:
+        data = base64.b64encode(f.read()).decode()
+    ext = p.suffix.lower().lstrip(".")
+    mime = {"png": "image/png", "jpg": "image/jpeg", "jpeg": "image/jpeg"}.get(ext, "image/png")
+    return f"data:{mime};base64,{data}"
+
+
+def score_color(score, max_score):
+    if not max_score:
+        return "#888"
+    pct = score / max_score
+    if pct >= 0.85:
+        return "#4ade80"
+    elif pct >= 0.65:
+        return "#fbbf24"
+    else:
+        return "#f87171"
+
+
+def load_json(path, default=None):
+    p = Path(path)
+    if not p.exists():
+        return default
+    try:
+        with open(p) as f:
+            return json.load(f)
+    except Exception:
+        return default
+
+
+def render_expectations(expectations):
+    if not expectations:
+        return ""
+    html = '<ul class="exp-list">'
+    for exp in expectations:
+        if isinstance(exp, dict):
+            passed = exp.get("passed", None)
+            text = exp.get("text", str(exp))
+            evidence = exp.get("evidence", "")
+            if passed is True:
+                badge = '<span class="badge pass">PASS</span>'
+            elif passed is False:
+                badge = '<span class="badge fail">FAIL</span>'
+            else:
+                badge = '<span class="badge unknown">?</span>'
+            ev_html = f'<div class="evidence">{evidence}</div>' if evidence else ""
+            html += f'<li>{badge} {text}{ev_html}</li>'
+        else:
+            html += f'<li><span class="badge unknown">?</span> {exp}</li>'
+    html += "</ul>"
+    return html
+
+
+def render_quality(quality):
+    if not quality:
+        return ""
+    dims = quality.get("dimensions", [])
+    subtotal = quality.get("subtotal", 0)
+    max_total = quality.get("max", 0)
+    summary = quality.get("summary", "")
+    html = '<div class="quality-block">'
+    html += f'<div class="quality-header">Design Quality: <b>{subtotal}/{max_total}</b></div>'
+    for d in dims:
+        name = d.get("name", "")
+        score = d.get("score", 0)
+        mx = d.get("max", 3)
+        evidence = d.get("evidence", "")
+        pct = (score / mx * 100) if mx else 0
+        color = score_color(score, mx)
+        html += f'''<div class="quality-dim">
+  <div class="dim-label">{name} <span style="color:{color}">{score}/{mx}</span></div>
+  <div class="dim-bar-wrap"><div class="dim-bar" style="width:{pct:.0f}%;background:{color}"></div></div>
+  {f'<div class="dim-evidence">{evidence}</div>' if evidence else ""}
+</div>'''
+    if summary:
+        html += f'<div class="quality-summary">{summary}</div>'
+    html += "</div>"
+    return html
+
+
+def render_config_card(iter_dir, eval_id, config, eval_case, grading, static_result):
+    screenshots = []
+    for plat in eval_case.get("runtime", {}).get("platforms", ["ios"]):
+        img_path = iter_dir / f"eval-{eval_id}" / config / "outputs" / f"{plat}.png"
+        screenshots.append((plat, b64_img(img_path)))
+
+    static_pass = static_result and static_result.get("exit_code") == 0
+    static_badge = '<span class="badge pass">BUILD OK</span>' if static_pass else '<span class="badge fail">BUILD FAIL</span>'
+
+    score = grading.get("score", 0) if grading else None
+    max_score = grading.get("max_score", 1) if grading else 1
+    score_html = ""
+    if score is not None:
+        color = score_color(score, max_score)
+        score_html = f'<div class="score" style="color:{color}">{score}/{max_score}</div>'
+
+    label = "With Skill" if config == "with_skill" else "Without Skill"
+    html = '<div class="config-card">'
+    html += f'<div class="config-header"><span class="config-label {"with" if config == "with_skill" else "without"}">{label}</span>{static_badge}{score_html}</div>'
+
+    for plat, img_b64 in screenshots:
+        if img_b64:
+            html += f'<div class="screenshot-wrap"><div class="plat-label">{plat}</div>'
+            html += f'<img src="{img_b64}" class="screenshot" onclick="this.classList.toggle(\'zoomed\')" />'
+            html += '</div>'
+        else:
+            html += f'<div class="screenshot-wrap"><div class="plat-label">{plat}</div><div class="no-screenshot">No screenshot</div></div>'
+
+    if grading:
+        html += render_expectations(grading.get("expectations", []))
+
+        ref_match = grading.get("reference_match")
+        if ref_match:
+            rm_score = ref_match.get("score", 0)
+            rm_max = ref_match.get("max", 10)
+            rm_color = score_color(rm_score, rm_max)
+            html += f'<div class="ref-match"><b>Reference Match:</b> <span style="color:{rm_color}">{rm_score}/{rm_max}</span>'
+            if ref_match.get("evidence"):
+                html += f'<div class="evidence">{ref_match["evidence"]}</div>'
+            html += '</div>'
+
+        html += render_quality(grading.get("quality"))
+
+        notes = grading.get("user_notes_summary", {})
+        if notes and notes.get("notes"):
+            html += f'<div class="reviewer-notes"><b>Notes:</b> {notes["notes"]}</div>'
+
+    html += '</div>'
+    return html
+
+
+def render_iteration(iter_dir):
+    evals = load_json(iter_dir / "evals.json")
+    if not evals:
+        return f"<p>No evals.json found in {iter_dir}</p>"
+
+    html = ""
+    total_with = total_without = 0
+    scored_with = scored_without = 0
+    qual_with = qual_without = 0
+    total_evals = 0
+
+    for ev in evals:
+        eid = ev["id"]
+        ref_img_b64 = b64_img(ev.get("reference_image", ""))
+
+        with_grading = load_json(iter_dir / f"eval-{eid}" / "with_skill" / "grading.json")
+        without_grading = load_json(iter_dir / f"eval-{eid}" / "without_skill" / "grading.json")
+        with_static = load_json(iter_dir / f"eval-{eid}" / "with_skill" / "static.json")
+        without_static = load_json(iter_dir / f"eval-{eid}" / "without_skill" / "static.json")
+
+        total_evals += 1
+
+        if with_grading and with_grading.get("max_score"):
+            scored_with += with_grading.get("score", 0)
+            total_with += with_grading.get("max_score", 0)
+        if without_grading and without_grading.get("max_score"):
+            scored_without += without_grading.get("score", 0)
+            total_without += without_grading.get("max_score", 0)
+        if with_grading and with_grading.get("quality"):
+            qual_with += with_grading["quality"].get("subtotal", 0)
+        if without_grading and without_grading.get("quality"):
+            qual_without += without_grading["quality"].get("subtotal", 0)
+
+        html += '<div class="eval-case">'
+        html += f'<div class="eval-header">Eval #{eid}</div>'
+        html += f'<div class="eval-prompt">{ev.get("prompt", "")[:200]}</div>'
+
+        if ref_img_b64:
+            html += '<div class="ref-image-wrap"><div class="ref-label">Target Reference</div>'
+            html += f'<img src="{ref_img_b64}" class="ref-image" onclick="this.classList.toggle(\'zoomed\')" />'
+            html += '</div>'
+
+        html += '<div class="configs-row">'
+        html += render_config_card(iter_dir, eid, "with_skill", ev, with_grading, with_static)
+        html += render_config_card(iter_dir, eid, "without_skill", ev, without_grading, without_static)
+        html += '</div>'
+        html += '</div>'
+
+    with_pct = (scored_with / total_with * 100) if total_with else 0
+    without_pct = (scored_without / total_without * 100) if total_without else 0
+    delta = with_pct - without_pct
+    delta_color = "#4ade80" if delta > 0 else "#f87171" if delta < 0 else "#888"
+
+    qual_html = ""
+    if qual_with or qual_without:
+        qdelta = qual_with - qual_without
+        qcolor = "#4ade80" if qdelta > 0 else "#f87171" if qdelta < 0 else "#888"
+        qual_html = f'  <div class="summary-item">Quality Δ: <span style="color:{qcolor}">{qdelta:+d}</span></div>\n'
+
+    summary = f'''<div class="summary-bar">
+  <div class="summary-item">With Skill: <span style="color:{score_color(scored_with, total_with) if total_with else "#888"}">{with_pct:.0f}%</span></div>
+  <div class="summary-item">Without Skill: <span style="color:{score_color(scored_without, total_without) if total_without else "#888"}">{without_pct:.0f}%</span></div>
+  <div class="summary-item">Delta: <span style="color:{delta_color}">{delta:+.0f}pp</span></div>
+{qual_html}  <div class="summary-item">Evals: {total_evals}</div>
+</div>'''
+
+    return summary + html
+
+
+def render_trigger_table(results_path):
+    data = load_json(results_path)
+    if not data:
+        return ""
+
+    html = '<div class="trigger-section"><h2>Trigger Accuracy</h2>'
+    recall = data.get("recall", 0)
+    color = score_color(recall, 1)
+    passed_count = data.get("passed", data.get("triggered", 0))
+    html += f'<div class="trigger-summary">Recall: <span style="color:{color}">{100*recall:.0f}%</span> ({passed_count}/{data.get("total")} passed)</div>'
+    html += '<table class="trigger-table"><tr><th>#</th><th>Prompt</th><th>Should Trigger</th><th>Triggered</th><th>Result</th><th>Time</th></tr>'
+    for i, r in enumerate(data.get("results", []), 1):
+        # Support both schema variants: {id, prompt, should_trigger, pass} and {query, triggered, duration}
+        rid = r.get("id", i)
+        prompt = r.get("prompt", r.get("query", ""))
+        should_trigger = r.get("should_trigger", True)  # default True for recall-only runs
+        triggered = r.get("triggered", False)
+        passed = r.get("pass", triggered if should_trigger else not triggered)
+        result_badge = '<span class="badge pass">PASS</span>' if passed else '<span class="badge fail">FAIL</span>'
+        should = "Yes" if should_trigger else "No"
+        triggered_str = "Yes" if triggered else "No"
+        elapsed = r.get("elapsed_s", r.get("duration", "?"))
+        html += f'<tr><td>{rid}</td><td class="prompt-cell">{prompt[:80]}</td><td>{should}</td><td>{triggered_str}</td><td>{result_badge}</td><td>{elapsed}s</td></tr>'
+    html += '</table></div>'
+    return html
+
+
+CSS = """\
+:root {
+  --ground: #090C14;
+  --surface: #0E1320;
+  --surface-hi: #131929;
+  --border: #1A2238;
+  --text: #D9E2F5;
+  --text-muted: #6B7A9E;
+  --text-dim: #3A4560;
+  --accent: #7B6FD3;
+  --accent-glow: rgba(123,111,211,0.12);
+  --pass: #4DB87C;
+  --pass-bg: rgba(77,184,124,0.10);
+  --fail: #E05555;
+  --fail-bg: rgba(224,85,85,0.10);
+  --score-with: #9B8EE8;
+  --score-without: #5A6480;
+}
+* { box-sizing: border-box; margin: 0; padding: 0; }
+body { background: var(--ground); color: var(--text); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif; font-size: 14px; line-height: 1.5; padding: 20px 24px; }
+h1 { font-size: 15px; font-weight: 500; letter-spacing: 0.06em; text-transform: uppercase; color: var(--text-muted); margin-bottom: 20px; }
+h2 { font-size: 11px; font-weight: 600; letter-spacing: 0.08em; text-transform: uppercase; color: var(--text-muted); margin: 24px 0 10px; }
+
+/* Tabs */
+.tabs { display: flex; gap: 6px; margin-bottom: 20px; }
+.tab { background: var(--surface); border: 1px solid var(--border); color: var(--text-muted); padding: 5px 14px; border-radius: 5px; cursor: pointer; font-size: 12px; font-weight: 500; transition: color .15s, border-color .15s; }
+.tab:hover { color: var(--text); border-color: #2A3558; }
+.tab.active { background: var(--surface-hi); border-color: var(--accent); color: var(--text); }
+
+/* Summary strip */
+.summary-bar { display: flex; gap: 0; background: var(--surface); border: 1px solid var(--border); border-radius: 8px; overflow: hidden; margin-bottom: 20px; }
+.summary-item { flex: 1; padding: 12px 16px; border-right: 1px solid var(--border); font-size: 11px; letter-spacing: 0.04em; text-transform: uppercase; color: var(--text-muted); }
+.summary-item:last-child { border-right: none; }
+.summary-item span { display: block; font-size: 22px; font-weight: 700; font-variant-numeric: tabular-nums; letter-spacing: -0.02em; color: var(--text); margin-top: 2px; }
+
+/* Eval card */
+.eval-case { background: var(--surface); border: 1px solid var(--border); border-radius: 10px; margin-bottom: 24px; overflow: hidden; }
+.eval-header { padding: 10px 16px; font-size: 11px; font-weight: 600; letter-spacing: 0.07em; text-transform: uppercase; color: var(--text-muted); border-bottom: 1px solid var(--border); }
+.eval-prompt { padding: 12px 16px; font-size: 13px; color: var(--text); border-bottom: 1px solid var(--border); line-height: 1.55; }
+
+/* Reference image */
+.ref-image-wrap { padding: 16px; background: #07090F; border-bottom: 1px solid var(--border); }
+.ref-label { font-size: 10px; font-weight: 600; letter-spacing: 0.09em; text-transform: uppercase; color: var(--text-dim); margin-bottom: 8px; }
+.ref-image { max-height: 260px; width: auto; border-radius: 10px; border: 1px solid #1E2840; cursor: zoom-in; display: block; }
+.ref-image.zoomed { max-height: none; cursor: zoom-out; }
+
+/* Side-by-side config columns */
+.configs-row { display: grid; grid-template-columns: 1fr 1fr; }
+.config-card { padding: 16px; border-right: 1px solid var(--border); position: relative; }
+.config-card:last-child { border-right: none; }
+
+/* The aesthetic risk: the with_skill card gets a faint violet radial glow from its header edge */
+.config-card:first-child::before {
+  content: "";
+  position: absolute;
+  top: 0; left: 0; right: 0; height: 180px;
+  background: radial-gradient(ellipse 80% 120px at 50% 0, var(--accent-glow), transparent 70%);
+  pointer-events: none;
+}
+
+.config-header { display: flex; align-items: center; gap: 8px; margin-bottom: 14px; flex-wrap: wrap; }
+.config-label { font-size: 10px; font-weight: 700; letter-spacing: 0.07em; text-transform: uppercase; padding: 3px 8px; border-radius: 4px; }
+.config-label.with { background: rgba(123,111,211,0.15); color: var(--accent); border: 1px solid rgba(123,111,211,0.25); }
+.config-label.without { background: var(--surface-hi); color: var(--text-muted); border: 1px solid var(--border); }
+.score { font-size: 22px; font-weight: 700; font-variant-numeric: tabular-nums; margin-left: auto; }
+.config-card:first-child .score { color: var(--score-with); }
+.config-card:last-child .score { color: var(--score-without); }
+
+/* Badges */
+.badge { display: inline-flex; align-items: center; font-size: 9px; font-weight: 700; padding: 2px 7px; border-radius: 3px; letter-spacing: 0.05em; text-transform: uppercase; }
+.badge.pass { background: var(--pass-bg); color: var(--pass); border: 1px solid rgba(77,184,124,0.2); }
+.badge.fail { background: var(--fail-bg); color: var(--fail); border: 1px solid rgba(224,85,85,0.2); }
+.badge.unknown { background: var(--surface-hi); color: var(--text-dim); border: 1px solid var(--border); }
+
+/* Screenshots */
+.screenshot-wrap { margin-bottom: 14px; }
+.plat-label { font-size: 9px; font-weight: 600; letter-spacing: 0.09em; text-transform: uppercase; color: var(--text-dim); margin-bottom: 6px; }
+.screenshot { max-width: 100%; max-height: 380px; width: auto; border-radius: 14px; border: 1px solid #1A2540; cursor: zoom-in; display: block; box-shadow: 0 4px 24px rgba(0,0,0,0.5); }
+.screenshot.zoomed { max-height: none; cursor: zoom-out; }
+.no-screenshot { color: var(--text-dim); font-size: 11px; padding: 16px; background: var(--surface-hi); border-radius: 6px; text-align: center; border: 1px dashed var(--border); }
+
+/* Expectations */
+.exp-list { list-style: none; margin-top: 12px; }
+.exp-list li { padding: 6px 0; border-bottom: 1px solid var(--border); font-size: 12px; color: var(--text-muted); display: flex; flex-wrap: wrap; gap: 6px; align-items: flex-start; }
+.exp-list li:last-child { border-bottom: none; }
+.evidence { font-size: 10px; color: var(--text-dim); width: 100%; line-height: 1.5; margin-top: 2px; }
+
+/* Reference match block */
+.ref-match { margin-top: 12px; font-size: 12px; color: var(--text-muted); background: var(--surface-hi); padding: 10px 12px; border-radius: 6px; border-left: 2px solid var(--accent); }
+.ref-match b { color: var(--text); }
+
+/* Quality rubric */
+.quality-block { margin-top: 12px; background: var(--surface-hi); border: 1px solid var(--border); border-radius: 6px; padding: 12px; }
+.quality-header { font-size: 11px; font-weight: 600; letter-spacing: 0.05em; text-transform: uppercase; color: var(--text-muted); margin-bottom: 10px; }
+.quality-dim { margin-bottom: 10px; }
+.quality-dim:last-of-type { margin-bottom: 0; }
+.dim-label { font-size: 10px; color: var(--text-muted); margin-bottom: 4px; display: flex; justify-content: space-between; }
+.dim-label span { font-variant-numeric: tabular-nums; }
+.dim-bar-wrap { height: 3px; background: var(--border); border-radius: 2px; overflow: hidden; }
+.dim-bar { height: 100%; border-radius: 2px; }
+.dim-evidence { font-size: 10px; color: var(--text-dim); margin-top: 3px; line-height: 1.45; }
+.quality-summary { font-size: 11px; color: var(--text-dim); margin-top: 8px; padding-top: 8px; border-top: 1px solid var(--border); }
+.reviewer-notes { margin-top: 10px; font-size: 11px; color: var(--text-dim); background: var(--ground); padding: 8px 10px; border-radius: 4px; }
+
+/* Trigger table */
+.trigger-section { margin-top: 32px; }
+.trigger-summary { font-size: 13px; margin-bottom: 12px; color: var(--text-muted); }
+.trigger-table { width: 100%; border-collapse: collapse; font-size: 12px; }
+.trigger-table th { background: var(--surface); padding: 9px 10px; text-align: left; font-size: 10px; font-weight: 600; letter-spacing: 0.07em; text-transform: uppercase; color: var(--text-muted); border-bottom: 1px solid var(--border); }
+.trigger-table td { padding: 8px 10px; border-bottom: 1px solid var(--border); color: var(--text-muted); vertical-align: top; }
+.trigger-table tr:last-child td { border-bottom: none; }
+.trigger-table tr:hover td { background: var(--surface-hi); }
+.prompt-cell { max-width: 320px; word-break: break-word; color: var(--text); }
+@media (prefers-reduced-motion: reduce) { .dim-bar { transition: none; } }
+"""
+
+JS = """\
+function showTab(i) {
+  document.querySelectorAll('.panel').forEach((p, idx) => { p.style.display = idx === i ? 'block' : 'none'; });
+  document.querySelectorAll('.tab').forEach((t, idx) => { t.classList.toggle('active', idx === i); });
+  localStorage.setItem('expo-eval-tab', i);
+}
+(function() {
+  const saved = parseInt(localStorage.getItem('expo-eval-tab') || '0', 10);
+  if (saved > 0) showTab(saved);
+})();
+"""
+
+
+def build_page(ws, title, artifact=False):
+    iterations = sorted(p for p in ws.glob("iteration-*") if p.is_dir())
+    if not iterations:
+        return f"<p>No iteration directories found under {ws}.</p>"
+
+    tabs_html = ""
+    panels_html = ""
+    for i, it in enumerate(iterations):
+        active = "active" if i == 0 else ""
+        tabs_html += f'<button class="tab {active}" onclick="showTab({i})" id="tab-{i}">{it.name}</button>'
+        content = render_iteration(it)
+        panels_html += f'<div class="panel" id="panel-{i}" style="display:{"block" if i == 0 else "none"}">{content}</div>'
+
+    trigger_html = render_trigger_table(ws / "trigger-evals" / "trigger_results.json")
+    body_content = f'<h1>{title}</h1>\n<div class="tabs">{tabs_html}</div>\n{panels_html}\n{trigger_html}'
+
+    if artifact:
+        return f'<title>{title}</title>\n<style>\n{CSS}</style>\n{body_content}\n<script>\n{JS}</script>'
+    return f'''<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="UTF-8" />
+<meta name="viewport" content="width=device-width, initial-scale=1" />
+<title>{title}</title>
+<style>
+{CSS}
+</style>
+</head>
+<body>
+{body_content}
+<script>
+{JS}
+</script>
+</body>
+</html>'''
+
+
+def main():
+    args = [a for a in sys.argv[1:] if a != "--artifact"]
+    artifact = "--artifact" in sys.argv
+    if not args:
+        print("usage: generate_viewer.py <workspace-root> [--artifact]", file=sys.stderr)
+        sys.exit(1)
+
+    ws = Path(args[0]).resolve()
+    skill = ws.name.replace("expo-skill-eval-", "")
+    title = f"{skill} Skill Eval"
+    html = build_page(ws, title, artifact=artifact)
+
+    if artifact:
+        out = ws / "viewer_artifact.html"
+        out.write_text(html)
+        print(f"Artifact viewer written: {out}")
+    else:
+        out = ws / "viewer.html"
+        out.write_text(html)
+        print(f"Viewer written: {out}")
+        webbrowser.open("file://" + str(out))
+
+
+if __name__ == "__main__":
+    main()
diff --git a/.agents/skills/expo-skill-eval/scripts/latest-sdk.sh b/.agents/skills/expo-skill-eval/scripts/latest-sdk.sh
new file mode 100755
index 0000000..c650d80
--- /dev/null
+++ b/.agents/skills/expo-skill-eval/scripts/latest-sdk.sh
@@ -0,0 +1,46 @@
+#!/usr/bin/env bash
+# Print the latest Expo SDK major version.
+#
+# Usage: latest-sdk.sh
+#
+# The `expo` package's major version IS the SDK version (expo@56.x -> SDK 56).
+# Uses bun to run `npm view expo dist-tags --json` (so it honors the local npm
+# registry / proxy / auth config rather than hardcoding registry.npmjs.org),
+# JSON.parse the result, and take the major via the `semver` package (falling
+# back to a numeric split if semver can't be resolved). Run via the skill's
+# `bash *expo-skill-eval/scripts/*` rule so SDK detection stays prompt-free —
+# the npm child runs under bun, not as its own Bash tool call.
+set -euo pipefail
+
+exec bun -e '
+  let out;
+  try {
+    out = await Bun.$`npm view expo dist-tags --json`.text();
+  } catch (e) {
+    console.error("error: `npm view expo` failed: " + (e?.message ?? e));
+    process.exit(1);
+  }
+  let latest;
+  try {
+    latest = JSON.parse(out)?.latest;
+  } catch {
+    console.error("error: could not JSON.parse `npm view` output");
+    process.exit(1);
+  }
+  if (!latest) {
+    console.error("error: no `latest` dist-tag for expo");
+    process.exit(1);
+  }
+  let major;
+  try {
+    const semver = await import("semver");
+    major = (semver.default ?? semver).major(latest);
+  } catch {
+    major = Number.parseInt(String(latest).split(".")[0], 10);
+  }
+  if (!Number.isInteger(major)) {
+    console.error(`error: could not parse SDK major from "${latest}"`);
+    process.exit(1);
+  }
+  console.log(major);
+'
diff --git a/.agents/skills/expo-skill-eval/scripts/make-fixture.sh b/.agents/skills/expo-skill-eval/scripts/make-fixture.sh
new file mode 100755
index 0000000..9e9eae3
--- /dev/null
+++ b/.agents/skills/expo-skill-eval/scripts/make-fixture.sh
@@ -0,0 +1,95 @@
+#!/usr/bin/env bash
+# Create an Expo app fixture for an eval run.
+#
+# Usage: make-fixture.sh <project-path> [sdk-version] [variant]
+#   project-path  Where the app should end up (must not exist yet)
+#   sdk-version   Expo SDK major version, e.g. "56". Omit for the latest template.
+#   variant       "clean" (default) runs the template's reset-project script so
+#                 executors start from a blank app instead of the example
+#                 screens. "full" keeps the example tabs (Home/Explore) - use
+#                 it for evals whose prompt assumes an existing app.
+#
+# One pristine app is created per SDK version + variant with
+# `bunx create-expo-app -t default@sdk-<version>` and cached under
+# $EXPO_SKILL_EVAL_CACHE (default ~/.cache/expo-skill-eval/fixtures).
+# Each call clones the cache with APFS copy-on-write, so only the first
+# call per SDK version pays the install cost.
+set -euo pipefail
+
+PROJECT_PATH="${1:?usage: make-fixture.sh <project-path> [sdk-version] [variant]}"
+SDK_VERSION="${2:-}"
+VARIANT="${3:-clean}"
+if [[ "$VARIANT" != "clean" && "$VARIANT" != "full" ]]; then
+  echo "error: variant must be 'clean' or 'full', got '$VARIANT'" >&2
+  exit 1
+fi
+CACHE_ROOT="${EXPO_SKILL_EVAL_CACHE:-$HOME/.cache/expo-skill-eval/fixtures}"
+
+if [[ -e "$PROJECT_PATH" ]]; then
+  echo "error: $PROJECT_PATH already exists" >&2
+  exit 1
+fi
+
+TEMPLATE="default"
+CACHE_KEY="latest"
+if [[ -n "$SDK_VERSION" ]]; then
+  TEMPLATE="default@sdk-${SDK_VERSION}"
+  CACHE_KEY="sdk-${SDK_VERSION}"
+fi
+if [[ "$VARIANT" == "clean" ]]; then
+  CACHE_KEY="${CACHE_KEY}-clean"
+fi
+CACHE_DIR="$CACHE_ROOT/$CACHE_KEY"
+
+if [[ ! -d "$CACHE_DIR" ]]; then
+  echo "building fixture cache for template '$TEMPLATE'..." >&2
+  mkdir -p "$CACHE_ROOT"
+  TMP_DIR="$(mktemp -d)"
+  trap 'rm -rf "$TMP_DIR"' EXIT
+  (cd "$TMP_DIR" && bunx create-expo-app --yes --template "$TEMPLATE" fixture) >&2
+  if [[ "$VARIANT" == "clean" ]]; then
+    # Strip the example screens so executors start from a blank app.
+    # Answer "n" to the "move to /example?" prompt - delete them instead.
+    (cd "$TMP_DIR/fixture" && echo n | bun run reset-project) >&2
+  fi
+  # Pin a stable iOS bundle identifier and Android package. The default template
+  # leaves both unset, so a dev-build run (`expo run:ios`/`expo run:android`)
+  # would prompt for them - which fails in the snapshot scripts' non-interactive
+  # mode - and the snapshot scripts need a known id to relaunch the app by.
+  (cd "$TMP_DIR/fixture" && bun -e '
+    const f = "app.json";
+    const j = await Bun.file(f).json();
+    j.expo ??= {};
+    j.expo.ios ??= {};
+    j.expo.android ??= {};
+    j.expo.ios.bundleIdentifier ??= "com.exposkilleval.fixture";
+    j.expo.android.package ??= "com.exposkilleval.fixture";
+    await Bun.write(f, JSON.stringify(j, null, 2) + "\n");
+  ') >&2
+  # The CLI normally generates expo-env.d.ts on first `expo start`; the static
+  # gate runs tsc before any start, so create it up front (it provides the
+  # CSS-module and Metro type declarations from expo/types).
+  printf '/// <reference types="expo/types" />\n' >"$TMP_DIR/fixture/expo-env.d.ts"
+  # expo-dev-client is required for dev-build snapshots: it registers the
+  # expo-development-client URL scheme and enables custom Metro port connections
+  # (expo run:ios/android --port N opens the app via a deep link that the dev
+  # client handles). Without it, a custom port deep link may not open the app.
+  (cd "$TMP_DIR/fixture" && bunx expo install expo-dev-client) >&2
+  # First `expo lint` self-installs eslint + eslint-config-expo and writes
+  # eslint.config.js if missing; it may exit non-zero on that bootstrap run.
+  (cd "$TMP_DIR/fixture" && CI=1 bunx expo lint) >&2 || true
+  printf '.eval-static/\n' >>"$TMP_DIR/fixture/.gitignore"
+  mv "$TMP_DIR/fixture" "$CACHE_DIR"
+fi
+
+mkdir -p "$(dirname "$PROJECT_PATH")"
+# -c uses APFS clonefile (instant, no extra disk); fall back to a plain copy.
+cp -Rc "$CACHE_DIR" "$PROJECT_PATH" 2>/dev/null || cp -R "$CACHE_DIR" "$PROJECT_PATH"
+
+# Fresh git history so `git diff` in the app shows exactly what the executor changed.
+rm -rf "$PROJECT_PATH/.git"
+git -C "$PROJECT_PATH" init -q
+git -C "$PROJECT_PATH" add -A
+git -C "$PROJECT_PATH" commit -qm "fixture: pristine $TEMPLATE template" --no-verify
+
+echo "$PROJECT_PATH"
diff --git a/.agents/skills/expo-skill-eval/scripts/make-workspace.sh b/.agents/skills/expo-skill-eval/scripts/make-workspace.sh
new file mode 100755
index 0000000..09e2e23
--- /dev/null
+++ b/.agents/skills/expo-skill-eval/scripts/make-workspace.sh
@@ -0,0 +1,31 @@
+#!/usr/bin/env bash
+# Create the eval workspace directory tree for a run.
+#
+# Usage: make-workspace.sh <workspace> <iteration> <num-evals> [configs]
+#   workspace   Run root, e.g. /private/tmp/expo-skill-eval-<skill>
+#   iteration   Iteration folder name, e.g. "iteration-1"
+#   num-evals   Number of eval cases; creates eval-0 .. eval-(N-1)
+#   configs     Space- or comma-separated config names
+#               (default: "with_skill without_skill")
+#
+# Creates <workspace>/trigger-evals/scratch and, per eval x config,
+# <workspace>/<iteration>/eval-<i>/<config>/outputs. Run this once at the
+# start of a run instead of ad-hoc `mkdir` so the call is covered by the
+# skill's `Bash(bash *expo-skill-eval/scripts/*)` rule (the mkdir calls
+# inside run as children of this script and need no permission of their own).
+set -euo pipefail
+
+WORKSPACE="${1:?usage: make-workspace.sh <workspace> <iteration> <num-evals> [configs]}"
+ITERATION="${2:?usage: make-workspace.sh <workspace> <iteration> <num-evals> [configs]}"
+NUM_EVALS="${3:?usage: make-workspace.sh <workspace> <iteration> <num-evals> [configs]}"
+CONFIGS="${4:-with_skill without_skill}"
+CONFIGS="${CONFIGS//,/ }"
+
+mkdir -p "$WORKSPACE/trigger-evals/scratch"
+for ((i = 0; i < NUM_EVALS; i++)); do
+  for cfg in $CONFIGS; do
+    mkdir -p "$WORKSPACE/$ITERATION/eval-$i/$cfg/outputs"
+  done
+done
+
+echo "workspace ready: $WORKSPACE/$ITERATION ($NUM_EVALS evals x [$CONFIGS])"
diff --git a/.agents/skills/expo-skill-eval/scripts/snapshot-android.sh b/.agents/skills/expo-skill-eval/scripts/snapshot-android.sh
new file mode 100755
index 0000000..c4e7d26
--- /dev/null
+++ b/.agents/skills/expo-skill-eval/scripts/snapshot-android.sh
@@ -0,0 +1,284 @@
+#!/usr/bin/env bash
+# Run an Expo app in Expo Go on an Android emulator and capture a screenshot.
+#
+# Usage: snapshot-android.sh <project-path> <output-png> [port] [settle-seconds]
+#
+# Env: EXPO_SKILL_EVAL_RUNNER = expo-go (default) | dev-build — dev-build runs the
+#   app via `expo run:android` (native dev-client compile, slow) instead of Expo Go.
+#
+# If no device is attached, boots the first available AVD and waits for it
+# (the slow path - keep one emulator running across an eval session).
+# Starts Metro with `expo start --android` (auto-installs Expo Go, sets up
+# adb reverse, opens the app), waits for the bundle, settles, screenshots
+# via screencap, and tears Metro down. The Metro log is saved next to the
+# screenshot as <name>.metro.log. On bundle failure it still captures a
+# best-effort screenshot and exits 1.
+set -uo pipefail
+
+PROJECT_PATH="${1:?usage: snapshot-android.sh <project-path> <output-png> [port] [settle-seconds]}"
+OUT="${2:?usage: snapshot-android.sh <project-path> <output-png> [port] [settle-seconds]}"
+PORT="${3:-8082}"
+RUNNER="${EXPO_SKILL_EVAL_RUNNER:-expo-go}"   # expo-go | dev-build
+
+# Step-level logging with timestamp. Every major phase emits a marker so a
+# crash report can be correlated to "which step was running when it died."
+log_step() { echo "[$(date '+%H:%M:%S')] [snapshot-android] STEP: $*" >&2; }
+
+# Track the emulator qemu PID so liveness checks in wait loops can detect a
+# mid-flight crash and emit a clear "emulator crashed at step X" message.
+EMULATOR_PID=""
+
+emulator_alive() {
+  [[ -n "$EMULATOR_PID" ]] && kill -0 "$EMULATOR_PID" 2>/dev/null
+}
+
+log_step "start  runner=$RUNNER port=$PORT project=$PROJECT_PATH"
+
+# GPU mode is fixed to host (Metal on Apple Silicon, hardware-accelerated). The
+# env-var knob was removed on purpose. If host self-aborts the emulator on a
+# given machine (qemu SIGABRT deep in gfxstream/Metal — possible on Apple Silicon
+# under load), change this to "guest" and bump SETTLE to ~25 (software rendering
+# paints slowly). Avoid swiftshader_indirect — it hangs at boot on arm64.
+GPU_MODE="host"
+log_step "gpu_mode=$GPU_MODE"
+
+SETTLE="${4:-8}"
+
+if [[ "$RUNNER" == "dev-build" ]]; then
+  BUNDLE_TIMEOUT="${EXPO_SKILL_EVAL_BUNDLE_TIMEOUT:-900}"   # native compile is slow
+else
+  BUNDLE_TIMEOUT="${EXPO_SKILL_EVAL_BUNDLE_TIMEOUT:-240}"
+fi
+LOG="${OUT%.png}.metro.log"
+
+mkdir -p "$(dirname "$OUT")"
+
+# Free the port up front in case a previous run (or a crash) left Metro on it,
+# so `expo start` binds the port we expect instead of silently incrementing.
+# Runs inside this script, so the eval harness never needs ad-hoc lsof/kill.
+lsof -ti "tcp:$PORT" -sTCP:LISTEN 2>/dev/null | xargs kill -9 2>/dev/null || true
+
+find_sdk_tool() {
+  local tool="$1" subdir="$2"
+  if command -v "$tool" >/dev/null; then
+    command -v "$tool"
+    return
+  fi
+  local sdk
+  for sdk in "${ANDROID_HOME:-}" "${ANDROID_SDK_ROOT:-}" "$HOME/Library/Android/sdk" "$HOME/Android/Sdk"; do
+    if [[ -n "$sdk" && -x "$sdk/$subdir/$tool" ]]; then
+      echo "$sdk/$subdir/$tool"
+      return
+    fi
+  done
+  return 1
+}
+
+ADB="$(find_sdk_tool adb platform-tools)" || { echo "error: adb not found (set ANDROID_HOME)" >&2; exit 1; }
+
+# Recycle a wedged emulator before the boot check. An "offline"/unresponsive
+# emulator isn't in "device" state, so the check below would otherwise reuse it
+# (and hang) or stack a second emulator beside it. Graceful console shutdown
+# first; force-kill only the survivors, then reset adb to clear the stale entry —
+# so the boot check sees a clean slate and cold-boots a fresh (swiftshader) one.
+log_step "checking for wedged/offline emulators"
+STALE="$("$ADB" devices | awk 'NR>1 && $1 ~ /^emulator-/ && $2!="device" {print $1}')"
+if [[ -n "$STALE" ]]; then
+  echo "recycling wedged emulator(s): $STALE" >&2
+  for serial in $STALE; do
+    "$ADB" -s "$serial" emu kill 2>/dev/null || true   # graceful: ask the console to quit
+  done
+  sleep 2
+  # Still wedged after the graceful attempt? Force-kill the qemu process(es) and
+  # reset the adb server to drop the stale "offline" entry. pkill is broad (all
+  # qemu emulators), which is fine here: the eval harness runs a single emulator.
+  if "$ADB" devices | awk 'NR>1 && $1 ~ /^emulator-/ && $2!="device"' | grep -q .; then
+    pkill -9 -f qemu-system-aarch64 2>/dev/null || true
+    "$ADB" kill-server 2>/dev/null || true
+    "$ADB" start-server 2>/dev/null || true
+    sleep 2
+  fi
+fi
+
+# GPU mismatch: if an emulator is already running with a different GPU mode than
+# the one we need, recycle it so the boot path cold-starts with the correct mode.
+# gfxstream (host GPU) uses a gRPC channel that can crash on Metro teardown via
+# a bad_function_call SIGABRT; guest GPU avoids this by keeping rendering in-guest.
+CURRENT_GPU="$(ps aux | grep qemu-system-aarch64 | grep -v grep | grep -o -- '-gpu [a-z_]*' | awk '{print $2}' | head -1)"
+log_step "current_gpu=${CURRENT_GPU:-none}  required=$GPU_MODE"
+if [[ -n "$CURRENT_GPU" && "$CURRENT_GPU" != "$GPU_MODE" ]]; then
+  echo "GPU mismatch: running=$CURRENT_GPU required=$GPU_MODE — recycling emulator" >&2
+  "$ADB" emu kill 2>/dev/null || true
+  sleep 2
+  pkill -9 -f qemu-system-aarch64 2>/dev/null || true
+  "$ADB" kill-server 2>/dev/null || true
+  "$ADB" start-server 2>/dev/null || true
+  sleep 2
+fi
+
+log_step "checking device availability"
+if ! "$ADB" devices | awk 'NR>1 && $2=="device"' | grep -q .; then
+  EMULATOR="$(find_sdk_tool emulator emulator)" || { echo "error: no device attached and emulator binary not found" >&2; exit 1; }
+  AVD="$("$EMULATOR" -list-avds | head -1)"
+  if [[ -z "$AVD" ]]; then
+    echo "error: no AVDs configured" >&2
+    exit 1
+  fi
+  # Reset adb server before cold-booting. A previously crashed emulator leaves
+  # the server in a bad state (still trying to reconnect to dead ports 5554/5555),
+  # which causes adb wait-for-device to hang indefinitely on the next boot.
+  log_step "resetting adb server before cold boot"
+  "$ADB" kill-server 2>/dev/null || true
+  "$ADB" start-server 2>/dev/null || true
+  sleep 1
+  log_step "booting emulator avd=$AVD gpu=$GPU_MODE"
+  # nohup + disown so the emulator outlives this script and is reused by later
+  # eval runs. -no-snapshot forces a clean cold boot (no stale snapshot to replay)
+  # and writes no multi-GB snapshot (disk is often tight).
+  nohup "$EMULATOR" -avd "$AVD" -no-boot-anim \
+    -gpu "$GPU_MODE" -no-snapshot </dev/null >/dev/null 2>&1 &
+  disown
+  EMULATOR_PID="$(pgrep -f "emulator.*-avd $AVD" | head -1)"
+  log_step "emulator booted pid=${EMULATOR_PID:-unknown}"
+  "$ADB" wait-for-device
+  log_step "adb device appeared — waiting for full boot"
+  until [[ "$("$ADB" shell getprop sys.boot_completed 2>/dev/null | tr -d '\r')" == "1" ]]; do
+    if [[ -n "$EMULATOR_PID" ]] && ! kill -0 "$EMULATOR_PID" 2>/dev/null; then
+      echo "error: emulator pid=$EMULATOR_PID crashed during boot (check DiagnosticReports for qemu SIGABRT)" >&2
+      exit 1
+    fi
+    sleep 2
+  done
+  log_step "emulator fully booted"
+else
+  EMULATOR_PID="$(pgrep -f qemu-system-aarch64 | head -1)"
+  log_step "reusing running emulator pid=${EMULATOR_PID:-unknown}"
+fi
+
+# --android makes the CLI install Expo Go on the device when missing. Pin the
+# packager hostname to 127.0.0.1 so every exp:// URL goes through the adb
+# reverse tunnel - the default LAN-IP URL is often unreachable from the
+# emulator (host firewall) and leaves a stuck experience in Expo Go's task
+# stack that hijacks later deep links.
+# dev-build: expo run:android prebuilds + native-compiles a dev client, installs
+# and launches it, and starts Metro — no Expo Go involved.
+if [[ "$RUNNER" == "dev-build" ]]; then
+  log_step "starting expo run:android port=$PORT"
+  # Pass --port so Metro binds to $PORT and the health-check curl matches.
+  (cd "$PROJECT_PATH" && exec env -u CI REACT_NATIVE_PACKAGER_HOSTNAME=127.0.0.1 bunx expo run:android --port "$PORT") </dev/null >"$LOG" 2>&1 &
+else
+  log_step "starting expo start --android port=$PORT"
+  (cd "$PROJECT_PATH" && exec env -u CI REACT_NATIVE_PACKAGER_HOSTNAME=127.0.0.1 bunx expo start --port "$PORT" --android) </dev/null >"$LOG" 2>&1 &
+fi
+METRO_PID=$!
+# APP_PKG is set later (dev-build only) but must be in scope for cleanup.
+APP_PKG=""
+cleanup() {
+  kill "$METRO_PID" 2>/dev/null
+  lsof -ti "tcp:$PORT" -sTCP:LISTEN 2>/dev/null | xargs kill -9 2>/dev/null || true
+  wait "$METRO_PID" 2>/dev/null
+}
+trap cleanup EXIT
+# Resolve the app package name up front so the cleanup trap has it even on
+# early exit. app.json is a fixture source file always present before Metro starts.
+if [[ "$RUNNER" == "dev-build" ]]; then
+  APP_PKG="$(node -e "try{var a=require('$PROJECT_PATH/app.json');console.log((a.expo&&a.expo.android&&a.expo.android.package)||'com.exposkilleval.fixture')}catch(e){console.log('com.exposkilleval.fixture')}" 2>/dev/null || echo 'com.exposkilleval.fixture')"
+  log_step "app package=$APP_PKG"
+fi
+
+DEADLINE=$((SECONDS + BUNDLE_TIMEOUT))
+STATUS=0
+
+log_step "waiting for Metro on port=$PORT"
+until curl -sf "http://localhost:$PORT/status" >/dev/null; do
+  if ! kill -0 "$METRO_PID" 2>/dev/null; then
+    echo "error: Metro (pid=$METRO_PID) exited before coming up. Log tail:" >&2
+    tail -40 "$LOG" >&2
+    exit 1
+  fi
+  if emulator_alive; then : ; elif [[ -n "$EMULATOR_PID" ]]; then
+    echo "error: emulator pid=$EMULATOR_PID crashed while waiting for Metro" >&2
+    tail -40 "$LOG" >&2
+    exit 1
+  fi
+  if ((SECONDS > DEADLINE)); then
+    echo "error: timed out after ${BUNDLE_TIMEOUT}s waiting for Metro. Log tail:" >&2
+    tail -40 "$LOG" >&2
+    exit 1
+  fi
+  sleep 2
+done
+log_step "Metro is up"
+# Expo Go only: wait for it to install (the CLI may still be installing it).
+if [[ "$RUNNER" != "dev-build" ]]; then
+  log_step "waiting for Expo Go install on device"
+  until "$ADB" shell pm list packages 2>/dev/null | grep -q host.exp.exponent; do
+    if ((SECONDS > DEADLINE)); then
+      echo "error: Expo Go was not installed on the device. Log tail:" >&2
+      tail -40 "$LOG" >&2
+      exit 1
+    fi
+    sleep 2
+  done
+fi
+# Both runners: route the bundle over the adb reverse tunnel.
+log_step "setting up adb reverse tunnel port=$PORT"
+"$ADB" reverse "tcp:$PORT" "tcp:$PORT"
+if [[ "$RUNNER" == "dev-build" ]]; then
+  # expo run:android launches the dev client BEFORE Metro is ready, so it shows
+  # "Cannot connect to Expo CLI". Now that Metro + adb-reverse are both up,
+  # force-restart via explicit MainActivity to avoid the "Open in X?" dialog
+  # that an implicit VIEW intent triggers. expo run:android --port embeds the
+  # Metro URL in the build, so the dev client auto-connects on relaunch.
+  if [[ -n "$APP_PKG" ]]; then
+    log_step "launching dev-build app pkg=$APP_PKG"
+    "$ADB" shell am force-stop "$APP_PKG" 2>/dev/null || true
+    sleep 2
+    "$ADB" shell am start -W -n "${APP_PKG}/.MainActivity" >/dev/null 2>&1 || true
+  fi
+else
+  log_step "launching Expo Go exp://127.0.0.1:$PORT"
+  # Force-stop so a stale experience from a previous run can't be resumed, then
+  # give the system a moment to finish task cleanup - launching immediately
+  # after force-stop races it and the new activity gets torn down too.
+  "$ADB" shell am force-stop host.exp.exponent
+  sleep 2
+  "$ADB" shell am start -W -a android.intent.action.VIEW -d "exp://127.0.0.1:$PORT" >/dev/null
+fi
+
+log_step "waiting for JS bundle"
+until grep -q 'Bundled' "$LOG"; do
+  if ! kill -0 "$METRO_PID" 2>/dev/null; then
+    echo "error: Metro (pid=$METRO_PID) exited before bundling. Log tail:" >&2
+    tail -40 "$LOG" >&2
+    STATUS=1
+    break
+  fi
+  if emulator_alive; then : ; elif [[ -n "$EMULATOR_PID" ]]; then
+    echo "error: emulator pid=$EMULATOR_PID crashed while waiting for JS bundle" >&2
+    tail -40 "$LOG" >&2
+    STATUS=1
+    break
+  fi
+  if ((SECONDS > DEADLINE)); then
+    echo "error: timed out after ${BUNDLE_TIMEOUT}s waiting for bundle. Log tail:" >&2
+    tail -40 "$LOG" >&2
+    STATUS=1
+    break
+  fi
+  sleep 2
+done
+
+log_step "bundle done — settling ${SETTLE}s"
+sleep "$SETTLE"
+log_step "taking screenshot"
+"$ADB" exec-out screencap -p >"$OUT" || STATUS=1
+# Raw emulator captures are ~2800px tall and overflow the eval viewer's
+# window. Downscale to a review/grading-friendly size.
+if [[ -s "$OUT" ]]; then
+  sips -Z "${EXPO_SKILL_EVAL_MAX_DIM:-600}" "$OUT" >/dev/null 2>&1 || true
+fi
+log_step "done  status=$STATUS  screenshot=$OUT"
+echo "screenshot: $OUT"
+echo "metro log: $LOG"
+exit "$STATUS"
diff --git a/.agents/skills/expo-skill-eval/scripts/snapshot-ios.sh b/.agents/skills/expo-skill-eval/scripts/snapshot-ios.sh
new file mode 100755
index 0000000..dae3c4a
--- /dev/null
+++ b/.agents/skills/expo-skill-eval/scripts/snapshot-ios.sh
@@ -0,0 +1,132 @@
+#!/usr/bin/env bash
+# Run an Expo app in Expo Go on an iOS simulator and capture a screenshot.
+#
+# Usage: snapshot-ios.sh <project-path> <output-png> [port] [settle-seconds]
+#
+# Env: EXPO_SKILL_EVAL_RUNNER = expo-go (default) | dev-build — dev-build runs the
+#   app via `expo run:ios` (native dev-client compile, slow) instead of Expo Go.
+#
+# Boots the newest available iPhone simulator if none is booted, starts
+# Metro with `expo start --ios` (auto-installs Expo Go on the simulator and
+# opens the app), waits for the bundle to load, settles, screenshots, and
+# tears Metro down. The Metro log is saved next to the screenshot as
+# <name>.metro.log. On bundle failure it still captures a best-effort
+# screenshot (the error screen is grading evidence) and exits 1.
+set -uo pipefail
+
+PROJECT_PATH="${1:?usage: snapshot-ios.sh <project-path> <output-png> [port] [settle-seconds]}"
+OUT="${2:?usage: snapshot-ios.sh <project-path> <output-png> [port] [settle-seconds]}"
+PORT="${3:-8081}"
+SETTLE="${4:-8}"
+RUNNER="${EXPO_SKILL_EVAL_RUNNER:-expo-go}"   # expo-go | dev-build
+if [[ "$RUNNER" == "dev-build" ]]; then
+  BUNDLE_TIMEOUT="${EXPO_SKILL_EVAL_BUNDLE_TIMEOUT:-900}"   # native compile is slow
+else
+  BUNDLE_TIMEOUT="${EXPO_SKILL_EVAL_BUNDLE_TIMEOUT:-240}"
+fi
+LOG="${OUT%.png}.metro.log"
+
+mkdir -p "$(dirname "$OUT")"
+
+# Free the port up front in case a previous run (or a crash) left Metro on it,
+# so `expo start` binds the port we expect instead of silently incrementing.
+# Runs inside this script, so the eval harness never needs ad-hoc lsof/kill.
+lsof -ti "tcp:$PORT" -sTCP:LISTEN 2>/dev/null | xargs kill -9 2>/dev/null || true
+
+if ! xcrun simctl list devices booted | grep -q '(Booted)'; then
+  UDID="$(xcrun simctl list devices available | grep 'iPhone' | tail -1 | grep -oE '[0-9A-F-]{36}')"
+  if [[ -z "$UDID" ]]; then
+    echo "error: no available iPhone simulator found" >&2
+    exit 1
+  fi
+  echo "booting simulator $UDID..." >&2
+  xcrun simctl boot "$UDID"
+  open -a Simulator
+  xcrun simctl bootstatus "$UDID"
+fi
+
+# expo-go: --ios installs Expo Go when missing; its own open is unreliable if a
+# previous experience is foregrounded, so we relaunch deterministically below.
+# dev-build: expo run:ios prebuilds + native-compiles a dev client, installs and
+# launches it on the simulator, and starts Metro — no Expo Go involved.
+if [[ "$RUNNER" == "dev-build" ]]; then
+  # Pass --port so Metro binds to $PORT and the health-check curl matches.
+  (cd "$PROJECT_PATH" && exec env -u CI bunx expo run:ios --port "$PORT") </dev/null >"$LOG" 2>&1 &
+else
+  (cd "$PROJECT_PATH" && exec env -u CI REACT_NATIVE_PACKAGER_HOSTNAME=127.0.0.1 bunx expo start --port "$PORT" --ios) </dev/null >"$LOG" 2>&1 &
+fi
+METRO_PID=$!
+cleanup() {
+  kill "$METRO_PID" 2>/dev/null
+  lsof -ti "tcp:$PORT" -sTCP:LISTEN 2>/dev/null | xargs kill -9 2>/dev/null || true
+  wait "$METRO_PID" 2>/dev/null
+}
+trap cleanup EXIT
+
+DEADLINE=$((SECONDS + BUNDLE_TIMEOUT))
+STATUS=0
+
+until curl -sf "http://localhost:$PORT/status" >/dev/null; do
+  if ! kill -0 "$METRO_PID" 2>/dev/null || ((SECONDS > DEADLINE)); then
+    echo "error: Metro did not come up. Log tail:" >&2
+    tail -40 "$LOG" >&2
+    exit 1
+  fi
+  sleep 2
+done
+# Expo Go only: wait for Expo Go to install, then relaunch the experience
+# deterministically. dev-build skips this — expo run:ios launches the dev client.
+if [[ "$RUNNER" != "dev-build" ]]; then
+  until xcrun simctl get_app_container booted host.exp.Exponent >/dev/null 2>&1; do
+    if ((SECONDS > DEADLINE)); then
+      echo "error: Expo Go was not installed on the simulator. Log tail:" >&2
+      tail -40 "$LOG" >&2
+      exit 1
+    fi
+    sleep 2
+  done
+  # Terminate any running Expo Go so a stale experience can't stay foregrounded,
+  # then open the project URL explicitly.
+  xcrun simctl terminate booted host.exp.Exponent 2>/dev/null || true
+  sleep 2
+  xcrun simctl openurl booted "exp://127.0.0.1:$PORT"
+fi
+
+until grep -q 'Bundled' "$LOG"; do
+  if ! kill -0 "$METRO_PID" 2>/dev/null; then
+    echo "error: Metro exited before bundling. Log tail:" >&2
+    tail -40 "$LOG" >&2
+    STATUS=1
+    break
+  fi
+  if ((SECONDS > DEADLINE)); then
+    echo "error: timed out after ${BUNDLE_TIMEOUT}s waiting for bundle. Log tail:" >&2
+    tail -40 "$LOG" >&2
+    STATUS=1
+    break
+  fi
+  sleep 2
+done
+
+# dev-build: after bundling, relaunch the app so it is reliably in the
+# foreground. Use xcrun simctl launch (not openurl) to avoid the "Open in X?"
+# confirmation dialog that xcrun simctl openurl triggers on the iOS Simulator.
+# expo run:ios embeds the Metro URL in the build, so the dev client auto-connects.
+if [[ "$RUNNER" == "dev-build" ]]; then
+  BUNDLE_ID="$(node -e "try{var a=require('$PROJECT_PATH/app.json');console.log((a.expo&&a.expo.ios&&a.expo.ios.bundleIdentifier)||'com.exposkilleval.fixture')}catch(e){console.log('com.exposkilleval.fixture')}" 2>/dev/null || echo 'com.exposkilleval.fixture')"
+  xcrun simctl terminate booted "$BUNDLE_ID" 2>/dev/null || true
+  sleep 2
+  xcrun simctl launch --terminate-running-process booted "$BUNDLE_ID" >/dev/null 2>&1 || true
+  sleep 3
+fi
+
+sleep "$SETTLE"
+xcrun simctl io booted screenshot "$OUT" || STATUS=1
+# Raw simulator captures are 3x retina (~2600px tall) and overflow the eval
+# viewer's window. Downscale to a review/grading-friendly size.
+if [[ -f "$OUT" ]]; then
+  sips -Z "${EXPO_SKILL_EVAL_MAX_DIM:-600}" "$OUT" >/dev/null 2>&1 || true
+fi
+echo "screenshot: $OUT"
+echo "metro log: $LOG"
+exit "$STATUS"
diff --git a/.agents/skills/expo-skill-eval/scripts/snapshot-web.sh b/.agents/skills/expo-skill-eval/scripts/snapshot-web.sh
new file mode 100755
index 0000000..64990a3
--- /dev/null
+++ b/.agents/skills/expo-skill-eval/scripts/snapshot-web.sh
@@ -0,0 +1,61 @@
+#!/usr/bin/env bash
+# Run an Expo app's web target and capture a browser screenshot. (Phase 4 -
+# only for eval cases whose runtime.platforms includes "web".)
+#
+# Usage: snapshot-web.sh <project-path> <output-png> [port] [settle-seconds]
+#
+# Starts Metro with `expo start --web`, waits for the dev server to respond,
+# then screenshots with Playwright's CLI at an iPhone-ish viewport. The first
+# run downloads Chromium via `bunx playwright install chromium`.
+set -uo pipefail
+
+PROJECT_PATH="${1:?usage: snapshot-web.sh <project-path> <output-png> [port] [settle-seconds]}"
+OUT="${2:?usage: snapshot-web.sh <project-path> <output-png> [port] [settle-seconds]}"
+PORT="${3:-8081}"
+SETTLE="${4:-8}"
+SERVER_TIMEOUT="${EXPO_SKILL_EVAL_BUNDLE_TIMEOUT:-240}"
+LOG="${OUT%.png}.metro.log"
+
+mkdir -p "$(dirname "$OUT")"
+
+# Free the port up front in case a previous run (or a crash) left Metro on it,
+# so `expo start` binds the port we expect instead of silently incrementing.
+# Runs inside this script, so the eval harness never needs ad-hoc lsof/kill.
+lsof -ti "tcp:$PORT" -sTCP:LISTEN 2>/dev/null | xargs kill -9 2>/dev/null || true
+
+bunx playwright install chromium >/dev/null 2>&1 || true
+
+(cd "$PROJECT_PATH" && exec env -u CI bunx expo start --port "$PORT" --web) </dev/null >"$LOG" 2>&1 &
+METRO_PID=$!
+cleanup() {
+  kill "$METRO_PID" 2>/dev/null
+  pkill -f "expo start --port $PORT" 2>/dev/null
+  wait "$METRO_PID" 2>/dev/null
+}
+trap cleanup EXIT
+
+DEADLINE=$((SECONDS + SERVER_TIMEOUT))
+until curl -sf "http://localhost:$PORT" >/dev/null; do
+  if ! kill -0 "$METRO_PID" 2>/dev/null || ((SECONDS > DEADLINE)); then
+    echo "error: web dev server did not come up. Log tail:" >&2
+    tail -40 "$LOG" >&2
+    exit 1
+  fi
+  sleep 2
+done
+
+STATUS=0
+bunx playwright screenshot \
+  --browser chromium \
+  --viewport-size "390,844" \
+  --wait-for-timeout "$((SETTLE * 1000))" \
+  "http://localhost:$PORT" "$OUT" || STATUS=1
+
+# Keep parity with the device snapshot scripts: cap the largest dimension so
+# screenshots fit the eval viewer's window.
+if [[ -f "$OUT" ]]; then
+  sips -Z "${EXPO_SKILL_EVAL_MAX_DIM:-600}" "$OUT" >/dev/null 2>&1 || true
+fi
+echo "screenshot: $OUT"
+echo "metro log: $LOG"
+exit "$STATUS"
diff --git a/.agents/skills/expo-skill-feedback/SKILL.md b/.agents/skills/expo-skill-feedback/SKILL.md
new file mode 100644
index 0000000..2076096
--- /dev/null
+++ b/.agents/skills/expo-skill-feedback/SKILL.md
@@ -0,0 +1,87 @@
+---
+name: expo-skill-feedback
+description: 'Submit feedback on an Expo skill—or Expo itself—and control bundled anonymous usage telemetry (off by default / opt-in). Submit feedback with: npx --yes submit-expo-feedback@latest "ACTIONABLE_FEEDBACK". Optionally add either or both: --category "CATEGORY" and --subject "SUBJECT". Replace the uppercase placeholders before running. Use when a skill was useful, confusing, broken, missing context, or worth improving; when Expo, Expo CLI, EAS CLI, docs, or MCP worked well or fell short; when an AI agent repeatedly failed, got stuck, or needed the user to take over an Expo task (report it as an eval candidate); or when the user explicitly asks to enable or disable telemetry (tracking), check its status, or understand what it collects.'
+---
+
+# Expo Skill Feedback
+
+Help Expo improve by sharing specific feedback about what worked well or what fell short. Feedback
+submission is independent of usage telemetry and does not require enabling it.
+
+## Submit feedback
+
+```bash
+npx --yes submit-expo-feedback@latest "<ACTIONABLE_FEEDBACK>"
+```
+
+Add either optional flag independently when it provides useful context:
+
+```bash
+npx --yes submit-expo-feedback@latest --category "<CATEGORY>" --subject "<SUBJECT>" "<ACTIONABLE_FEEDBACK>"
+```
+
+`--category` defaults to `unknown`, and `--subject` may be omitted when there is no specific target.
+When including them, choose the values that most precisely identify what the feedback is about:
+
+| Category | Subject |
+| --- | --- |
+| `skills` | Exact skill name from its frontmatter, such as `expo-router` |
+| `docs` | Full Expo documentation URL |
+| `mcp` | Exact MCP tool name used |
+| `expo-cli` | Full Expo CLI command, such as `npx expo install` |
+| `eas-cli` | Full EAS CLI command, such as `eas build` |
+| `evals` | Expo package or command the failed task involves, else a capability phrase, such as `expo-router` or `eas build` |
+| `unknown` | Concise Expo product, package, feature, or other topic |
+
+In the final argument, say what helped and why, or provide the relevant context, expected behavior,
+and what happened instead. Do not include secrets, source code, personal data, long prompts, or stack traces.
+
+## Eval candidates: tasks that broke the model
+
+Expo turns hard real-world tasks into agent evals: anything Expo an agent can attempt — framework,
+EAS, tooling — qualifies, whether or not a skill was involved. The signal worth sending is a task an
+AI agent could not complete cleanly despite real effort: several failed attempts, a build or screen
+that never worked, or the user stepping in to fix it manually. Never submit quick slips the agent
+corrected itself, more than one candidate per session, or a task already reported.
+
+When such a failure happens — or the user says a model failed at an Expo task — show the user the exact
+submission you intend to send and get approval; the Task field must describe the Expo-technical
+shape of the task, never the user's product or business context. Without a user to approve it
+(headless or CI runs), do not submit. Then run from the failing app's directory (the CLI attaches
+the SDK and package versions, agent harness, and platform automatically) with `--category evals`,
+`--subject` naming the Expo package or command involved (a capability phrase only when no single
+package fits), and this structure in the final argument:
+
+```text
+Task: <what was asked, self-contained>.
+Expected: <observable success criteria>.
+Actual: <what the agent did instead>.
+Wrong approach: <the specific mistake, such as a wrong API, hallucinated prop, or bad pattern>.
+Evidence: <model name, attempts, how it was solved — or never was; omit what you cannot verify>.
+```
+
+A good candidate is solvable (eventually done or clearly doable), verifiable (success is
+observable), and specific. Mention only environment details the CLI cannot see, such as other key
+packages or a freshly created app. Describe code; do not paste it. If the command fails with an
+error naming `evals` as an invalid category, resend once with `--category unknown` and the same
+subject prefixed `eval-candidate: `; on any other error, do not resend.
+
+## Usage telemetry
+
+Automatic skill usage telemetry is separate from feedback and **off by default**. Never enable it
+without an explicit user request. Use the following script with `--on`, `--off`, or `--status`:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/skills/expo-skill-feedback/scripts/telemetry.cjs" --status
+```
+
+Environment equivalents are `EXPO_SKILLS_TELEMETRY=1` to enable and
+`EXPO_SKILLS_TELEMETRY=0` or `DO_NOT_TRACK=1` to disable. CI never sends telemetry.
+
+## 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-skill-feedback" "<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.
diff --git a/.agents/skills/expo-skill-feedback/agents/openai.yaml b/.agents/skills/expo-skill-feedback/agents/openai.yaml
new file mode 100644
index 0000000..2beddad
--- /dev/null
+++ b/.agents/skills/expo-skill-feedback/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Expo Skill Feedback"
+  short_description: "Help Expo improve with feedback, eval candidates, and usage telemetry"
+  default_prompt: "Use $expo-skill-feedback to help Expo improve by submitting feedback, reporting an Expo task an AI agent failed at as an eval candidate, or controlling Expo skills telemetry."
diff --git a/.agents/skills/expo-skill-feedback/scripts/skill-event.cjs b/.agents/skills/expo-skill-feedback/scripts/skill-event.cjs
new file mode 100644
index 0000000..1ef47a8
--- /dev/null
+++ b/.agents/skills/expo-skill-feedback/scripts/skill-event.cjs
@@ -0,0 +1,180 @@
+#!/usr/bin/env node
+// Submit a `skill_invoked` event to PostHog — fire-and-forget.
+//
+// Invoked two ways, both cross-platform (plain `node`, no shell wrapper, so it runs the
+// same on macOS / Linux / Windows):
+//   1. From Claude Code hooks (../../../hooks/hooks.json) as
+//      `node skill-event.cjs --skill auto --initiator <ai|user> --plugin-root <dir> --detach --quiet`.
+//      The foreground process reads the hook payload from stdin, resolves which skill ran,
+//      runs the cheap local gates, then — for `--detach` — re-launches a DETACHED copy of
+//      itself to do the network POST and returns immediately, so the agent turn never blocks.
+//   2. Directly (that detached child, or manual / --dry-run testing) with a resolved
+//      `--skill <name>`, which builds the event and sends it inline.
+
+const fs = require("fs");
+const path = require("path");
+
+const {
+  POSTHOG_PROJECT_API_KEY,
+  SOURCE,
+  telemetryActive,
+  telemetryConfigured,
+  detectHarness,
+  platformProps,
+  telemetryIdentity,
+  sendToPosthog,
+} = require("./telemetry_common.cjs");
+
+const EVENT = "skill_invoked";
+
+function parseArgs(argv) {
+  const args = { skill: "", agentHarness: "", initiator: "", pluginRoot: "", dryRun: false, quiet: false, detach: false };
+  for (let i = 0; i < argv.length; i++) {
+    const flag = argv[i];
+    const next = () => argv[++i] || "";
+    switch (flag) {
+      case "--skill": args.skill = next(); break;
+      case "--agent-harness": args.agentHarness = next(); break;
+      case "--initiator": args.initiator = next(); break;
+      case "--plugin-root": args.pluginRoot = next(); break;
+      case "--detach": args.detach = true; break;
+      case "--dry-run": args.dryRun = true; break;
+      case "--quiet": args.quiet = true; break;
+      default: break; // ignore unknown flags
+    }
+  }
+  return args;
+}
+
+// Read the hook payload from stdin (fd 0) and parse it as JSON. Only used to resolve
+// `--skill auto` in the foreground hook process; the detached sender is handed the
+// already-resolved name and never touches stdin.
+function readHookInput() {
+  try {
+    if (process.stdin.isTTY) return {};
+    const raw = (fs.readFileSync(0, "utf8") || "").trim(); // fd 0 = stdin
+    if (!raw) return {};
+    const parsed = JSON.parse(raw);
+    return parsed && typeof parsed === "object" && !Array.isArray(parsed) ? parsed : {};
+  } catch {
+    return {};
+  }
+}
+
+// Resolve the invoked skill name from the hook payload. The name arrives in different
+// fields across payload shapes, so check every plausible location:
+//   - Claude Code Skill tool:        tool_input.skill        (e.g. "expo:eas-observe")
+//   - Claude Code /slash command:    command_name            (UserPromptExpansion)
+//   - other payload shapes:          tool_input.skill_name, top-level skill / skill_name
+// Namespaced names must be OURS: "expo:<skill>" keeps the final segment, any other
+// namespace is dropped — another plugin's "foo:expo-ui" must not count as ours, and
+// skillBelongsToPlugin() can't tell name collisions apart. Bare names stay permissive
+// and are scoped by skillBelongsToPlugin() downstream.
+function skillFromHook(hookInput) {
+  const ti = hookInput && typeof hookInput.tool_input === "object" && hookInput.tool_input ? hookInput.tool_input : {};
+  const raw = String(
+    ti.skill || ti.skill_name || hookInput.command_name || hookInput.skill || hookInput.skill_name || ""
+  ).trim().replace(/^\//, ""); // tolerate a leading "/" from slash-command payloads
+  if (!raw.includes(":")) return raw;
+  const sep = raw.lastIndexOf(":");
+  return raw.slice(0, sep) === "expo" ? raw.slice(sep + 1) : "";
+}
+
+function pluginRootFor(args) {
+  // Self-derive from this script's location: <root>/skills/expo-skill-feedback/scripts.
+  return args.pluginRoot || path.resolve(__dirname, "..", "..", "..");
+}
+
+// Only emit for skills that belong to THIS plugin (so we never track other plugins'
+// or the user's own skills). Confirms <pluginRoot>/skills/<skill>/SKILL.md exists.
+// The skill name must be a single kebab-case segment — this also blocks path traversal
+// (e.g. "../../x") from a malformed payload reaching path.join or the event property.
+function skillBelongsToPlugin(skill, pluginRoot) {
+  if (!skill || !pluginRoot) return false;
+  if (!/^[a-z0-9][a-z0-9-]*$/.test(skill)) return false;
+  try { return fs.existsSync(path.join(pluginRoot, "skills", skill, "SKILL.md")); }
+  catch { return false; }
+}
+
+function eventPayload(skill, args) {
+  const agentHarness = args.agentHarness.trim() || detectHarness();
+  const initiator = args.initiator.trim();
+  const timestamp = new Date().toISOString();
+  const [distinctId, identityProperties] = telemetryIdentity(agentHarness, { createInstallation: !args.dryRun });
+
+  const properties = {
+    $process_person_profile: false,
+    source: SOURCE,
+    skill,
+    agent_harness: agentHarness,
+    ...(initiator ? { initiator } : {}),
+    ...platformProps(),
+    ...identityProperties,
+  };
+
+  return { api_key: POSTHOG_PROJECT_API_KEY, event: EVENT, distinct_id: distinctId, timestamp, properties };
+}
+
+// Re-launch this script DETACHED to perform the network POST off the agent's critical
+// path — the cross-platform equivalent of `node skill-event.cjs … &`. We pass the already
+// resolved `--skill <name>` (not "auto") and drop `--detach`, so the child sends inline and
+// never reads stdin or re-detaches. It runs under the same runtime that launched us
+// (process.execPath = node or bun) and inherits our env (CLAUDECODE, EXPO_SKILLS_*, …).
+// windowsHide avoids a console-window flash on Windows; failures are ignored (best-effort).
+function spawnDetachedSend(skill, args) {
+  try {
+    const { spawn } = require("child_process");
+    const childArgs = [__filename, "--skill", skill, "--quiet"];
+    if (args.initiator.trim()) childArgs.push("--initiator", args.initiator.trim());
+    if (args.agentHarness.trim()) childArgs.push("--agent-harness", args.agentHarness.trim());
+    const child = spawn(process.execPath, childArgs, { detached: true, stdio: "ignore", windowsHide: true });
+    child.unref();
+  } catch {
+    // best-effort: if the child can't be spawned, skip the send rather than block
+  }
+}
+
+async function main(argv) {
+  const args = parseArgs(argv);
+
+  // Resolve which skill ran. `--skill auto` means "read it from the hook payload on
+  // stdin" — which must happen HERE, in the foreground hook process, because a detached
+  // child's stdin is /dev/null.
+  let skill = args.skill.trim();
+  if (skill === "auto") skill = skillFromHook(readHookInput());
+
+  // Cheap, local, no-network gates: decide up front whether anything will be sent, so the
+  // common "not an Expo skill / opted out" cases cost nothing and never spawn a child.
+  if (!skill) return 0;                                            // not a skill invocation
+  if (!args.dryRun && !telemetryActive()) return 0;                // opt-in: off until enabled (dry-run inspects regardless)
+  if (!telemetryConfigured() && !args.dryRun) return 0;            // no key in this build (e.g. a fork) -> inert
+  if (!skillBelongsToPlugin(skill, pluginRootFor(args))) return 0; // not one of ours
+
+  // Hook path: hand the network POST to a detached copy of ourselves so the turn never
+  // blocks on it, then return immediately. (--dry-run stays inline so it can be inspected.)
+  if (args.detach && !args.dryRun) {
+    spawnDetachedSend(skill, args);
+    return 0;
+  }
+
+  const payload = eventPayload(skill, args);
+
+  if (args.dryRun) {
+    console.log(JSON.stringify({ ...payload, api_key: "phc_..." }, null, 2));
+    return 0;
+  }
+
+  try {
+    await sendToPosthog(payload, { userAgent: "expo-skills/skill-event", timeoutMs: 3000 });
+  } catch (err) {
+    if (!args.quiet) console.error(`skill-event: ${err.message}`);
+    return args.quiet ? 0 : 1;
+  }
+
+  if (!args.quiet) console.log(`sent ${EVENT}: ${payload.properties.skill} (${payload.properties.initiator || "?"})`);
+  return 0;
+}
+
+main(process.argv.slice(2))
+  .then((code) => process.exit(code))
+  .catch(() => process.exit(0));
diff --git a/.agents/skills/expo-skill-feedback/scripts/telemetry.cjs b/.agents/skills/expo-skill-feedback/scripts/telemetry.cjs
new file mode 100644
index 0000000..718e4fe
--- /dev/null
+++ b/.agents/skills/expo-skill-feedback/scripts/telemetry.cjs
@@ -0,0 +1,65 @@
+#!/usr/bin/env node
+// Turn Expo skills usage telemetry on or off, or check its status.
+//
+// Telemetry is OFF by default (opt-in) — nothing is sent until you enable it here or
+// via EXPO_SKILLS_TELEMETRY=1. Usage:
+//   node telemetry.cjs --status   # show whether telemetry is on/off and why
+//   node telemetry.cjs --on       # enable  (writes the opt-in marker)
+//   node telemetry.cjs --off      # disable (removes the opt-in marker — the default)
+//
+// The opt-in marker is the reliable switch: it works no matter how the agent was
+// launched. EXPO_SKILLS_TELEMETRY=1/0 and DO_NOT_TRACK also work (handy for CI), but
+// env vars don't always reach hook subprocesses.
+
+const fs = require("fs");
+const path = require("path");
+const {
+  OPT_IN_PATH,
+  telemetryActive,
+  telemetryEnvSignal,
+  telemetryConfigured,
+  isCI,
+} = require("./telemetry_common.cjs");
+
+// One-line explanation of the current state (mirrors telemetryActive()'s precedence).
+function reason() {
+  const env = telemetryEnvSignal();
+  if (env === "off") return "env var (EXPO_SKILLS_TELEMETRY=0 / DO_NOT_TRACK)";
+  if (isCI()) return "CI environment (telemetry never emits from CI)";
+  if (env === "on") return "env var EXPO_SKILLS_TELEMETRY=1";
+  if (safeExists(OPT_IN_PATH)) return `opt-in marker (${OPT_IN_PATH})`;
+  return "default (opt-in — off until enabled)";
+}
+
+function safeExists(p) { try { return fs.existsSync(p); } catch { return false; } }
+
+function printStatus() {
+  const on = telemetryActive();
+  if (on && !telemetryConfigured()) {
+    console.log(`Expo skills telemetry: ON via ${reason()}, but no PostHog key in this build (stripped to placeholder) — nothing is sent.`);
+  } else if (on) {
+    console.log(`Expo skills telemetry: ON (anonymous) — ${reason()}. Turn off with: telemetry.cjs --off`);
+  } else {
+    console.log(`Expo skills telemetry: OFF — ${reason()}. Turn on with: telemetry.cjs --on (or EXPO_SKILLS_TELEMETRY=1)`);
+  }
+}
+
+const cmd = process.argv[2];
+
+if (cmd === "--on" || cmd === "--enable") {
+  fs.mkdirSync(path.dirname(OPT_IN_PATH), { recursive: true, mode: 0o700 });
+  fs.writeFileSync(OPT_IN_PATH, "Expo skills telemetry enabled by user.\n");
+  console.log(`Telemetry enabled — wrote ${OPT_IN_PATH}`);
+  if (telemetryEnvSignal() === "off") console.log("Note: an env var (EXPO_SKILLS_TELEMETRY=0 / DO_NOT_TRACK) still forces it OFF; unset it to send.");
+  else if (isCI()) console.log("Note: this looks like CI, where telemetry stays OFF regardless.");
+  console.log("Turn off any time with: telemetry.cjs --off");
+} else if (cmd === "--off" || cmd === "--disable") {
+  try { fs.rmSync(OPT_IN_PATH, { force: true }); } catch {}
+  console.log("Telemetry off — removed the opt-in marker (off is the default).");
+  if (telemetryEnvSignal() === "on") console.log("Note: EXPO_SKILLS_TELEMETRY=1 still forces it ON; unset it to stay off.");
+} else if (cmd === "--status" || cmd === undefined) {
+  printStatus();
+} else {
+  console.error(`Unknown option: ${cmd}\nUsage: telemetry.cjs [--status | --on | --off]`);
+  process.exit(2);
+}
diff --git a/.agents/skills/expo-skill-feedback/scripts/telemetry_common.cjs b/.agents/skills/expo-skill-feedback/scripts/telemetry_common.cjs
new file mode 100644
index 0000000..41fc52e
--- /dev/null
+++ b/.agents/skills/expo-skill-feedback/scripts/telemetry_common.cjs
@@ -0,0 +1,171 @@
+// Shared helpers for Expo skills PostHog telemetry.
+//
+// Zero npm dependencies — Node.js built-ins only (crypto, fs, https, os, path).
+// Node is a hard requirement for Expo development, so it is available wherever
+// these skills are used. If `node` is ever missing, the calling hook simply
+// fails non-blocking and no telemetry is sent.
+
+const crypto = require("crypto");
+const fs = require("fs");
+const https = require("https");
+const os = require("os");
+const path = require("path");
+
+const POSTHOG_HOST = "https://us.i.posthog.com";
+
+// PostHog project API key. This is a *write-only, public* ingestion key — the
+// same kind embedded in browser snippets — so it is safe to commit. Override
+// per environment with EXPO_SKILLS_POSTHOG_KEY (e.g. a staging project).
+// NOTE: never put a PostHog *personal* API key (phx_...) here — those are secret.
+const POSTHOG_PROJECT_API_KEY =
+  process.env.EXPO_SKILLS_POSTHOG_KEY || "phc_w8xRytdAAwkV3oExnuUozqH64PMzCmDLnyoChpPBcNXs";
+
+const SOURCE = "expo-skills";
+const INSTALLATION_ID_PATH = path.join(os.homedir(), ".expo-skills", "installation-id");
+
+// Opt-in is the model: telemetry is OFF by default and only sends once the user
+// explicitly enables it. This is the one product knob — flip to true for an opt-out
+// (on-by-default) model instead.
+const DEFAULT_ON = false;
+
+// Persistent opt-in marker. Its presence turns telemetry on across sessions, regardless
+// of how the agent was launched (env vars don't always reach hook subprocesses).
+// Written / removed by scripts/telemetry.cjs --on / --off.
+const OPT_IN_PATH = path.join(os.homedir(), ".expo-skills", "opt-in");
+
+// CI detection — never emit from automated environments so usage data reflects real
+// humans. Honors the common CI=true convention plus major providers' signals.
+function isCI() {
+  const ci = String(process.env.CI || "").trim().toLowerCase();
+  if (ci && ci !== "0" && ci !== "false") return true;
+  return Boolean(
+    process.env.GITHUB_ACTIONS ||
+      process.env.GITLAB_CI ||
+      process.env.CIRCLECI ||
+      process.env.TRAVIS ||
+      process.env.BUILDKITE ||
+      process.env.JENKINS_URL ||
+      process.env.TEAMCITY_VERSION ||
+      process.env.TF_BUILD
+  );
+}
+
+// Explicit on/off intent from env vars: returns "on" | "off" | null.
+//   DO_NOT_TRACK=1                        -> off (https://consoledonottrack.com)
+//   EXPO_SKILLS_TELEMETRY=0/off/false/no  -> off
+//   EXPO_SKILLS_TELEMETRY=1/on/true/yes   -> on
+function telemetryEnvSignal() {
+  const dnt = String(process.env.DO_NOT_TRACK || "").trim().toLowerCase();
+  if (dnt && dnt !== "0" && dnt !== "false") return "off";
+  const flag = String(process.env.EXPO_SKILLS_TELEMETRY || "").trim().toLowerCase();
+  if (["0", "false", "off", "no"].includes(flag)) return "off";
+  if (["1", "true", "on", "yes"].includes(flag)) return "on";
+  return null;
+}
+
+// Master gate. Nothing is sent unless this returns true. Precedence (highest first):
+//   1. explicit env off (DO_NOT_TRACK / EXPO_SKILLS_TELEMETRY=0) -> off
+//   2. CI                                                        -> off (never emit from bots)
+//   3. explicit env on  (EXPO_SKILLS_TELEMETRY=1)                -> on
+//   4. persistent opt-in marker (telemetry.cjs --on)            -> on
+//   5. default                                                   -> DEFAULT_ON (off = opt-in)
+// So explicit-off and CI always win; otherwise it's on only when explicitly enabled.
+function telemetryActive() {
+  const env = telemetryEnvSignal();
+  if (env === "off") return false;
+  if (isCI()) return false;
+  if (env === "on") return true;
+  try { if (fs.existsSync(OPT_IN_PATH)) return true; } catch {}
+  return DEFAULT_ON;
+}
+
+// A real key ships in this file, so this check passes by default. This guard only
+// makes the scripts inert if someone strips the key (e.g. a fork or private build).
+function telemetryConfigured() {
+  const key = String(POSTHOG_PROJECT_API_KEY || "").trim();
+  return key.length > 0 && key !== "phc_REPLACE_ME";
+}
+
+// Best-effort agent-harness label for the event (default when --agent-harness isn't passed).
+function detectHarness() {
+  if (process.env.CLAUDECODE) return "claude-code";
+  if (process.env.CODEX_SANDBOX || process.env.CODEX_SANDBOX_NETWORK_DISABLED ||
+      String(process.env.AGENT || "").toLowerCase() === "codex") return "codex";
+  return "unknown";
+}
+
+// Friendly OS + CPU arch for event properties (non-PII).
+function platformProps() {
+  const osName = { darwin: "macos", win32: "windows" }[process.platform] || process.platform;
+  return { os: osName, arch: process.arch };
+}
+
+// Random, anonymous, per-install id — created once at 0600, only its hash is ever sent.
+function readInstallationId(create = true) {
+  try {
+    if (fs.existsSync(INSTALLATION_ID_PATH)) {
+      const existing = fs.readFileSync(INSTALLATION_ID_PATH, "utf8").trim();
+      if (existing) return existing;
+    }
+    if (!create) return null;
+    fs.mkdirSync(path.dirname(INSTALLATION_ID_PATH), { recursive: true, mode: 0o700 });
+    try { fs.chmodSync(path.dirname(INSTALLATION_ID_PATH), 0o700); } catch {}
+    const installationId = crypto.randomUUID().replace(/-/g, "");
+    try {
+      // 'wx' = O_CREAT | O_EXCL | O_WRONLY — atomic create, fails if it exists.
+      const fd = fs.openSync(INSTALLATION_ID_PATH, "wx", 0o600);
+      try { fs.writeFileSync(fd, installationId + "\n"); } finally { fs.closeSync(fd); }
+      return installationId;
+    } catch (err) {
+      if (err && err.code === "EEXIST") return fs.readFileSync(INSTALLATION_ID_PATH, "utf8").trim() || null;
+      throw err;
+    }
+  } catch {
+    return null;
+  }
+}
+
+function telemetryIdentity(agentHarness, { createInstallation = true } = {}) {
+  const id = readInstallationId(createInstallation);
+  const installHash = id ? crypto.createHash("sha256").update(id).digest("hex").slice(0, 32) : null;
+  if (installHash) return [`expo-skills-installation:${installHash}`, { installation_id_hash: installHash }];
+  return [`expo-skills-events:${agentHarness}`, {}];
+}
+
+function sendToPosthog(payload, { userAgent, timeoutMs }) {
+  return new Promise((resolve, reject) => {
+    const url = new URL("/i/v0/e/", POSTHOG_HOST);
+    const body = Buffer.from(JSON.stringify(payload), "utf8");
+    const req = https.request(url, {
+      method: "POST",
+      headers: { "Content-Type": "application/json", "Content-Length": body.length, "User-Agent": userAgent },
+      timeout: timeoutMs,
+    }, (res) => {
+      const chunks = [];
+      res.on("data", (c) => chunks.push(c));
+      res.on("end", () => {
+        const status = res.statusCode || 0;
+        if (status >= 200 && status < 300) return resolve();
+        reject(new Error(`HTTP ${status} ${Buffer.concat(chunks).toString("utf8")}`));
+      });
+    });
+    req.on("timeout", () => req.destroy(new Error("request timed out")));
+    req.on("error", reject);
+    req.write(body);
+    req.end();
+  });
+}
+
+module.exports = {
+  POSTHOG_PROJECT_API_KEY,
+  SOURCE,
+  OPT_IN_PATH,
+  telemetryActive,
+  telemetryEnvSignal,
+  telemetryConfigured,
+  detectHarness,
+  isCI,
+  platformProps,
+  telemetryIdentity,
+  sendToPosthog,
+};
diff --git a/.agents/skills/expo-tailwind-setup/SKILL.md b/.agents/skills/expo-tailwind-setup/SKILL.md
new file mode 100644
index 0000000..a9d5822
--- /dev/null
+++ b/.agents/skills/expo-tailwind-setup/SKILL.md
@@ -0,0 +1,488 @@
+---
+name: expo-tailwind-setup
+description: Framework (OSS). Set up Tailwind CSS v4 in Expo with react-native-css and NativeWind v5 for universal styling
+version: 1.0.0
+license: MIT
+---
+
+# Tailwind CSS Setup for Expo with react-native-css
+
+This guide covers setting up Tailwind CSS v4 in Expo using react-native-css and NativeWind v5 for universal styling across iOS, Android, and Web.
+
+## Overview
+
+This setup uses:
+
+- **Tailwind CSS v4** - Modern CSS-first configuration
+- **react-native-css** - CSS runtime for React Native
+- **NativeWind v5** - Metro transformer for Tailwind in React Native
+- **@tailwindcss/postcss** - PostCSS plugin for Tailwind v4
+
+## Installation
+
+```bash
+# Install dependencies
+npx expo install tailwindcss@^4 nativewind@5.0.0-preview.2 react-native-css@0.0.0-nightly.5ce6396 @tailwindcss/postcss tailwind-merge clsx
+```
+
+Add resolutions for lightningcss compatibility:
+
+```json
+// package.json
+{
+  "resolutions": {
+    "lightningcss": "1.30.1"
+  }
+}
+```
+
+- autoprefixer is not needed in Expo because of lightningcss
+- postcss is included in expo by default
+
+## Configuration Files
+
+### Metro Config
+
+Create or update `metro.config.js`:
+
+```js
+// metro.config.js
+const { getDefaultConfig } = require("expo/metro-config");
+const { withNativewind } = require("nativewind/metro");
+
+/** @type {import('expo/metro-config').MetroConfig} */
+const config = getDefaultConfig(__dirname);
+
+module.exports = withNativewind(config, {
+  // inline variables break PlatformColor in CSS variables
+  inlineVariables: false,
+  // We add className support manually
+  globalClassNamePolyfill: false,
+});
+```
+
+### PostCSS Config
+
+Create `postcss.config.mjs`:
+
+```js
+// postcss.config.mjs
+export default {
+  plugins: {
+    "@tailwindcss/postcss": {},
+  },
+};
+```
+
+### Global CSS
+
+Create `src/global.css`:
+
+```css
+@import "tailwindcss/theme.css" layer(theme);
+@import "tailwindcss/preflight.css" layer(base);
+@import "tailwindcss/utilities.css";
+
+/* Platform-specific font families */
+@media android {
+  :root {
+    --font-mono: monospace;
+    --font-rounded: normal;
+    --font-serif: serif;
+    --font-sans: normal;
+  }
+}
+
+@media ios {
+  :root {
+    --font-mono: ui-monospace;
+    --font-serif: ui-serif;
+    --font-sans: system-ui;
+    --font-rounded: ui-rounded;
+  }
+}
+```
+
+## IMPORTANT: No Babel Config Needed
+
+With Tailwind v4 and NativeWind v5, you do NOT need a babel.config.js for Tailwind. Remove any NativeWind babel presets if present:
+
+```js
+// DELETE babel.config.js if it only contains NativeWind config
+// The following is NO LONGER needed:
+// module.exports = function (api) {
+//   api.cache(true);
+//   return {
+//     presets: [
+//       ["babel-preset-expo", { jsxImportSource: "nativewind" }],
+//       "nativewind/babel",
+//     ],
+//   };
+// };
+```
+
+## CSS Component Wrappers
+
+Since react-native-css requires explicit CSS element wrapping, create reusable components:
+
+### Main Components (`src/tw/index.tsx`)
+
+```tsx
+import {
+  useCssElement,
+  useNativeVariable as useFunctionalVariable,
+} from "react-native-css";
+
+import { Link as RouterLink } from "expo-router";
+import Animated from "react-native-reanimated";
+import React from "react";
+import {
+  View as RNView,
+  Text as RNText,
+  Pressable as RNPressable,
+  ScrollView as RNScrollView,
+  TouchableHighlight as RNTouchableHighlight,
+  TextInput as RNTextInput,
+  StyleSheet,
+} from "react-native";
+
+// CSS-enabled Link
+export const Link = (
+  props: React.ComponentProps<typeof RouterLink> & { className?: string }
+) => {
+  return useCssElement(RouterLink, props, { className: "style" });
+};
+
+Link.Trigger = RouterLink.Trigger;
+Link.Menu = RouterLink.Menu;
+Link.MenuAction = RouterLink.MenuAction;
+Link.Preview = RouterLink.Preview;
+
+// CSS Variable hook
+export const useCSSVariable =
+  process.env.EXPO_OS !== "web"
+    ? useFunctionalVariable
+    : (variable: string) => `var(${variable})`;
+
+// View
+export type ViewProps = React.ComponentProps<typeof RNView> & {
+  className?: string;
+};
+
+export const View = (props: ViewProps) => {
+  return useCssElement(RNView, props, { className: "style" });
+};
+View.displayName = "CSS(View)";
+
+// Text
+export const Text = (
+  props: React.ComponentProps<typeof RNText> & { className?: string }
+) => {
+  return useCssElement(RNText, props, { className: "style" });
+};
+Text.displayName = "CSS(Text)";
+
+// ScrollView
+export const ScrollView = (
+  props: React.ComponentProps<typeof RNScrollView> & {
+    className?: string;
+    contentContainerClassName?: string;
+  }
+) => {
+  return useCssElement(RNScrollView, props, {
+    className: "style",
+    contentContainerClassName: "contentContainerStyle",
+  });
+};
+ScrollView.displayName = "CSS(ScrollView)";
+
+// Pressable
+export const Pressable = (
+  props: React.ComponentProps<typeof RNPressable> & { className?: string }
+) => {
+  return useCssElement(RNPressable, props, { className: "style" });
+};
+Pressable.displayName = "CSS(Pressable)";
+
+// TextInput
+export const TextInput = (
+  props: React.ComponentProps<typeof RNTextInput> & { className?: string }
+) => {
+  return useCssElement(RNTextInput, props, { className: "style" });
+};
+TextInput.displayName = "CSS(TextInput)";
+
+// AnimatedScrollView
+export const AnimatedScrollView = (
+  props: React.ComponentProps<typeof Animated.ScrollView> & {
+    className?: string;
+    contentClassName?: string;
+    contentContainerClassName?: string;
+  }
+) => {
+  return useCssElement(Animated.ScrollView, props, {
+    className: "style",
+    contentClassName: "contentContainerStyle",
+    contentContainerClassName: "contentContainerStyle",
+  });
+};
+
+// TouchableHighlight with underlayColor extraction
+function XXTouchableHighlight(
+  props: React.ComponentProps<typeof RNTouchableHighlight>
+) {
+  const { underlayColor, ...style } = StyleSheet.flatten(props.style) || {};
+  return (
+    <RNTouchableHighlight
+      underlayColor={underlayColor}
+      {...props}
+      style={style}
+    />
+  );
+}
+
+export const TouchableHighlight = (
+  props: React.ComponentProps<typeof RNTouchableHighlight>
+) => {
+  return useCssElement(XXTouchableHighlight, props, { className: "style" });
+};
+TouchableHighlight.displayName = "CSS(TouchableHighlight)";
+```
+
+### Image Component (`src/tw/image.tsx`)
+
+```tsx
+import { useCssElement } from "react-native-css";
+import React from "react";
+import { StyleSheet } from "react-native";
+import Animated from "react-native-reanimated";
+import { Image as RNImage } from "expo-image";
+
+const AnimatedExpoImage = Animated.createAnimatedComponent(RNImage);
+
+export type ImageProps = React.ComponentProps<typeof Image>;
+
+function CSSImage(props: React.ComponentProps<typeof AnimatedExpoImage>) {
+  // @ts-expect-error: Remap objectFit style to contentFit property
+  const { objectFit, objectPosition, ...style } =
+    StyleSheet.flatten(props.style) || {};
+
+  return (
+    <AnimatedExpoImage
+      contentFit={objectFit}
+      contentPosition={objectPosition}
+      {...props}
+      source={
+        typeof props.source === "string" ? { uri: props.source } : props.source
+      }
+      // @ts-expect-error: Style is remapped above
+      style={style}
+    />
+  );
+}
+
+export const Image = (
+  props: React.ComponentProps<typeof CSSImage> & { className?: string }
+) => {
+  return useCssElement(CSSImage, props, { className: "style" });
+};
+
+Image.displayName = "CSS(Image)";
+```
+
+### Animated Components (`src/tw/animated.tsx`)
+
+```tsx
+import * as TW from "./index";
+import RNAnimated from "react-native-reanimated";
+
+export const Animated = {
+  ...RNAnimated,
+  View: RNAnimated.createAnimatedComponent(TW.View),
+};
+```
+
+## Usage
+
+Import CSS-wrapped components from your tw directory:
+
+```tsx
+import { View, Text, ScrollView, Image } from "@/tw";
+
+export default function MyScreen() {
+  return (
+    <ScrollView className="flex-1 bg-white">
+      <View className="p-4 gap-4">
+        <Text className="text-xl font-bold text-gray-900">Hello Tailwind!</Text>
+        <Image
+          className="w-full h-48 rounded-lg object-cover"
+          source={{ uri: "https://example.com/image.jpg" }}
+        />
+      </View>
+    </ScrollView>
+  );
+}
+```
+
+## Custom Theme Variables
+
+Add custom theme variables in your global.css using `@theme`:
+
+```css
+@layer theme {
+  @theme {
+    /* Custom fonts */
+    --font-rounded: "SF Pro Rounded", sans-serif;
+
+    /* Custom line heights */
+    --text-xs--line-height: calc(1em / 0.75);
+    --text-sm--line-height: calc(1.25em / 0.875);
+    --text-base--line-height: calc(1.5em / 1);
+
+    /* Custom leading scales */
+    --leading-tight: 1.25em;
+    --leading-snug: 1.375em;
+    --leading-normal: 1.5em;
+  }
+}
+```
+
+## Platform-Specific Styles
+
+Use platform media queries for platform-specific styling:
+
+```css
+@media ios {
+  :root {
+    --font-sans: system-ui;
+    --font-rounded: ui-rounded;
+  }
+}
+
+@media android {
+  :root {
+    --font-sans: normal;
+    --font-rounded: normal;
+  }
+}
+```
+
+## Apple System Colors with CSS Variables
+
+Create a CSS file for Apple semantic colors:
+
+```css
+/* src/css/sf.css */
+@layer base {
+  html {
+    color-scheme: light;
+  }
+}
+
+:root {
+  /* Accent colors with light/dark mode */
+  --sf-blue: light-dark(rgb(0 122 255), rgb(10 132 255));
+  --sf-green: light-dark(rgb(52 199 89), rgb(48 209 89));
+  --sf-red: light-dark(rgb(255 59 48), rgb(255 69 58));
+
+  /* Gray scales */
+  --sf-gray: light-dark(rgb(142 142 147), rgb(142 142 147));
+  --sf-gray-2: light-dark(rgb(174 174 178), rgb(99 99 102));
+
+  /* Text colors */
+  --sf-text: light-dark(rgb(0 0 0), rgb(255 255 255));
+  --sf-text-2: light-dark(rgb(60 60 67 / 0.6), rgb(235 235 245 / 0.6));
+
+  /* Background colors */
+  --sf-bg: light-dark(rgb(255 255 255), rgb(0 0 0));
+  --sf-bg-2: light-dark(rgb(242 242 247), rgb(28 28 30));
+}
+
+/* iOS native colors via platformColor */
+@media ios {
+  :root {
+    --sf-blue: platformColor(systemBlue);
+    --sf-green: platformColor(systemGreen);
+    --sf-red: platformColor(systemRed);
+    --sf-gray: platformColor(systemGray);
+    --sf-text: platformColor(label);
+    --sf-text-2: platformColor(secondaryLabel);
+    --sf-bg: platformColor(systemBackground);
+    --sf-bg-2: platformColor(secondarySystemBackground);
+  }
+}
+
+/* Register as Tailwind theme colors */
+@layer theme {
+  @theme {
+    --color-sf-blue: var(--sf-blue);
+    --color-sf-green: var(--sf-green);
+    --color-sf-red: var(--sf-red);
+    --color-sf-gray: var(--sf-gray);
+    --color-sf-text: var(--sf-text);
+    --color-sf-text-2: var(--sf-text-2);
+    --color-sf-bg: var(--sf-bg);
+    --color-sf-bg-2: var(--sf-bg-2);
+  }
+}
+```
+
+Then use in components:
+
+```tsx
+<Text className="text-sf-text">Primary text</Text>
+<Text className="text-sf-text-2">Secondary text</Text>
+<View className="bg-sf-bg">...</View>
+```
+
+## Using CSS Variables in JavaScript
+
+Use the `useCSSVariable` hook:
+
+```tsx
+import { useCSSVariable } from "@/tw";
+
+function MyComponent() {
+  const blue = useCSSVariable("--sf-blue");
+
+  return <View style={{ borderColor: blue }} />;
+}
+```
+
+## Key Differences from NativeWind v4 / Tailwind v3
+
+1. **No babel.config.js** - Configuration is now CSS-first
+2. **PostCSS plugin** - Uses `@tailwindcss/postcss` instead of `tailwindcss`
+3. **CSS imports** - Use `@import "tailwindcss/..."` instead of `@tailwind` directives
+4. **Theme config** - Use `@theme` in CSS instead of `tailwind.config.js`
+5. **Component wrappers** - Must wrap components with `useCssElement` for className support
+6. **Metro config** - Use `withNativewind` with different options (`inlineVariables: false`)
+
+## Troubleshooting
+
+### Styles not applying
+
+1. Ensure you have the CSS file imported in your app entry
+2. Check that components are wrapped with `useCssElement`
+3. Verify Metro config has `withNativewind` applied
+
+### Platform colors not working
+
+1. Use `platformColor()` in `@media ios` blocks
+2. Fall back to `light-dark()` for web/Android
+
+### TypeScript errors
+
+Add className to component props:
+
+```tsx
+type Props = React.ComponentProps<typeof RNView> & { className?: string };
+```
+
+## 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-tailwind-setup" "<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.
diff --git a/.agents/skills/expo-tailwind-setup/agents/openai.yaml b/.agents/skills/expo-tailwind-setup/agents/openai.yaml
new file mode 100644
index 0000000..b72cc60
--- /dev/null
+++ b/.agents/skills/expo-tailwind-setup/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Expo Tailwind Setup"
+  short_description: "Set up Tailwind CSS v4, react-native-css, NativeWind v5, and CSS wrappers in Expo"
+  default_prompt: "Use $expo-tailwind-setup to install and configure Tailwind CSS v4 with Expo, NativeWind v5, react-native-css, Metro, PostCSS, global CSS, typed component wrappers, and theme variables."
diff --git a/.agents/skills/expo-ui/SKILL.md b/.agents/skills/expo-ui/SKILL.md
index fd59c8c..ff356a7 100644
--- a/.agents/skills/expo-ui/SKILL.md
+++ b/.agents/skills/expo-ui/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: expo-ui
-description: "Build native UI with the @expo/ui package: real SwiftUI on iOS and Jetpack Compose on Android rendered from React in an Expo or React Native app. Covers universal cross-platform components (Host, Column, Row, Button, Text, List, and more imported from @expo/ui), drop-in replacements for popular React Native community libraries (BottomSheet, DateTimePicker, Slider, Menu, etc.), and platform-specific SwiftUI (@expo/ui/swift-ui, iOS only) and Jetpack Compose (@expo/ui/jetpack-compose, Android only) trees and modifiers. Use when adding or reviewing @expo/ui Host/RNHostView trees, building native-feeling UI where standard React Native components fall short (grouped settings forms with toggles, sections, menus, sheets, pickers, sliders), choosing between universal and platform-specific components, or replacing an RN community UI library with a native @expo/ui equivalent. Not for custom native modules, Expo Router navigation, Reanimated, or data fetching."
+description: "Framework (OSS). Build native UI with the @expo/ui package: real SwiftUI on iOS and Jetpack Compose on Android rendered from React in an Expo or React Native app. Covers universal cross-platform components (Host, Column, Row, Button, Text, List, and more imported from @expo/ui), drop-in replacements for popular React Native community libraries (BottomSheet, DateTimePicker, Slider, Menu, etc.), and platform-specific SwiftUI (@expo/ui/swift-ui, iOS only) and Jetpack Compose (@expo/ui/jetpack-compose, Android only) trees and modifiers. Use when adding or reviewing @expo/ui Host/RNHostView trees, building native-feeling UI where standard React Native components fall short (grouped settings forms with toggles, sections, menus, sheets, pickers, sliders), choosing between universal and platform-specific components, or replacing an RN community UI library with a native @expo/ui equivalent. Not for custom native modules, Expo Router navigation, Reanimated, or data fetching."
 version: 1.0.0
 license: MIT
 allowed-tools: "Bash(node *expo-ui/scripts/list-components.js *)"
@@ -45,3 +45,11 @@ references/
   swift-ui.md              Platform-specific iOS UI: @expo/ui/swift-ui components, modifiers, RNHostView, useNativeState
   jetpack-compose.md       Platform-specific Android UI: @expo/ui/jetpack-compose components, modifiers, LazyColumn caveat, icons, useNativeState
 ```
+
+## 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-ui" "<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.
diff --git a/.agents/skills/expo-upgrade/SKILL.md b/.agents/skills/expo-upgrade/SKILL.md
new file mode 100644
index 0000000..326be1a
--- /dev/null
+++ b/.agents/skills/expo-upgrade/SKILL.md
@@ -0,0 +1,148 @@
+---
+name: expo-upgrade
+description: Framework (OSS). Guidelines for upgrading Expo SDK versions and fixing dependency issues
+version: 1.0.0
+license: MIT
+---
+
+## References
+
+- ./references/react-19.md -- SDK +54: React 19 changes (useContext → use, Context.Provider → Context, forwardRef removal)
+- ./references/new-architecture.md -- SDK +53: New Architecture migration guide
+- ./references/react-compiler.md -- SDK +54: React Compiler setup and migration guide
+- ./references/native-tabs.md -- SDK +55: Native tabs changes (Icon/Label/Badge now accessed via NativeTabs.Trigger.\*)
+- ./references/expo-av-to-audio.md -- SDK +55: Migrate audio playback and recording from expo-av to expo-audio
+- ./references/expo-av-to-video.md -- SDK +55: Migrate video playback from expo-av to expo-video
+- ./references/react-navigation-to-expo-router.md -- SDK +56: Migrate `@react-navigation/*` imports to `expo-router` entry points (codemod + manual mapping)
+
+## Beta/Preview Releases
+
+Beta versions use `.preview` suffix (e.g., `55.0.0-preview.2`), published under `@next` tag.
+
+Check if latest is beta: https://exp.host/--/api/v2/versions (look for `-preview` in `expoVersion`)
+
+```bash
+npx expo install expo@next --fix  # install beta
+```
+
+## Step-by-Step Upgrade Process
+
+> If upgrading from SDK 55 or earlier, skip SDK 56 and upgrade directly to SDK 57. Don't use `expo@57.0.8` or below. SDK 55 with Hermes V1 enabled, SDK 56, and older SDK 57 releases contain a Hermes V1 memory regression that can drastically increase memory usage when using `react-native-worklets` or `react-native-reanimated`.
+
+1. Upgrade Expo and dependencies
+
+```bash
+npx expo install expo@latest
+npx expo install --fix
+```
+
+2. Run diagnostics: `npx expo-doctor`
+
+3. Clear caches and reinstall
+
+```bash
+npx expo export -p ios --clear
+rm -rf node_modules .expo
+watchman watch-del-all
+```
+
+## Breaking Changes Checklist
+
+- Check for removed APIs in release notes
+- Update import paths for moved modules
+- Review native module changes requiring prebuild
+- Test all camera, audio, and video features
+- Verify navigation still works correctly
+
+## Prebuild for Native Changes
+
+**First check if `ios/` and `android/` directories exist in the project.** If neither directory exists, the project uses Continuous Native Generation (CNG) and native projects are regenerated at build time — skip this section and "Clear caches for bare workflow" entirely.
+
+If upgrading requires native changes:
+
+```bash
+npx expo prebuild --clean
+```
+
+This regenerates the `ios` and `android` directories. Ensure the project is not a bare workflow app before running this command.
+
+## Clear caches for bare workflow
+
+These steps only apply when `ios/` and/or `android/` directories exist in the project:
+
+- Clear the cocoapods cache for iOS: `cd ios && pod install --repo-update`
+- Clear derived data for Xcode: `npx expo run:ios --no-build-cache`
+- Clear the Gradle cache for Android: `cd android && ./gradlew clean`
+
+## Housekeeping
+
+- Review release notes for the target SDK version at https://expo.dev/changelog
+- Update versioned docs links in agent instruction files (`AGENTS.md`). The default template links to `https://docs.expo.dev/versions/v<version>/`. Search for `docs.expo.dev/versions/` and bump each link to the new SDK version.
+- If using Expo SDK 54 or later, ensure react-native-worklets is installed — this is required for react-native-reanimated to work.
+- Enable React Compiler in SDK 54+ by adding `"experiments": { "reactCompiler": true }` to app.json — it's stable and recommended
+- Delete sdkVersion from `app.json` to let Expo manage it automatically
+- Remove implicit packages from `package.json`: `@babel/core`, `babel-preset-expo`, `expo-constants`.
+- If the babel.config.js only contains 'babel-preset-expo', delete the file
+- If the metro.config.js only contains expo defaults, delete the file
+
+## Deprecated Packages
+
+| Old Package          | Replacement                                          |
+| -------------------- | ---------------------------------------------------- |
+| `expo-av`            | `expo-audio` and `expo-video`                        |
+| `expo-permissions`   | Individual package permission APIs                   |
+| `@expo/vector-icons` | `expo-symbols` (for SF Symbols)                      |
+| `AsyncStorage`       | `expo-sqlite/localStorage/install`                   |
+| `expo-app-loading`   | `expo-splash-screen`                                 |
+| expo-linear-gradient | experimental_backgroundImage + CSS gradients in View |
+
+When migrating deprecated packages, update all code usage before removing the old package. For expo-av, consult the migration references to convert Audio.Sound to useAudioPlayer, Audio.Recording to useAudioRecorder, and Video components to VideoView with useVideoPlayer.
+
+## expo.install.exclude
+
+Check if package.json has excluded packages:
+
+```json
+{
+  "expo": { "install": { "exclude": ["react-native-reanimated"] } }
+}
+```
+
+Exclusions are often workarounds that may no longer be needed after upgrading. Review each one.
+
+## Removing patches
+
+Check if there are any outdated patches in the `patches/` directory. Remove them if they are no longer needed.
+
+## Postcss
+
+- `autoprefixer` isn't needed in SDK +53. Remove it from dependencies and check `postcss.config.js` or `postcss.config.mjs` to remove it from the plugins list.
+- Use `postcss.config.mjs` in SDK +53.
+
+## Metro
+
+Remove redundant metro config options:
+
+- resolver.unstable_enablePackageExports is enabled by default in SDK +53.
+- `experimentalImportSupport` is enabled by default in SDK +54.
+- `EXPO_USE_FAST_RESOLVER=1` is removed in SDK +54.
+- cjs and mjs extensions are supported by default in SDK +50.
+- Expo webpack is deprecated, migrate to [Expo Router and Metro web](https://docs.expo.dev/router/migrate/from-expo-webpack/).
+
+## Hermes engine v1
+
+Hermes V1 is the default on SDK 56 and later. SDK 55 apps using Hermes V1, all SDK 56 apps, and SDK 57 apps before `expo@57.0.9` may encounter a memory regression when importing `react-native-worklets` or `react-native-reanimated`. Upgrade directly to SDK 57 and `expo@57.0.9` or later. Do not recommend Worklets Bundle Mode as a production workaround; it is unsupported and experimental and may not work as expected.
+
+Do not guide users to opt in to or out of Hermes V1. Changing the Hermes version from the SDK default is unsupported and has significant build and dependency-management caveats.
+
+## New Architecture
+
+The new architecture is enabled by default, the app.json field `"newArchEnabled": true` is no longer needed as it's the default. Expo Go only supports the new architecture as of SDK +53.
+
+## 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-upgrade" "<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.
diff --git a/.agents/skills/expo-upgrade/agents/openai.yaml b/.agents/skills/expo-upgrade/agents/openai.yaml
new file mode 100644
index 0000000..39d580e
--- /dev/null
+++ b/.agents/skills/expo-upgrade/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Expo Upgrade"
+  short_description: "Upgrade Expo SDKs, fix dependencies, adopt React 19 / React Compiler, and migrate deprecated Expo packages"
+  default_prompt: "Use $expo-upgrade to upgrade an Expo SDK, run diagnostics, fix dependency conflicts, decide whether prebuild/cache clearing applies, and migrate away from deprecated Expo packages."
diff --git a/.agents/skills/expo-upgrade/references/expo-av-to-audio.md b/.agents/skills/expo-upgrade/references/expo-av-to-audio.md
new file mode 100644
index 0000000..afacde7
--- /dev/null
+++ b/.agents/skills/expo-upgrade/references/expo-av-to-audio.md
@@ -0,0 +1,132 @@
+# Migrating from expo-av to expo-audio
+
+## Imports
+
+```tsx
+// Before
+import { Audio } from 'expo-av';
+
+// After
+import { useAudioPlayer, useAudioRecorder, RecordingPresets, AudioModule, setAudioModeAsync } from 'expo-audio';
+```
+
+## Audio Playback
+
+### Before (expo-av)
+
+```tsx
+const [sound, setSound] = useState<Audio.Sound>();
+
+async function playSound() {
+  const { sound } = await Audio.Sound.createAsync(require('./audio.mp3'));
+  setSound(sound);
+  await sound.playAsync();
+}
+
+useEffect(() => {
+  return sound ? () => { sound.unloadAsync(); } : undefined;
+}, [sound]);
+```
+
+### After (expo-audio)
+
+```tsx
+const player = useAudioPlayer(require('./audio.mp3'));
+
+// Play
+player.play();
+```
+
+## Audio Recording
+
+### Before (expo-av)
+
+```tsx
+const [recording, setRecording] = useState<Audio.Recording>();
+
+async function startRecording() {
+  await Audio.requestPermissionsAsync();
+  await Audio.setAudioModeAsync({ allowsRecordingIOS: true, playsInSilentModeIOS: true });
+  const { recording } = await Audio.Recording.createAsync(Audio.RecordingOptionsPresets.HIGH_QUALITY);
+  setRecording(recording);
+}
+
+async function stopRecording() {
+  await recording?.stopAndUnloadAsync();
+  const uri = recording?.getURI();
+}
+```
+
+### After (expo-audio)
+
+```tsx
+const recorder = useAudioRecorder(RecordingPresets.HIGH_QUALITY);
+
+async function startRecording() {
+  await AudioModule.requestRecordingPermissionsAsync();
+  await recorder.prepareToRecordAsync();
+  recorder.record();
+}
+
+async function stopRecording() {
+  await recorder.stop();
+  const uri = recorder.uri;
+}
+```
+
+## Audio Mode
+
+### Before (expo-av)
+
+```tsx
+await Audio.setAudioModeAsync({
+  allowsRecordingIOS: true,
+  playsInSilentModeIOS: true,
+  staysActiveInBackground: true,
+  interruptionModeIOS: InterruptionModeIOS.DoNotMix,
+});
+```
+
+### After (expo-audio)
+
+```tsx
+await setAudioModeAsync({
+  playsInSilentMode: true,
+  shouldPlayInBackground: true,
+  interruptionMode: 'doNotMix',
+});
+```
+
+## API Mapping
+
+| expo-av | expo-audio |
+|---------|------------|
+| `Audio.Sound.createAsync()` | `useAudioPlayer(source)` |
+| `sound.playAsync()` | `player.play()` |
+| `sound.pauseAsync()` | `player.pause()` |
+| `sound.setPositionAsync(ms)` | `player.seekTo(seconds)` |
+| `sound.setVolumeAsync(vol)` | `player.volume = vol` |
+| `sound.setRateAsync(rate)` | `player.playbackRate = rate` |
+| `sound.setIsLoopingAsync(loop)` | `player.loop = loop` |
+| `sound.unloadAsync()` | Automatic via hook |
+| `playbackStatus.positionMillis` | `player.currentTime` (seconds) |
+| `playbackStatus.durationMillis` | `player.duration` (seconds) |
+| `playbackStatus.isPlaying` | `player.playing` |
+| `Audio.Recording.createAsync()` | `useAudioRecorder(preset)` |
+| `Audio.RecordingOptionsPresets.*` | `RecordingPresets.*` |
+| `recording.stopAndUnloadAsync()` | `recorder.stop()` |
+| `recording.getURI()` | `recorder.uri` |
+| `Audio.requestPermissionsAsync()` | `AudioModule.requestRecordingPermissionsAsync()` |
+
+## Key Differences
+
+- **No auto-reset on finish**: After `play()` completes, the player stays paused at the end. To replay, call `player.seekTo(0)` then `play()`
+- **Time in seconds**: expo-audio uses seconds, not milliseconds (matching web standards)
+- **Immediate loading**: Audio loads immediately when the hook mounts—no explicit preloading needed
+- **Automatic cleanup**: No need to call `unloadAsync()`, hooks handle resource cleanup on unmount
+- **Multiple players**: Create multiple `useAudioPlayer` instances and store them—all load immediately
+- **Direct property access**: Set volume, rate, loop directly on the player object (`player.volume = 0.5`)
+
+## API Reference
+
+https://docs.expo.dev/versions/latest/sdk/audio/
diff --git a/.agents/skills/expo-upgrade/references/expo-av-to-video.md b/.agents/skills/expo-upgrade/references/expo-av-to-video.md
new file mode 100644
index 0000000..5c9bec1
--- /dev/null
+++ b/.agents/skills/expo-upgrade/references/expo-av-to-video.md
@@ -0,0 +1,160 @@
+# 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/
diff --git a/.agents/skills/expo-upgrade/references/native-tabs.md b/.agents/skills/expo-upgrade/references/native-tabs.md
new file mode 100644
index 0000000..95214c2
--- /dev/null
+++ b/.agents/skills/expo-upgrade/references/native-tabs.md
@@ -0,0 +1,124 @@
+# 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/
diff --git a/.agents/skills/expo-upgrade/references/new-architecture.md b/.agents/skills/expo-upgrade/references/new-architecture.md
new file mode 100644
index 0000000..b4b27ba
--- /dev/null
+++ b/.agents/skills/expo-upgrade/references/new-architecture.md
@@ -0,0 +1,79 @@
+# 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
diff --git a/.agents/skills/expo-upgrade/references/react-19.md b/.agents/skills/expo-upgrade/references/react-19.md
new file mode 100644
index 0000000..74035b2
--- /dev/null
+++ b/.agents/skills/expo-upgrade/references/react-19.md
@@ -0,0 +1,79 @@
+# 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
diff --git a/.agents/skills/expo-upgrade/references/react-compiler.md b/.agents/skills/expo-upgrade/references/react-compiler.md
new file mode 100644
index 0000000..4d58e28
--- /dev/null
+++ b/.agents/skills/expo-upgrade/references/react-compiler.md
@@ -0,0 +1,59 @@
+# 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.
diff --git a/.agents/skills/expo-upgrade/references/react-navigation-to-expo-router.md b/.agents/skills/expo-upgrade/references/react-navigation-to-expo-router.md
new file mode 100644
index 0000000..c0155f4
--- /dev/null
+++ b/.agents/skills/expo-upgrade/references/react-navigation-to-expo-router.md
@@ -0,0 +1,61 @@
+# 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
diff --git a/.agents/skills/expo-web-to-native/SKILL.md b/.agents/skills/expo-web-to-native/SKILL.md
new file mode 100644
index 0000000..eca1345
--- /dev/null
+++ b/.agents/skills/expo-web-to-native/SKILL.md
@@ -0,0 +1,91 @@
+---
+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.
diff --git a/.agents/skills/expo-web-to-native/agents/openai.yaml b/.agents/skills/expo-web-to-native/agents/openai.yaml
new file mode 100644
index 0000000..7245548
--- /dev/null
+++ b/.agents/skills/expo-web-to-native/agents/openai.yaml
@@ -0,0 +1,4 @@
+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."
diff --git a/.agents/skills/expo-web-to-native/references/false-friends.md b/.agents/skills/expo-web-to-native/references/false-friends.md
new file mode 100644
index 0000000..a43c261
--- /dev/null
+++ b/.agents/skills/expo-web-to-native/references/false-friends.md
@@ -0,0 +1,119 @@
+# False Friends: web idioms → native
+
+Disclosed reference for [`expo-web-to-native`](../SKILL.md). A *false friend* is a web idiom that looks portable but isn't - it compiles in your head, then breaks (or silently no-ops) on native. Each row is `web idiom → native equivalent → the gotcha`. Reach for this in steps 3–5 of a migration, and whenever you're learning native after the web.
+
+This is the single source of truth for the mapping; the SKILL.md steps name a few high-traffic swaps but defer the full list here.
+
+## Elements & text
+
+| Web | Native | Gotcha |
+|---|---|---|
+| `<div>`, `<section>`, `<span>` | `<View>` | `View` is the only generic container; no semantic element variants. |
+| `<p>`, `<h1>`, raw text in JSX | `<Text>` | **All** text must sit inside `<Text>`. Bare strings in a `View` throw. |
+| `<img src>` | `<Image>` / `expo-image` | `expo-image` adds caching, blurhash, transitions. Remote images need an explicit `width`/`height` or a flex parent. |
+| `<button>`, `<a>` | `<Pressable>` (or `TouchableOpacity`) | No default styling, no hover. Wrap label text in `<Text>`. |
+| `<input>` | `<TextInput>` | Controlled via `value` + `onChangeText` (not `onChange`/`e.target.value`). |
+| `<ul>/<li>` rendered with `.map()` | `<FlatList>` / `<FlashList>` | `.map()` over a long list mounts every row at once → jank. Use a virtualized list with `data` + `renderItem`. |
+
+## Events & interaction
+
+| Web | Native | Gotcha |
+|---|---|---|
+| `onClick` | `onPress` | Also `onLongPress`, `onPressIn/Out`. There is no click. |
+| `onChange={e => e.target.value}` | `onChangeText={text => ...}` | The handler receives the string directly, not an event. |
+| `onSubmit` (form) | `onPress` / `onSubmitEditing` | No `<form>` element and no submit event; wire the button/keyboard return key. |
+| `:hover`, `:focus` | press/focus state | No hover on touch. Track state and style from it, or use `Pressable`'s state callback. |
+| `e.preventDefault()` | — | No default actions to prevent; remove it. |
+
+## Styling & layout
+
+| Web | Native | Gotcha |
+|---|---|---|
+| `className` / CSS files | `StyleSheet.create` or NativeWind | Plain RN has no className. For Tailwind muscle memory use NativeWind (`expo-tailwind-setup`). |
+| CSS cascade & inheritance | none | Styles don't inherit (except a few `Text` props like `color`/`fontSize` to nested `Text`). Style each node. |
+| `display: flex` opt-in, default `row` | flex always on, default **`column`** | Biggest layout surprise: flex is the only layout model and the main axis is vertical by default. |
+| `px`, `rem`, `%` | unitless numbers (dp) | `padding: 16` = density-independent pixels. `%` works in some props; no `rem`/`em`/`vh`. |
+| `@media` queries | `useWindowDimensions()` / `Platform` | No media queries. Branch on dimensions or platform at runtime. |
+| `position: fixed` | `position: absolute` + safe area | No `fixed`. Pin with `absolute` and respect insets (`react-native-safe-area-context`). |
+| `z-index` | `zIndex` (+ `elevation` on Android) | Works mostly, but Android shadow/stacking also needs `elevation`. |
+| CSS transitions / `@keyframes` | `Animated` / Reanimated | No CSS animation. Reanimated is the standard; gestures via `react-native-gesture-handler`. |
+| `gap`, flexbox | `gap`, flexbox | These largely transfer — flexbox is the one big win for web devs. |
+
+## Navigation & URLs
+
+| Web | Native | Gotcha |
+|---|---|---|
+| React Router / Next.js routes | Expo Router (file-based) | File-based like Next App Router; `react-router` concepts map but the API differs. |
+| `<a href>` / `<Link>` | `expo-router` `<Link href>` | Works in DOM components too. |
+| `useNavigate()` / `router.push` | `useRouter()` from `expo-router` | `router.push/replace/back`. |
+| `useParams` / `useSearchParams` | `useLocalSearchParams()` | Note: doesn't work *inside* a DOM component - read in the native parent, pass as props (see `expo-dom`). |
+| `window.location` | `usePathname()` / router | No `location` object. |
+| Deep links / `myapp://` | URL scheme + universal links | Configure `scheme` in app config; native gives you real deep linking and (with AASA) app links - see `expo-app-clip` for the AASA file. |
+
+## React architecture & data (Next.js / SSR apps)
+
+| Web | Native | Gotcha |
+|---|---|---|
+| Async Server Component (`async function Page()`) | client component + data fetch | No RSC on native (Expo's is experimental and different). Split into a client component that fetches via the API + a presentational child *before* porting. |
+| Server actions (`'use server'`) | API route + `fetch` | No server actions. Expose an endpoint and call it. |
+| `cookies()` / `headers()` (server) | token in `expo-secure-store` | Server-only. Auth moves to a bearer token sent as a header. |
+| ORM / DB client in a page (Drizzle, Prisma) | server only - call over HTTP | The device never talks to the DB. Keep the backend deployed, or move routes to EAS Hosting (`eas-hosting`); the app fetches. |
+| `next/navigation` (`notFound`, `redirect`) | `expo-router` | `redirect()` → `router.replace`; `notFound()` → a native `+not-found` route. |
+| `_layout` as a DOM component | always native | Layout routes can't be DOM components — they *are* the native shell. Rewrite web-only layout logic (theme scripts, providers) with native APIs. |
+
+## Storage, state & sessions
+
+| Web | Native | Gotcha |
+|---|---|---|
+| `localStorage` / `sessionStorage` | `expo-sqlite` (`globalThis.localStorage`) | `import 'expo-sqlite/localStorage/install';` polyfills the global `localStorage`, so existing code works as-is (or `expo-sqlite/kv-store`). **No `sessionStorage` equivalent** — native has no session concept. |
+| Cookies / `document.cookie` | `expo-secure-store` + headers | No cookie jar by default. Store tokens in SecureStore; send as auth headers. |
+| Auth via session cookie | token in SecureStore | Redesign auth around bearer tokens, not browser sessions. |
+| In-memory React state | same | `useState`/`useReducer`/`useContext` transfer unchanged. |
+
+## Browser & platform APIs
+
+| Web | Native | Gotcha |
+|---|---|---|
+| `window`, `document` | none | Don't exist. Guard web-only libs, or keep them in a DOM component (`expo-dom`). |
+| `window.matchMedia('(prefers-color-scheme: dark)')` | `useColorScheme()` | Hook from `react-native`, reactive to the system theme. Web theme bootstrap scripts in the layout don't run. |
+| `window.innerWidth/Height` | `useWindowDimensions()` | Reactive hook; updates on rotation. |
+| `navigator.*`, Web APIs | Expo SDK modules | e.g. camera → `expo-camera`, geolocation → `expo-location`, clipboard → `expo-clipboard`. |
+| `alert()` / `confirm()` / `prompt()` | `alert()` works; `Alert.alert(...)` for the rest | RN provides a global `alert()`; `confirm()` / `prompt()` don't exist — use `Alert.alert` with a button array. |
+| `process.env.X` | `process.env.EXPO_PUBLIC_X` | Only `EXPO_PUBLIC_`-prefixed vars are inlined into the client bundle. |
+| `console.log` | `console.log` | Works — shows in the dev tools/terminal. |
+| `dangerouslySetInnerHTML` | — | No DOM to inject into. Render data, or use a DOM component / WebView. |
+| inline SVG | `react-native-svg` | No native `<svg>`; the library mirrors the element API. |
+
+## Networking
+
+| Web | Native | Gotcha |
+|---|---|---|
+| `fetch('/api/x')` (relative) | absolute URL | Native has no origin — relative paths fail. Use a configured base URL (`EXPO_PUBLIC_API_URL`). |
+| CORS | n/a | No browser CORS, but you still need a reachable absolute host. |
+| `fetch`, React Query, SWR | same | The libraries themselves work on native - see `expo-data-fetching`. |
+| Next.js API routes | Expo Router API routes | Move server endpoints to Expo API routes on EAS Hosting - see `eas-hosting`. |
+| Streaming responses (SSE, AI SDK `useChat`) | `expo/fetch` with `textStreaming` | RN's built-in `fetch` can't read a streaming response body. Use `expo/fetch` (streams, and works with the Vercel AI SDK) or an XHR-based polyfill. |
+
+## Third-party services & SDKs
+
+Browser SDKs don't run on native — each needs a native equivalent. The canonical, version-matched integrations live in the `expo-examples` skill (the `expo/examples` repo); reach for those instead of wiring from scratch.
+
+| Web service | Native | Gotcha |
+|---|---|---|
+| **Stripe.js — digital goods / subscriptions** | store **In-App Purchase** via **RevenueCat** (`react-native-purchases`) | **Policy, not just an SDK swap.** Apple & Google *require* IAP for in-app digital goods and take ~15–30%; shipping Stripe for them gets the app rejected. Decide at assess time — it can change the business model. |
+| **Stripe.js — physical goods / services** | `@stripe/stripe-react-native` (PaymentSheet, Apple/Google Pay) | Stripe's RN SDK is allowed for physical goods; see `expo-examples` `with-stripe`. |
+| Google Maps JS | `react-native-maps` | A native map view, not an embedded iframe. |
+| Web Push | `expo-notifications` (APNs / FCM) | Different delivery + permission model. |
+| OAuth redirect flow | `expo-auth-session` (deep-link OAuth), or a native auth SDK (Clerk, Supabase…) | No browser redirect — an app deep link completes the flow. |
+| GA / Segment.js analytics | native SDK (`posthog-react-native`, Segment RN) | The web JS snippet won't load; swap for the native SDK. |
+| `<input type=file>` / `getUserMedia` | `expo-image-picker` / `expo-camera` / `expo-document-picker` | Native pickers + runtime permissions. |
+
+## Scrolling, keyboard & safe area
+
+| Web | Native | Gotcha |
+|---|---|---|
+| Body scrolls by default | `<ScrollView>` / `<FlatList>` | Nothing scrolls unless you make it. Wrap overflowing content explicitly. |
+| `overflow: scroll` | `<ScrollView>` | Don't nest a `ScrollView` inside a `FlatList` of the same axis. |
+| Keyboard overlaps inputs | `KeyboardAvoidingView` | The keyboard covers inputs by default; wrap forms to push content up. |
+| Notch / status bar | `react-native-safe-area-context` | Content flows under the notch/home indicator unless you apply safe-area insets. |
+| `:focus` ring, tab order | manual | No automatic focus management; wire `ref`/`focus()` and `returnKeyType`. |
diff --git a/.agents/skills/expo-web-to-native/references/native-patterns.md b/.agents/skills/expo-web-to-native/references/native-patterns.md
new file mode 100644
index 0000000..53d7cbe
--- /dev/null
+++ b/.agents/skills/expo-web-to-native/references/native-patterns.md
@@ -0,0 +1,39 @@
+# Native patterns: redesigning web UX for native
+
+Disclosed reference for [`expo-web-to-native`](../SKILL.md), step 4. `false-friends.md` translates *idioms* (`div` → `View`); this translates *UX patterns* - a web interaction into its native equivalent. Step 4 isn't a port, it's this redesign.
+
+**Reach for `@expo/ui` first.** It renders real SwiftUI (iOS) and Jetpack Compose (Android), so its components look and feel *exactly* like the OS — the difference between "native-ish RN" and "indistinguishable from an app Apple/Google shipped." See the `expo-ui` skill. Drop to styled RN primitives only for what `@expo/ui` doesn't cover: custom layouts (chat bubbles, bespoke cards) and **large data lists** (`@expo/ui` `List` is a JS-thread node per item — use `FlashList`/`FlatList` for feeds). `@expo/ui` runs in **Expo Go** (SDK 56+) — no dev build needed; reach for a dev build (the `expo-dev-client` skill) only for *custom* native modules.
+
+| Web pattern | Native redesign — reach for first | Why |
+|---|---|---|
+| Top tab bar / nav links | **NativeTabs** - bottom, liquid glass on iOS 26 (`expo-router`) | Thumb-reachable, OS-native bar |
+| Page header / breadcrumb | **large-title** Stack header + header **search field** (`expo-router`) | The native screen frame |
+| In-page tabs / toggle group | **SegmentedControl** — `@expo/ui` (`community/segmented-control`) | Native segmented switch |
+| Modal / dialog | **BottomSheet** — `@expo/ui` | Sheets *are* the native modal |
+| `<select>` / dropdown | **Picker**, or long-press **MenuView** — `@expo/ui` (`community/menu`) | Native wheel / menu, no popover |
+| Accordion / "show more" | **Collapsible** — `@expo/ui` | Native disclosure |
+| Settings / short list | **List** + **FieldGroup** rows (Switch / Picker / TextInput) — `@expo/ui` | The Settings-app look |
+| Data feed / table / long list | **FlashList** / `FlatList`, virtualized + momentum | Tables don't exist on mobile; `@expo/ui` `List` isn't for big data |
+| Checkbox / toggle | **Switch** (on/off) or **Checkbox** (multi-select) — `@expo/ui` | Native control, not a styled box |
+| Date / time input | **DateTimePicker** — `@expo/ui` (`community/datetime-picker`) | Native wheel / calendar |
+| Range slider | **Slider** — `@expo/ui` | |
+| Onboarding / carousel / swipe pages | **PagerView** — `@expo/ui` (`community/pager-view`) | Native paging, not a scroll strip |
+| Refresh button / auto-poll | pull-to-refresh (`RefreshControl`) | The native refresh gesture |
+| Hover menu / tooltip | long-press **MenuView** context menu — `@expo/ui` (`community/menu`) | No hover on touch |
+| Toast / snackbar | native banner + **haptic** (`expo-haptics`) | |
+| Buttons | `@expo/ui` **Button**; `Pressable` for custom | Native press + haptics |
+| Multi-column layout | single column + tabs / stack | One thing at a time on a phone |
+
+**The test:** if a screenshot of the native screen could pass for the web version, you reskinned it. Redesign until it could pass for a screen the OS shipped.
+
+## Feel — beyond the components
+
+The table gets the right *components*; "native" also lives in *motion and touch* - and a web port arrives with almost none, so you must add it. The tooling is in `expo-router` (navigation/transitions) and `expo-native-ui` (motion/effects); reach for it, don't hand-roll:
+
+- **Transitions for free** - use Expo Router's native-stack so push/pop, modals, and sheets animate with real platform physics; shared-element zoom via `expo-router` `zoom-transitions.md`.
+- **Motion** - Reanimated (`withSpring`/`withTiming`; `entering`/`exiting` for list items) + `react-native-gesture-handler` for swipes/drags → `expo-native-ui` `animations.md`.
+- **Touch** — `expo-haptics` on commits, selection changes, and pull-to-refresh — choreography, not just a toast buzz.
+- **Native rhythm** — large-title collapse on scroll, momentum / inverted scroll, a keyboard that pushes content (`KeyboardAvoidingView`).
+- **Respect reduced motion** — gate non-essential animation on Reanimated's `useReducedMotion()`.
+
+**Feel can't be screenshotted.** A janky transition or wrong easing passes a still-image parity check and still betrays the app — for screens with motion, verify with a short recording (iOS `xcrun simctl io booted recordVideo feel.mov`; Android `adb shell screenrecord`; or a device-agent flow), not just a screenshot.
diff --git a/.agents/skills/expo-web-to-native/references/run-as-goal.md b/.agents/skills/expo-web-to-native/references/run-as-goal.md
new file mode 100644
index 0000000..67a77b0
--- /dev/null
+++ b/.agents/skills/expo-web-to-native/references/run-as-goal.md
@@ -0,0 +1,48 @@
+# Run the migration as a goal loop
+
+Disclosed reference for [`expo-web-to-native`](../SKILL.md) - the recommended way to drive the whole migration. The migration is a repeat-until-done loop (assess → nativize each screen → verify → check off), which is exactly the shape of a **goal loop**: a single objective re-injected every turn until the worklist is empty. This file carries a ready-shaped, migration-specific objective - and, crucially, the objective **re-reads this skill every iteration**, so the loop keeps following the playbook (and self-bootstraps the assess step if no worklist exists yet).
+
+Use it in one of two modes depending on the agent you're running.
+
+## Mode A — the agent can run a goal loop
+
+Harnesses with a goal/loop command (Claude Code `/goal`, Codex CLI, or any harness of the same shape) can drive this themselves. Fill the template below and hand it to that command — the loop re-runs it until `migration-progress.md` has no unchecked nativize-now items.
+
+## Mode B — the agent can't loop itself
+
+Write the filled-in objective to `migration-goal.md` in the project, then give the user the one-line instruction to launch it (e.g. *"run your agent's goal loop with the objective in `migration-goal.md`"*). The objective is plain text and portable, so the user runs it in whatever harness they have.
+
+## The objective (template)
+
+Fill the two `<…>` slots, then run or hand off verbatim. It is written to survive re-injection — it restates its own worklist, direction, and stop condition every turn.
+
+```
+Goal: migrate <APP NAME> from web to a native Expo app by following the expo-web-to-native skill, one screen per iteration, until done.
+
+Each iteration, FIRST re-read the playbook - plugins/expo/skills/expo-web-to-native/SKILL.md (and its references) - then:
+1. If migration-progress.md doesn't exist yet, do the skill's step 1 (Assess) to
+   create the worklist, then stop. Otherwise open it and take the top unchecked
+   item under "nativize-now"; if none are left unresolved (every nativize-now is
+   done or blocked), STOP and summarize what shipped + what's blocked and why.
+2. Redesign that screen native per the skill's step 4 — reach for @expo/ui FIRST
+   (real SwiftUI/Compose), then expo-router (NativeTabs, large titles);
+   RN primitives only for custom layouts. NEVER a webview port.
+   Use references/native-patterns.md (UX patterns) and references/false-friends.md
+   (idioms). Match the web screen's content and behavior.
+3. Verify per references/verify-on-device.md: compare the running web original
+   (browser agent) against the native screen (simulator / argent) — content and
+   behavior parity, NOT pixels (it should look more native). If it's off for reasons
+   IN the code, fix it this iteration. If it's blocked by something OUTSIDE the code
+   (missing backend/auth/data, or a secret you can't supply), don't loop — mark it
+   blocked in step 4 and move on.
+4. Check the item off in migration-progress.md, appending one line:
+   "<screen> — done", or "<screen> — blocked: <reason> — needs <what would unlock>".
+   Either way the item is resolved; never revisit a blocked one.
+
+Rules: one screen per pass; the app builds green each iteration; @expo/ui before RN primitives; never touch "nativize-later" items.
+Base API URL for native (no relative paths): <EXPO_PUBLIC_API_URL>
+```
+
+## Why a pre-shaped objective
+
+The objective is filled in for this migration — worklist, redesign rules, and self-verification path already wired to the skill's references — so you can launch the loop without authoring one from scratch. Tailor the `<…>` slots and direction when a specific migration needs more than the template covers.
diff --git a/.agents/skills/expo-web-to-native/references/verify-on-device.md b/.agents/skills/expo-web-to-native/references/verify-on-device.md
new file mode 100644
index 0000000..b5d82bd
--- /dev/null
+++ b/.agents/skills/expo-web-to-native/references/verify-on-device.md
@@ -0,0 +1,45 @@
+# Verify a migrated screen against the running web app
+
+Disclosed reference for [`expo-web-to-native`](../SKILL.md), steps 3–4. Verification means **running both apps and comparing the same screen** - the native port beside the web original. A clean compile or a green `expo export` proves nothing - a screen can build and still render blank or mis-render. This parity check is the gate the strangle loop runs each iteration.
+
+Two agents drive it, and this skill is **opinionated**: it requires both and installs them rather than falling back to manual screenshots.
+
+- **Web side — `agent-browser`** (vercel-labs, a Rust browser CLI): `open <url>`, `snapshot --json` (accessibility tree with refs), `screenshot <path>`, `read` (rendered DOM/text).
+- **Native side — `argent`** (`@swmansion/argent`): drives the simulator — `describe` (a11y tree), `debugger-component-tree` (RN tree), `gesture-tap`/`keyboard`, `flow` to record a check and replay it each pass. Invoke as `argent run <tool> --udid <udid>` (get the udid from `argent run list-devices`).
+
+## Setup — install if missing (don't skip, don't fall back to manual)
+
+Check both are on PATH; if either is absent, ask the user, then install before proceeding:
+
+```bash
+which agent-browser || (npm i -g agent-browser && agent-browser install)   # web agent (+ its Chrome)
+which argent        || npm i -g @swmansion/argent                          # device agent
+```
+
+## The workflow
+
+**A. Capture the web original** with agent-browser — the source of truth for parity. Run the web app (its `pnpm dev` server, or the **deployed URL** if local setup needs DB/auth env), then:
+
+```bash
+agent-browser open "<web-url>/<route>?<params>"
+agent-browser snapshot --json      # structure to diff
+agent-browser screenshot web.png   # visual reference
+```
+
+**Tip:** capture web baselines for every screen once, up front, then diff against them instead of re-opening the web app each iteration.
+
+**B. Capture the native screen** (iOS shown via `simctl`; Android note below):
+1. Run the app: `npx expo start --ios` (Expo Go). On **SDK 56+ both `@expo/ui` and DOM components run in Expo Go** — no dev build, no `react-native-webview` to install; reach for a dev build (the `expo-dev-client` skill) only for *custom* native modules. Stale-bundle trap: a CI-mode Metro + cached Expo Go can show an old build — terminate Expo Go and add `--clear` if a change doesn't appear.
+2. Boot a sim: `xcrun simctl boot <udid>` (`xcrun simctl list devices available`); `open -a Simulator`.
+3. Open the route: deep-link `xcrun simctl openurl booted "exp://<lan-ip>:8081/--/<route>?<params>"`, or argent `launch-app` + `gesture-tap`.
+4. Capture: `xcrun simctl io booted screenshot native.png`, or `argent run describe --udid <udid>` for structure.
+
+> **Android:** `simctl` / `expo run:ios` are iOS-only. Use an Android emulator + `adb` — `adb exec-out screencap -p > native.png`, `adb shell am start -a android.intent.action.VIEW -d "<deep-link>"`, `adb shell screenrecord` for motion — or `npx expo run:android` for a dev build.
+
+**C. Compare** the two for the same route — layout, content, behavior. Diff the structures (agent-browser `snapshot` against argent `describe` / `debugger-component-tree`), not just pixels. Pass only on parity: same data, and params passed into a DOM webview must produce the same result.
+
+**Feel needs motion, not a still.** For a nativized screen with transitions, gestures, or haptics, a screenshot can't catch a janky push or wrong easing — capture a short recording (iOS `xcrun simctl io booted recordVideo feel.mov`; Android `adb shell screenrecord`; or an argent flow) and confirm it moves like a native app (see `native-patterns.md` → Feel).
+
+## What "pass" looks like
+- **DOM-shelled screen (step 3):** the web UI renders inside the native header/shell; params from the native route drive it the same as on web.
+- **Nativized screen (step 4):** native primitives only, no webview; matches the web original screen.
diff --git a/skills-lock.json b/skills-lock.json
index a3a5bf9..56e497a 100644
--- a/skills-lock.json
+++ b/skills-lock.json
@@ -7,41 +7,167 @@
       "skillPath": "plugins/expo/skills/building-native-ui/SKILL.md",
       "computedHash": "bed8dace471bc68d4d6e588fa4d72eedac54afe9f4a34ed9921da3ff994463a0"
     },
+    "eas-app-stores": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/eas-app-stores/SKILL.md",
+      "computedHash": "4092e637ac0db1ac728accd9621f0e92d25934dabdc326ea119ec0c7437be519"
+    },
+    "eas-hosting": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/eas-hosting/SKILL.md",
+      "computedHash": "4d24f5471371668a0ee5a859a2c1a145fa0d4b2b30e8347f2ba06b001a1ace12"
+    },
+    "eas-observe": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/eas-observe/SKILL.md",
+      "computedHash": "ee5f33e5de29ca3131763f68c83efa7e4fb6e9ce43b4d9565ab4e6765799c4e0"
+    },
+    "eas-simulator": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/eas-simulator/SKILL.md",
+      "computedHash": "f50147686ee17ca4ec257563000861c5c4e2de58012e77007e4b22b735e93325"
+    },
+    "eas-update-insights": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/eas-update-insights/SKILL.md",
+      "computedHash": "d5d79f243bfaab0324e87581016cae7ad7b6392439134418827b4408863c0b12"
+    },
+    "eas-workflows": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/eas-workflows/SKILL.md",
+      "computedHash": "40c39c7c73597ce263e35f2e6bbc6e534321b5365f70beb772085e9adbc3ec5c"
+    },
+    "expo-animation": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/expo-animation/SKILL.md",
+      "computedHash": "55d68c0a4507340b9f1da38337884ab2958c1b051197600e628151fb3cceb077"
+    },
+    "expo-app-clip": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/expo-app-clip/SKILL.md",
+      "computedHash": "6fb608b7dace828f2f85ed16e7a71314260042c57307e657cb0d8a660257266c"
+    },
+    "expo-brownfield": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/expo-brownfield/SKILL.md",
+      "computedHash": "07ce124e416f89a24c21c57402c03960a16e573675752be6a89735fba073b9d4"
+    },
     "expo-cicd-workflows": {
       "source": "expo/skills",
       "sourceType": "github",
       "skillPath": "plugins/expo/skills/expo-cicd-workflows/SKILL.md",
       "computedHash": "6b5b10d32105e345a3494cf60f1b80165f971fd72e1a0ad355ca9b0b36af1f43"
     },
+    "expo-data-fetching": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/expo-data-fetching/SKILL.md",
+      "computedHash": "422197195d96fd32036f92001cebd1590caf6445ba338aabc0c0b0cff5fa8977"
+    },
     "expo-deployment": {
       "source": "expo/skills",
       "sourceType": "github",
       "skillPath": "plugins/expo/skills/expo-deployment/SKILL.md",
       "computedHash": "f70cd561a2d726f329f45eb0ad262f298c57676a80d7ecf288dc3919a6a7a50d"
     },
+    "expo-design-system": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/expo-design-system/SKILL.md",
+      "computedHash": "926d79a5c2246a6dd57400089b4a72d2c67c1dd49c5a1cfe6cab807a49cd1aba"
+    },
     "expo-dev-client": {
       "source": "expo/skills",
       "sourceType": "github",
       "skillPath": "plugins/expo/skills/expo-dev-client/SKILL.md",
-      "computedHash": "af7b1cc2824db64888aa10d5d8c009b960d2c649dd7be2b86ae6b9f092a73ae6"
+      "computedHash": "41496a5bb64bb753640c3a7de9d58fce81330fbba61f822dabbc04b5f1d7447d"
+    },
+    "expo-dom": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/expo-dom/SKILL.md",
+      "computedHash": "9841a2ee168b41e1d1377b20a1c041aa89843b5d507db73b43693d058ea32a27"
     },
     "expo-examples": {
       "source": "expo/skills",
       "sourceType": "github",
       "skillPath": "plugins/expo/skills/expo-examples/SKILL.md",
-      "computedHash": "d1793279706f5e2112023c0a26a2a2909fc7ce3da640812f6f2911a4ad497d6c"
+      "computedHash": "1d525c773458f166590f40cd3575d6fca440786fc99fdf58d4704af77d1495df"
+    },
+    "expo-migrate-module": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo-experiments/skills/expo-migrate-module/SKILL.md",
+      "computedHash": "dda77f2d6afbbe70e8d6bdb399265e4bb0dc03858aff4d6778f598c1f7e6d5ca"
     },
     "expo-module": {
       "source": "expo/skills",
       "sourceType": "github",
       "skillPath": "plugins/expo/skills/expo-module/SKILL.md",
-      "computedHash": "fe91e433d28dcc49439c4edc016e7f931e6f699bc84d65cf6975dd494bc04bfa"
+      "computedHash": "9c968a5bcb153ccdac1edbe014145ae37d6e6dac06846bfad7b2faaf890d88f0"
+    },
+    "expo-native-ui": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/expo-native-ui/SKILL.md",
+      "computedHash": "938f33e77410dd410b7baa25f2380b5fa104e7b7d67b0f0ca64f7a53ddedcc61"
+    },
+    "expo-project-structure": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/expo-project-structure/SKILL.md",
+      "computedHash": "00fd1404bb984f058c97296d28dce87c701ea4213b30c864babe24ed6cf12dc0"
+    },
+    "expo-router": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/expo-router/SKILL.md",
+      "computedHash": "b5baa66d0024536b1410136b05e83d749fb5a1c8b72326b5096193c03523361c"
+    },
+    "expo-skill-eval": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": ".claude/skills/expo-skill-eval/SKILL.md",
+      "computedHash": "01213c423623d6f4ceb3f610c05ec3e69f772675c329144c35465162f7794152"
+    },
+    "expo-skill-feedback": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/expo-skill-feedback/SKILL.md",
+      "computedHash": "7964b0683a81a9e2932151d5f1ddda27f60f22932e38c1687e60f754fdb45277"
+    },
+    "expo-tailwind-setup": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/expo-tailwind-setup/SKILL.md",
+      "computedHash": "fe7cb21735243b2701a3a1e35be6fbfd7cff6a146447200d4b14d225b619a46d"
     },
     "expo-ui": {
       "source": "expo/skills",
       "sourceType": "github",
       "skillPath": "plugins/expo/skills/expo-ui/SKILL.md",
-      "computedHash": "96b8e9190119110df2ec0efcd4f67fe7c8f686c0a022b28d3efa2533b3167536"
+      "computedHash": "5cbb2f0049e4d3a51cf6450b2d0032684e0881681a8f3dcea21b94164352fe61"
+    },
+    "expo-upgrade": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/expo-upgrade/SKILL.md",
+      "computedHash": "77aea7026b8cfc732fd09587a9ee612d4abe5c7c82d00b0370f1079b9f3c59ce"
+    },
+    "expo-web-to-native": {
+      "source": "expo/skills",
+      "sourceType": "github",
+      "skillPath": "plugins/expo/skills/expo-web-to-native/SKILL.md",
+      "computedHash": "8b438fca8004ae91514c9ad8e2fd34566cef0866065451a6e89279c52992a966"
     },
     "native-data-fetching": {
       "source": "expo/skills",