Auto-Setup Maestro UI Tests for React Native App

Setting up Maestro UI tests for a React Native app by hand is slow — read your
navigator, decide which screens matter, tag every element with a stable `testID`, write
each flow, wire up auth, connect to a backend. **This skill does all of that wiring for
you.** Point it at your project root; it reads how your app is built and generates a
complete, runnable Maestro suite — then tells you exactly how to run it.

### ✅ What you get
- **Auto-detected navigation** — React Navigation (native-stack, stack, tabs, drawer),
  Expo Router, or Wix react-native-navigation
- **Curated screen coverage** — it discovers your screens and *you* pick which ones
  matter (selective, not every file)
- **A `testID` tagging plan** — including the iOS gotchas that silently break selectors
- **One Maestro flow per screen** — happy-path, plus server-side error-state flows when
  a mock server is available
- **Setup + login subflows** — `clearState`/`launchApp`, and a zero-app-source login
  contract for auth-gated apps
- **`package.json` scripts + exact run commands** — ready to `maestro test`

### 🔌 How it connects to your backend
The test build points your app's API base URL at your backend via
`EXPO_PUBLIC_API_URL` (baked at build time — `localhost` for iOS, `10.0.2.2` for the
Android emulator). No HTTP-client hacks, no in-app test code.

### 🧩 Works on its own — better with a mock server
On its own it stands up a complete, runnable **happy-path** suite — that's the
auto-setup, done, no extra purchase needed.

For **deterministic, offline runs and error-state coverage**, add a mock server that
exposes the `/__mock/*` control API — the companion skill **Bootstrap Mobile Mock
Server** scaffolds one in a single step. No mock server yet? This skill asks how you'd
like to proceed and scaffolds the happy-path suite right away; add the mock server later
and re-run to generate the error-state flows.

### 🛡️ Safe by default
It shows the full plan and asks before writing anything. The only source edits it makes
are `testID` props (and the minimal accessibility props that make elements addressable)
— **no refactors, no logic changes.** The default auth strategy touches no app source.

### 🧪 Why it works
Distilled from a **production React Native testing harness used on real shipping apps**,
so it already handles what makes hand-rolled Maestro setups flaky:
- iOS not forwarding a `TextInput`'s `testID` to `accessibilityIdentifier`
- `TouchableWithoutFeedback` merging the accessibility tree so child `testID`s vanish
- Maestro `runScript` quirks (no reliable `env`, `http.post` needs a body)
- Per-platform mock host (`localhost` vs `10.0.2.2`) and OS permission dialogs

### ▶️ What you run
It **scaffolds and instructs** — writes the suite and the run commands; you run
`maestro test` against your simulator/emulator.

### 📋 Requirements
- A React Native project (Expo or bare RN)
- Maestro CLI + Java 17 *(it prints the install commands if missing)*

---
*Built for React Native developers and mobile QA engineers who want a real E2E UI-test
suite stood up in minutes instead of days.*