react-native-platform-integration

스타8

포크0

업데이트2026년 7월 7일 13:21

React Native and Expo native/platform integration guidance for FE Dev. Use when a task touches Expo config, native iOS/Android files, permissions, deep links, push notifications, secure storage, app lifecycle, native modules, build settings, or platform-specific behavior.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

evolplus

evolplus/talos

GitHub 저장소 열기 Creator 저장소 보기

다운로드

React Native Platform Integration

When to use

Use this for React Native/Expo work that crosses the JS/native boundary: native modules, permissions, platform files, app config, deep links, push notifications, background tasks, secure storage, lifecycle hooks, or iOS/Android-specific behavior. Load it alongside react-native-implementation.

Inputs and outputs

Inputs: SRS/architecture permission and platform requirements, API contracts, env configuration, existing Expo/bare RN setup, iOS/Android project files, current native module inventory.
Outputs: platform changes that are approved by architecture, configured per environment, covered by smoke/build checks, and documented in task notes or deploy reports when QA/DevOps needs them.

Procedure

Classify the runtime:
- Expo managed: prefer config plugins and Expo APIs already present;
- Expo prebuild: understand generated native files and project rules before editing;
- bare RN: edit native iOS/Android files directly only when the task requires it.
Check authorization before changing platform capabilities:
- new permissions, native modules, background modes, push notifications, app groups, associated domains, and platform services require architecture/dependency approval;
- if the requirement is absent, halt with an OQ instead of silently adding capability.
Implement environment-safe config:
- use SRS §3.4.6 keys and existing config loaders;
- keep dev/staging/prod endpoints out of source literals;
- expose only non-secret values to JS bundles.
Keep permission UX complete:
- update iOS usage descriptions and Android permission declarations;
- provide user-facing rationale/copy where required by the feature;
- handle denied, restricted, unavailable, and recoverable states in UI.
Isolate platform differences:
- use .ios.tsx / .android.tsx, platform adapters, or config modules for real divergence;
- keep shared UI unaware of native file details.
Verify platform behavior:
- run at least one affected platform build/check when native files or permissions change;
- test deep links, push/open flows, storage migration, or lifecycle paths on the relevant simulator/emulator/device;
- record any platform that could not be checked.

Hard rules

Do not add native capabilities or permissions without SRS/architecture coverage.
Do not store tokens or secrets in plain async storage.
Do not edit generated native files in Expo managed/prebuild projects unless that is the established project workflow.
Do not let iOS and Android selector IDs diverge unless the instrumentation contract explicitly declares platform-specific IDs.

References

../react-native-implementation/SKILL.md - baseline RN implementation discipline.
../react-native-performance/SKILL.md - performance review for native bridge or platform-heavy changes.
../third-party-dependency-evaluation/SKILL.md - dependency approval for native modules.
../local-deployment/SKILL.md - deploy/env evidence consumed by QA.

이 저장소의 다른 Skills

같은 저장소

be-framework-coding-standard

evolplus/talos

Standardized backend implementation guidance for BE Dev using the SRS-declared Backend-Track and Backend-Framework. Use when coding, refactoring, or reviewing backend web APIs, BFFs, microservices, workers, jobs, or service integrations in TypeScript with Express, TypeScript with NestJS, Python with FastAPI, Java with Spring Boot, .NET Core C#, Pure Golang, Java Core, Golang with Gin, Golang with Fiber, Golang with Echo, or Golang with Kratos; BE Dev reads docs/SRS.md Backend-Track and Backend-Framework plus §3.4.5 Source Layout, then selects the matching reference so routing, layering, contracts, validation, observability, errors, transactions, and tests match the chosen stack.

2026-07-308

local-deployment

evolplus/talos

How DevOps composes the local Docker environment for QA and operator trials, including port probing, secret-safe env discovery, test-only runtime-reset endpoint verification for direct-DB fixtures, QA deploy-report fields, and human trial URLs without editing project Compose files.

2026-07-308

playwright-author

