CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/mobile-a11y-test-author

Use when an iOS or Android app needs accessibility tests: XCUITest performAccessibilityAudit (iOS 17+), VoiceOver labels and traits, Espresso AccessibilityChecks, Accessibility Scanner and TalkBack order, plus WCAG checks for labels, 44pt and 48dp touch targets, contrast and focus order.

Quality

86%

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

86%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, highly actionable skill: complete executable test examples for both platforms, concrete CI wiring, and a distinctive anti-patterns table with specific fixes. Detail is correctly pushed to verified one-level-deep references; remaining gaps are minor — a duplicated differentiation note and the absence of an explicit audit-failure triage loop.

Suggestions

Drop the duplicated xcuitest-suite/espresso-suite differentiation from the References section (it is already covered in the Overview's 'Nearest neighbors') to save tokens.

Add a short failure-triage step after the CI section (e.g., on audit failure: fix the element, or suppress by auditType + element.label for known false positives, then re-run) to close the validation feedback loop.

DimensionReasoningScore

Conciseness

The body is lean — rationale-bearing code comments ("report ALL issues per screen, not just the first"), an anti-patterns table instead of prose, and no explanation of concepts Claude already knows — but the xcuitest-suite/espresso-suite differentiation is stated twice (Overview "Nearest neighbors" and again in References), a minor instance of content that could be trimmed, fitting anchor 4 rather than 5.

4 / 5

Actionability

Both test classes are complete and copy-paste ready (imports, setUp, continueAfterFailure rationale, setRunChecksFromRootView), the CI section gives executable GitHub Actions YAML with runner versions, api-level, and artifact upload steps, and the anti-patterns table pairs each failure mode with a concrete fix — covering the common cases fully, matching anchor 5.

5 / 5

Workflow Clarity

Sections progress logically (when-to-use → per-platform core examples → CI integration → anti-patterns → limitations) and the single action is unambiguous, but there is no explicit failure-triage feedback loop in the main flow (e.g., what to do when the audit fails in CI before suppressing or fixing), fitting anchor 4 ('clear sequence with most checkpoints; minor validation gaps') rather than 5.

4 / 5

Progressive Disclosure

SKILL.md is a genuine overview with per-platform quick-start examples, and detail is appropriately split into two verified, one-level-deep reference files; each link is well-signaled with an itemized list of what the file contains ("Scoped audits, false-positive suppression, audit-per-screen, VoiceOver label/trait/hint checks, 44pt touch targets"), matching the anchor-5 example.

5 / 5

Total

18

/

20

Passed

Description

80%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 dense, specific description with an explicit 'Use when' trigger and concrete per-platform API names. Its main gaps are the implicit action verb (what the skill does must be inferred from the tool list) and missing natural synonyms like 'a11y' and 'screen reader' in the description text itself.

Suggestions

State the action explicitly, e.g. "Write and run accessibility tests for iOS and Android apps: ...", so the 'what' is asserted rather than inferred from the tool enumeration.

Fold natural synonyms such as "a11y" and "screen reader" (currently only in metadata keywords) into the description text to improve trigger-term coverage.

Qualify the framework mentions (e.g., "XCUITest accessibility audits" rather than bare "XCUITest") to reduce overlap with general UI-automation skills.

DimensionReasoningScore

Specificity

The description enumerates concrete, named capabilities across both platforms — "XCUITest performAccessibilityAudit (iOS 17+)", "Espresso AccessibilityChecks", "Accessibility Scanner and TalkBack order", "44pt and 48dp touch targets, contrast and focus order" — comprehensive coverage of audits, screen readers, and WCAG checks, matching the anchor-5 example's density rather than anchor 4's 'minor gaps'.

5 / 5

Completeness

The 'when' is explicit and concrete ("Use when an iOS or Android app needs accessibility tests"), and the 'what' is conveyed through a specific tool/check enumeration, but no explicit action verb (e.g., "Write and run accessibility tests") states what the skill does — the action must be inferred, fitting anchor 4 rather than 5.

4 / 5

Trigger Term Quality

Natural phrases users would say are present ("accessibility tests", "VoiceOver", "TalkBack", "WCAG", "contrast"), but common synonyms such as "a11y" and "screen reader" appear only in metadata keywords, not the description itself, so coverage is good with a few natural terms missing rather than comprehensive.

4 / 5

Distinctiveness Conflict Risk

The accessibility niche is clear and triggers are distinct, but the bare framework names "XCUITest" and "Espresso" create minor overlap risk with general UI-automation skills — the body itself differentiates from 'xcuitest-suite' and 'espresso-suite' — fitting anchor 4 ('minor overlap risk with closely related skills') rather than 5.

4 / 5

Total

17

/

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