I built a CLI that catches design inconsistencies — like Lighthouse, but for your design system

Published: (March 3, 2026 at 01:31 PM EST)
2 min read
Source: Dev.to

Source: Dev.to

You run Lighthouse to catch performance issues. You run axe to catch accessibility issues. But what catches the moment your site ends up with 54 shades of blue and 22 different line‑heights?

I built design-auditor for exactly that.

The problem

You’re three sprints in. The designer is happy. The client is happy. Then someone opens the site on a large monitor and notices the buttons have four different border‑radiuses. The headings are using six font sizes that don’t follow any scale. There are at least five “grays” that are almost — but not quite — the same.

None of this breaks anything. Linters don’t catch it. Lighthouse doesn’t catch it. PR reviewers miss it because it lives in computed styles, not source code.

This is design drift. And it’s invisible until it isn’t.

What design-auditor does

It opens your URL in a real browser (via Playwright), reads every element’s computed styles, and runs them through a set of design‑system rules.

npx design-auditor https://yoursite.com

No config. No installation. One command.

design-auditor usage preview

What it checks

🔤 Typography

  • How many font families are actually in use (recommended: ≤ 3)
  • Whether font sizes follow a modular scale
  • Line‑height consistency — does your site have a baseline grid, or chaos?

🎨 Colors

  • Total unique colors across the page
  • Perceptual color clustering using ΔE (CIE76) — catches #f0f6fc and #f6f8fa as “basically the same color”
  • WCAG AA contrast validation for every text/background pair
  • Whether colors are tokenized in CSS variables or hard‑coded everywhere

📐 Spacing

  • Detects your rhythm unit (font-size × line-height)
  • Checks if spacing follows a 4 px or 8 px grid
  • Flags outliers like 13px, 17px, 22px — the “magic numbers” that creep in

🧩 Components

  • Touch‑target sizes (WCAG 2.5.5 minimum: 44 × 44 px)
  • Button padding variations — are you using sm/md/lg or 11 random sizes?
  • Border‑radius consistency
  • Z‑index organization

Real output example

────────────────────────────────────────────────────────────
  TYPOGRAPHY
────────────────────────────────────────────────────────────
  ✅ Font families: 2 — OK
  ⚠️  Font sizes: 11 unique — recommended ≤ 8
  ❌ Line-heights: 22 unique — no vertical rhythm detected

  COLORS
────────────────────────────────────────────────────────────
  ❌ 54 unique colors found — recommended   
Website: 

I’m actively developing this — feedback on what checks would be most useful to you is very welcome. What design inconsistencies do you find hardest to catch in code review?
0 views
Back to Blog

Related posts

Read more »

LazyLogcat is available in Homebrew now

Android Studio's Logcat panel is great, but I don't want to use the IDE when I need access to logs only. So I built lazylogcat — a keyboard‑driven terminal UI f...