evolplus/talos

Concrete how-to for QA-Author writing Playwright specs from markdown TCs — project layout, full-state resets for direct-DB fixtures and caches, parallel-worker isolation, contract-aware URL assertions, network mocking, retries, traces, and visual diffs. Consult after `ui-test-execution` when the target surface is web AND the project uses Playwright.

2026-07-308

qa-execution-runner

evolplus/talos

QA-Exec run contract for executing authored test cases against the deployed build. Use when QA-Exec is dispatched for a task in-test to gather by-us/by-task test cases, check executable specs and instrumentation coverage, invoke the proper runner, execute UI tiers, validate visual specs, route failures, and write docs/qa-reports/<task-id>.md plus artifacts.

2026-07-308

sdlc-loop

evolplus/talos

Codex-native orchestration entrypoint for Evo Talos. Use when the user asks for /sdlc-loop, sdlc-loop, start project, continue the SDLC loop, run the governed workflow, or auto-dispatch eligible SDLC work until the next gate. Acts as the Codex equivalent of the Claude slash command.

2026-07-308

ui-test-execution

evolplus/talos

Framework-agnostic principles for executing UI tests against the running build — TC-to-spec mapping, selectors, full-state fixture reset across DB/cache/worker state, shared-resource parallelism, determinism, and visual diffs. Consult when QA-Author writes executable specs or QA-Exec invokes a runner against a deployed build.

2026-07-308

name	react-native-platform-integration
description	React Native and Expo native/platform integration guidance for FE Dev. Use when a task touches Expo config, native iOS/Android files, permissions, deep links, push notifications, secure storage, app lifecycle, native modules, build settings, or platform-specific behavior.
agents	["fe-dev"]
sdlc_phase	implementation
owner	Platform Eng
status	active

React Native Platform Integration

When to use

Inputs and outputs

Inputs: SRS/architecture permission and platform requirements, API contracts, env configuration, existing Expo/bare RN setup, iOS/Android project files, current native module inventory.
Outputs: platform changes that are approved by architecture, configured per environment, covered by smoke/build checks, and documented in task notes or deploy reports when QA/DevOps needs them.

Procedure

Classify the runtime:
- Expo managed: prefer config plugins and Expo APIs already present;
- Expo prebuild: understand generated native files and project rules before editing;
- bare RN: edit native iOS/Android files directly only when the task requires it.
Check authorization before changing platform capabilities:
- new permissions, native modules, background modes, push notifications, app groups, associated domains, and platform services require architecture/dependency approval;
- if the requirement is absent, halt with an OQ instead of silently adding capability.
Implement environment-safe config:
- use SRS §3.4.6 keys and existing config loaders;
- keep dev/staging/prod endpoints out of source literals;
- expose only non-secret values to JS bundles.
Keep permission UX complete:
- update iOS usage descriptions and Android permission declarations;
- provide user-facing rationale/copy where required by the feature;
- handle denied, restricted, unavailable, and recoverable states in UI.
Isolate platform differences:
- use .ios.tsx / .android.tsx, platform adapters, or config modules for real divergence;
- keep shared UI unaware of native file details.
Verify platform behavior:
- run at least one affected platform build/check when native files or permissions change;
- test deep links, push/open flows, storage migration, or lifecycle paths on the relevant simulator/emulator/device;
- record any platform that could not be checked.

Hard rules

Do not add native capabilities or permissions without SRS/architecture coverage.
Do not store tokens or secrets in plain async storage.
Do not edit generated native files in Expo managed/prebuild projects unless that is the established project workflow.
Do not let iOS and Android selector IDs diverge unless the instrumentation contract explicitly declares platform-specific IDs.

References

../react-native-implementation/SKILL.md - baseline RN implementation discipline.
../react-native-performance/SKILL.md - performance review for native bridge or platform-heavy changes.
../third-party-dependency-evaluation/SKILL.md - dependency approval for native modules.
../local-deployment/SKILL.md - deploy/env evidence consumed by QA.