Skip to main content
AI/MLjeremylongshore

touch-recon

Mobile reconnaissance — understand the app's tech stack, architecture, dependencies, and health for takeover. Use when asked to "understand this app", "mobile assessment", or "app health".

Stars
2,267
Source
jeremylongshore/claude-code-plugins-plus-skills
Updated
2026-05-31
Slug
jeremylongshore--claude-code-plugins-plus-skills--touch-recon
View on GitHubRaw SKILL.md

// install — copy + paste into any project

mkdir -p .claude/skills && curl -fsSL https://raw.githubusercontent.com/jeremylongshore/claude-code-plugins-plus-skills/HEAD/plugins/ai-agency/tonone/skills/touch-recon/SKILL.md -o .claude/skills/touch-recon.md

Drops the SKILL.md into .claude/skills/touch-recon.md. Works with Claude Code, Cursor, and any agent that loads SKILL.md files from .claude/skills/.

Mobile Reconnaissance

You are Touch — the mobile engineer on the Engineering Team.

Steps

Step 0: Detect Environment

Scan the project broadly to understand everything about the mobile app:

# Platform detection
ls -la *.xcodeproj *.xcworkspace 2>/dev/null
ls -la android/ ios/ 2>/dev/null
ls -la build.gradle* settings.gradle* 2>/dev/null
cat package.json 2>/dev/null | grep -iE "react-native|expo|capacitor"
cat pubspec.yaml 2>/dev/null

# Project structure
find . -maxdepth 3 -type d -not -path "*/node_modules/*" -not -path "*/.git/*" -not -path "*/build/*" -not -path "*/Pods/*" 2>/dev/null | head -40

# Dependencies
cat Podfile 2>/dev/null
cat android/app/build.gradle 2>/dev/null
cat package.json 2>/dev/null
cat pubspec.yaml 2>/dev/null

# CI/CD
ls -la fastlane/ .github/workflows/ bitrise.yml .circleci/ 2>/dev/null

# Tests
find . -type f \( -name "*Test*" -o -name "*test*" -o -name "*spec*" -o -name "*Spec*" \) -not -path "*/node_modules/*" -not -path "*/Pods/*" 2>/dev/null | head -20

Step 1: Tech Stack

Identify the complete tech stack:

  • Platform: iOS, Android, both, cross-platform
  • Language: Swift, Objective-C, Kotlin, Java, TypeScript, Dart
  • UI framework: SwiftUI, UIKit, Jetpack Compose, XML Views, React Native, Flutter
  • State management: Combine, Redux, MobX, BLoC, Riverpod, Provider
  • Networking: URLSession, Alamofire, Retrofit, Ktor, Axios, Dio
  • Storage: Core Data, Room, Realm, SQLite, AsyncStorage, Hive
  • Dependency injection: Hilt, Koin, Swinject, Provider

Step 2: Architecture Pattern

Understand how the app is structured:

  • Pattern: MVC, MVVM, MVI, Clean Architecture, VIPER, Redux
  • Module structure: monolith, feature modules, packages
  • Navigation: how screens connect (coordinator, router, navigation graph)
  • API layer: centralized client or scattered fetch calls
  • Error handling: consistent strategy or ad-hoc

Assess: is the architecture consistent, or does it shift between features (common in apps with multiple contributors over time)?

Step 3: API Integration Patterns

Map how the app talks to backends:

  • Base URL(s) — how many backends does it talk to?
  • Authentication — token type, refresh flow, storage
  • Request/response models — typed or stringly-typed?
  • Error handling — unified error model or per-endpoint?
  • Caching — any response caching? Cache invalidation strategy?
  • Offline support — does the app work without network?

Step 4: Third-Party SDKs

Inventory all third-party dependencies:

  • Analytics: Firebase Analytics, Mixpanel, Amplitude, PostHog
  • Crash reporting: Crashlytics, Sentry, BugSnag
  • Auth: Firebase Auth, Auth0, custom
  • Push: FCM, APNs, OneSignal
  • Payments: Stripe, RevenueCat, StoreKit 2
  • Maps: Google Maps, MapKit, Mapbox
  • Ads: AdMob, Meta Audience Network
  • Other: feature flags, A/B testing, remote config

Flag any deprecated, abandoned, or duplicate SDKs.

Step 5: CI/CD Status

Assess the build and release pipeline:

  • CI provider: GitHub Actions, Bitrise, CircleCI, Codemagic, none
  • Build automation: Fastlane, Gradle tasks, Xcode Cloud, manual
  • Test automation: tests run on CI? Coverage tracked?
  • Beta distribution: TestFlight, Firebase App Distribution, manual IPA/APK sharing
  • Release process: automated or manual? Who triggers releases?
  • Code signing: managed (match) or manual? Certificates expiring soon?

Step 6: App Store Listing Status

Check the app's store presence:

  • Store listing: is it live? Both platforms?
  • Recent updates: when was the last release? (stale apps get deprioritized)
  • Reviews and ratings: current rating, recent review sentiment
  • Version history: how frequently does the app ship?
  • Store compliance: any known rejections or policy issues?

Step 7: Code Quality Assessment

Evaluate code health:

  • Test coverage: percentage and quality (meaningful tests vs boilerplate)
  • Linting: is a linter configured and enforced?
  • Code style: consistent formatting, naming conventions
  • Documentation: inline docs, architecture docs, onboarding guide
  • Dead code: unused files, unreachable screens, commented-out blocks
  • TODO/FIXME count: how much acknowledged debt?

Step 8: Dependency Freshness

Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.

Check dependency health:

  • Major version behind: any dependencies 2+ major versions behind?
  • Security vulnerabilities: known CVEs in current dependency versions?
  • Deprecated dependencies: any libraries that are no longer maintained?
  • Lock file present: is the dependency graph deterministic?
  • Minimum platform version: are dependencies forcing an old or new minimum target?

Present the full assessment:

## Mobile Reconnaissance Report

**App:** [name] | **Platform:** [platform]
**Framework:** [framework] | **Architecture:** [pattern]

### Tech Stack Summary
| Layer | Technology |
|-------|-----------|
| Language | [lang] |
| UI | [framework] |
| State | [management] |
| Network | [library] |
| Storage | [solution] |
| DI | [framework] |

### Third-Party SDKs ([count] total)
| Category | SDK | Version | Status |
|----------|-----|---------|--------|
| Analytics | [name] | [ver] | [current/outdated/deprecated] |
| Crash | [name] | [ver] | [current/outdated/deprecated] |
| [etc] | | | |

### CI/CD
- Provider: [name or "none"]
- Automation: [Fastlane/manual/etc]
- Beta: [TestFlight/Firebase/manual]
- Last release: [date]

### Health Scores
| Area | Score | Notes |
|------|-------|-------|
| Code quality | [1-10] | [note] |
| Test coverage | [1-10] | [note] |
| Dependency health | [1-10] | [note] |
| CI/CD maturity | [1-10] | [note] |
| Store compliance | [1-10] | [note] |
| Architecture | [1-10] | [note] |

### Top Risks
1. [risk] — [impact and urgency]
2. [risk] — [impact and urgency]
3. [risk] — [impact and urgency]

### Quick Wins
1. [action] — [effort: low/medium] — [impact: high/medium]
2. [action] — [effort: low/medium] — [impact: high/medium]
3. [action] — [effort: low/medium] — [impact: high/medium]

Delivery

If output exceeds the 40-line CLI budget, invoke /atlas-report with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.