CtrlK
BlogDocsLog inGet started
Tessl Logo

e2e-testing-mobile

Plans, generates, runs, and heals end-to-end tests for Expo and React Native mobile apps using Maestro (the 2026 standard for RN E2E, adopted by Meta, Microsoft, and DoorDash, and integrated with Expo via EAS Workflows). Drives a spec-first YAML-flow loop, proposes `testID` source diffs (never `accessibilityLabel` reuse), runs Maestro Cloud as an EAS job, and stays token-aware via `--shards`, `--retries`, and failure-only healing. Use for native flows in Expo / RN apps. Triggers on "test this RN flow", "add mobile e2e", "maestro flow", "expo e2e", "e2e for react native", "test the native app", "/e2e-testing-mobile". Defer to [`e2e-testing`](../e2e-testing/SKILL.md) for web flows and the WebView portion of hybrid apps.

69

Quality

87%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

77%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured phase-gated workflow with genuinely executable preflight checks, explicit defaults, and strong validation/escalation loops. The two real weaknesses are the broken bundle layout — the rules/ and templates/ files the thin index depends on are absent, undermining both navigation and the flow-emission guidance — and moderate duplication between the deferral lists and the summary decision table.

Suggestions

Ship the referenced bundle files or fix the links: all 5 `rules/*.md` and 6 `templates/*` paths (and `../e2e-testing/templates/spec.md`) point at files absent from the bundle, so the skill's central thin-index promise currently dangles for more than half its references.

Include one minimal inline Maestro YAML snippet (e.g. a launchApp + tapOn id: + assertVisible triple) so flow emission and healing do not depend entirely on the missing `templates/flow.yaml`.

Merge the "Do not reach for this skill" list and the "Decision flow at a glance" table — they restate the same tdd/e2e-testing/WebView deferral rules twice within ~150 lines of each other.

DimensionReasoningScore

Conciseness

The body is largely lean — terse decision tables, command blocks, and defaults with no explanation of concepts Claude already knows. Minor trimming opportunities remain: the "Do not reach for this skill" list and the later "Decision flow at a glance" table repeat the same deferral rules (tdd / e2e-testing / WebView) almost verbatim, and asides like "the per-step token cost is already an order of magnitude below screenshot-driven runners" are rationale Claude does not need. This fits the anchor-4 'efficient; minor instances of over-explanation that could be trimmed' rather than anchor 5's every-token-earns-its-place.

4 / 5

Actionability

Phase 0 gives copy-paste-ready read-only checks (`maestro --version`, `jq '.build | has("e2e")' eas.json`, `xcrun simctl list devices available`), Phase 2 prescribes exact defaults (`maestro test .maestro/<flow>.yaml`, `retries: 1` local / `retries: 2` Cloud, `record_screen: false`), and the locator ladder is a concrete ordered procedure. The gap keeping it from anchor 5: the core emit/heal loop has no inline executable example — every flow and template artifact (e.g. `templates/flow.yaml`, `templates/testid-helper.tsx`) is delegated to files that are not present in the bundle, and the heal step itself is never shown as a concrete command or patch procedure.

4 / 5

Workflow Clarity

Phases 0–3 are clearly sequenced with a mandatory preflight gate, explicit halt-and-ask checkpoints before installs or builds, and defined feedback loops: the heal loop is capped at three attempts, then "run `confidence(analysis)`" and "escalate to the user with the Maestro log, the spec, and the proposed locator changes — do not keep healing blindly." Phase 3 adds verification steps (first-run pass or heal convergence, `test-provenance-guard` on imported helpers, EAS workflow wiring check) and a Definition of done checklist, matching the anchor for clear sequence with explicit validation, error-recovery loops, and checklists.

5 / 5

Progressive Disclosure

The design intent is exemplary — "This `SKILL.md` is a thin index... Do not preload everything — load only what the current phase asks for" with one-level-deep, per-phase pointers — but scored against the actual bundle: only `references/` exists (all 5 referenced reference files are real), while the 5 referenced `rules/*.md` and 6 `templates/*` files (plus `../e2e-testing/templates/spec.md`) do not exist in the bundle, so over half the on-demand-load paths dangle. That is more than the 'minor organization gaps' of anchor 4; a reader following the index hits missing files, which is a structural defect the anchor-3 'could be better organized' band captures.

3 / 5

Total

16

/

20

Passed

Description

95%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: concrete and comprehensive capability list, explicit use-when guidance with seven natural trigger phrases, and explicit deferral boundaries to the sibling web-E2E skill. Its only flaw is the marketing parenthetical naming Meta, Microsoft, and DoorDash, which is padded over-claiming rather than capability information.

Suggestions

Drop the "(the 2026 standard for RN E2E, adopted by Meta, Microsoft, and DoorDash, ...)" parenthetical or shrink it to a factual clause like "the current standard RN E2E driver" — the adoption name-drop is unverifiable over-claim padding that dilutes an otherwise crisp capability list.

DimensionReasoningScore

Specificity

The description lists multiple concrete, comprehensive actions — "Plans, generates, runs, and heals end-to-end tests", "Drives a spec-first YAML-flow loop, proposes `testID` source diffs (never `accessibilityLabel` reuse), runs Maestro Cloud as an EAS job" — matching the anchor-5 action coverage. However, the parenthetical "the 2026 standard for RN E2E, adopted by Meta, Microsoft, and DoorDash" is unverifiable name-dropping padding, which the guidelines penalize as over-claim/buzzword fluff, holding it below a clean 5.

4 / 5

Completeness

Both questions are explicitly answered: "what" via the concrete action list, and "when" via "Use for native flows in Expo / RN apps" plus the explicit "Triggers on ..." phrase list. This matches the anchor for clearly and explicitly answering both what AND when with concrete trigger phrases, not the anchor-4 case where the "when" could be more specific.

5 / 5

Trigger Term Quality

Seven natural trigger phrases users would actually say are explicitly enumerated: "test this RN flow", "add mobile e2e", "maestro flow", "expo e2e", "e2e for react native", "test the native app", "/e2e-testing-mobile" — comprehensive coverage including the slash-command form. This clearly matches the anchor for comprehensive natural-term coverage rather than the anchor-4 case of missing common variations.

5 / 5

Distinctiveness Conflict Risk

The niche is unambiguous (native mobile E2E for Expo / React Native via Maestro), and it proactively defuses the closest conflict: "Defer to [`e2e-testing`] for web flows and the WebView portion of hybrid apps." Minimal conflict risk with a clear boundary, matching the anchor-5 example of a clear niche with distinct triggers.

5 / 5

Total

19

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_field

'metadata' should map string keys to string values

Warning

relative_links

Relative link issues: 19 missing, 15 suspicious

Warning

Total

14

/

16

Passed

Repository
mthines/agent-skills
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.