agentsclimarketplace

Maestro e2e

Skill ahtishamshahzad/agent_dev_flow/.ai/skills/testing/maestro-e2e

Tool-neutral AI Engineering System: 174 reusable skills (installable as Claude Code plugins) for planning and building software with AI agents. Classify → plan → approve → build under quality gates. Works with Claude Code, Codex, Cursor, Windsurf, Copilot & Antigravity. Canonical in .ai/.

Install
npx -y skills add ahtishamshahzad/agent_dev_flow --skill maestro-e2e

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

2 things to look at

  • 21 days oldThe repository was created 21 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 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

Use to plan mobile end-to-end and smoke tests with Maestro — critical device flows on emulator/simulator, resilient to timing, covering happy path plus key error and authorization-denied variants. Reserved for critical mobile journeys; coordinates with the mobile pack.

SKILL.md

4.6 KB, 987 tokens by cl100k_base, as published. Nobody here has run it

Maestro E2E

Purpose

Verify critical mobile journeys end-to-end on a device/emulator using Maestro — the few flows whose breakage blocks release — plus fast smoke flows for post-build/deploy confidence. The mobile pack's ../../mobile/mobile-maestro-e2e owns mobile-side detail; this testing-pack skill places Maestro in the cross-project testing strategy.

When to Use

  • For business-critical mobile journeys (onboarding, login, core transaction) and smoke checks.
  • Not for logic (unit-testing), component behavior (Testing Library / ../../mobile/mobile-component-testing), or web (playwright-e2e).

Inputs

  • Selected mobile app + critical flows (testing-selection, ../../mobile/mobile-stack-selection).
  • Build to test against + device/emulator (../../mobile/mobile-builds), seeded backend state (test-data-management).

Discovery Questions

  • Which mobile flows are critical enough for device E2E (few, high-value)?
  • Which minimal flows form the smoke set (app launches, logs in, core screen loads) for post-deploy checks?
  • What backend/test state must exist for the flows to run deterministically?

Responsibilities

  • Cover critical device journeys: happy path through the real app, plus key error and authorization-denied variants at the journey level.
  • Define a smoke set: minimal, fast flows proving the build is fundamentally alive (launch → auth → primary screen) — run after builds/deploys (smoke-testing, ../../devops/production-readiness).
  • Use Maestro's resilient waiting (element-based, not fixed sleeps); stable selectors (ids/accessibility labels — ../../mobile/mobile-accessibility).
  • Control backend/test state deterministically (test-data-management); run on emulator/simulator in CI where feasible (../../devops/ci-cd, ../../mobile/mobile-builds).
  • Keep the set small — top of the mobile pyramid; push detail to component/unit tests.

Required Workflow

  1. Select critical flows + define the smoke set.
  2. Ensure a testable build + deterministic backend state.
  3. Script flows with element-based waits + stable selectors.
  4. Wire E2E + smoke into CI/build pipeline.
  5. Keep small; move detail down the pyramid.

Decision Rules

  • Device E2E for whole-journey integration only; component-level cases go to ../../mobile/mobile-component-testing.
  • Smoke flows stay minimal and fast — they gate deploys, not features.
  • Element-based waits, never sleeps (flakiness — flaky-test-audit).
  • A flaky device test is worse than none — stabilize or cut.

Rules

  • Deterministic backend/test state per run.
  • Runs against a real build on device/emulator.
  • Failures produce logs/screenshots for triage.

Anti-Patterns

  • E2E-testing every screen/edge on device.
  • Fixed sleeps to paper over timing.
  • Selectors tied to volatile UI text.
  • Smoke sets that balloon into full regression suites.
  • Duplicating component coverage on device.

Validation Checklist

  • Critical flows + minimal smoke set defined.
  • Happy path + key error/authorization-denied variants.
  • Element-based waits; stable selectors; no sleeps.
  • Deterministic backend state.
  • E2E + smoke CI-wired with failure artifacts; set kept small.

Definition of Done

A small, stable Maestro suite covering critical mobile journeys and a fast smoke set — happy path plus key error/denial variants — with resilient waits, deterministic state, and CI/build integration.

Related Skills

../../mobile/mobile-maestro-e2e, testing-selection, playwright-e2e, smoke-testing, ../../mobile/mobile-component-testing, test-data-management, flaky-test-audit, ../../devops/ci-cd, ../../devops/production-readiness.

Related Knowledge

../../../knowledge/ (critical mobile flows).

Related References

../../../references/testing/ (mobile E2E patterns, when populated).

Context Loading Guidance

  • Requires: critical mobile flow list, testable build, backend seed strategy.
  • Does not require: unit internals, unrelated screens.
  • May load: ../../mobile/mobile-maestro-e2e, smoke-testing.
  • Stop when: critical flows + smoke set pass stably in CI.

Token Efficiency Guidance

The flow list (critical + smoke) bounds the suite; don't enumerate every screen — that detail lives lower in the pyramid.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.