Mobile Project Audit
Purpose
Understand an existing mobile app before changing it: its runtime, structure, navigation, state approach, native modules, build/release setup, and platform readiness — so mobile planning is grounded, not assumed. The mobile counterpart to ../../existing-project-audit.
When to Use
- Any request against an existing mobile codebase.
- Before recommending a runtime change or mobile migration.
- Not for greenfield mobile work (record "greenfield").
Inputs
- Read access to the mobile project.
- The classified request (to scope the audit).
Discovery Questions
- Expo or React Native CLI? Which SDK/RN version?
- What navigation, state, and data-fetching approaches are in use?
- Which native modules/SDKs and permissions are present?
- What is the current build/release setup (EAS? Fastlane? manual)?
Responsibilities
- Detect runtime (Expo managed / dev builds / bare CLI) and versions.
- Map navigation, state ownership, and data-fetching patterns.
- Inventory native modules, permissions, and config plugins.
- Assess build/release setup and iOS/Android readiness signals.
- Flag security/performance signals; hand depth to
../../security-review / mobile-performance.
- Record findings; do not edit code.
Required Workflow
- Scope the audit to the request.
- Detect runtime + versions from config (
app.json/app.config, Podfile, Gradle).
- Map navigation/state/data patterns from representative screens.
- Inventory native modules, permissions, plugins.
- Survey build/release and readiness.
- Record findings + risks.
Decision Rules
- Report what the project proves vs what you infer.
- Scope to the affected area for small requests; don't audit everything.
- Deep security/performance analysis is delegated, not done here.
Rules
- Read-only; no edits during the audit.
- Do not print secret values (redact) (
../../security-review).
- Ground later mobile stages in findings, not guesses.
Anti-Patterns
- Proposing changes before understanding the runtime/patterns.
- Auditing the whole app for a one-screen change.
- Treating inferences as confirmed.
Validation Checklist
Definition of Done
A scoped, read-only audit of the mobile app covering runtime, patterns, native modules, build/release, and readiness — confirmed vs inferred separated — ready to inform mobile planning.
Related Skills
../../existing-project-audit, mobile-stack-selection, mobile-navigation, mobile-state-management, mobile-native-modules, mobile-builds, ios-readiness, android-readiness, ../../security-review, mobile-performance.
Related Knowledge
../../../knowledge/ (existing mobile architecture).
Related References
../../../references/mobile/ topic folders when populated.
Context Loading Guidance
- Requires: mobile project read access, the classified request.
- Does not require: the whole app source, unrelated references, every mobile skill.
- May load:
mobile-native-modules, mobile-builds, readiness skills for depth.
- Stop when: the scoped audit is recorded.
Token Efficiency Guidance
Read config and representative screens first; sample, don't read everything. Summarize into findings; don't paste large files.
1---2name: mobile-project-audit3description: Use when a mobile app already exists, before changing it — inventory the runtime (Expo vs CLI), navigation, state, native modules, build config, and iOS/Android readiness. Read-only; grounds mobile planning in reality. Delegates deep security/performance to their skills.4---56# Mobile Project Audit78## Purpose910Understand an existing mobile app before changing it: its runtime, structure, navigation, state approach, native modules, build/release setup, and platform readiness — so mobile planning is grounded, not assumed. The mobile counterpart to `../../existing-project-audit`.1112## When to Use1314- Any request against an existing mobile codebase.15- Before recommending a runtime change or mobile migration.16- **Not** for greenfield mobile work (record "greenfield").1718## Inputs1920- Read access to the mobile project.21- The classified request (to scope the audit).2223## Discovery Questions2425- Expo or React Native CLI? Which SDK/RN version?26- What navigation, state, and data-fetching approaches are in use?27- Which native modules/SDKs and permissions are present?28- What is the current build/release setup (EAS? Fastlane? manual)?2930## Responsibilities3132- Detect **runtime** (Expo managed / dev builds / bare CLI) and versions.33- Map **navigation**, **state ownership**, and **data-fetching** patterns.34- Inventory **native modules**, permissions, and config plugins.35- Assess **build/release** setup and **iOS/Android readiness** signals.36- Flag security/performance signals; hand depth to `../../security-review` / `mobile-performance`.37- Record findings; do **not** edit code.3839## Required Workflow40411. Scope the audit to the request.422. Detect runtime + versions from config (`app.json`/`app.config`, `Podfile`, Gradle).433. Map navigation/state/data patterns from representative screens.444. Inventory native modules, permissions, plugins.455. Survey build/release and readiness.466. Record findings + risks.4748## Decision Rules4950- Report what the project proves vs what you infer.51- Scope to the affected area for small requests; don't audit everything.52- Deep security/performance analysis is delegated, not done here.5354## Rules5556- Read-only; no edits during the audit.57- Do not print secret values (redact) (`../../security-review`).58- Ground later mobile stages in findings, not guesses.5960## Anti-Patterns6162- Proposing changes before understanding the runtime/patterns.63- Auditing the whole app for a one-screen change.64- Treating inferences as confirmed.6566## Validation Checklist6768- [ ] Runtime + versions detected.69- [ ] Navigation/state/data patterns mapped.70- [ ] Native modules/permissions/plugins inventoried.71- [ ] Build/release + readiness surveyed.72- [ ] Security/performance signals flagged.73- [ ] No code edited.7475## Definition of Done7677A scoped, read-only audit of the mobile app covering runtime, patterns, native modules, build/release, and readiness — confirmed vs inferred separated — ready to inform mobile planning.7879## Related Skills8081`../../existing-project-audit`, `mobile-stack-selection`, `mobile-navigation`, `mobile-state-management`, `mobile-native-modules`, `mobile-builds`, `ios-readiness`, `android-readiness`, `../../security-review`, `mobile-performance`.8283## Related Knowledge8485`../../../knowledge/` (existing mobile architecture).8687## Related References8889`../../../references/mobile/` topic folders when populated.9091## Context Loading Guidance9293- **Requires:** mobile project read access, the classified request.94- **Does not require:** the whole app source, unrelated references, every mobile skill.95- **May load:** `mobile-native-modules`, `mobile-builds`, readiness skills for depth.96- **Stop when:** the scoped audit is recorded.9798## Token Efficiency Guidance99100Read config and representative screens first; sample, don't read everything. Summarize into findings; don't paste large files.
ahtishamshahzad