Skip to content
Back to skills

Visual Diff

ASecurity

Visual Regression Testing — screenshot comparison before and after changes. Use when user wants to check for visual regressions, compare UI changes, or verify CSS/layout changes didn't break anything.

  • 121 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added May 27, 2026
data-airustgotesting

Works with

  • cli
  • mcp

Security analysis

A100/100

Scanned May 27, 2026

npx -y skills add Houseofmvps/ultraship --skill visual-diff --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Visual Diff?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Visual Diff
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/houseofmvps-visual-diff/badge)](https://www.skillsdirectory.com/skills/houseofmvps-visual-diff)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: visual-diff
description: "Visual Regression Testing — screenshot comparison before and after changes. Use when user wants to check for visual regressions, compare UI changes, or verify CSS/layout changes didn't break anything."
---

# Visual Regression Testing

Automated screenshot comparison using Playwright. Catch visual bugs before they ship.

## Process

### Phase 1: Determine Test Scope

Ask the user:
1. **What URL(s) to test?** (localhost, staging, or production)
2. **What changed?** (CSS update, component refactor, dependency upgrade, etc.)

If the user already described what changed, skip asking.

### Phase 2: Take "Before" Screenshots

If comparing against the current state (before making changes):

Use the Playwright MCP to capture screenshots:

1. Navigate to the URL:
   - Use `browser_navigate` to go to the target URL

2. Take full-page screenshot:
   - Use `browser_take_screenshot` to capture the current state

3. Capture key viewports:
   - Desktop (1920x1080): `browser_resize` then `browser_take_screenshot`
   - Tablet (768x1024): `browser_resize` then `browser_take_screenshot`
   - Mobile (375x812): `browser_resize` then `browser_take_screenshot`

4. Save screenshots with descriptive names noting they are "before" state.

### Phase 3: Make Changes

Let the user make their changes, or make them yourself if that's the task.

### Phase 4: Take "After" Screenshots

Repeat the same screenshot process for the same URLs and viewports.

### Phase 5: Visual Comparison

Compare before and after screenshots:

1. **Layout shifts** — did any elements move unexpectedly?
2. **Color changes** — did colors, gradients, or shadows change?
3. **Typography** — did font sizes, weights, or spacing change?
4. **Responsive issues** — does it look correct on all viewports?
5. **Missing elements** — did anything disappear?
6. **Overflow issues** — is content clipping or overflowing?

Use `browser_snapshot` to get the accessibility tree and compare DOM structure between before/after.

### Phase 6: Report

Present findings in a clear format:

**No Visual Regressions Found:**
- "All pages look identical across desktop, tablet, and mobile viewports."

**Regressions Detected:**
For each regression:
- **Page:** URL where the issue appears
- **Viewport:** Which screen size is affected
- **What changed:** Description of the visual difference
- **Severity:** Critical (broken layout), High (noticeable shift), Medium (minor difference), Low (pixel-level)
- **Suggested fix:** How to resolve the regression

### Phase 7: Targeted Testing

For specific component changes, also test:
- Hover states (use `browser_hover`)
- Click interactions (use `browser_click`)
- Form states (use `browser_fill_form`)
- Dark mode (if applicable)
- Loading states
- Error states
- Empty states

## Key Pages to Always Test

When the user doesn't specify pages, test these by default:
1. Homepage / Landing page (/)
2. Login/signup page (if exists)
3. Main app page (dashboard, etc.)
4. Any page the user recently modified

## Key Principle

**Trust screenshots, not assumptions.** CSS changes cascade unpredictably. A "small tweak" in one component can break layouts across the entire app. Always verify visually.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.