A design skill is only worth reviewing if you let it hurt you, so I ran the Impeccable skill's critique against my own site, the one with my name on the domain, and it scored me 25 out of 40. One point below its own threshold for borderline AI slop. Three of the five issues it flagged were decisions I had personally defended in past design passes. That sting is the review: Impeccable is the rare Claude Code skill whose value is that it disagrees with you, specifically and correctly, about work you have stopped being able to see.
I have kept it loaded ever since, and it earned a real role in the token-driven redesign I later shipped across this blog. Here is what the skill actually is, what it caught on my site, where its alpha edges are, and the one lesson about making its findings permanent that I have not seen anyone else write down.
What Impeccable actually is
The pbakaus/impeccable project, by Paul Bakaus, is at its core a folder of markdown that loads into your AI coding tool's context and changes how the model thinks about front-end work. It ships as one skill with 23 commands and a set of domain reference files covering typography, color, spatial design, responsiveness, interactions, motion, and UX writing, plus a curated list of explicit anti-patterns. It works in Claude Code and the other major AI harnesses, and installation is two steps:
npx impeccable install
then, inside your coding agent, /impeccable init. There is a companion site at impeccable.style with docs and galleries, but the core value is the skill files; everything else is optional.
The accurate one-line description: it is a vocabulary upgrade. Anthropic's built-in frontend-design skill gives Claude general design direction. Impeccable gives it operative words, quieter, bolder, distill, polish, each a command with documented visual meaning. Models can describe design ("16px, 1.5 line height") but are weak at directing it ("make this section quieter so the CTA earns the eye"). Impeccable installs the direction layer, and that is the actual innovation.
Why AI front-ends all look the same, and what this does about it
The anti-pattern list is the part that made me put the post down and stare at my own site. Explicit do-not rules: no gray text on colored backgrounds, no cyan-on-dark AI palette, no purple-to-blue gradient defaults, no pure black or pure white without tinting, no loading three font families to use two, no primary CTA buried in a card that matches the section behind it.
I had shipped nearly every one of those in the preceding six months. Not from ignorance, from defaults: when you tell a model "build a hero section" at 11 PM, it produces the statistical center of every hero section in its training data, and the public internet's statistical center is precisely the look those rules ban. Most anti-slop tooling tries to detect that output after generation. Impeccable's approach is better: it changes what gets generated by pinning opinionated constraints into context before the model writes a line. Editing the distribution beats editing the draft.
Even if you never run a single command, having those rules resident in your Claude Code context measurably changes output. That alone justifies the install.
What it caught on my site
I ran impeccable document first, which reverse-engineers a design description from the codebase as it actually is, not as you remember it. Then the critique. The 25/40 came with five specific findings:
- Competing emphasis above the fold. Three visual elements fighting for first attention on the home page. I had called this "rich" in my own head; the critique called it scattered, and it was right.
- Weak hierarchy on the blog index. Insufficient size contrast between post titles and their metadata. Custom CSS I was proud of, which is exactly why I had not questioned it.
- Ambiguous CTAs. Three header buttons with no clear primary. Recommendation: demote two to text links.
- Decorative backdrop-blur. Glassmorphism on cards with no functional reason, which read as modern in 2022 and reads as template now.
- A loaded, unused font family. A leftover from a previous iteration, costing page weight and coherence for nothing.
I fixed the two that mattered most, the fold and the CTAs, re-ran the critique, and landed at 32/40. The score is not the point; the point is that every finding came with reasoning I could check, and checking it kept proving the skill right. I have watched the same categories of findings repeat on other codebases I have pointed it at since: decorative mockup imagery in heroes, unused fonts, CTAs of equal weight. If an outside reviewer looked at your site today, those are the likeliest first three notes.
The lesson from a real redesign: findings only stick as tokens
Here is the insight I earned using Impeccable during actual production work rather than a demo. When I later rebuilt this blog's surfaces, the redesign's core move was making everything token-driven: color, type, spacing decisions defined once and consumed everywhere. Impeccable ran during that work as the critique layer, and the combination taught me something about the skill that its own docs do not say.
An Impeccable finding fixed as a page patch is temporary. Fix "insufficient title contrast" by editing one template, and the next generated page reintroduces the drift, because the model's defaults have not changed and neither has your system. Fix it by changing the type-scale token that every surface consumes, and the finding is dead permanently, including on pages that do not exist yet.
So my rule now: critique findings get triaged into token changes versus template changes, and token changes win whenever possible. The skill tells you what is wrong; your design system decides whether it stays fixed. Running one without the other is why people re-fix the same issues quarterly. This pairs naturally with the codebase-native direction design tooling is heading, where shipped code is the source of truth; my Claude Design review covers that same principle from the generation side, and Impeccable is the audit I run after that handoff lands.
The commands worth knowing beyond the famous ones
craft and critique get the attention. Two quieter ones changed how I work:
Discipline before delight. The skill's decoration-audit pass evaluates every shadow, gradient, border, and flourish against one question: does this earn its place? Output is routinely a third leaner and reads dramatically more confident. Its counterpart adds personality back afterward, but only in functional moments, an empty state with character, a hover that means something. The ordering is the craft: strip first, then add character. Reverse it and the personality drowns in noise; skip the second step and the result is competent but cold.
The interview matters more than the generation. Starting a greenfield project through the skill's setup interview produces two files, a strategic one (audience, voice, anti-references) and a visual one (tokens, rules, do-nots), and every subsequent generation reads them as context. The smartest question in the interview asks what you do not want to look like. Forced differentiation, baked in before any pixel exists. Once those files live in the repo, you are extending a documented system instead of re-rolling the dice per prompt.
One practical warning that applies to both: the skill's constraint set leans on modernist, Western design conventions, restraint, space, quiet color. For most product work that is the correct bias. If your project deliberately needs maximalism or a different visual tradition, expect to override it, and know that overriding is allowed.
Honest limits
Live browser iteration is the skill's alpha edge, and it behaves like alpha software: sessions occasionally need restarting, element selection gets finicky in deeply nested DOMs, and I once had an accepted change land in the wrong file of a monorepo. Treat that mode as a sketch tool, commit often, and it is genuinely fun; treat it as finished and it will frustrate you.
The steadier cost is context. Loading the full command set and reference files consumes a real slice of a Claude Code session's context window, so I load Impeccable for design-focused sessions and leave it out of refactor sessions. Skills are lego, not furniture; my rundown of which Claude Code skills earn a permanent slot covers how I ration that budget, and if you are curious what building one of these well takes, the lessons from building my own skills apply doubly to one this opinionated.
Whether it earns a slot
Run the honest version of my test. Point the skill at something you built and read the critique without defending yourself. It takes an hour the first time and about ten minutes forever after, and the second-order effect is the real payoff: the vocabulary transfers. After a few weeks of quieter, distill, and decoration audits, you start writing better front-end prompts, and better front-ends, with the skill unloaded. A tool that trains its user is a different class of tool.
Impeccable now loads second in every design session I run, right after my own agent definitions. Go look at what loads first: my skills for design workflows, content systems, and Laravel work are published in the agent skills marketplace, written to sit alongside an opinionated third-party skill like this one rather than compete with it.
