assess-react-native-migration

Name: assess-react-native-migration
Author: callstackincubator

1.6kstars111forks

How to install assess-react-native-migration?

callstackincubator/agent-skills/assess-react-native-migration

$npx -y skills add callstackincubator/agent-skills --skill assess-react-native-migration

Installs into the current project.

Summary

Assesses whether and how an existing mobile product should migrate to React Native. Use when auditing one or more product repositories for migration readiness, including products whose iOS, Android, and other clients live in separate directories or repositories; choosing brownfie

Files · 1

View on GitHub

SKILL.md

1	# Assess React Native Migration
2
3	Produce a read-only migration decision. Diagnose the product and delivery system; do not execute the migration.
4
5	## Establish Product Scope
6
7	Run the assessment from a workspace that exposes as many production client codebases as possible. The current checkout is not evidence that it contains the whole product.
8
9	Before assessing readiness:
10
11	1. Inspect the current repository and every workspace root available to the agent.
12	2. Infer supported client platforms from product documentation, CI, release configuration, workspace manifests, submodules, and references to sibling repositories.
13	3. Locate each production client codebase, including separate native iOS and Android repositories, app variants, and any web client relevant to staffing or proposed code sharing.
14	4. Record a platform inventory with the client, repository or path, evidence of product membership, and access status.
15
16	When iOS and Android are both supported, inspect both native codebases before recommending a path. If a codebase remains unavailable, mark its evidence `unknown`, state that the assessment covers only the accessible platforms, and lower confidence accordingly. Do not infer that a platform is unsupported merely because its project is absent from the current repository.
17
18	Scope gate: every supported production client is listed, and each codebase is accessible, explicitly unavailable, or confirmed not to exist.
19
20	## First Response Gate
21
22	When the scope gate has not passed, the first response must be exactly:
23
24	```markdown
25	Question: Where can I access the production codebase for each client platform this product supports, including iOS and Android if both exist?
26
27	Why it matters: A migration path based on only one platform can miss native dependencies, product behavior, and delivery constraints that change the decision.
28	```
29
30	After the scope gate passes, grill rather than survey when repository evidence is unavailable.
31
32	If the measurable migration driver is unknown, the first response must be exactly:
33
34	```markdown
35	Question: What measurable delivery or business problem should a React Native migration solve?
36
37	Why it matters: This determines whether migration is relevant and which outcomes the assessment must test.
38	```
39
40	If the driver is already known, ask only the next highest-impact unknown using the same two-line shape. End the turn immediately after the question and reason. Do not add a preamble, questionnaire, recommendation, or implementation guidance.
41
42	## Rules
43
44	- Treat every production app as a source of truth, including undocumented behavior.
45	- Inspect available code, CI, tests, release configuration, product documents, and runtime evidence before asking questions.
46	- Compare iOS and Android explicitly where their implementation, behavior, dependencies, delivery, or roadmap differ.
47	- Base product-wide claims only on evidence from every supported platform, or qualify their platform coverage.
48	- Label material claims `observed`, `measured`, `reported`, `assumed`, or `unknown`.
49	- Recommend from evidence, not an aggregate readiness score.
50	- Default to gathering evidence, not to brownfield, greenfield, or migration itself.
51	- Own the decision phase. Do not apply implementation skills or select Expo versus bare React Native before Path A is accepted.
52	- Count only React Native's marginal value over the current native system.
53	- Measure agents by accepted, verified work, not tokens, generated code, or pull requests.
54	- Make no universal claims about duration, cost, code sharing, agent productivity, or ROI.
55
56	## Select the Evidence Mode
57
58	Use repository-backed assessment when source code or delivery artifacts are available:
59
60	1. Complete the platform inventory and establish which repositories the assessment can inspect.
61	2. For each accessible mobile codebase, locate app variants, CI, tests, release configuration, architecture records, and product documentation.
62	3. Search each native codebase for SDKs, permissions, app extensions, storage, authentication, push, deep links, analytics, experiments, and platform-specific behavior.
63	4. Cite repository names plus file paths and line numbers so evidence remains attributable when codebases are separate.
64	5. Ask stakeholde

