CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/appium-testing

Use for any question or task about Appium mobile UI tests, even a quick fix, including tests that break after an Appium upgrade and suites that pass on Android but fail on iOS: one suite for iOS and Android (native or React Native) with XCUITest, UiAutomator2 and Espresso drivers, capabilities, clients in JS, Python, Java, Ruby or .NET, simulators, emulators and device farms.

Quality

90%

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

Overview
Quality
Evals
Security
Files

Quality

Content

82%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 lean, highly actionable skill body: every step from install to CI has executable commands or code, version-specific gotchas are cited from primary sources, and anti-patterns give failure-mode guidance. The main gaps are a missing local run-verification checkpoint before CI, a date-stamped version claim outside the migration section, and no use of bundle files to split reference-grade material out of the overview.

Suggestions

Add an explicit validation checkpoint between Step 6 and Step 7: run one platform locally, confirm the session starts and the first test passes (with a fix-retry hint if driver doctor or session creation fails) before promoting to the CI matrix.

Move the time-sensitive version claim ("3.9.0 on npm, 3 Nov 2026") into the 'Upgrading from Appium 2 to Appium 3' section or drop the date, keeping the main install step stable as just "Appium 3" with the Node/npm minimums.

Split reference-grade material into bundle files (e.g., references/capabilities.md for the Step 4 catalog and references/migration.md for the 2-to-3 table) so SKILL.md stays a lean overview with clearly signaled one-level-deep references.

DimensionReasoningScore

Conciseness

The body is dense and non-obvious throughout (scoped insecure flags, removed endpoints, W3C capability requirements, "WebdriverIO 10 requires Appium 3") with almost no padding of concepts Claude already knows. It misses the 5 anchor partly because time-sensitive specifics — "Appium 3 is current (3.9.0 on npm, 3 Nov 2026)" — sit in the main workflow rather than a migration/deprecated section (most other version info is properly confined to the upgrade table). It is clearly above the 3 anchor, which requires unnecessary explanation.

4 / 5

Actionability

The common path is fully copy-paste ready: install and verify commands ("appium driver install xcuitest", "appium driver doctor uiautomator2"), a complete runnable WebdriverIO test with capabilities, working selector syntax for each strategy, a wdio.conf.js multi-capability config, and a CI matrix YAML. Only trivial user-specific placeholders ("/path/to/app.apk", "...iosCaps") appear, which matches the 5 anchor's 'copy-paste ready covering the common cases' rather than the 4 anchor's substantive gaps.

5 / 5

Workflow Clarity

Steps 1-7 form a clear install → verify → start → author → configure → run → CI sequence, with one explicit validation checkpoint ("appium driver doctor" and the interpretation that "0 required fixes needed" means setup is complete) and an upgrade-order checklist. It falls short of the 5 anchor because there is no validate-and-retry loop around authoring/running (e.g., verify the first session starts and the first test passes locally before moving to CI), leaving checkpoints present but incomplete — squarely the 4 anchor.

4 / 5

Progressive Disclosure

With no bundle files present, all content is inline in a single ~280-line SKILL.md; sections are well-organized and the References section clearly labels one-level-deep external links ("[mig3] - Appium 2 to 3 migration...", "[wdiosvc] - @wdio/appium-service..."). This matches the 4 anchor (good structure, references mostly clear, minor organization gaps) but not the 5 anchor, which expects content appropriately split across referenced files — e.g., the capabilities catalog or migration table could live in separate reference files. It is well above the 3 anchor's buried references.

4 / 5

Total

17

/

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, trigger-first description: it explicitly states when to use the skill with phrasing that mirrors real user requests (broken-after-upgrade, passes-on-Android-fails-on-iOS), and concretely scopes the domain across drivers, clients, languages, and infrastructure. Its only weakness is that capabilities are expressed as enumerated scope rather than explicit action verbs, which caps specificity just below the top anchor.

DimensionReasoningScore

Specificity

The description enumerates many concrete, specific items — "XCUITest, UiAutomator2 and Espresso drivers", "clients in JS, Python, Java, Ruby or .NET", "simulators, emulators and device farms" — with comprehensive domain coverage, but the capability is framed as scope/topics rather than the explicit action verbs ("Extract text... fill forms... merge documents") exemplified by the 5 anchor. It sits noticeably above the 3 anchor (only 1-2 concrete actions) and just below the 5 anchor's action-verb comprehensiveness.

4 / 5

Completeness

Both halves are explicit: "Use for any question or task about Appium mobile UI tests... including tests that break after an Appium upgrade and suites that pass on Android but fail on iOS" answers 'when' with concrete trigger phrases, and "one suite for iOS and Android (native or React Native) with XCUITest, UiAutomator2 and Espresso drivers, capabilities, clients... simulators, emulators and device farms" answers 'what'. This mirrors the 5 anchor example's structure; the 4 anchor ('when' could be more explicit) does not apply.

5 / 5

Trigger Term Quality

It covers the natural terms users would actually say: "Appium mobile UI tests", "even a quick fix", "tests that break after an Appium upgrade", "suites that pass on Android but fail on iOS", plus tool names (XCUITest, UiAutomator2, Espresso) and infrastructure synonyms (simulators, emulators, device farms, native or React Native). This matches the 5 anchor's comprehensive natural-term coverage including synonyms; the 4 anchor's "a few natural terms missing" underdescribes it.

5 / 5

Distinctiveness Conflict Risk

It carves out a clear niche anchored on the specific tool name "Appium" with driver- and scenario-level triggers, so it would not fire for the neighboring skills it itself names in the body (xcuitest-suite, detox-testing, maestro-flows). Minimal conflict risk, matching the 5 anchor ('clear niche with distinct triggers'); the 4 anchor's "minor overlap risk with closely related skills" is weaker than what the text supports.

5 / 5

Total

19

/

20

Passed

Validation

100%

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

On this page