Skill

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.

From majestic-engineer
Install
1
Run in your terminal
$
npx claudepluginhub majesticlabs-dev/majestic-marketplace --plugin majestic-engineer
Tool Access

This skill is limited to using the following tools:

Read Grep Glob Bash
Skill Content

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 = /majestic:config 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:

## 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"
Stats
Parent Repo Stars30
Parent Repo Forks6
Last CommitMar 15, 2026