CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

visual-check

Use when the user asks to visually check, eyeball, screenshot, or review the UI of their current branch/PR in OPRE-OPS, compare it against a Figma design, or check a responsive/mobile layout ("does this look right", "visual check", "check the UI changes", "does this match Figma", "compare to the design", "check the mobile layout"). Drives the running app (or Storybook) with Playwright MCP, screenshots the pages/components the diff touches at desktop and mobile widths, and reports visual, accessibility-tree, and console issues.

75

Quality

94%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Quality

Content

88%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 strong, dense skill body: every step is executable with exact commands, viewports, and error-recovery paths, and the 7-step workflow is sequenced with real validation checkpoints (prerequisite checks, server verification, rate-limit honesty, attribution uncertainty). The only weaknesses are the redundant 'Lessons' section duplicating guidance already in steps 6-7 and an all-inline structure slightly beyond overview length.

Suggestions

Delete the 'Lessons' section (or fold it into steps 6-7): its three bullets restate guidance already given inline — 'measure spacing, don't eyeball it', data-driven text classification, and shared-component mismatches being a UX decision — so the recap costs tokens without adding new information.

Move the detailed design-comparison procedure (step 6's measurement workflow, Figma-to-USWDS unit mapping, and text-difference classification rules) into a references/ file (e.g. references/design-comparison.md) and keep a two-line pointer in the workflow, keeping SKILL.md a lean overview.

Tighten step 1's Figma-link collection into a compact table or single grep instruction; the ordered three-source list with per-source conditionals can be compressed without losing the search order.

DimensionReasoningScore

Conciseness

Nearly every line carries non-obvious project knowledge Claude cannot infer (routes are JSX attributes not object-literal 'path:', Playwright MCP rejects absolute paths outside allowed roots, Figma seat rate limits, ticket-less branch conventions, USWDS 8px spacing units). The one inefficiency is the 'Lessons' section, which restates three points already embedded verbatim in steps 6-7 (measure don't eyeball, classify data-driven text by format, shared component = UX decision). Efficient with minor over-explanation that could be trimmed, fitting the 4 anchor; not 5 because of that genuine redundancy, and not 3 because the prose is otherwise tight with no filler or explanation of concepts Claude already knows.

4 / 5

Actionability

Copy-paste-ready commands throughout: 'git fetch origin main && git diff --name-only origin/main...HEAD -- frontend/src', 'curl -s -o /dev/null -w "%{http_code}" http://localhost:3000', 'mktemp -d /tmp/playwright-mcp/visual-check.XXXX', a concrete grep regex for Figma URLs, and 'grep -n 'path="' frontend/src/index.jsx'. Exact viewport sizes (1280x800, 375x812), a numeric tolerance (+-2px), specific MCP tool names per step, and named sign-in users fully cover the common cases.

5 / 5

Workflow Clarity

A clearly sequenced 7-step workflow (presented as a checklist then elaborated) with explicit validation checkpoints and feedback loops: check MCP availability before starting and stop if Playwright MCP is missing; verify the server responds before capturing ('curl -s -o /dev/null -w "%{http_code}"'); 'browser_wait_for' the main content rather than fixed sleeps; handle rate-limit errors by reporting them 'rather than reporting "no differences found"'; ask before exceeding ~6 targets; and mark attribution as uncertain when no baseline was run. Error recovery is addressed at every fragile point.

5 / 5

Progressive Disclosure

Well-organized single file: Prerequisites, Inputs, a workflow overview checklist, numbered step elaborations, and clearly separated optional Before/after and Lessons sections — no bundle files exist (no references/, scripts/, or assets/), so nothing is misfiled. However at ~80 lines everything is inline, and some content (the step-6 measurement procedure and the Lessons recap) could live in a one-level-deep reference file to keep SKILL.md a leaner overview. Anchor 4 ('good structure; most content appropriately placed; minor organization gaps') fits better than 5, which expects well-signaled external references or a sub-50-line skill with none needed.

4 / 5

Total

18

/

20

Passed

Description

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

An exemplary description: it pairs an explicit 'Use when...' clause full of natural user phrasings (including quoted utterances like 'does this look right') with a precise statement of what the skill does, how (Playwright MCP, app/Storybook, desktop + mobile widths), and what it reports. Specific, complete, and unlikely to trigger the wrong skill.

DimensionReasoningScore

Specificity

Lists multiple concrete actions with the mechanism and outputs named: 'Drives the running app (or Storybook) with Playwright MCP, screenshots the pages/components the diff touches at desktop and mobile widths, and reports visual, accessibility-tree, and console issues.' Nothing is vague, and the actions comprehensively cover input handling, execution, and reporting, matching the 5 anchor rather than 4's 'minor gaps'.

5 / 5

Completeness

Explicitly answers both: what ('Drives the running app (or Storybook) with Playwright MCP, screenshots... and reports visual, accessibility-tree, and console issues') and when ('Use when the user asks to visually check, eyeball, screenshot, or review the UI... or check a responsive/mobile layout') with concrete trigger phrases. This mirrors the 5 anchor example's structure exactly.

5 / 5

Trigger Term Quality

Comprehensive natural phrasings including synonyms and quoted user utterances: 'visually check, eyeball, screenshot, or review the UI', 'does this look right', 'visual check', 'check the UI changes', 'does this match Figma', 'compare to the design', 'check the mobile layout', plus 'responsive/mobile layout'. A user needing this skill would naturally say one of these; no common variation is missing.

5 / 5

Distinctiveness Conflict Risk

Clear niche scoped to a specific repo ('the UI of their current branch/PR in OPRE-OPS') with distinct triggers (Figma design comparison, visual check of branch UI). It would not fire for generic code review, PDF, or browser-automation skills; conflict risk is minimal.

5 / 5

Total

20

/

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

HHS/OPRE-OPS

Path

.claude/skills/visual-check/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.