Skip to content
TrustedSkillsbeta
Back to all skills

Maestro Mobile Testing

Listed
tovimx·vlatest·testing

Helps with mobile development, testing as part of testing, debugging, and quality assurance workflows.

Repository

Install on your platform

Showing Claude Code. One command installs this skill into any of the agents below.

  1. 1

    Run this in your project

    terminal
    $ npx skills add tovimx/maestro-mobile-testing-skill --skill maestro-mobile-testing -a claude-code

  2. Uses the open-source skills CLI and needs Node.js. Add -g to install it for your user instead of this project.

What we know about this skill

Publisher

tovimx

Taken from the source listing. We haven't verified who controls this account.

Install target

Live repository

Not pinned. Installing fetches whatever the repository holds at the time you run the command.

No human has reviewed this code. The checks below are a static scan of the files at one commit — nobody has run this skill or judged whether it works. A skill runs with whatever access you give your agent, so read the source before you install it.

Automated safety checks

scanned

This skill failed 2 of 6 checks. A failure is not proof of bad intent; it means something in the code needs a human to look at it before you run it.

  • No undeclared network calls: failed

    Contacts 1 host that is neither well-known infrastructure nor declared in the skill's frontmatter: get.maestro.mobile.dev.

    Every host the skill dials — from its scripts, its config endpoints or the commands it tells the agent to run — is either well-known package and API infrastructure or declared in its own frontmatter. Links in documentation are not counted.

    Hosts contacted

    get.maestro.mobile.devundeclared

    What it found

    • SKILL.md:54contacts get.maestro.mobile.dev
      curl -Ls "https://get.maestro.mobile.dev" | bash
    • SKILL.md:795contacts get.maestro.mobile.dev
      RUN curl -Ls "https://get.maestro.mobile.dev" | bash

  • No pipe-to-shell installers: failed

    Runs code fetched at install time in 2 places.

    No `curl … | sh` pattern, in the code or in the instructions, that runs code fetched at run time.

    What it found

    • SKILL.md:54remote script piped into a shell
      curl -Ls "https://get.maestro.mobile.dev" | bash
    • SKILL.md:795remote script piped into a shell
      RUN curl -Ls "https://get.maestro.mobile.dev" | bash

  • Declares what it does: passed

    SKILL.md parses and declares a name and a description.

    SKILL.md exists, its frontmatter parses, and it declares a name and a description.

  • No obfuscated payloads: passed

    No encoded or obfuscated payloads.

    No base64, hex or compressed blob is decoded and then executed, and no encoded shell commands.

  • No credential access: passed

    Reads no keys, tokens, keychains or credential files.

    Neither the code nor the SKILL.md instructions read SSH keys, cloud credentials, keychains, token stores, browser cookie databases or dotfiles that hold secrets.

  • Pinned to a commit: passed

    Scanned tovimx/maestro-mobile-testing-skill at d4c0be2c1e.

    The exact upstream commit SHA that was scanned is recorded, so the result refers to specific bytes.

Commit
d4c0be2c1e
Manifest
SKILL.md
Scanned
1 file, 897 lines
This is a static scan, not a review. It reads the skill's files; it does not run them, and it cannot tell you whether the skill is any good or whether the code does what its description says. A skill runs with whatever access you give your agent.
What each check looks for →

About this skill

What it does

Maestro Mobile Testing is an automated mobile end-to-end (E2E) testing framework designed for React Native applications. It uses declarative YAML files to define test steps, eliminating much of the boilerplate code typically found in other frameworks like Detox or Appium. Maestro provides automatic waiting and built-in retry logic for more stable tests, and offers a fast execution speed with minimal setup overhead.

When to use it

  • Automating React Native app testing: Ideal for creating repeatable E2E test suites.
  • Improving test stability: Reduce flaky tests through automatic waiting and retries.
  • Rapidly building tests: Leverage the declarative YAML approach and interactive builder (Maestro Studio) to create tests quickly.
  • Running tests on real devices: Utilize Maestro Cloud for testing within CI/CD pipelines without local simulators.

Key capabilities

  • Declarative YAML-based tests: Define test steps in a human-readable YAML format, avoiding imperative code.
  • Automatic waiting: Eliminates the need for manual sleep() calls and unreliable waits.
  • Built-in retry logic: Automatically retries failed test steps to reduce flakiness.
  • Fast execution: Optimized for speed with minimal setup overhead.
  • Maestro Studio: An interactive tool for visually building tests.
  • Sub-flows: Create reusable sequences of YAML steps for DRY (Don't Repeat Yourself) testing.
  • JavaScript scripting: Utilizes a GraalJS runtime to handle HTTP calls and data manipulation within tests.
  • Maestro Cloud: Enables real device testing in CI/CD environments.
  • Selector Strategies: Supports both testID and text-based selectors for UI element identification, with guidance on when to use each approach.

Example prompts

While this skill doesn't directly respond to natural language prompts, users would interact with it by providing YAML configuration files or using Maestro Studio. Examples of YAML test configurations include:

  • maestro test .maestro/smoke-test.yaml - Runs a specific test suite.
  • maestro test --debug .maestro/smoke-test.yaml - Runs the test suite in debug mode, allowing step-by-step execution.
  • maestro studio - Launches the interactive test builder interface.

Tips & gotchas

  • Requires Java 17: Ensure you have OpenJDK@17 installed and JAVA_HOME properly configured.
  • Selector Choice: Carefully consider whether to use testID or text selectors based on your app's localization, UI stability, and team preferences. Use testIDs for multi-language apps or dynamic content.
  • TestID Naming Convention: When using testID selectors, follow the recommended naming convention: {component}-{action/type}[-{variant}].