Impeccable Catches AI Slop With 62 Rules That Don't Need a Model.

There's a specific look to a page built by a model. You've seen it: Inter for everything, a purple-to-blue gradient on the hero, cards nested inside cards, gray text on a colored background, and a rounded-square icon tile floating above every heading. Paul Bakaus gave that look a name and then wrote a linter for it.

Impeccable is a design skill for coding agents. It picked up about 6,700 stars this week and sits at roughly 91,500 total. The pitch — "the design vocabulary for your coding agent" — undersells the part that's actually unusual, which is that 62 of its checks run as deterministic rules with no model involved.

What it is, concretely

One skill, 24 commands, and a detector. It started as an extension of Anthropic's frontend-design skill and grew into something with its own opinions.

Install is a single command at the project root:

npx impeccable install
/impeccable init

The second step is the one people skip. init interviews you about the product — audience, purpose, constraints, tone — and writes the answers to PRODUCT.md. A separate document command generates DESIGN.md from your existing code. The split matters: product facts and visual system are different artifacts that change on different schedules, and merging them into one file is how design docs go stale.

Then there are the 24 commands. They're a vocabulary more than a workflow:

craft runs the full shape-then-build sequence with visual iteration. critique reviews hierarchy, clarity, and emotional register. audit checks accessibility, performance, and responsiveness. polish aligns to the design system before release. bolder and quieter are directional adjustments — amplify or restrain. harden handles error states, i18n, text overflow, and edge cases. typeset and layout fix the two things most agent-generated UIs get wrong. live opens a browser and generates variants of a named element in place.

You can pin any of them to a standalone shortcut:

/impeccable pin audit

Which creates /audit as a top-level command. Small feature, big difference in whether the vocabulary actually gets used.

The detector is the interesting engineering

Here's what separates Impeccable from the pile of prompt-collection repos: the 62 rules don't need a model, an API key, or an agent.

npx impeccable detect src/
npx impeccable detect index.html
npx impeccable detect --json .
npx impeccable detect --list-rules

That means it runs in CI. A pull request that reintroduces bounce easing, or a stray purple gradient, or a 14px gray-on-teal caption can fail a check without anyone paying for tokens. There's a --github flag that emits GitHub Actions annotations, which is the only integration detail that matters for most teams.

The rule set is opinionated in ways that will annoy people, and the docs are upfront about it. The anti-pattern list bans Arial, Inter, and system defaults; bans pure black and pure gray (always tinted); bans cards wrapped around everything and cards nested in cards; bans bounce and elastic easing as dated; bans gray text on colored backgrounds.

Some of those are defensible craft arguments. Paragraph text with insufficient contrast on a saturated background is an accessibility failure that happens to look cheap. The Inter ban is fashion, and fashion rules age badly — the same document that bans Inter will look like a period piece in three years. But a linter with no opinions is just a formatter, and the point of this one is to have a position.

Because it's deterministic, it's also gameable. Any team that wants to ship the purple gradient can add an inline exemption:

<!-- impeccable-disable overused-font: exported brand doc -->

Or manage ignores globally with npx impeccable ignores add-value overused-font Inter --reason "Brand font". The --reason flag is doing quiet social work: it makes the exception visible in a diff.

How it hooks into the agent

The install path you pick determines how intrusive this gets. For Claude Code, Copilot, Codex, Cursor, and Grok Build, install writes a provider-native hook manifest. In Claude Code that's .claude/settings.local.json, which is gitignored and machine-local. In Copilot it's .github/hooks/impeccable.json, which is committed and shared with cloud agents. In Cursor it's .cursor/hooks.json, firing on postToolUse when a file is written.

The effect is that the detector runs on the agent's own edits and feeds findings back into its loop. That's a meaningfully different mechanism from "run the audit command when you remember to." It catches the slop at the moment of generation rather than at review.

The tradeoff is the usual one: hooks that write to your repo config are hooks that show up in code review, and Codex users have to explicitly approve project hooks via /hooks after install. If your team has strong opinions about committed tool config, the submodule route exists for exactly this reason — git submodule add plus npx impeccable link --source=.impeccable --providers=claude,cursor keeps the tool versioned alongside the code it governs.

What it won't fix

Three limits worth naming.

It can't tell you whether the page is any good. The 62 rules catch surface tells. A page can pass every one and still have no point of view, which is the deeper version of the AI-slop problem and the one no linter has solved.

live mode only works on a local checkout. It won't inject into a production site, HTTPS or otherwise. Reasonable, but it means the visual iteration loop is a development-time tool, not a review tool.

And the vocabulary only helps if the agent reads it. Impeccable's own framing is honest about this: the reason every model produces the same design is that every model was trained on the same SaaS templates. A skill file is a nudge against a training distribution, and nudges lose to distributions more often than anyone would like.

Why not just write a checklist?

Fair question. A style guide in a markdown file costs nothing and does roughly the same job.

The difference is enforcement. A checklist in a prompt is a suggestion; the model reads it, agrees, and then produces a purple gradient because the gradient was in its training data forty thousand times. A deterministic rule fails a build. That's a different category of pressure, and it's the only kind that survives a deadline.

The second difference is granularity. A checklist says "use good typography." Impeccable's typeset command addresses hierarchy, scale, and pairing specifically, and the detector has individual rules for individual failures, which means the feedback loop can point at a line of CSS instead of gesturing at taste. That's the whole argument for tooling over documentation, and it applies here for the same reason it applied to linters twenty years ago.

The third is that the vocabulary is shared. bolder, quieter, distill, harden — these are words a designer and an agent can both act on. "Make it pop" is not.

Why it's trending now

Because the volume problem arrived. A year ago, an agent generated a landing page occasionally. Now a team can generate forty variants before lunch, and the bottleneck has moved from "can we build it" to "can we tell which of these is any good, fast enough."

A deterministic checker for the cheap failures is the only part of that problem that scales. Taste doesn't. Sixty-two regex-shaped rules about fonts and easing do, and shipping them as a thing that runs in CI without a model call is the least glamorous and most useful decision in the repo.