How dwic works.

Why it matters

Design review on every run, not every launch.

Linters check your code. Type checkers check your types. Nothing checks your design system, so contrast failures, a type scale that drifted three sizes off, and unlabeled inputs ship quietly. Someone catches them weeks later, by eye, if at all.

dwic turns that review into a command. It runs in seconds, returns the same answer every time, and fits in CI. So checking your design system stops being a thing a senior designer does occasionally and becomes a thing that happens on every change.

The engine

A deterministic design review.

Under the hood, dwic reads your CSS and components and runs eight category checks: WCAG contrast math, design-token parsing, and markup heuristics. There is no LLM in this step and nothing leaves your machine, so the result is fast, private, and reproducible: the same project always returns the same findings.

On every run

One dashboard, a report, an exit code.

Each run prints a triage dashboard, writes a shareable markdown report to .dwic/ so it’s reviewable in a pull request, and exits non-zero when there are errors, which is all CI needs to fail a build on design-system drift.

Inside Claude Code

The senior designer that fixes it.

Install the MCP server and the same engine runs inside Claude Code. When you ask a specialist (color-specialist, accessibility-specialist, or any of the others), dwic runs the deterministic checks to find the facts, then Claude reasons over those findings to explain them and apply specific fixes. The engine finds what’s wrong; Claude fixes it.

Memory

It remembers your project.

The first time you call a specialist in a new project, dwic asks a few questions (what you’re building, your stack, your design system) and stores the answers. After that, every call carries that profile plus your most recent specialist decisions, so the designer builds on what you’ve already chosen instead of re-interrogating you each session.

That’s the difference between a one-off prompt and a designer who knows your project: continuity, without you re-explaining it.

Honest boundaries

What dwic doesn’t do.

A senior designer is most useful when you know exactly what they will and won’t weigh in on. So, plainly:

• It checks structure, not taste. dwic won't tell you whether your design is good. It tells you where it breaks its own rules.
• It's a rules engine, not a guesser. The audit is deterministic math and parsing, so it never hallucinates a finding, but it only catches what the rules cover.
• It won't redesign for you. The CLI reports; the fixes happen when you ask a specialist in Claude Code, with you in the loop.
• It remembers your decisions, not your whole codebase. Memory is your project profile plus your recent specialist calls, not a semantic index of every file.

One brain, two surfaces

The expertise is open.

dwic isn’t a black box. Each specialist’s knowledge lives in a plain markdown role prompt, and those prompts are the free, open design skill library. When you ask dwic’s color-specialist inside Claude Code, its expertise comes from the exact same file the free /color-specialist slash command loads.

dwic wires twelve of those specialists as MCP tools and adds what plain prompts can’t: a deterministic audit engine, project memory, and the one-line CLI. The rest of the library is free to drop into Claude Code as slash commands today.

Going deeper

Where to read next.