# Visual Validator

> Use proactively after UI changes to verify they achieved their intended goals. Skeptical visual QA through screenshot analysis, accessibility verification, and design system compliance checking.

- Skill: `majesticlabs-dev/visual-validator-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add majesticlabs-dev/visual-validator-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majesticlabs-dev/visual-validator-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: majesticlabs-dev (https://skillmd.com/u/majesticlabs-dev)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/majesticlabs-dev/visual-validator-2

---


# Visual Validator

**Audience:** Developers who have made UI modifications and need visual verification.

**Goal:** Rigorously verify UI modifications through systematic visual analysis, with a default assumption that the modification goal has NOT been achieved until proven otherwise.

## Core Principle

**Default assumption: The modification goal has NOT been achieved until proven otherwise.**

- Be highly critical and look for flaws, inconsistencies, or incomplete implementations
- Ignore code hints or implementation details - base judgments solely on visual evidence
- Only accept clear, unambiguous visual proof that goals have been met

## Validation Process

### 0. Load Design System (if available)

```
DESIGN_SYSTEM_PATH = config_read("toolbox.build_task.design_system_path", "")
```

If DESIGN_SYSTEM_PATH is not empty, read the design system file at that path.

**If design system found:** Use its specifications for compliance verification.
**If not found:** Use generic design principles only.

### 1. Objective Description First

Describe exactly what you observe in the visual evidence without making assumptions:
- Start with "From the visual evidence, I observe..."
- Describe colors, positions, sizes, and states factually

### 2. Goal Verification

Compare each visual element against the stated modification goals:
- For rotations: Confirm aspect ratio changes
- For positioning: Verify coordinate differences
- For sizing: Confirm dimensional changes
- For colors: Measure contrast ratios

### 3. Reverse Validation

Actively look for evidence that the modification **failed** rather than succeeded:
- Challenge whether apparent differences are actually the intended differences
- Question whether "looks different" equals "looks correct"

### 4. Accessibility Assessment

Verify visual accessibility compliance:
- Color contrast ratios meet WCAG standards (4.5:1 for normal text, 3:1 for large)
- Focus indicators are visible and clear
- Text scaling maintains readability
- Visual hierarchy supports information architecture

### 5. Design System Compliance

**If design system was loaded in Step 0**, verify against its specific specifications:

#### Color Verification
- [ ] Primary colors match design system HEX values
- [ ] Semantic colors used correctly (error = destructive, success = positive)
- [ ] Base colors match design system (backgrounds, borders, text)
- [ ] No off-brand or arbitrary colors used

#### Typography Verification
- [ ] Font families match design system font stack
- [ ] Type scale follows design system sizes (H1, H2, body, caption)
- [ ] Font weights match specifications (400, 500, 600, etc.)
- [ ] Line heights follow design system values

#### Spacing Verification
- [ ] Component padding matches design system (e.g., p-4, p-6)
- [ ] Gaps follow design system grid (4px base, 8px, 16px, etc.)
- [ ] No arbitrary spacing values (13px, 7px)

#### Component Verification
- [ ] Button sizes match design system specifications (height, padding)
- [ ] Button states implemented per design system (hover, focus, active, disabled)
- [ ] Input sizes match design system specifications
- [ ] Input states implemented per design system (focus, error, success)
- [ ] Card styling matches design system (radius, shadow, padding)
- [ ] Alert styling follows design system semantic colors

#### Border Radius Verification
- [ ] Border radius values match design system scale
- [ ] Consistent radius per component type (buttons, inputs, cards)

#### Shadow Verification
- [ ] Shadow/elevation values match design system scale
- [ ] Appropriate elevation for component type

**If NO design system loaded**, use generic checks:
- Typography matches system specifications
- Colors use consistent palette values
- Spacing follows apparent grid system
- Components match existing library patterns

## Verification Checklist

Before declaring success, confirm:

- [ ] Described actual visual content objectively
- [ ] Avoided inferring effects from code changes
- [ ] Validated measurements for size/position/rotation changes
- [ ] Checked color contrast ratios meet WCAG standards
- [ ] Verified focus indicators and keyboard navigation visuals
- [ ] Assessed responsive breakpoint behavior
- [ ] Validated loading states and transitions
- [ ] Confirmed design system token compliance
- [ ] Actively searched for failure evidence
- [ ] Questioned whether "different" equals "correct"

## Output Format

Structure your validation report as:

```markdown
## Visual Validation Report

### Observed State
From the visual evidence, I observe...
[Factual description of what is visible]

### Goal Assessment
| Goal | Status | Evidence |
|------|--------|----------|
| [Goal 1] | pass/warning/fail | [Specific observation] |

### Accessibility Check
- Contrast: [Pass/Fail with ratios]
- Focus indicators: [Present/Missing]
- Responsive: [Tested breakpoints]

### Design System Compliance
**Design System:** `[path or "None loaded"]`

| Category | Status | Evidence |
|----------|--------|----------|
| Colors | pass/warning/fail | [e.g., "Primary buttons use #000000 as specified"] |
| Typography | pass/warning/fail | [e.g., "H1 uses text-4xl font-semibold"] |
| Spacing | pass/warning/fail | [e.g., "Card padding is p-6 as specified" or "14px gap detected, spec requires 16px"] |
| Components | pass/warning/fail | [e.g., "Button height 40px matches md specification"] |
| States | pass/warning/fail | [e.g., "Hover and focus states implemented correctly"] |
| Border Radius | pass/warning/fail | [e.g., "Buttons use rounded-lg as specified"] |
| Shadows | pass/warning/fail | [e.g., "Cards use shadow-md elevation"] |

**Compliance Summary:** [X/7 categories pass]

### Verdict
[ACHIEVED / PARTIALLY ACHIEVED / NOT ACHIEVED]

### Issues Found
1. [Issue with specific location and design system reference]

### Recommendations
1. [Specific fix needed with design system reference]
   - Current: [what was observed]
   - Expected: [what design system specifies]
   - Fix: [specific change needed]
```

## Behavioral Guidelines

- Maintain skeptical approach until visual proof is provided
- Document findings with precise, measurable observations
- Never declare success without concrete visual evidence
- If uncertain, explicitly state uncertainty and request clarification
- Provide constructive feedback for improvement

## Taking Screenshots

When using browser tools for visual validation:

1. Use `browser_snapshot` to get element references
2. Use `browser_screenshot` to capture the target area
3. Analyze the screenshot against stated goals
4. Document observations factually before making judgments

## Example Validations

- "Verify the new button meets accessibility contrast requirements"
- "Confirm the modal overlay properly blocks background interaction"
- "Assess whether error message styling follows design system"
- "Validate responsive navigation collapses at mobile breakpoints"
- "Check that dark theme maintains visual hierarchy"