Check design parity figma

Skill southleft/skills-for-figma/skills/check-design-parity-figma

Compare a Figma node's actual specs against a code spec (the values your component renders) and get a 0–100 parity score, a list of discrepancies, and fix suggestions. Use to detect design-to-code DRIFT: triggers 'check design parity', 'does my code match the Figma', 'compare this component to the design', 'is my implementation faithful', 'find differences between design and code', 'verify the build matches Figma', 'design QA against code', 'parity score'. Reads the node's visual / typography / spacing / token / accessibility specs via use_figma (any plan) and diffs them against a codeSpec you provide. Complements the native get_design_context: instead of GENERATING code, it VALIDATES that existing code stayed in sync with the design.From its SKILL.md

Install

npx -y skills add southleft/skills-for-figma --skill check-design-parity-figma

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

12 stars12 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.
runs commandsInstructs the agent to run 1 command, including `scan-code-accessibility-figma --map-to-codespec`.

SKILL.md

3.9 KB, 818 tokens by cl100k_base, as published. Nobody here has run it

check-design-parity-figma — design vs code drift checker

Pull a Figma node's real specs and diff them against a codeSpec (what your implementation actually renders). Returns a weighted parity score, per-property discrepancies with severity, and suggested fixes. This is the inverse of code generation: get_design_context turns a design into code; this skill confirms the code didn't drift away from the design.

All design reads go through use_figma, so it works on any Figma plan.

Skill boundaries

use_figma rules — load the official figma-use skill first; it is the full Figma Plugin API reference. Essentials these scripts rely on: plain JS with top-level await + return (no IIFE, no figma.closePlugin(); console.log is not returned), inputs inlined as const at the top of each script, colors in 0–1 range, load fonts before any text op, await figma.getNodeByIdAsync(...), and atomic errors (a failed script applies nothing — read the error, fix, retry).
Generating code from a design → that's the native get_design_context; this skill validates, not generates.
CODE-side a11y to feed codeSpec.accessibility → use scan-code-accessibility-figma (--map-to-codespec emits exactly that object).
Design-side WCAG lint → use lint-design-figma.

Workflow

Assemble the codeSpec. Gather the values your component renders into the codeSpec object (references/parity-scoring.md has the full shape). You only need to fill the sections you want compared — visual, spacing, typography, accessibility. Tip: scan-code-accessibility-figma --map-to-codespec builds codeSpec.accessibility automatically.
Read the design specs. Set NODE_ID and paste your codeSpec into scripts/check-parity.js. Run it via use_figma (skillNames: "check-design-parity-figma"). It extracts the node's fills, strokes, corner radius, opacity, padding/gap, and text properties, then diffs them against the codeSpec.
Read the scorecard. summary.parityScore is max(0, 100 − (critical×15 + major×8 + minor×3 + info×1)). discrepancies[] lists each mismatch with category, property, severity, designValue, codeValue, and a suggestion.
Decide which side to fix. Each discrepancy says what design has vs what code has. Update code to match the design, or push the design to match an intentional code change (via manage-variables-figma / figma-use), then re-run to confirm the score rose.

Key rules

Colors are 0–1 in Figma; the script converts to hex and normalizes both sides before comparing.
Only filled codeSpec sections are compared. Omit a section to skip it — no false positives for data you didn't provide.
Numeric tolerance: dimensions compare with a small epsilon (≈2px for width/height, 0.01 for opacity) so sub-pixel rounding doesn't register as drift.
Severity drives the score: color/spacing mismatches are major (−8), radius/border-width/opacity are minor (−3). See parity-scoring.md for the full weighting.

What ships with it: 2 files

17.8 KB alongside SKILL.md, 1 of them executable

references/

parity-scoring.md4.6 KB

scripts/

check-parity.jsruns13.2 KB

Gives 0 of the 12 instructions most quality gates skills give in 818 tokens

Counted across 1,524 of the 2,830 authors here whose files we hold, read 2026-09-06

Read full output and check exit codein 45 of 1524, across 40 files
Verify output confirms the claimin 44 of 1524, across 39 files
Identify the command that proves the claimin 43 of 1524, across 39 files
Execute the full verification commandin 36 of 1524, across 30 files
Produce a verification reportin 34 of 1524, across 18 files
Review git diff changesin 30 of 1524, across 16 files
Fix build failures immediatelyin 29 of 1524, across 9 files
Group findings by severityin 28 of 1524
State claim only with evidencein 27 of 1524, across 22 files
Verify regression tests with red-green cyclein 26 of 1524, across 22 files
Run the full test suitein 26 of 1524, across 25 files
Run test suite with coveragein 25 of 1524, across 10 files

Said here and by no other author read

load the figma-use skill first
assemble the codeSpec object with rendered values
set NODE_ID and codeSpec in the parity script
run the parity script via use_figma
update code or design based on discrepancies
use scan-code-accessibility-figma to build accessibility specs

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.