Expo Native Module Migration Assistant
Move an existing Expo Swift module from the 1.0 DSL to the 2.0 macro API without changing its JavaScript contract.
The skill requires checking the Expo version and actual macro/core support, limits edits to the JS contract, avoids unverified migrations, and requires user confirmation before creating an external issue. It lacks complete data-flow disclosure, sensitive-data handling, rollback guidance, and explicit source attribution, so points are deducted.
The workflow, compatibility gates, mixed-mode strategy, and abnormal-case handling are detailed and provide controlled stopping behavior. However, the selected skill has no tests or build evidence, so static calibration keeps the score below 10.
The name, audience, use case, and non-fit boundaries are clear: Swift native-module migration only, excluding new modules, general SDK upgrades, and Android/Kotlin migrations. Chinese-language support, full environment prerequisites, and broader trigger boundaries are not documented, so points are deducted.
The skill includes a version, MIT license, layered reference documents, migration checklist, known hazards, dependency checks, and handoff requirements. It lacks skill-specific ownership, changelog, update path, and sufficient FAQs; publisher identity is also unverified, so points are deducted.
The workflow directly targets preserving the JS/TypeScript contract during Swift 1.0-to-2.0 migration and includes incremental migration, mixed mode, and handoff verification. No real output or execution result is statically demonstrated, so the score is capped at 7.
The references provide auditable rules, compatibility-check commands, and a contract checklist, while repository-wide CI offers limited corroboration. There are no committed tests covering this skill's key paths, third-party execution records, or independent reproduction, so the score is capped at 5.
- This review is based only on static source reading; no commands, builds, tests, or real migration were executed.
- The skill instructs agents to create an external issue in expo/expo for some failures; user approval, minimal disclosure, and issue contents should be reconfirmed before posting.
- Migration can change execution queues, event names, defaults, or record optionality; each item must be verified against the actual expo-modules-core revision rather than an SDK number alone.
- Publisher identity is not verified by the FollowSkills enterprise registry, and maintenance ownership and update path are not explicit in the skill documentation.
What does this skill do, and when should you use it?
This is the expo-migrate-module skill from the expo/skills collection, focused on migrating existing Apple/Swift Expo native modules from the Expo Modules API 1.0 definition DSL to the 2.0 macro API. It treats the current JavaScript, TypeScript, and test surface as the compatibility contract and supports incremental mixed-mode migration. The target project must use expo 57.0.7 or newer. It does not cover new module creation, general Expo SDK upgrades, or Android/Kotlin migrations.
Inspects the target project's Expo version, repository instructions, Swift module, JavaScript/TypeScript bindings, tests, example app, podspec, and expo-modules-core; reads migration, example, and compatibility references; inventories JavaScript-visible module names, functions, properties, constants, events, records, and shared objects; verifies the actual 2.0 macro and runtime surface; migrates Swift code by semantic group while retaining 1.0 definition() DSL entries when needed; runs builds, type checks, native tests, and JS/TS tests; and compares the final exported surface with the pre-migration inventory.
- A maintainer has an existing Swift Expo native module and wants to adopt the Expo Modules API 2.0 macros.
- A team needs to migrate incrementally while preserving the module's existing JavaScript and TypeScript contract.
- A module uses concepts corresponding to @ExpoModule, @JS, @Event, @SharedObject, or @Record.
- A migration requires classifying each member as migratable, safely retained in the DSL, or blocked by missing runtime support.
- A team needs to verify event names, record requiredness, constant caching, queue behavior, and sync/async semantics after migration.
What are this skill's strengths and limitations?
- Uses the existing JS/TS surface and tests as a compatibility contract.
- Supports mixed mode, allowing unsupported members to remain in the 1.0 definition() DSL.
- Covers functions, properties, constants, events, shared objects, and records.
- Requires build, test, example-app, and stale-registration checks.
- Limited to existing Apple/Swift Expo native modules; it is not for new modules or Android/Kotlin migration.
- Requires expo 57.0.7 or newer, while exact macro and runtime support still must be checked in the actual source.
- The source provides no independent test results or platform coverage for this individual skill.
- Tracking issues for unsupported functionality require user confirmation before publication.
How do you install this skill?
This skill is part of the expo/skills collection. Install all Expo skills with the Skills CLI: npx skills@latest add expo/skills --skill '*'. In Codex, you can install the Expo plugin with: codex plugin add expo@openai-curated. The source does not provide a command for installing only expo-migrate-module.
How do you use this skill?
After installation, ask the agent for a concrete migration, for example: “Migrate this existing Swift Expo native module from the Expo Modules API 1.0 DSL to the 2.0 macro API while preserving its JavaScript/TypeScript contract.” The target project must use expo 57.0.7 or newer. Android/Kotlin migration requires a separate explicit request.
How does this skill compare with similar options?
Compared with staying entirely on the Expo Modules API 1.0 DSL, this skill provides an incremental path toward the 2.0 macro API while preserving the existing JavaScript interface.