React Native Migration Assessor
Evidence-led decisions for React Native migration readiness
The skill explicitly requires read-only assessment, scope control, unknown disclosure, protection of secrets and test data, and human architecture and release approval. It does not specify concrete access controls, sensitive-data isolation, confirmation, rollback, or retention procedures; publisher identity is also unverified, so points are deducted.
The workflow, evidence gates, single-question interview rule, and handling of unavailable evidence are clear. However, there is no test suite, executable validation, dependency check, or reproducible abnormal-input feedback; under static calibration the score cannot exceed 10, so points are deducted.
The audience, migration scenarios, outcome boundaries, and invocation context are comparatively precise. Chinese interaction support is not specified, and cross-environment reachability and tool availability are unverified, so points are deducted.
The document has strong layering and includes metadata, MIT licensing, evidence labels, gates, an output contract, and handoff guidance. It lacks an explicit version, changelog, named maintenance responsibility, update path, installation/dependency notes, and troubleshooting guidance, so points are deducted.
The skill offers a substantial migration decision framework, checkpoint design, and ROI constraints that could produce a directly reviewable report. No representative output or execution evidence is supplied, so practical completeness and marginal benefit over manual assessment remain unverified; points are deducted.
It requires repository paths and line numbers, separates evidence status from assumptions, and can use repository and CI artifacts. There is no committed test coverage for the skill's key paths or independent third-party execution evidence, so only limited static verifiability is supported.
- The skill requires inspecting all production clients but does not define permission boundaries or fallback evidence procedures for inaccessible workspaces, private repositories, or devices.
- Its exact-first-response Markdown contract may conflict with callers that require JSON output.
- No executable tests or representative report are provided, so recommendation consistency, completeness, and ROI quality require human review.
- Chinese-language support and mainland-China network fit are not explicitly designed or verified.
What does this skill do, and when should you use it?
This is a read-only decision skill for assessing whether an existing mobile product should migrate to React Native. It examines product scope, native coupling, continuity, verification, release operations, ownership, agent governance, and delivery economics across accessible client codebases. It compares brownfield, greenfield, checkpoint-based, defer, and do-not-migrate outcomes. When material evidence is missing, it asks exactly one decision-changing question per turn instead of issuing a questionnaire. It does not perform the migration or provide implementation guidance for Expo, bare React Native, or host integration.
Reads the current workspace and available product repositories, CI, tests, release configuration, architecture records, and product documentation; identifies iOS, Android, app variants, and relevant clients; builds a platform inventory and coverage assessment; examines SDKs, permissions, storage, authentication, push, deep links, analytics, experiments, background work, extensions, payments, hardware APIs, offline behavior, and platform differences; evaluates verification, release, governance, and delivery baselines; asks one question at a time when evidence is missing; and produces a migration recommendation, representative checkpoint, acceptance criteria, ROI inputs, and next decision.
- An engineering lead with native iOS and Android clients needs to decide whether a shared React Native migration is justified.
- A team with separate client repositories needs an evidence-based platform inventory before choosing a migration path.
- A product and architecture group is weighing brownfield against greenfield while protecting installed-user and release continuity.
- A team wants a representative trial covering ordinary UI, authenticated state, and the native boundary most likely to disprove the plan.
- A business owner needs to estimate migration economics while retaining two-platform verification and counting full investment.
What are this skill's strengths and limitations?
- Covers product, native surface, continuity, verification, release, ownership, agent governance, and economics in one decision workflow.
- Requires explicit iOS-versus-Android comparison and evidence-status labeling for material claims.
- Supports brownfield, greenfield, checkpoint-based, defer, and do-not-migrate outcomes.
- The checkpoint tests real behavior, state, analytics, accessibility, performance, devices, and release evidence rather than easy screens alone.
- It is read-only and does not execute migration or host integration work.
- Assessment confidence depends on access to production client codebases and delivery artifacts; missing platforms reduce confidence.
- It does not invent cost, benefit, duration, or ROI inputs.
- Stakeholders may need to supply repository locations and business, organizational, and operational facts that repositories cannot establish.
How do you install this skill?
The skill is located at skills/assess-react-native-migration/. Install it with skill-installer: $skill-installer install assess-react-native-migration from callstackincubator/agent-skills. Alternatively, clone the repository and copy skills/* into project-level .codex/skills/ or user-level ~/.codex/skills/, then restart Codex. The repository is licensed under MIT.
How do you use this skill?
Run it from a workspace exposing as many production client codebases as possible, with a prompt such as: “Assess whether this product should migrate to React Native, inspect all accessible iOS and Android codebases, and produce a migration decision.” If scope or material evidence is missing, it continues with one question per turn; it produces the full report only after the evidence gate passes.
How does this skill compare with similar options?
The skill explicitly compares Path A brownfield, Path B greenfield, and Path C greenfield-first with brownfield fallback, while also allowing defer or do-not-migrate decisions. It favors brownfield when release or installed-user continuity dominates, native coupling is deep, or whole-app cutover risk is unacceptable; greenfield requires recoverable behavior, credible native replacements, proven continuity, and strong verification.