People who liked this also viewed

6 picks

Type

assess-react-native-migration

1.6kstars111forks

View on GitHub

How to install assess-react-native-migration?

callstackincubator/agent-skills/assess-react-native-migration

$npx -y skills add callstackincubator/agent-skills --skill assess-react-native-migration

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Assess React Native Migration
2
3	Produce a read-only migration decision. Diagnose the product and delivery system; do not execute the migration.
4
5	## Establish Product Scope
6
7	Run the assessment from a workspace that exposes as many production client codebases as possible. The current checkout is not evidence that it contains the whole product.
8
9	Before assessing readiness:
10
11	1. Inspect the current repository and every workspace root available to the agent.
12	2. Infer supported client platforms from product documentation, CI, release configuration, workspace manifests, submodules, and references to sibling repositories.
13	3. Locate each production client codebase, including separate native iOS and Android repositories, app variants, and any web client relevant to staffing or proposed code sharing.
14	4. Record a platform inventory with the client, repository or path, evidence of product membership, and access status.
15
16	When iOS and Android are both supported, inspect both native codebases before recommending a path. If a codebase remains unavailable, mark its evidence `unknown`, state that the assessment covers only the accessible platforms, and lower confidence accordingly. Do not infer that a platform is unsupported merely because its project is absent from the current repository.
17
18	Scope gate: every supported production client is listed, and each codebase is accessible, explicitly unavailable, or confirmed not to exist.
19
20	## First Response Gate
21
22	When the scope gate has not passed, the first response must be exactly:
23
24	```markdown
25	Question: Where can I access the production codebase for each client platform this product supports, including iOS and Android if both exist?
26
27	Why it matters: A migration path based on only one platform can miss native dependencies, product behavior, and delivery constraints that change the decision.
28	```
29
30	After the scope gate passes, grill rather than survey when repository evidence is unavailable.
31
32	If the measurable migration driver is unknown, the first response must be exactly:
33
34	```markdown
35	Question: What measurable delivery or business problem should a React Native migration solve?
36
37	Why it matters: This determines whether migration is relevant and which outcomes the assessment must test.
38	```
39
40	If the driver is already known, ask only the next highest-impact unknown using the same two-line shape. End the turn immediately after the question and reason. Do not add a preamble, questionnaire, recommendation, or implementation guidance.
41
42	## Rules
43
44	- Treat every production app as a source of truth, including undocumented behavior.
45	- Inspect available code, CI, tests, release configuration, product documents, and runtime evidence before asking questions.
46	- Compare iOS and Android explicitly where their implementation, behavior, dependencies, delivery, or roadmap differ.
47	- Base product-wide claims only on evidence from every supported platform, or qualify their platform coverage.
48	- Label material claims `observed`, `measured`, `reported`, `assumed`, or `unknown`.
49	- Recommend from evidence, not an aggregate readiness score.
50	- Default to gathering evidence, not to brownfield, greenfield, or migration itself.
51	- Own the decision phase. Do not apply implementation skills or select Expo versus bare React Native before Path A is accepted.
52	- Count only React Native's marginal value over the current native system.
53	- Measure agents by accepted, verified work, not tokens, generated code, or pull requests.
54	- Make no universal claims about duration, cost, code sharing, agent productivity, or ROI.
55
56	## Select the Evidence Mode
57
58	Use repository-backed assessment when source code or delivery artifacts are available:
59
60	1. Complete the platform inventory and establish which repositories the assessment can inspect.
61	2. For each accessible mobile codebase, locate app variants, CI, tests, release configuration, architecture records, and product documentation.
62	3. Search each native codebase for SDKs, permissions, app extensions, storage, authentication, push, deep links, analytics, experiments, and platform-specific behavior.
63	4. Cite repository names plus file paths and line numbers so evidence remains attributable when codebases are separate.
64	5. Ask stakeholde

People who liked this also viewed

6 picks

Type