Task recipes

Practical routing recipes for common Expo work.

Ordered, skill-named procedures only—no large code samples. Stop conditions and authorization boundaries are part of each recipe.

Standard app audit

1. $expo-development-foundation → classify as existing consumer app and audit_scope: consumer-app.
2. $expo-project-orientation → emit the evidence-backed stack card.
3. $expo-app-audit at standard depth → select only relevant domain skills.
4. Add $expo-design-review, $expo-native-ui, and $expo-a11y when UI is in scope.
5. $expo-verify → safe local checks only; report exact evidence, skipped checks, remediation order, and residual risk.

Stop: the audit is read-only. Findings and recommendations do not authorize fixes, native builds, EAS, store, OTA, telemetry, or production actions.

Quick app health check

1. Orient the existing app.
2. Run $expo-app-audit at quick depth.
3. Check critical security/config/runtime stops, SDK/dependency health, verification availability, and highest-severity architecture risks.
4. Close with safe local $expo-verify evidence.

Stop: do not silently expand a quick check into a standard/deep audit or implementation.

Design and accessibility review

1. Orient and identify the UI surfaces and platforms.
2. $expo-design-review → hierarchy, tokens, responsive layout, complete states, interaction feedback, motion, and accessibility.
3. Compose $expo-native-ui, $expo-ui, $expo-router, and $expo-a11y only where their boundaries match.
4. Separate source inspection from screenshots/device evidence and report unavailable visual or assistive-technology checks as residual risk.

Stop: do not claim visual verification without screenshots/runtime evidence and do not edit without authorization.

Audit, then separately authorized remediation

1. Complete and hand off the read-only audit report.
2. Stop and obtain a second explicit request authorizing named fixes.
3. Reconfirm scope and prioritize critical/high findings in dependency order.
4. Implement only the authorized findings with their owning domain skills.
5. Close with $expo-verify; keep unaddressed findings and residual risk in the handoff.

Stop: an audit request is never the authorization for step 3.

Bootstrap a new app

1. $expo-development-foundation → classify as new app
2. $expo-bootstrap → ordered chain
3. $expo-project-structure then $expo-router
4. $expo-native-ui / $expo-ui when screens need native-feeling UI
5. Data, DOM, modules, upgrade, EAS only when boundaries match

Stop: do not treat showcase/ as the product app; no EAS without explicit authorization.

Onboard an existing app

1. $expo-development-foundation → classify as existing app
2. $expo-project-orientation (mandatory first)
3. Emit stack card + ordered shortlist
4. Stop unless implementation is authorized
5. Proceed only with shortlisted domain skills; never $expo-project-structure restructure of a mature layout

Stop: monorepo style-only flatten; inventing credentials; foundation audit by default.

Add a route

Use $expo-router for route groups, typed dynamic parameters, tabs, modals, form sheets, headers, and not-found behavior. Keep route files focused and move shared code into existing consumer folders (do not invent a new tree layout on mature apps).

Add data

Use $expo-data-fetching for a typed boundary with loading, error, cancellation, cache, and offline behavior. Keep secrets out of the client bundle. Full session / OAuth lifecycle → $expo-auth (not data-fetching alone).

Add an authenticated screen

1. Existing app → $expo-project-orientation first
2. $expo-auth for session, secure storage, Auth Session / PKCE, logout
3. $expo-linking when deep-link / redirect schemes are involved
4. $expo-data-fetching for authenticated API clients and cache invalidation
5. $expo-examples for vendor-specific SDK patterns (Clerk, etc.)

Stop: tokens in AsyncStorage; secrets in EXPO_PUBLIC_*; inventing OAuth client secrets.

Add camera / media (permissioned capability)

1. Orientation if existing app
2. $expo-permissions for timing, privacy strings, denial UX, Expo Go limits
3. Package APIs only after permission policy is clear
4. $expo-dev-client when Expo Go is insufficient

Stop: permission prompt on first frame; store submit is not part of this recipe.

Publish OTA or submit to stores

OTA updates and store submissions are outside this skill catalog. Do not run paid EAS or store actions by inference. Confirm explicit authorization, credentials, and JS-only OTA safety (decision tree 5) first, then follow the Expo/EAS vendor docs for the authorized action.

Works in Expo Go, fails in build

1. $expo-project-orientation + $expo-debugging
2. Re-run Expo Go vs development-client tree
3. $expo-dev-client / config plugins / native modules as indicated
4. Local static checks before any cloud build

Add a config-plugin dependency

1. Orientation if existing app
2. $expo-config-env for app config / plugins surface
3. $expo-permissions when privacy strings are required
4. Mark development client required; $expo-dev-client for runtime
5. New binary for native-breaking changes—not OTA alone

SDK upgrade dry-run

1. $expo-project-orientation on existing apps
2. $expo-upgrade for version matrix and breaking changes
3. Plan-only until implementation is authorized
4. Consumer typecheck / doctor; no store submit by inference

Use web code incrementally

Use $expo-dom for an isolated DOM Component and $expo-web-to-native for an end-to-end migration. Keep props serializable and actions explicit.

Native capability or release

Use $expo-module and $expo-dev-client for custom native code. Use $eas-hosting only for explicitly authorized hosting deploys. Store and OTA releases are outside this catalog.