Visual regression testing
Skill sairam0424/MindForge/.mindforge/skills/visual-regression-testing
MindForge: The Enterprise Agentic Framework for Claude Code & Antigravity. High-performance autonomous execution, wave-parallelism, and multi-tier governance for production-grade AI engineering.
npx -y skills add sairam0424/MindForge --skill visual-regression-testingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.9 KB, as published. Nobody here has run it
Visual Regression Testing
When this skill activates
This skill activates when implementing screenshot-based testing, configuring visual diff tools, managing visual baselines, or investigating unexpected UI changes. It applies to component-level visual testing (Storybook), page-level screenshots, and responsive layout verification.
Mandatory actions when this skill is active
Before
- Determine the scope: component-level (individual components in isolation) or page-level (full page renders).
- Select the tooling approach (Playwright screenshots, Chromatic, Percy, BackstopJS).
- Identify dynamic content that must be stabilized (timestamps, avatars, animations, ads).
- Define viewport sizes to capture (mobile: 375px, tablet: 768px, desktop: 1440px minimum).
- Establish the pixel diff threshold (recommended: 0.1% for strict, 0.5% for lenient).
- Confirm baseline images exist or plan initial baseline capture.
During
Core Workflow:
- Capture baseline screenshots (the "known good" state).
- Make code changes (feature, refactor, dependency update).
- Capture new screenshots under identical conditions.
- Run pixel diff comparison between baseline and new.
- Review diffs: approve intentional changes, reject regressions.
- Update baselines for approved changes.
Handling Dynamic Content (Critical):
- Timestamps/dates: Mock to a fixed date (
2024-01-15T10:00:00Z). - Avatars/images: Use deterministic placeholder images.
- Animations: Disable CSS animations and transitions during capture.
- Cursor blink: Hide input cursors via CSS override.
- Loading states: Wait for network idle and all images loaded before capture.
- Random content: Seed random generators or use fixed test data.
- Third-party widgets: Hide or mock (chat widgets, analytics banners).
Component-Level Testing (Storybook + Chromatic):
- Every component gets a story with representative states (default, loading, error, empty, overflow).
- Chromatic captures each story as a visual baseline automatically.
- Review changes in Chromatic UI with side-by-side comparison.
- Use
argsanddecoratorsto control component state deterministically. - Group related stories to reduce noise in review.
Page-Level Testing (Playwright/BackstopJS):
- Navigate to page, wait for full render (network idle + specific element visible).
- Capture at multiple viewports for responsive verification.
- Use
page.screenshot({ fullPage: true })for scroll content. - Clip to specific regions when full-page comparison is too noisy.
- Set
maxDiffPixelRatiothreshold in Playwright config.
Diff Thresholds:
- 0.0%: Exact match required. Use only for pixel-perfect components (logos, icons).
- 0.1%: Strict. Catches anti-aliasing differences across OS/browser combos.
- 0.5%: Standard. Tolerates minor rendering engine differences.
- 1.0%: Lenient. Use for pages with slight layout flexibility.
- Above 1%: Likely a real regression — always investigate.
CI Integration:
- Run visual tests on every PR (component-level at minimum).
- Full page-level suite on merge to main or nightly.
- Store baseline images in version control or dedicated storage (LFS for large sets).
- Block merge if unapproved visual diffs exist.
- Provide direct links to diff viewer in PR comments.
Approval Workflow:
- Designer or frontend lead reviews visual diffs before approval.
- Bulk approve when changes are intentional (theme update, design system change).
- Document WHY a visual change was approved (link to design ticket).
- Never auto-approve visual diffs — human review is the point.
After
- All visual diffs are reviewed and explicitly approved or rejected.
- Baselines are updated to reflect the new approved state.
- Dynamic content is fully stabilized (no flaky screenshots).
- Responsive breakpoints are covered (minimum 3 viewport widths).
- CI pipeline gates merge on unapproved visual changes.
Self-check before task completion
- Dynamic content is fully mocked/frozen (no timestamps, no random data in screenshots).
- Screenshots are captured after full render (network idle, fonts loaded, animations disabled).
- Diff threshold is explicitly configured and appropriate for the content type.
- Multiple viewport sizes are tested (mobile, tablet, desktop at minimum).
- Approval workflow is defined (who reviews, how to approve, where to document).
- Baseline images are stored durably and versioned with the code.
- CI blocks deployment on unapproved visual regressions.
- Flakiness is below 1% (re-run same code twice, expect identical screenshots).
Gives 0 of the 12 instructions most e2e browser skills give
Counted across 407 of the 410 authors here whose files we hold, read 2026-08-06
- use page object model patternin 35 of 407, across 25 files
- Snapshot to get element refsin 24 of 407, across 14 files
- keep tests independentin 23 of 407, across 18 files
- Interact using refs from the latest snapshotin 23 of 407, across 11 files
- clean up test data after each testin 21 of 407, across 15 files
- test user behavior not implementationin 20 of 407, across 14 files
- quarantine flaky tests explicitlyin 19 of 407, across 10 files
- wait for specific network conditionsin 18 of 407, across 8 files
- re-snapshot after navigation or dom changesin 17 of 407, across 10 files
- Detect running dev servers before writing test codein 17 of 407, across 7 files
- use web-first assertionsin 17 of 407, across 14 files
- capture screenshots or videos on test failurein 17 of 407, across 14 files
Said here and by no other author read
- determine scope of visual testing
- select visual testing tool
- identify dynamic content to stabilize
- define viewport sizes to capture
- confirm baseline images exist
- capture new screenshots after code changes
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.