qa-device-management
Boot and control iOS Simulators and Android Emulators for QA testing using agent-device CLI. Manage sessions, capture screenshots, launch apps, and control devices across platforms. Invoke when user says "bring up simulators", "boot the device", "take a screenshot", "launch the app", "compare iOS and Android", "test both platforms", "visual parity check", or any task requiring device/simulator lifecycle management.
- License 许可
- MIT
- 最近更新
- 2026-07-29
- Stars
- ★ 1
- Forks
- 0
01 前言 Front Matter
- name
- qa-device-management
- description
- Boot and control iOS Simulators and Android Emulators for QA testing using agent-device CLI. Manage sessions, capture screenshots, launch apps, and control devices across platforms. Invoke when user says "bring up simulators", "boot the device", "take a screenshot", "launch the app", "compare iOS and Android", "test both platforms", "visual parity check", or any task requiring device/simulator lifecycle management.
- allowed-tools
- Bash(agent-device:*) Bash(xcrun:*) Bash(adb:*) Bash(open:*) Bash(find:*) Bash(npx:*) Read
02 资源文件 1
- 参考文档COORDINATE-MAP.md3.1 KB
03 SKILL.md 正文
qa-device-management
Side-by-side iOS Simulator and Android Emulator control using the agent-device CLI. Manages the device lifecycle for all QA Automation skills.
When to Use
- Bringing up simulators/emulators for testing
- Launching your app on one or both platforms
- Capturing baseline or comparison screenshots
- Checking device state, app state, or accessibility tree
- Managing agent-device sessions across platforms
Configuration
All device settings are in qa.config.sh. Set these before using:
# In qa.config.sh or qa.config.local.sh:
export APP_BUNDLE_ID="com.yourapp.dev" # Your app's bundle/package ID
export SIMULATOR_UDID="auto" # "auto" or specific UDID
export SIMULATOR_DEVICE_NAME="iPhone 16 Pro" # For creating simulators
export ANDROID_AVD="Pixel_8" # Android AVD name
export ANDROID_SERIAL="emulator-5554" # Android serial
Quick Start — Full Startup Sequence
Boot iOS Simulator
# Auto-detect a booted simulator, or boot one
source .pi/skills/qa-automation/qa.config.sh
UDID=$(qa_detect_simulator_udid)
# Or boot a specific one
xcrun simctl boot "$SIMULATOR_UDID" 2>&1 || true
open -a Simulator
Boot Android Emulator
nohup $EMULATOR_PATH -avd "$ANDROID_AVD" -no-snapshot-load > /tmp/qa-emu.log 2>&1 &
# Wait for boot
for i in $(seq 1 30); do
BOOT=$($ADB_PATH shell getprop sys.boot_completed 2>/dev/null | tr -d '\r')
if [ "$BOOT" = "1" ]; then
echo "Android emulator booted after ~$((i*2))s"
break
fi
sleep 2
done
Verify Both Devices
agent-device devices --json
Launch App on iOS
agent-device open "$APP_BUNDLE_ID" --platform ios --session default
Launch App on Android
agent-device open "$APP_BUNDLE_ID" --platform android --serial "$ANDROID_SERIAL" --session android
Capture Baseline Screenshots
agent-device screenshot /tmp/qa-ios-baseline.png --session default
agent-device screenshot /tmp/qa-android-baseline.png --session android
Session Management
agent-device binds each session to one platform. Use the correct session flag:
| Platform | Session Flag | Example |
|---|---|---|
| iOS | --session default (or omit) |
agent-device snapshot --session default |
| Android | --session android |
agent-device snapshot --session android |
# List active sessions
agent-device session list
# Release a session
agent-device close --session default
Common Operations
Screenshots (Both Platforms)
agent-device screenshot /tmp/qa-ios.png --session default
agent-device screenshot /tmp/qa-android.png --session android
Accessibility Snapshots
agent-device snapshot --session default # iOS
agent-device snapshot --session android # Android
# With options
agent-device snapshot -i --session default # Interactive elements only
agent-device snapshot --depth 3 # Limit depth
Navigate and Interact
# Tap
agent-device click 200 400 --session default
# Swipe
agent-device swipe 200 800 200 200 --session default
# Scroll
agent-device scroll down --session default
# Type
agent-device fill @e3 "hello world" --session default
Go Home / Go Back
agent-device home --session default
agent-device back --session android
Check Foreground App
agent-device appstate --session default
agent-device appstate --session android
Relaunch App (Fresh State)
agent-device open "$APP_BUNDLE_ID" --session default --relaunch
Building and Installing Your App
iOS — Expo
cd "$PROJECT_DIR"
npx expo run:ios --device "$SIMULATOR_DEVICE_NAME"
iOS — React Native CLI
cd "$PROJECT_DIR"
npx react-native run-ios --simulator "$SIMULATOR_DEVICE_NAME"
Android — Expo
cd "$PROJECT_DIR"
npx expo run:android
Android — React Native CLI
cd "$PROJECT_DIR"
npx react-native run-android
Check If App Is Installed
# iOS
xcrun simctl listapps booted 2>/dev/null | grep "$APP_BUNDLE_ID"
# Android
$ADB_PATH shell pm list packages | grep "$APP_BUNDLE_ID"
Shutdown Sequence
# Close agent-device sessions
agent-device close --session default
agent-device close --session android
# Shutdown simulators
xcrun simctl shutdown "$SIMULATOR_UDID"
$ADB_PATH emu kill
CDP Connection (for React Native apps)
When coordinate-based tapping fails (e.g., full-screen video players intercept touches), use CDP to control navigation directly via the React Native Hermes runtime.
Prerequisites
- Dev server running (e.g.,
npx expo start) wsnpm package available
Discover CDP Endpoints
# List available debug targets
curl -s http://localhost:$METRO_PORT/json
# Get WebSocket URL (auto-detected by qa.config.sh)
source qa.config.sh
qa_detect_cdp_ws_url
Navigate via CDP
source .pi/skills/qa-automation/qa-test-flows/lib/cdp-helpers.sh
# Navigate to a screen
cdp_navigate "SettingsScreen"
# Navigate to a tab
cdp_navigate_tab "ProfileScreen"
# Get current route
cdp_get_route
Troubleshooting
| Problem | Solution |
|---|---|
| "No device found" | Verify simulator is booted: xcrun simctl list devices | grep Booted |
| Session bound to wrong platform | Use --session android for Android, close session and rebind |
| Simulator already booted (error 149) | Safe to ignore — simulator is already running |
| App not installed | Build and install: npx expo run:ios or npx expo run:android |
| agent-device click hangs | Wrap with timeout: timeout 5 agent-device click 100 200 |
| CDP "Connection refused" | Ensure dev server is running: curl http://localhost:$METRO_PORT/status |
04 同仓库更多 Skills
using-agent-skills
Discovers and invokes the right @runecraft/spells skill for the current task. Use when starting a session, when a request is ambiguous about which workflow to apply, or when you need to pick among the 13-skill Arcanum catalog. EN triggers: /skill, which skill, pick a skill, what skill should I use, skill discovery, meta skill. PT triggers: qual skill, qual habilidade, descobrir skill, qual fluxo usar. Do NOT use for: actual implementation work (route to the specific skill instead), unrelated standalone tasks outside the Arcanum catalog, or runtime-specific configuration (e.g., opencode.json / Claude Code plugin paths).
typescript-patterns
TypeScript best practices and patterns for type-safe, maintainable code. Covers discriminated unions, generics, const assertions, type narrowing, and common anti-patterns. Extends (does not override) project tsconfig. EN triggers: /typescript, TypeScript patterns, TS best practices, type safety, discriminated unions, generics, type narrowing. PT triggers: /typescript, padrões TypeScript, boas práticas TS, segurança de tipos, unions discriminadas, genéricos. Do NOT use for: JavaScript-only projects, runtime performance, or replacing project tsconfig rules.
test-driven-development
Drives development with tests — fail first, then make them pass, then refactor. Use when implementing any logic, fixing any bug, or changing any behavior. EN triggers: /test, write tests first, TDD, prove it, 80/15/5 pyramid, Beyonce Rule. PT triggers: /teste, testes primeiro, provar com teste, pirâmide 80/15/5. Do NOT use for: production incident triage (use /debug), or cosmetic-only changes with no behavioral surface.
spec-driven
Feature planning and implementation with 4 adaptive phases — Specify, Design, Tasks, Execute. Auto-sizes depth by complexity. Creates atomic tasks with verification criteria, atomic git commits, and requirement traceability. Features an independent Verifier (author != verifier, evidence-or-zero), persistent decision log (STATE.md), and test-coverage-matrix-driven tests, plus a self-improving lessons layer that turns verification failures into reusable project-local guidance. Stack-agnostic. Use when planning features (requirements, design, task breakdown), implementing with verification and atomic commits, or validating/verifying an implementation against a spec. Triggers (PT/EN): "specify feature", "vamos especificar", "discutir feature", "discutir este caso", "design", "design da feature", "tarefas", "quebrar em tarefas", "implementar", "build", "validar", "verify work", "UAT", "validar implementação", "record decision", "pause work", "pausar trabalho", "resume work", "retomar trabalho". Do NOT use for architecture decomposition analysis (use architecture skills) or technical design docs (treat as Complex scope: discuss gray areas + architecture-focused design).
skill-forge
Designs, authors, validates, and optimizes new Agent Skills from scratch. Use when creating a new skill, packaging a workflow as a skill, improving a skill's triggering accuracy, or evaluating whether a skill improves output quality. Covers the full lifecycle: DISCOVER, DESIGN, AUTHOR, VALIDATE, OPTIMIZE, DELIVER. Produces skills that follow the open SKILL.md format (YAML frontmatter + Markdown body, progressive disclosure, validation loops). EN triggers: /forge, create a skill, write a skill, build a skill, new skill, author a skill, package this as a skill, validate a skill, improve skill triggering, optimize skill description, evaluate skill quality. PT triggers: /forge, criar uma skill, escrever uma skill, construir uma skill, nova skill, empacotar como skill, validar skill, melhorar disparo, otimizar descrição de skill. Do NOT use for: discovering which existing skill to apply (use a dispatch/meta skill), planning feature implementation, or designing software architecture.
shipping-and-launch
Prepares production launches with a pre-launch checklist, staged rollout, monitoring, and a rollback strategy — plus feature flag lifecycle (off → internal → beta → GA). Use when deploying a feature to production for the first time, releasing a significant change, or planning a rollout. EN triggers: /ship, pre-launch checklist, staged rollout, feature flag, rollback plan, monitoring. PT triggers: /shippar, checklist pré-lançamento, rollout gradual, feature flag, plano de rollback. Do NOT use for: pre-production development work, or one-off internal tools with no user exposure.