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 agentmods add skills/shenyuexin/mobile-e2e-mcp/android-e2e-readinessnpx skills add shenyuexin/mobile-e2e-mcp --skill android-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/android-e2e-readiness)<a href="https://agentmods.dev/skills/shenyuexin/mobile-e2e-mcp/android-e2e-readiness"><img src="https://agentmods.dev/badge/skills/shenyuexin/mobile-e2e-mcp/android-e2e-readiness.svg" alt="Measured on agentmods" 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.00057 | $0.01684 |
| Opus 5 | $0.00028 | $0.00842 |
| Sonnet 5 | $0.00011 | $0.00337 |
| Haiku 4.5 | $0.00006 | $0.00168 |
Grade A, and why
android-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 6d 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.
Android E2E Readiness
Overview
Use this skill after the shared baseline when the problem is clearly Android-specific. The goal is to turn vague “Compose timing” or “weak selector” debates into Android-specific contract fixes around entry/reset, stable hooks, hybrid ownership, ready-state visibility, and blocked-state interpretation.
When to Use
- Android-only mobile E2E is flaky
- Compose screens look correct but taps miss or do nothing
- View screens rely on repeated labels or weak ids
- Hybrid Compose/View screens are hardest to diagnose
- Restarting a flow makes it pass and the team is debating timing vs selector
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 Android.
Quick Reference
| Android layer | Question to ask first | Typical app-side fix |
|---|---|---|
| Entry / reset | Is the flow reproducible from a stable Android entry path? | Fix deep link / intent entry and reset assumptions |
| Compose hooks | Are critical nodes addressable by testTag and semantics? |
Add stable tags and state/role exposure |
| View hooks | Are actions addressable by stable resource-id / useful contentDescription? |
Add durable ids and reduce repeated-label ambiguity |
| Hybrid ownership | Is one target clearly owned across Compose/View boundaries? | Define one actionable owner and one stable hook |
| State visibility | Can automation tell ready from busy or blocked? | Expose actionable ready-state and blocker signals |
| Blocked state | Could dialogs, sheets, OEM blockers, or protected states be present? | Surface blocked-vs-ready explicitly before tuning waits |
Symptom → Next Action
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.
- 6d ago First seen · 188 lines · 57 tokens per session scan A eb100c18eb13
android-e2e-readiness is a skill published in the GitHub repository shenyuexin/mobile-e2e-mcp (2 stars, last pushed 3mo ago), licensed MIT. It adds 57 tokens to every session and 1,684 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
通过 SoloPi 的机器可读 CLI 编译和执行 AI 验证计划，管理签名端侧 ExecuTorch 决策模型、持久设备池、无人值守任务、安卓设备、应用、动作、配置、用例步骤与交互录制、回放及性能历史、动态 Agent、批量与重复执行、性能监控、压力测试和证据。适用于需求/AC 到 Result Judge 三态结论、cloud/on-device 决策切换、模型发布门禁，以及 generation 租约的多设备 CI 执行。.
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.