expo-smoke-test

Files (6)

• SKILL.md
• openai.yaml · agents/
• expo-smoke-runner.md · companion-agents/claude/
• expo-smoke-runner.toml · companion-agents/codex/
• manifest.json · companion-agents/
• evals.json · evals/

SKILL.md (first lines)

# Expo Smoke Test

This skill requires `project-knowledge`. Before doing any work, confirm it is
installed. When it is missing, stop and report it with its install command,
`npx skills@latest add toy-crane/skills --skill project-knowledge`, using the
project's package manager runner where it pins one.

Prove two things on each platform: the current change works, and the app's core
loop still works. Static inspection, type checks, unit tests, and a successful
bundle support the result but do not replace device verification.

## Establish the run

Inspect the request, the current diff, the Expo config, and the package
manifest to identify the flow the change affects and its observable result.

Read root `PRODUCT.md` when it exists and derive one representative journey
from its core loop. Read that file only; never create or edit it. When
`PRODUCT.md` or its core loop is absent, verify the change flow alone and
report the missing regression coverage.

Use the installed CLI's version-matched guidance instead of remembered command
shapes:

```bash
agent-device help workflow
agent-device help react-native
```

If `agent-device` is unavailable, report that runtime verification is blocked
and give `npm install -g agent-device@latest` as the setup command.

Point each platform's client at this project's own dev server rather than a
default port another checkout may already hold. Pass the port as a session
runtime hint with `--metro-port`, and confirm from the running tools which port
this project actually serves.

## Pass preflight before behavior

Keep three gates explicit for each platform:

1. **Runtime readiness:** the exact target, development build, project-owned
   Metro server, and observation path are usable, and the loaded bundle or
   native build belongs to this checkout.
2. **Known initial state:** app-local data, OS permissions, login or fixture
   state, and every affected backend boundary match the journey's premise.
3. **Behavior verification:** the prepared app is driven and the change flow
   plus core loop reach their exact outcomes. Passing preparation never
   satisfies this gate.

Use narrow checks for routine readiness. Run `agent-device doctor` only when
the user asks for environment diagnosis or a failed readiness check suggests an
unhealthy device, app, development server, or runner.

Choose and report one state profile per platform:

- **Known app state** is the default. Prepare only the app data, explicit
  permissions, login, and fixture state the journey needs while preserving
  unrelated device state. Empty and seeded states both qualify when they are
  explicit and reproducible. App-state clearing and permission reset are
  separate boundaries; report each one actually changed.
- **Fresh device** applies when the request requires a fresh install or the
  change depends on first launch, onboarding, OS permission history, secure
  device storage, application identity, native configuration, deep links, push
  behavior, another device-level surface, or evidenced device-state
  contamination. Reset only a simulator or emulator the request or project
  allocation establishes as dedicated to this run. Fresh-device preparation
  requires `agent-device` 0.20.10 or newer, whose device claims reject foreign
  local mutations; earlier releases advertise claims without enforcing them.
  Acquire each exact target through its final `smoke-ios` or `smoke-android`
  session with `agent-device open`, confirm
  `agent-device device status` names that session and workspace, and keep the
  claim through reset, boot, reinstall, Metro reconnection, and worker handoff.
  If the claim cannot be acquired or held across the selected reset mechanism,
  stop before reset. Absence from an advisory claim list is not proof of
  ownership. Address one exact target, never all devices. After reset,
  re-establish the allowed backend fixture before behavior verification.
- **Preserved or prior state** retains or seeds the earlier application and
  backend state needed for returning-user, upgrade, or migration behavior.
  Once that premise is prepared, do not clear app data or erase the target
  before driving the flow.

Never erase a physical, user-owned, shared, or otherwise unowned target. When a
fresh-device claim has no eligible virtual target, report that platform's
runtime-readiness blocker. When a usable target exists but its required state
cannot safely be established, report the known-initial-state blocker. Do not
weaken the scenario or mutate another owner's environment.

Treat Supabase or another stateful service as a separate affected surface. Use
only the repository's deterministic local or test readiness, migration, reset,
and seed path needed by the journey. A ready client never proves backend state,
and ordinary verification authority never permits a destructive linked or
remote reset.

## Choose devices and sessions

Use a local simulator and emulator as the default targets. Use a physical
device when one is connected and the user asks for it. A physical iOS target
additionally needs Developer Mode and a signed XCTest runner; when that setup
is missing, report the exact prerequisites from
`agent-device help physical-device` as a blocker rather than substituting a
simulator.

Run every platform against a development build of the project itself. A
development build is the binary this change will ship in, so it is the only
client that can carry the project's own native modules, config plugins,
permissions, and entitlements. Expo Go is a fixed prebuilt shell: passing there
proves the JavaScript behaved inside a different binary than the one being
delivered, which is not the evidence this check exists to produce. When no
development build is installed, build one with the repository-supported command,
normally `expo run:ios` or `expo run:android` through the project's own package
manager, before verifying. `npx` aborts with `EBADDEVENGINES` where
`package.json` pins another package manager through `devEngines`.

Give each platform its own named session, so both apps can run at once. Target
devices by the names `agent-device devices` reports, which are not adb serials
or simulator UDIDs, and open the development build by its own app id:

```bash

From toy-crane/skills, MIT.

More from toy-crane/skills