Mobile maestro e2e orchestrator

Skill mo-hawary/hawary-workflow-skills/skills/mobile-maestro-e2e-orchestrator

Reusable Agent Skills for Codex, Claude, and AI coding agents

Install

npx -y skills add mo-hawary/hawary-workflow-skills --skill mobile-maestro-e2e-orchestrator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Run evidence-driven mobile E2E tests with Maestro, device logs, checkpoints, and targeted retries for iOS or Android flows.

SKILL.md

3.3 KB, as published. Nobody here has run it

Mobile Maestro E2E Orchestrator

Run mobile E2E tests using evidence, not blind waiting. Prefer small checkpoints, logs, and targeted retries.

When To Use

Use this when Maestro is the test runner or when the user asks to validate mobile flows with device logs and checkpoints.

Do not use this for generic web QA, unit tests, or non-Maestro mobile frameworks unless the user wants the workflow adapted.

Workflow

Identify the target flow and platforms.
Discover app run commands, device IDs, Maestro flows, and test data setup.
Check whether Maestro is installed and the requested flow files are present before attempting execution:
- If Maestro is missing or not configured, report the setup gap and the smallest install/configuration step needed.
- Still produce a checkpoint-based test plan from the available app and flow context.
- Do not claim E2E validation ran when only a plan was produced.
Start app logs before running the flow.
Run Maestro in short checkpoints:
- Keep UI waits short.
- Use logs or visible state to decide when to continue.
- Capture failure screenshots and logs.
On failure:
- Classify as app bug, test bug, setup issue, environment issue, or flake.
- Re-run only the smallest useful checkpoint.
- Propose a fix path with evidence.
Summarize proof and residual risk.

For sample prompts and evidence summaries, see references/examples.md. For checkpoint and evidence capture guidance, see references/evidence-checklist.md.

Input Signals

Use the flow name, platform, device or simulator IDs, app flavor, Maestro YAML files, test account setup, logs, screenshots, backend traces, and any known flaky step. If the platform or runner is missing, report the missing setup before attempting a run.

Output

Return:

Flow: scenario and platforms tested.
Setup: devices, commands, app flavor, and test data assumptions.
Results: pass/fail per checkpoint, or not run when setup is missing.
Evidence: relevant logs, screenshots, routes, API status, state transitions, or setup-gap proof.
Diagnosis: failure class and likely cause.
Next Fix: smallest change or test adjustment needed.
Residual Risk: untested platforms, flakes, missing assertions, or unavailable runner setup.

Guardrails

Do not rely on long arbitrary sleeps as proof.
Do not treat a visible screen alone as full business-flow success when logs/API/state matter.
Ask before changing app code, test flows, product behavior, or UI layout.
Keep commands platform-specific and explicit.

Avoid

Do not rerun the full suite when one checkpoint is enough.
Do not call a failure a flake without evidence from a retry or environment signal.
Do not edit app code or test flows during diagnosis unless the user approves.
Do not present a setup-only plan as a completed E2E run.

Final Checks

Each pass/fail result has evidence beyond a guess.
Failures are classified before proposing fixes.
Retries are targeted to the smallest useful checkpoint.
Untested platforms, devices, app flavors, or missing runner setup are listed as residual risk.