CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/playwright-snapshots

Use when a project wants self-hosted visual regression tests in Playwright with no external service: toHaveScreenshot assertions, masks, clips and thresholds, per-OS and per-browser snapshot folders, --update-snapshots, and a viewport matrix across responsive breakpoints.

Quality

91%

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-crafted, highly actionable skill body: executable code at every step, genuinely non-obvious operational guidance (platform-specific baselines, CI matching), and clean use of a one-level-deep reference file. The remaining gains are trimming a few sentences that restate Playwright basics and making the first-run-to-CI sequence an explicit numbered workflow with a diff-failure feedback loop.

Suggestions

Cut sentences that restate known Playwright behavior (e.g. 'The first run generates the baseline PNG; subsequent runs compare against it') to tighten conciseness toward the lean anchor.

Add a short numbered adoption sequence (add assertion → commit baseline from matching platform → verify CI green) with an explicit 'if a snapshot fails unexpectedly, inspect the report diff before updating baselines' feedback loop to lift workflow clarity.

Consider moving the full toHaveScreenshot options table into a reference file (like the viewport pattern) so SKILL.md carries only the most-used options inline.

DimensionReasoningScore

Conciseness

The body is dense with non-obvious operational knowledge (platform-suffix load-bearingness, CI baseline-matching strategies, the options table) and mostly assumes Playwright competence. Not 5: a few sentences restate basics Claude already knows, e.g. "The first run generates the baseline PNG; subsequent runs compare against it".

4 / 5

Actionability

Fully executable throughout: copy-paste-ready page- and locator-level spec examples, a complete playwright.config.ts, concrete --update-snapshots commands, and a whole CI workflow YAML, with the common cases (mask, maxDiffPixels, clip) each shown as code. Not 4: there are no gaps in executable guidance for the common cases.

5 / 5

Workflow Clarity

Sections progress logically (authoring → snapshot layout → config → run/update → CI matching → CI integration) and include a real validation checkpoint ("Always review the diff of the baselines in your PR") plus failure remediation for platform mismatch. Not 5: there is no explicit ordered step sequence or a failure→fix→rerun feedback loop for an unexpected snapshot diff; not 3: checkpoints are present and explicit, not implicit.

4 / 5

Progressive Disclosure

The SKILL.md is a clear overview and the advanced viewport-matrix pattern is correctly split into references/responsive-breakpoints.md (a real bundle file), which is linked in both the config section and References with an accurate description of its contents and nests no further. Not 4: the single reference is well signaled and all content is appropriately placed, meeting the 'clear overview with well-signaled one-level-deep references' anchor.

5 / 5

Total

18

/

20

Passed

Description

92%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 description: it states a precise trigger condition, distinguishes the self-hosted niche from hosted alternatives, and catalogs the concrete feature surface. The only improvement space is adding a few natural synonyms (screenshot tests, visual/pixel diff, baselines) for broader trigger coverage.

DimensionReasoningScore

Specificity

The description enumerates multiple concrete capabilities — "toHaveScreenshot assertions, masks, clips and thresholds, per-OS and per-browser snapshot folders, --update-snapshots, and a viewport matrix across responsive breakpoints" — giving comprehensive coverage of the skill's surface. Not 4: the 4 anchor requires minor gaps in coverage, and no significant capability area is missing.

5 / 5

Completeness

It explicitly answers 'when' with a concrete trigger clause ("Use when a project wants self-hosted visual regression tests in Playwright with no external service") and 'what' with the explicit capability list after the colon. Not 4: the 'when' clause is already specific and explicit, not merely present.

5 / 5

Trigger Term Quality

Strong natural phrasing ("visual regression tests", "Playwright", "snapshots", "self-hosted", "toHaveScreenshot", "--update-snapshots", "breakpoints") that users would plausibly say. Not 5: common synonyms and variations like "screenshot tests", "visual diff", "pixel diff", or "baseline images" are absent, which the 5 anchor demands.

4 / 5

Distinctiveness Conflict Risk

"self-hosted... no external service" plus Playwright-specific API names carve a clear niche distinct from hosted visual-regression skills (Chromatic, Percy) with minimal mis-trigger risk. Not 4: there is no meaningful overlap risk with closely related skills given the explicit self-hosted/no-external-service framing.

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