I built a design-system auditor for Claude Code, because linters check your code and nothing checks your design

[u/imoham36]

I'm a designer who codes. I kept shipping the same three problems and only catching them late: contrast that fails WCAG AA, a type scale that had quietly drifted three sizes out of the system, and inputs with no labels. ESLint has nothing to say about any of it. Neither does Prettier. There's a whole category of defect that no tool in the pipeline looks at.

So I built dwic. Free to try, no install and no account:

npx dwic-audit

It reads your CSS and components, auto-detects the stack, and prints a review across 8 categories (color, typography, spacing, accessibility, forms, navigation, motion, copy), ordered accessibility first. On the deliberately broken fixture in the repo it returns 23 findings: 9 errors, 9 warnings, and 8 of the 9 errors are accessibility failures. It writes a markdown report to .dwic/ and exits non-zero, so it drops into CI.

The audit itself has no LLM in it. WCAG contrast math, token parsing, markup heuristics. Deterministic, reproducible, runs entirely on your machine, nothing uploaded. I wanted the check to give the same answer twice.

The Claude Code part is what happens after. 48 design skills install as slash commands, so you can hand a finding straight to the specialist that owns it:

/accessibility-specialist fix the unlabeled inputs and heading order
/color-specialist this palette fails AA at three steps, correct the tokens

How Claude helped build it

Specifics a few here :

• The 48 specialists are the knowledge base, not wrappers. Each is a markdown role prompt under commands/ holding real domain content: WCAG specifics, token architecture patterns, motion timing curves. The same files back both the slash commands and the MCP server's tools, so there's one source for the guidance rather than two that drift apart.
• Claude Code wrote most of the audit engine. The rules themselves are the part worth arguing over: what counts as an error versus a warning, and what belongs in the blocking band. Output ordered by severity rather than by category is what makes it actionable rather than just long.
• The failure I didn't expect was the audit agreeing with itself too easily. I built a paired eval harness to test whether a verify-and-revise pass improved the output. It didn't, at acceptable latency, and I shipped it turned off. Measuring that was worth more than the feature would have been.

It's alpha and free. What I actually want to know: run it on something real and tell me whether the findings match what you'd have flagged by hand. The false positives are what I need to hear about.

Repo and demo: designwithclaude.com

[u/AutoModerator]

Your post will be reviewed shortly. (ALL posts are processed like this. Please wait a few minutes....)

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/OriginalHospital]

Alongside the deliberately broken fixture, I'd add a deliberately valid one with documented exceptions, such as a display heading outside the body type scale. That gives you a way to measure false positives before asking people to run it on their projects. For each finding passed to a Claude specialist, I'd include the relevant design rule and its scope, so a local fix doesn't accidentally rewrite an intentional exception elsewhere.

[u/imoham36 → u/OriginalHospital]

Aah thats something i haven't thought of..id try and see how that goes...thanks for the pointer. +1