← Back to Native mobile foundation team
See how it helps
Discover a mobile project
Maps the actual mobile stack, deployment targets and state ownership before changing implementation.
mobile-project-discovery
Team members using this skill
When is it useful?
Use when entering an existing React Native, Flutter or native project.
What does it help you do?
- Identifies framework versions, build workflow and platform targets.
- Traces navigation, state, API and persistence ownership.
- Coordinates shared boundaries with native, backend and design work.
Try asking this
Inspect our mobile repository and identify where notification routing, authentication and persisted drafts belong. Trace a notification from a terminated app through login to its destination. Identify the owners of routing, credentials and restored drafts before implementation.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Mobile Project & Platform Discovery
Adapt to the project's actual mobile stack, target OS versions and architectural boundaries before writing code. Never mix frameworks or introduce a competing state/navigation library; for a brand-new app, agree the stack with the architect based on product goals, hardware needs and release workflow.
1. Fingerprint the stack, workflow and deployment targets
| Stack | Manifests & Config to Inspect | Key Version & Architecture Signals |
|---|---|---|
| React Native / Expo | package.json, app.json / app.config.ts, eas.json, metro.config.js, babel.config.js |
Expo SDK version, CNG / Prebuild (generated ios/ & android/) vs Bare RN, New Architecture (newArchEnabled, Fabric/TurboModules), Hermes engine, runtimeVersion policy. |
| Flutter | pubspec.yaml, analysis_options.yaml, build.yaml, l10n.yaml, lib/main_*.dart |
Dart SDK constraint, Impeller renderer config, flavors, codegen (build_runner, freezed, json_serializable, riverpod_generator, pigeon). |
| Native iOS | *.xcodeproj, *.xcworkspace, Package.swift, Podfile, Info.plist, *.entitlements |
IPHONEOS_DEPLOYMENT_TARGET, Swift language mode (Swift 5 vs Swift 6 strict concurrency), SwiftUI vs UIKit lifecycle, App Groups / Keychain sharing. |
| Native Android | settings.gradle(.kts), app/build.gradle(.kts), gradle/libs.versions.toml, AndroidManifest.xml |
minSdk, targetSdk, compileSdk, Kotlin & Compose compiler versions, build flavors/variants, ProGuard/R8 rules (proguard-rules.pro). |
2. Map existing architecture and state ownership
- Trace how a feature flows end-to-end: Screen / Widget -> ViewModel / Notifier / Hook -> Repository / Service -> HTTP Client / Local DB / Native Bridge.
- Identify the single owner for each data category:
- Server cache: TanStack Query / RTK Query / Riverpod
AsyncNotifier/ Repository cache. - Encrypted credentials: iOS Keychain / Android Keystore (
expo-secure-store,react-native-keychain,flutter_secure_storage). - Structured local persistence: SQLite (
expo-sqlite, WatermelonDB, Drift, Room, SwiftData/CoreData) vs fast KV (MMKV,SharedPreferences,UserDefaults). - Ephemeral UI & route state: local component state and serializable route parameters.
- Server cache: TanStack Query / RTK Query / Riverpod
- Locate existing design tokens, safe-area wrappers, keyboard-avoiding containers, localization catalogs and test harnesses.
3. Coordinate cross-cutting boundaries
- Never hand-edit generated native folders in Expo CNG or generated
.g.dart/.freezed.dartfiles in Flutter. - When a task requires native toolchain changes, new OS entitlements or API contract changes, align with the architect, backend developers or security reviewer before coding.
Before you finish
- Stack, SDK version, New Architecture/Impeller status and
minSdk/ iOS deployment target verified. - Managed/CNG vs bare/native workflow and codegen pipeline identified.
- Existing router, state store, API client, secure storage and design primitives mapped.
- Exact commands for typecheck, static analysis, codegen and tests confirmed.
Included files 2
LICENSE.txtSKILL.md