Debug Visual Regression

VerifiedSafe

Analyze visual regression test failures in Vizzly by comparing baseline and current images. Identify visual differences and suggest appropriate actions.

Sby Skills Guide Bot
TestingIntermediate
3/9/2026
Claude Code
#visual-regression#screenshot-testing#debugging#vizzly#mcp

Recommended for

Automated summary

This skill guides Claude through diagnosing visual regression failures in Vizzly by fetching comparison details and inspecting the baseline and current screenshots.

Strengths

  • Automatically detects local TDD versus cloud mode and adapts image retrieval accordingly (file paths or URLs)
  • Requires actually viewing the baseline and current images before concluding, which prevents speculative analysis
  • Maps diff percentage ranges to likely causes such as anti-aliasing, layout shifts, or missing content
  • Suggests concrete next actions through MCP: accept a baseline, approve, or reject a comparison

Limitations

  • Assumes the Vizzly MCP server is installed and configured and that comparisons already exist
  • Never reads the diff image, which removes a signal that is often the most informative
  • Does not fix CSS or content itself; it stops at diagnosis and recommended next steps
When to use it

Use it when a Vizzly visual test fails or when you need to understand what changed in a screenshot before accepting or fixing the change.

When not to use it

Skip it when the project does not use Vizzly or no comparison MCP tools are available, since the skill would have no data to analyze.

Security analysis

Safe
Quality score82/100

The skill is a read-and-analyze workflow for Vizzly visual regression data. It uses only Read, WebFetch, and Vizzly MCP tools, with no shell commands, file writes, obfuscated payloads, or outbound transfer of secrets. WebFetch and the MCP tools are used for their legitimate purpose (viewing baseline/current screenshots and managing comparisons). The only mild concerns are state-changing approve/accept/reject actions and a placeholder token in an example; neither is destructive or exfiltrating, so overall risk is low.

Findings
  • •Mutating MCP tools (accept_baseline, approve_comparison, reject_comparison) change test baselines; the skill suggests them as next steps without explicitly requiring user confirmation before invoking, so an agent could alter recorded baselines on its own judgment.
  • •The cloud-mode example shows an `apiToken: "vzt_..."` passed as a tool parameter; it is only a placeholder, but it models inline credential handling rather than relying on configured auth.
  • •Skill includes state-mutating tools (accept_baseline, approve_comparison, reject_comparison) that can permanently overwrite visual baselines; guidance encourages approving sub-1% diffs, which could mask genuine regressions if the agent acts without human sign-off.
  • •Uses WebFetch against URLs returned by the MCP tool; the skill does not validate that URLs belong to the Vizzly domain, so a malicious/compromised response could direct fetches elsewhere (low risk, read-only).
  • •Example payloads contain a placeholder API token string ('vzt_...'); it is clearly illustrative and not a real secret, but token handling is not described safely.
How this analysis is made

Examples

Analyze a failing screenshot
My visual test for homepage_desktop is failing in Vizzly. Pull the comparison details, look at the baseline and current screenshots, and tell me what actually changed.
Decide whether to accept a diff
The checkout page screenshot shows a 2% diff. Investigate the comparison and tell me whether this looks like an intentional layout change I should accept or a regression I should fix.
Handle a cloud comparison
Comparison cmp_abc123 failed in cloud mode. Review the baseline and current images and recommend whether to approve or reject it, with a reason I can share with my team.

name: Debug Visual Regression description: Analyze visual regression test failures in Vizzly. Use when the user mentions failing visual tests, screenshot differences, visual bugs, diffs, or asks to debug/investigate/analyze visual changes. Works with both local TDD and cloud modes. allowed-tools: Read, WebFetch, mcp__plugin_vizzly_vizzly__read_comparison_details, mcp__plugin_vizzly_vizzly__search_comparisons, mcp__plugin_vizzly_vizzly__accept_baseline, mcp__plugin_vizzly_vizzly__approve_comparison, mcp__plugin_vizzly_vizzly__reject_comparison

Debug Visual Regression

Automatically analyze visual regression failures when the user mentions them. This Skill helps identify the root cause of visual differences and suggests whether to accept or fix changes.

When to Use This Skill

Activate this Skill when the user:

  • Mentions "failing visual test" or "screenshot failure"
  • Asks "what's wrong with my visual tests?"
  • Says "the homepage screenshot is different" or similar
  • Wants to understand why a visual comparison failed
  • Asks to "debug", "analyze", or "investigate" visual changes
  • Mentions specific screenshot names that are failing

