CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

mobile-emulation

Mobile device emulation and responsive testing with Playwright. Use when testing mobile layouts, touch interactions, device-specific features, or responsive breakpoints.

Quality

77%

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-emulation/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

75%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 solid, well-structured cookbook of executable Playwright patterns covering configuration, breakpoints, touch, orientation, geolocation, network, and device-specific features, with genuinely useful one-level-deep references. The main quality issues are a few code defects (test.use called inside a test callback, a non-functional pinch stub), mild duplication between the inline device catalog and references/device-list.md, and missing decision guidance between the two device-configuration approaches.

Suggestions

Fix the actionable-code defects: move test.use(devices['iPhone 14 Pro']) outside the test callback in the safe-areas example, add the missing devices import where it is used, and either replace the pinch stub with a working two-pointer touchscreen implementation or point to touch-patterns.md for it.

Trim the ~35-line device-name catalog in "Available Devices" to a handful of examples plus the Object.keys(devices) snippet, deferring the full enumeration to references/device-list.md, and link touch-patterns.md directly from the Touch Interactions section rather than only in the end-of-file References section.

Add brief guidance on when to use project-based device configuration in playwright.config.ts versus inline test.use per test/file, since both patterns are presented without trade-offs.

DimensionReasoningScore

Conciseness

The body is mostly lean: one-line intros followed directly by executable code, with no filler explaining concepts Claude already knows. Minor padding keeps it from level 5: the ~35-line device-name catalog in "Available Devices" is largely redundant with the adjacent "List All Devices" snippet and references/device-list.md, and the pinch-to-zoom example is a self-admitted non-working stub ("Multi-touch pinch requires custom implementation").

4 / 5

Actionability

Nearly every snippet is copy-paste-ready TypeScript with real selectors and assertions, e.g. "await page.getByRole('button', { name: 'Menu' }).click();" and "await expect(page).toHaveScreenshot(...)". Minor gaps hold it below level 5: devices is used without an import in the landscape-variant and notch examples, and the notch example calls test.use(devices['iPhone 14 Pro']) inside the test callback, which is invalid since test.use must be at file or describe scope.

4 / 5

Workflow Clarity

A well-organized cookbook where each recipe is self-contained and carries its own validation via expect(...) assertions, and no destructive or batch operations exist that would cap the score. It falls short of level 5 because it never explains when to choose project-based config versus inline test.use (both approaches are shown without trade-offs) and offers no error-recovery guidance for fragile cases like swipe or network-conditioned tests.

4 / 5

Progressive Disclosure

Good structure with both referenced files (references/device-list.md and references/touch-patterns.md) existing, one level deep, and clearly signaled in a dedicated References section ("Complete device list with specs", "Touch gesture implementations"). Below level 5 because the reference links appear only at the end rather than in the sections they extend — the Touch Interactions section duplicates material in touch-patterns.md without linking it there — and the inline device catalog partially duplicates device-list.md.

4 / 5

Total

16

/

20

Passed

Description

70%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 well-formed description that follows the good-example pattern: concrete domain, named tool, explicit third-person statement of what it does, and a clear 'Use when...' clause with natural trigger phrases. Its main weakness is that the what-side only enumerates two actions while the skill body covers a broader capability set (touch, orientation, network, geolocation), leaving the description slightly under-scoped relative to the content.

Suggestions

Enumerate more concrete capabilities in the what-clause, e.g. "Emulate mobile devices, touch interactions, responsive breakpoints, orientation, geolocation, and network conditions with Playwright" to reach the comprehensive coverage of the level-5 specificity anchor.

Add common trigger variations users naturally say, such as "mobile testing", "viewport testing", or "device emulation", to broaden trigger-term coverage toward level 5.

Narrow the when-clause slightly toward mobile-specific contexts (e.g. "when testing mobile or responsive layouts on emulated devices") to reduce overlap with general desktop responsive-testing skills.

DimensionReasoningScore

Specificity

"Mobile device emulation and responsive testing with Playwright" names the domain plus two actions (emulation, responsive testing), but omits capabilities the body actually covers (touch gestures, orientation, network and geolocation emulation), matching the anchor 'names domain and 1-2 concrete actions, but not comprehensive' rather than 'lists several specific actions'.

3 / 5

Completeness

Both halves are present: a clear what ("Mobile device emulation and responsive testing with Playwright") and an explicit when with four concrete triggers ("Use when testing mobile layouts, touch interactions, device-specific features, or responsive breakpoints"). It is not level 5 because the what lists only two actions rather than the multiple concrete actions in the anchor-5 example.

4 / 5

Trigger Term Quality

"mobile layouts, touch interactions, device-specific features, or responsive breakpoints" are natural phrases users would say, giving good keyword coverage; it stops short of level 5 because common variations like "mobile testing", "viewport", "device testing", or "emulator" are missing.

4 / 5

Distinctiveness Conflict Risk

Naming Playwright and the mobile emulation niche makes it mostly distinct with only minor overlap risk against a general Playwright/browser-testing skill; it is not level 5 because "responsive testing" could also trigger it for desktop-responsive checks where a general testing skill fits better.

4 / 5

Total

15

/

20

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.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

fernandezbaptiste/Skrillz

Path

skills/mobile-emulation/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.