design-parity-judge

Measure live UI renders against defined parity gates using DOM metrics.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/Scripsteam/scrips-stack --skill design-parity-judge
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: design-parity-judge
Source: https://github.com/Scripsteam/scrips-stack/tree/main/design-parity-judge
Command: npx skills add https://github.com/Scripsteam/scrips-stack --skill design-parity-judge

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Measures live UI renders against defined parity gates to prevent eyeballed judgments. A render passing is not a guarantee of design parity; this judge mechanically assesses the live DOM (getComputedStyle / getBoundingClientRect) against a Signal DS-calibrated craft checklist and reports a measurable parity verdict.

Core Features & Use Cases

  • Grounded in Signal DS tokens and contracts to align visual parity with the design source.
  • Measures live renders from Storybook stories, preview servers, or browser views, producing gate-by-gate scores.
  • Provides a formal parity verdict before claiming a UI is "done" or "at parity" and pairs with anti-fiction/operational checks like design-judge.

Quick Start

Run after rendering a Storybook story or preview to obtain gate scores and a parity verdict.

Frequently Asked Questions about design-parity-judge

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify UI parity between a live render and my design tokens?

To verify UI parity, measure live DOM renders against defined parity gates using getComputedStyle and getBoundingClientRect. This replaces eyeballed judgments by applying a Signal DS-calibrated checklist to produce a gate-by-gate score and an actionable parity verdict.

What is the best way to automate visual testing for Storybook stories?

Automate visual testing for Storybook stories by running a parity judge after rendering. It mechanically assesses the live DOM against token-based design state contracts, generating measurable gate scores and a formal parity verdict before claiming the UI is done.

Does design parity measurement work with preview deployments or only local Storybook?

Design parity measurement works with both preview deployments and local Storybook stories. It applies after rendering any in-browser view to verify visual parity during design handoffs, port validation, and UI polishing by reading live DOM measurements.

Why does my frontend pass visual review but still fail design handoff checks?

Your frontend may fail design handoff checks because visual review relies on eyeballed judgments rather than measured gates. Using a parity judge applies a craft checklist to live DOM styles and dimensions, producing a formal verdict that confirms true design alignment.

When should I not use eyeballed judgments for UI polishing?

You should not rely on eyeballed judgments for UI polishing when a render passing visually is not a guarantee of design parity. Instead, mechanically assess live renders against defined parity gates to obtain a measurable, actionable verdict grounded in Signal DS tokens.