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
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.
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
SafeThe 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.
- •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.
Examples
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.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.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
- Automatically detect the mode (local TDD or cloud)
- Fetch comparison details using the screenshot name or comparison ID
- View the actual images to perform visual analysis
- Provide detailed insights on what changed and why
- 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
modefield 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_baselinetool - Specific code areas to investigate if unintentional
- How to fix common issues
If cloud mode:
- Whether to approve using
approve_comparisontool - Whether to reject using
reject_comparisontool 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_comparisonsfor cloud debugging - to track changes across builds - Check the
modefield 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 filesThis 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.mdFrom 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.
ClickHouse Performance Comparison
Testing
Evaluate ClickHouse performance test results, check PR performance changes, compare with history, and assess whether a result is actionable.
Analyze CI Performance Reports
Testing
Analyze CI performance comparison reports for a ClickHouse PR. Cross-references master history to distinguish real regressions from flaky tests.
Santa Method
Testing
Multi-agent adversarial verification with two independent reviewers. Output is checked twice and iteratively fixed until both pass before shipping.