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 mobile-e2e-readiness-baselinegit 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/mobile-e2e-readiness-baseline)<a href="https://agentmods.dev/skills/shenyuexin/mobile-e2e-mcp/mobile-e2e-readiness-baseline"><img src="https://agentmods.dev/badge/skills/shenyuexin/mobile-e2e-mcp/mobile-e2e-readiness-baseline/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/mobile-e2e-readiness-baseline"><img src="https://agentmods.dev/badge/skills/shenyuexin/mobile-e2e-mcp/mobile-e2e-readiness-baseline.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.00051 | $0.01553 |
| Opus 5 | $0.00026 | $0.00776 |
| Sonnet 5 | $0.00010 | $0.00311 |
| Haiku 4.5 | $0.00005 | $0.00155 |
Grade A, and why
mobile-e2e-readiness-baseline 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 — 154 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Mobile E2E Readiness Baseline
Overview
Use this skill to diagnose app-side readiness contract gaps before jumping into platform-specific fixes. The core idea is simple: a flow is flaky because the app is not exposing deterministic entry, stable locators, actionable state, reset semantics, or enough evidence for the harness to explain failures.
When to Use
- Cross-platform mobile E2E is flaky and retries sometimes “fix” it
- A screen looks visible but actions are not reliably actionable
- The team is debating timing vs selector vs flaky app without a shared vocabulary
- You want platform-neutral triage before loading Android or iOS-specific skills
Do not use this when the problem is already clearly Android-only or iOS-only and you need platform implementation detail.
Quick Reference
| Contract | Question to ask first | Typical app-side fix |
|---|---|---|
| Deterministic entry | Can the flow be entered repeatably? | Add a stable entry path and remove hidden setup assumptions |
| Stable locators | Are targets addressable without brittle text-only selection? | Add durable automation hooks |
| Ready / busy / blocked state | Can automation tell visible from actionable? | Expose explicit state signals |
| Reset semantics | Can the run start cleanly every time? | Define reset/start-state behavior |
| Transition stability | Are taps happening during transient state? | Define stable post-transition conditions |
| Evidence hooks | Can failures explain why they failed? | Surface enough app-side signal for diagnosis |
| Remediation path | Does the fix point to the app, not just retries? | Change contracts before adding more retries |
Symptom → Next Action
| Failure signal | Most likely gap | Ask for this next | First app-side fix to try |
|---|---|---|---|
| Screen is visible but tap does nothing | Ready / blocked state gap | Screen summary or failing action evidence | Expose actionable ready-vs-blocked state |
| Retry later passes | Entry/state/transition contract gap | Exact retry path and whether state changed | Stabilize entry/reset and post-transition conditions |
| Element is missing on some runs | Locator or entry contract gap | Whether the run entered from a clean start path | Add durable hooks and fix deterministic entry |
| Failure report is too vague | Evidence hook gap | perform_action_with_evidence result or get_screen_summary |
Expose richer app-side failure signal |
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 · 154 lines · 51 tokens per session scan A 1a5f504f88e5
mobile-e2e-readiness-baseline is a skill published in the GitHub repository shenyuexin/mobile-e2e-mcp (2 stars, last pushed 3mo ago), licensed MIT. It adds 51 tokens to every session and 1,553 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.