How This Skill Works

  1. Automatically detect the mode (local TDD or cloud)
  2. Fetch comparison details using the screenshot name or comparison ID
  3. View the actual images to perform visual analysis
  4. Provide detailed insights on what changed and why
  5. Suggest next steps (accept, reject, or fix)

Instructions

Step 1: Call the Unified MCP Tool

Use read_comparison_details with the identifier:

  • Pass screenshot name (e.g., "homepage_desktop") for local mode
  • Pass comparison ID (e.g., "cmp_abc123") for cloud mode
  • The tool automatically detects which mode to use
  • Returns a response with mode field indicating local or cloud

Step 2: Check the Mode in Response

The response will contain a mode field:

  • Local mode (mode: "local"): Returns filesystem paths (baselinePath, currentPath, diffPath)
  • Cloud mode (mode: "cloud"): Returns URLs (baselineUrl, currentUrl, diffUrl)

Step 3: Analyze Comparison Data

Examine the comparison details:

  • Diff percentage and threshold
  • Status (failed/new/passed)
  • Image references (paths or URLs depending on mode)
  • Viewport and browser information

Step 4: View the Actual Images

CRITICAL: You MUST view the baseline and current images to provide accurate analysis.

If mode is "local":

  • Response contains filesystem paths (baselinePath, currentPath, diffPath)
  • Use the Read tool to view ONLY baselinePath and currentPath
  • DO NOT read diffPath - it causes API errors

If mode is "cloud":

  • Response contains public URLs (baselineUrl, currentUrl, diffUrl)
  • Use the WebFetch tool to view ONLY baselineUrl and currentUrl
  • DO NOT fetch diffUrl - it causes API errors

Step 5: Provide Detailed Visual Insights

Based on what you observe in the images:

Describe the specific visual differences:

  • Which UI components, elements, or layouts changed
  • Colors, spacing, typography, positioning changes
  • Missing or added elements

Categorize the change by diff percentage:

  • < 1%: Anti-aliasing, font rendering, subpixel differences
  • 1-5%: Layout shifts, padding/margin changes, color variations
  • > 5%: Significant layout changes, missing content, major visual updates

Identify possible causes:

  • CSS changes (margin, padding, positioning)
  • Content changes (text, images)
  • State issues (hover, focus, loading states)
  • Browser/viewport rendering differences

Step 6: Suggest Next Steps

If local mode:

  • Whether to accept using accept_baseline tool
  • Specific code areas to investigate if unintentional
  • How to fix common issues

If cloud mode:

  • Whether to approve using approve_comparison tool
  • Whether to reject using reject_comparison tool with reason
  • Team coordination steps

If changes are intentional:

  • Explain why it's safe to accept/approve
  • Confirm this matches expected behavior

If changes are unintentional:

  • Specific files to check (CSS, templates, components)
  • Git commands to investigate recent changes
  • How to reproduce and fix

Example Analysis (Local TDD Mode)

User: "The homepage screenshot is failing"

Step 1: Call tool
Tool: read_comparison_details({ identifier: "homepage" })

Response:
{
  "name": "homepage",
  "status": "failed",
  "diffPercentage": 2.3,
  "threshold": 2.0,
  "mode": "local",
  "baselinePath": "/Users/you/project/.vizzly/baselines/homepage.png",
  "currentPath": "/Users/you/project/.vizzly/screenshots/homepage.png"
}

Step 2: View images
Read(baselinePath)
Read(currentPath)

Step 3: Visual Analysis
Comparing the two images, I can see the following changes:

