Skip to content
Back to skills

Mobile Qa

ASecurity

Routes selected-device mobile QA to a compatible original native testing skill with owner device and evidence policy.

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added November 7, 2026
ai-agentsshelltestingperformance

Works with

  • cli
  • mcp

Security analysis

A100/100

Scanned November 7, 2026

npx -y skills add Mesteriis/Engineering-Bible-AI --skill mobile-qa --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Mobile Qa?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Mobile Qa
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/mesteriis-mobile-qa/badge)](https://www.skillsdirectory.com/skills/mesteriis-mobile-qa)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: mobile-qa
description: "Routes selected-device mobile QA to a compatible original native testing skill with owner device and evidence policy."
---

# Native Mobile QA

Use for native Android/iOS behavior. Mobile web layouts belong to
`responsive-breakpoint-check`; browser flows belong to `playwright-visual-qa`.
Load and follow the complete original native testing skill that covers the
selected platform and target. For Android emulator feature flows, the exposed
provider is `test-android-apps:android-emulator-qa`; performance investigations
use `test-android-apps:android-performance`. Keep the native plugin's original
instructions, scripts and update path intact. This adapter does not reproduce
the author's test loop.

An Android emulator provider does not establish physical-device or iOS support.
Those routes require an explicitly compatible original provider exposed by the
host. If a matching provider or device capability is missing, the route is
unavailable: report SKIP or BLOCKED with the missing platform or capability,
use the host's official plugin setup to install or enable the matching provider,
then refresh session exposure. Do not counterfeit a missing workflow with a
local summary or claim that a package proves a live connection.

## Owner Device And Runtime Policy

- Identify the app/build, exact device or emulator, synthetic fixture, and
  expected state before actions. Prefer a disposable emulator for setup tests.
  Do not select a physical device implicitly, reset user data, change accounts,
  install profiles, or operate unrelated apps.
- Discover only the capability needed by the selected original workflow.
  Mobile MCP is optional; the native provider may use established adb or
  simulator tooling when compatible. Missing devices/platform support are
  SKIP or BLOCKED with a reason, not a passing app test.
- Before activating a third-party server, verify its pinned source, advisory
  fixes, telemetry controls and actual action surface. Keep unsafe URL schemes
  disabled. Do not expose arbitrary shell, package installation, file transfer,
  account changes or unrelated device operations by default.
- Check each batch subcommand against the same allowed operations and target.
  A batch entry point can bypass a filter of top-level tool names; exclude it
  unless its nested operations are equally constrained.

## Owner Evidence And Cleanup Policy

- Require expected state versus observed state, including accessibility or
  screenshot evidence where needed. Successful clicks alone do not prove
  that an app passes; preserve the original safe logs and command results.
- Stop only emulator/server processes created for this task. Preserve existing
  devices, apps, SDKs, accounts and host settings.

Use synthetic photos, input text and provider errors. Never type real secrets
into fixtures or collect personal notifications, photos or account screens.
Keep screenshots, logs, device identifiers and MCP configuration outside public
repositories. Report source build, target, actions, expected versus observed
state, raw artifact paths, actual command exit codes, and remaining gaps.

Verify keyboard/input, gallery/permission, and provider-error recovery flows on
their actual app builds before claiming project acceptance. A generic emulator
smoke test proves only that tested device/tool path.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.