Conciseness

Efficient throughout: exact viewport dimensions ("360×800 (mobile ...)", "768×1024", "1440×900"), an executable snippet, and earned domain insights ("most layouts that break at 375–390 already break here") rather than concepts Claude already knows. Not a 5 because the intro ("not a pixel-diff regression tool, not a conversion/copy audit, not an aesthetic design critique") and the "When not to use this" section substantially restate the frontmatter's NOT list. Not a 3 because there is no padding or basic-concept explanation.

Actionability

Fully executable: a copy-paste-ready overflow-measurement snippet, exact breakpoint dimensions, a capture naming convention ("<page-slug>-<breakpoint-label>.png"), a concrete finding-format example ("pricing table overflows viewport at 360px, third column cut off" not "mobile layout needs work"), and a severity table. The only flexible step (browser automation) is explicitly justified: "Use whatever browser automation is available in the environment".

Workflow Clarity

Clear phase sequence (Scope → Capture → Checklist → Findings) with explicit validation checkpoints: overflow is verified by measurement, not eyeballing ("overflow > 0 is a finding even when every screenshot looks fine"), a full checklist governs the review pass, and a safety boundary is stated ("Do not fix anything automatically — hand the findings back for triage"). The skill is read-only, so the destructive/batch validation cap does not apply. Not a 4 because both validation steps and a complex-process checklist are present, not merely implied.

Progressive Disclosure

No bundle files exist, and none are needed: this is a single cohesive process skill where every section (breakpoints, snippet, checklist, severity table) is load-bearing on every run. Sections are clearly headed and navigable, with no buried or nested references and no content that clearly belongs in a separate file. Not a 4 because there are no organization gaps to point to.

Specificity

Base level is 4: it names the domain ("structural visual review of a website across breakpoints (mobile/tablet/desktop)") and several concrete caught-issue types ("layout breaks, overflow, and spacing issues") with minor gaps (no mention of capture, screenshots, or the checklist process). However, the trigger clause "Use when you need a structural visual review" is written in second person, so the rubric's voice guideline mandates a 1-point reduction, landing at 3. Not a 2 because the domain and specific issue types are explicitly named, not generic.

Completeness

Clearly answers both what ("structural visual review of a website across breakpoints ... to catch layout breaks, overflow, and spacing issues without a baseline or hosted regression service") and when ("Use when you need a structural visual review ... to catch layout breaks, overflow, and spacing issues"), supplemented by explicit negative triggers ("NOT for CRO/conversion/copy review, NOT for new UI design work..."). Not a 4 because the when-clause carries concrete trigger phrases and explicit exclusions rather than being merely present or generic.

Trigger Term Quality

Good natural keyword coverage: "visual review", "website", "breakpoints", "mobile/tablet/desktop", "layout breaks", "overflow", and "spacing issues" are phrases users would naturally say. Not a 5 because "responsive" — arguably the most natural trigger word for this task — appears only in the skill name, not the description, and common variations like "screen sizes" are also absent.

Distinctiveness Conflict Risk

Clear niche with minimal conflict risk: the exclusion list ("NOT for CRO/conversion/copy review, NOT for new UI design work, NOT for automated pixel-diff regression gating in CI, NOT for accessibility/contrast auditing") explicitly fences off every adjacent skill category, and the positive scope (structural layout review across breakpoints, no baseline) is distinct from generic design or audit skills.