Visual Differences:
- The navigation header has shifted down by approximately 10-15 pixels
- Logo position moved from y:20px to y:35px
- Navigation menu items are now overlapping with the hero section
- The "Sign Up" button background changed from blue (#2563eb) to darker blue (#1e40af)

Root Cause Analysis:
Based on the 2.3% diff and visual comparison, this appears to be:
1. A margin or padding change on the header element
2. The button color change suggests a hover state being captured

Recommendations:
If intentional:
- This appears to be a deliberate redesign of the header spacing
- Accept as new baseline if these changes match your design updates

If unintentional:
- Check recent CSS changes to `.header` or `nav` margin-top/padding-top
- Verify button states during screenshot capture to avoid hover state
- Investigate with: `git diff src/styles/header.css`
- Fix the header positioning and re-run tests

Example Analysis (Cloud Mode)

User: "Can you check comparison cmp_xyz789?"

Step 1: Call tool
Tool: read_comparison_details({
  identifier: "cmp_xyz789",
  apiToken: "vzt_..."
})

Response:
{
  "name": "login-page",
  "status": "failed",
  "diffPercentage": 0.8,
  "threshold": 2.0,
  "mode": "cloud",
  "baselineUrl": "https://app.vizzly.dev/screenshots/abc123/baseline.png",
  "currentUrl": "https://app.vizzly.dev/screenshots/abc123/current.png",
  "comparisonId": "cmp_xyz789"
}

Step 2: View images
WebFetch(baselineUrl, "show me the baseline screenshot")
WebFetch(currentUrl, "show me the current screenshot")

Step 3: Visual Analysis
The differences are very subtle (0.8% diff):

Visual Differences:
- Input field border color slightly different (#e5e7eb vs #d1d5db)
- Submit button has very slight shadow change
- Font anti-aliasing appears slightly different

Root Cause Analysis:
This appears to be browser rendering differences or minor CSS updates:
- The 0.8% diff suggests this is not a major visual change
- Could be Chrome version differences
- Could be sub-pixel rendering variations

Recommendations:
This is likely acceptable to approve:
- The changes are extremely minor (< 1%)
- No functional UI changes
- Probably browser/rendering variations

Approve with: approve_comparison tool
Or adjust threshold to 1% if these variations are expected

Cross-Build Debugging (Cloud Only)

When debugging visual regressions in cloud mode, you can track a screenshot across multiple builds to identify when changes were introduced.

When to Use Search

Use search_comparisons when:

  • The user asks "when did this screenshot start failing?"
  • They want to track a visual change across builds
  • They're investigating a regression that appeared recently
  • They want to see the history of a specific screenshot

How to Search

// Search for all comparisons of a screenshot
search_comparisons({
  name: "homepage_desktop",
  branch: "main",  // optional: filter by branch
  limit: 10        // optional: limit results
})

Example Workflow

User: "When did the homepage screenshot start failing?"

Step 1: Search for the screenshot across builds
Tool: search_comparisons({ name: "homepage", branch: "main", limit: 10 })

Response shows 10 comparisons from most recent to oldest, each with:
- Build name, branch, and creation date
- Diff percentage and status
- Screenshot URLs

Step 2: Analyze the timeline
- Build #45 (today): 5.2% diff - FAILED
- Build #44 (yesterday): 5.1% diff - FAILED
- Build #43 (2 days ago): 0.3% diff - PASSED
- Build #42 (3 days ago): 0.2% diff - PASSED

Step 3: Report findings
"The homepage screenshot started failing between Build #43 and #44
(approximately 1-2 days ago). The diff jumped from 0.3% to 5.1%,
suggesting a significant visual change was introduced."

Step 4: Deep dive into the failing build
Tool: read_comparison_details({ identifier: "cmp_xyz_from_build44" })
[View images and provide detailed analysis as usual]

Important Notes

  • Always use read_comparison_details - it automatically detects the mode
  • Use search_comparisons for cloud debugging - to track changes across builds
  • Check the mode field to know which viewing tool to use (Read vs WebFetch)
  • Never view diff images - only baseline and current
  • Visual inspection is critical - don't rely solely on diff percentages
  • Be specific in analysis - identify exact elements that changed
  • Provide actionable advice - specific files, commands, or tools to use
  • Consider context - small diffs might be acceptable, large ones need investigation

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/debug-visual-regression-mmio7217/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/debug-visual-regression-mmio7217' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/debug-visual-regression-mmio7217/download' --output '.skill-downloads/debug-visual-regression-mmio7217/SKILL.md.part' && mv '.skill-downloads/debug-visual-regression-mmio7217/SKILL.md.part' '.skill-downloads/debug-visual-regression-mmio7217/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

Tools declared by the author (check availability in your agent): Read, WebFetch, mcp__plugin_vizzly_vizzly__read_comparison_details, mcp__plugin_vizzly_vizzly__search_comparisons, mcp__plugin_vizzly_vizzly__accept_baseline, mcp__plugin_vizzly_vizzly__approve_comparison, mcp__plugin_vizzly_vizzly__reject_comparison

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

This file does not provide a usable name/description header for this native procedure. It remains available to download and inspect; use the manual method below.

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/debug-visual-regression-mmio7217/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills