Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add shenyuexin/mobile-e2e-mcp --skill ios-e2e-readinessgit clone --depth 1 https://github.com/shenyuexin/mobile-e2e-mcpWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/shenyuexin/mobile-e2e-mcp/ios-e2e-readiness)<a href="https://agentmods.dev/skills/shenyuexin/mobile-e2e-mcp/ios-e2e-readiness"><img src="https://agentmods.dev/badge/skills/shenyuexin/mobile-e2e-mcp/ios-e2e-readiness/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/shenyuexin/mobile-e2e-mcp/ios-e2e-readiness"><img src="https://agentmods.dev/badge/skills/shenyuexin/mobile-e2e-mcp/ios-e2e-readiness.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00061 | $0.01727 |
| Opus 5 | $0.00030 | $0.00864 |
| Sonnet 5 | $0.00012 | $0.00345 |
| Haiku 4.5 | $0.00006 | $0.00173 |
Grade A, and why
ios-e2e-readiness scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 188 lines — stays where its author put it; the contents beside it link to each section on GitHub.
iOS E2E Readiness
Overview
Use this skill after the shared baseline when the problem is clearly iOS-specific. The goal is to turn vague “SwiftUI timing” or “just add waits” debates into iOS-specific contract fixes around launch/reset behavior, stable identifiers, mixed ownership, ready-state visibility, interruption handling, and post-transition actionability.
When to Use
- iOS-only mobile E2E is flaky
- SwiftUI screens look correct but controls are not reliably actionable
- UIKit lists rely on repeated labels or weak identity
- Mixed SwiftUI/UIKit surfaces are hardest to diagnose
- Retries pass later and the team is debating timing vs selectors vs interruptions
Do not use this before the baseline skill when the problem is still cross-platform and the team lacks shared readiness vocabulary.
Inheritance Rule
This skill extends mobile-e2e-readiness-baseline.
Do not redefine the shared contract terms:
- deterministic entry
- stable locators
- ready / busy / blocked state
- reset semantics
- transition stability
- evidence hooks
- remediation path
Instead, answer what they mean on iOS.
Quick Reference
| iOS layer | Question to ask first | Typical app-side fix |
|---|---|---|
| Launch / reset | Is the flow reproducible from a stable iOS launch/reset path? | Fix launch args/env, URL entry, and stale app/simulator assumptions |
| SwiftUI hooks | Are critical controls addressable by stable accessibilityIdentifier and clear state? |
Add identifiers and actionable state exposure |
| UIKit hooks | Are controls and cells addressable by stable identifiers instead of repeated labels? | Add durable identifiers and reduce repeated-label ambiguity |
| Mixed ownership | Is one target clearly owned across SwiftUI/UIKit boundaries? | Define one actionable owner and one stable identifier |
| State visibility | Can automation tell ready from busy or blocked? | Expose explicit actionable ready-state and blocker signals |
| Interruption handling | Could a permission, modal, or protected state be blocking action? | Surface interruption/blocked-state explicitly before tuning waits |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 188 lines · 61 tokens per session scan A a4399364e7a0
ios-e2e-readiness is a skill published in the GitHub repository shenyuexin/mobile-e2e-mcp (2 stars, last pushed 3mo ago), licensed MIT. It adds 61 tokens to every session and 1,727 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
Appium Mobile Testing
Mobile application testing skill using Appium for iOS and Android, covering device capabilities, selectors, gestures, and cross-platform testing strategies.
zmr-mobile-testing
Use when testing mobile apps with Zeno Mobile Runner, integrating app-local .zmr setup, driving Android or iOS simulator scenarios, using JSON-RPC or MCP agent sessions, exporting traces, or comparing mobile runner benchmarks.
android-ui-journey-testing
XML-specified Android UI journey testing, interactive step execution, assertion verification, and JSON outcome reporting.
solopi-ai
A command-line framework for testing Android apps and devices with SoloPi, including on-device or cloud AI decision models. It manages devices, test cases, recorded interactions, replays, performance history, and evidence.
argent-test-ui-flow
Autonomously test an app UI (iOS or Android) by running interact-screenshot-verify loops using argent MCP tools. Use when testing UI flows, verifying login works, testing navigation, running end-to-end UI test scenarios, manual QA steps, visible UI changes, or visual behavior.
mobile-automation
Control Android and iOS devices, emulators and simulators — launch apps, tap, swipe, type, take screenshots, read the accessibility tree. Use when a task involves a mobile device or app, mobile UI testing, or reproducing a bug on a phone.