CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

common-mobile-visual-testing

Standardizes mobile UI audits, performance/scroll checks, RTL verification, and state-specific testing on iOS/Android.

Quality

70%

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

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/common/common-mobile-visual-testing/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

72%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.

The body is a well-disciplined, lean methodology overview with excellent progressive disclosure — dense inline taxonomy and tool mapping, with heavy detail correctly pushed to two clearly labeled, real reference files. Its main gap is workflow sequencing: the audit flow is implicit across sections rather than an explicit ordered procedure with validation checkpoints, and no inline executable example anchors the tool usage.

Suggestions

Add a short ordered "How to run an audit" sequence (e.g., 1. analyze diff → 2. pick test layer → 3. run the 10-area checklist from references/mobile-testing-matrix.md → 4. record evidence; BLOCKED if hardware/driver or expected outcome is missing) to make checkpoints explicit.

Include one minimal inline executable snippet (e.g., an appium_screenshot base/diff call or an appium_app_lifecycle background/terminate/activate sequence) so the tool mapping has a concrete usage anchor.

Remove the duplicated browser/mock substitution rule by stating it once in Anti-Patterns and only cross-referencing it from Testing Mindset.

DimensionReasoningScore

Conciseness

The body is dense and telegraphic with no re-teaching of concepts Claude already knows ("Wait for animations... before capturing", "fullReset (clean) vs noReset (upgrade)"), but the browser/mock substitution prohibition is stated twice ("NEVER counts as native device verification" in Testing Mindset and again as the first anti-pattern), which is trimmable redundancy. This places it at 'efficient; minor instances of over-explanation that could be trimmed' rather than the every-token-earns-its-place level 5.

4 / 5

Actionability

Concrete guidance is strong: a tool-mapping table with exact Appium tool names (appium_alert, appium_mobile_performance_data, appium_screenshot, appium_app_lifecycle), specific Appium capabilities (fullReset vs noReset + DB migration), and concrete evidence artifacts (.appium-mcp/<session>/, perf.json, video.url). As an instruction-only skill this satisfies the concrete-guidance bar, but fully executable command snippets live one reference away rather than inline, matching 'mostly executable guidance; concrete code or commands with minor gaps'.

4 / 5

Workflow Clarity

The sequence exists but is implicit: "Analyze diff and select the correct test layer" followed by the ten areas, tool mapping, anti-patterns, and evidence recording, with checkpoints like "honest BLOCKED reporting" and digest recording present but not ordered as an explicit step list with validation gates. This matches 'steps listed but validation gaps; sequence present but checkpoints missing or implicit' rather than 4, where most checkpoints would be explicit and sequenced.

3 / 5

Progressive Disclosure

The ~57-line body is a genuine overview: the 10-area taxonomy and tool mapping stay inline while the full matrix (10 areas x 4 stacks, verified to exist at references/mobile-testing-matrix.md) and the 20 procedures (references/scenarios.md, verified) are split out as clearly annotated one-level-deep references with section pointers (§0, §12). This matches the 'clear overview with well-signaled one-level-deep references; content appropriately split; easy navigation' anchor.

5 / 5

Total

16

/

20

Passed

Description

58%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.

The description is concise, third-person, and specific about capabilities with a clear mobile iOS/Android niche. Its main weakness is the absence of explicit 'when to use' trigger guidance within the description text itself, with natural trigger phrases relegated to a separate metadata keywords field. Merging a 'Use when...' clause with those natural phrases into the description would lift completeness and trigger-term quality.

Suggestions

Append a 'Use when...' clause to the description, e.g. "Use when the user asks to verify mobile UI, run visual regression on iOS/Android builds, or audit app behavior across state and lifecycle changes."

Fold 2-3 natural trigger phrases from metadata.triggers (e.g., "visual regression", "dark mode test", "accessibility audit") into the description text so users' phrasing matches without relying on the separate keywords field.

Replace the generic "state-specific testing" with the concrete states covered (e.g., "lifecycle/resume and empty/loading/error state testing") to sharpen specificity.

DimensionReasoningScore

Specificity

"mobile UI audits, performance/scroll checks, RTL verification, and state-specific testing on iOS/Android" lists several concrete, distinct actions, matching the 'several specific actions; minor gaps' anchor; it falls short of 5 because "state-specific testing" is generic and coverage areas (e.g., install/upgrade, accessibility) named in the body are absent from the description.

4 / 5

Completeness

The 'what' is clearly stated (standardizes UI audits, performance/scroll checks, RTL verification, state testing), but there is no 'Use when...' clause or equivalent trigger guidance inside the description itself — trigger keywords exist only in a separate metadata field. Per the guideline that a missing 'Use when...' clause caps completeness at 3, this cannot score 4.

3 / 5

Trigger Term Quality

The description contains relevant keywords ("mobile UI audits", "performance/scroll checks", "RTL verification", "iOS/Android") but misses common natural variations users would say, such as "visual regression", "screenshot test", or "cross-platform". The separate metadata.triggers keyword list covers these well, but the description field itself only partially covers natural phrasing, so it sits at the 'some relevant keywords but missing common variations' anchor rather than 4.

3 / 5

Distinctiveness Conflict Risk

"mobile UI audits... on iOS/Android" plus RTL and state/lifecycle testing carves a clear mobile-native niche with distinct triggers, matching 'mostly distinct; minor overlap risk' — the main residual overlap is with web or generic visual-regression skills, keeping it below 5.

4 / 5

Total

14

/

20

Passed

Validation

81%

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

Validation — 13 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

metadata_field

'metadata' should map string keys to string values

Warning

relative_links

Relative link issues: 2 suspicious

Warning

Total

13

/

16

Passed

Repository

HoangNguyen0403/agent-skills-standard

Path

.agents/skills/common/common-mobile-visual-testing/SKILL.md

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.