CtrlK
BlogDocsLog inGet started
Tessl Logo

mobile-testing

Use when reviewing CI coverage, automated checks, or test strategy related to Test on real mobile devices and viewports. Focus on whether the rule is continuously verified, not just documented.

65

Quality

78%

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 ./skills/mobile-testing/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%

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

A cleanly structured overview that defers detail to a real one-level reference file, but it spends tokens explaining mobile-browser basics Claude already knows and offers no executable code or explicit validation checkpoints in the body. The progressive disclosure is the strongest aspect; conciseness, actionability, and workflow clarity are each held at 2 by the padded intro and the lack of concrete code/feedback loops.

Suggestions

Cut or sharply compress the opening paragraph — drop the 55%-of-traffic stat and the explanation that mobile browsers/touch events differ from desktop; Claude already knows this, so lead with the actionable Quick Reference instead.

Add a short executable Playwright snippet (e.g., a projects entry using devices['iPhone 14']) in the Fix section so the guidance is copy-paste ready rather than a high-level instruction.

Make the review workflow explicit with a numbered Check → Verify-in-CI → Fix → Re-verify sequence, including a checkpoint confirming failures block regressions, so validation is not merely implicit.

DimensionReasoningScore

Conciseness

The opening paragraph explains concepts Claude already knows ('Mobile browsers have different rendering engines...', 'real touch events that differ from mouse events') and pads with a 55%-of-traffic stat, which the guidelines explicitly penalize. It is not score 1 because the Quick Reference and Check/Fix/Code Review sections are reasonably tight, and not score 3 because that padded intro does not earn its tokens.

2 / 3

Actionability

Gives concrete specifics — Playwright device presets, breakpoints 375px/390px/768px, BrowserStack — but the body contains no executable code or commands, and 'Add Playwright tests using mobile device presets to cover key user flows' is high-level rather than copy-paste ready. It is not score 3 (no fully executable examples in the body) and not score 1 (the tools and targets are specific, not vague).

2 / 3

Workflow Clarity

The Check → Fix → Code Review sections imply a sequence, but there are no explicit validation checkpoints or a validate→fix→retry feedback loop; verification is only implicitly addressed by 'Flag exact gaps where the rule is not automatically verified'. It is not score 3 because checkpoints are implicit rather than explicit, and not score 1 because a recognizable sequence is present.

2 / 3

Progressive Disclosure

The body is a concise overview with a well-signaled one-level-deep pointer — 'see references/rule.md' — and that referenced file exists and holds the code examples and framework guidance. This matches the score-3 anchor of a clear overview with appropriately split, easy-to-navigate references, unlike the score-2 case of inline content that should be separated.

3 / 3

Total

9

/

12

Passed

Description

100%

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 well-crafted description that follows the recommended 'Use when...' pattern: explicit trigger, concrete review actions, natural terminology, and a clearly scoped niche. Voice is appropriately third person with no first/second-person pronouns, so no voice penalty applies.

DimensionReasoningScore

Specificity

Lists multiple concrete review actions — 'reviewing CI coverage, automated checks, or test strategy' plus 'whether the rule is continuously verified, not just documented' — matching the score-3 anchor of several specific concrete actions. It is not the score-2 'some actions, not comprehensive' case because the review targets and the continuous-verification focus together cover the skill's scope.

3 / 3

Completeness

Explicitly answers both: 'when' via the 'Use when reviewing CI coverage, automated checks, or test strategy' trigger, and 'what' via the reviewing/continuous-verification actions. This matches the score-3 anchor of clearly answering both what and when with explicit triggers, unlike score 2 where 'when' is only implied.

3 / 3

Trigger Term Quality

Includes natural terms a user would actually say — 'CI coverage', 'automated checks', 'test strategy', 'real mobile devices', 'viewports' — giving good coverage rather than the score-2 'missing common variations' case. It is not score 1 because the terms are natural user language, not jargon.

3 / 3

Distinctiveness Conflict Risk

Scoped to 'Test on real mobile devices and viewports', a clear niche with distinct triggers unlikely to fire for unrelated skills. It avoids the score-2 'could still overlap' case because the mobile/viewport qualifier narrows the otherwise-generic review framing to a specific domain.

3 / 3

Total

12

/

12

Passed

Validation

93%

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

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository
thedaviddias/Front-End-Checklist
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.