Impeccable Skill by Paul Bakaus

We read the skill at commit f88b283 of pbakaus/impeccable. A sourcing note: this skill ships its SKILL.md into seventeen runtime directories, sixteen of them dot-prefixed, and our catalog's bundle holds 64 of the repository's files without the SKILL.md itself, so the walkthrough quotes the repository directly.

impeccable at a glance

1. It gives the agent permission, not just instructions, opening with a mandate to stop hedging.
2. It caps its own perfectionism, banning the open-ended self-QA loop that burns your money.
3. Twenty-three commands route to twenty-three playbooks, loaded one at a time.
4. Mode is chosen by surface, not by product, which is the distinction most design prompts miss.
5. The brief outranks the skill's own taste, stated as a failure condition.
6. A licensed rebrand of it out-installs it, declared inside its own bundle and invisible on both listing pages.

1. It gives the agent permission, not just instructions

Most design skills are rule lists. This one opens by changing the agent's self-image:

This skill gives you the tools and permission to create design that earns to be called out-of-distribution craft: Whereas before, your design work would have been safe, timid and measured, you now approach every design task as a award-winning design director

Source: SKILL.md, opening

"Safe, timid and measured" is an accurate diagnosis of default model output, and the fix here is a role rather than a checklist. The first core principle follows through: "Go all out. No hedging, no shortcuts."

2. It caps its own perfectionism

The third core principle is the one we would keep if we could keep only one, because it is the rule nobody writes:

Verify in bounded passes, not a loop [...] Build fully, inspect once with a batched round (desktop and mobile together on the web; the shipped device classes on a native platform), fix everything it shows in one batch, confirm with at most one more round, and stop polishing. Open-ended self-QA burns the user's money doing worse what the finish handoffs do better.

Source: SKILL.md, core principles

A skill that tells the agent to be maximally ambitious has to also tell it when to stop, or you pay for twenty screenshot rounds of diminishing returns. Naming the user's money in the file is the sort of thing you write after watching a bill.

3. Twenty-three commands route to twenty-three playbooks

The heart of the file is a command table: shape, critique, audit, polish, bolder, quieter, distill, harden, onboard, animate, colorize, typeset, layout, delight, overdrive, clarify, adapt, optimize, live, plus init, document, extract and a deprecated craft. Each row points at its own reference file, and the routing rule keeps the load small:

Explicit or clearly implied command: load its reference (native variant on native platforms) and follow it. Ask once if two commands fit.

Source: SKILL.md, "Routing"

Thin index, deep references, one playbook per task: the same architecture we found in vercel-react-best-practices and microsoft-foundry, applied to design verbs. The vocabulary is the product here. "Make it bolder" and "make it quieter" are things people actually say, and each one now has a documented procedure behind it.

4. Mode is chosen by surface, not by product

Four modes, defined by what success looks like for the visitor: Persuade, Operate, Read, Experience. The instruction that makes them work is the one about scope:

Choose the mode from the requested surface, not the product, and persist it only in that surface brief. A tool's landing page is still Persuade; a fashion house's documentation is still Read; a docs index is Read, not Persuade.

Source: SKILL.md, "Modes"

Every generic design prompt gets this wrong by inheriting the company's vibe onto every page it touches. Two examples in one sentence settle it, and the "docs index is Read, not Persuade" clause pre-empts the exact mistake an eager agent makes on a documentation homepage.

5. The brief outranks the skill's own taste

For a skill this opinionated, the deference rule matters more than the opinions:

The brief wins. Honor pinned aesthetics, eras, materials, fonts, and palettes even when they conflict with a saturated-pattern warning. Redirecting a clear brief toward your taste is failure.

Source: SKILL.md, "How to design"

Calling it "failure" rather than "discouraged" is deliberate. An agent primed to act like an award-winning director is exactly the agent most likely to override a client, and this line is the leash. The neighbouring rule draws the other hard line: refinement preserves the incumbent identity, redesign replaces it, and you never "split the difference into polish on the discarded look."

6. A licensed rebrand of it out-installs it

Here is the part you cannot see from either listing page. The skill anti-ui-slop, published under the domain uizze.com, is impeccable's playbook library under a different name. It carried 370,344 installs to impeccable's 238,573 when we checked (Skillselion catalog, August 20, 2026).

The derivation is not something we inferred. uizze declares it, in its own bundled MODIFICATIONS.md:

The Uizze skill contains renamed and product-integrated modifications of the design stack pinned at version 4.1.1, commit 5a149f3fdb1b5793f10567233b1dcab98fc305fd.

Source: anti-ui-slop MODIFICATIONS.md, shipped in the skill bundle, verified 2026-08-20

That pinned commit resolves in pbakaus/impeccable to a commit titled "Release: skill v4.1.1", and impeccable's own frontmatter reads version: 4.1.1. Direction is settled by dates too: the impeccable repository was created in November 2025, roughly nine months before the release uizze pins.

The bundled MANIFEST.json says the same in machine-readable form:

"designStack": { "version": "4.1.1", "commit": "5a149f3fdb1b5793f10567233b1dcab98fc305fd", "license": "Apache-2.0" }

Source: anti-ui-slop MANIFEST.json, shipped in the skill bundle, verified 2026-08-20

We then compared the bundles file by file, matching on exact relative path against the skill/ tree at that commit, which is the tree uizze forked. Of the 126 files uizze's manifest lists, 121 exist there at the same path. The remaining five are one-for-one renames of impeccable-prefixed filenames, keeping the extension each had upstream: four agent definitions under agents/, plus scripts/lib/uizze-paths.mjs, which is a script library rather than an agent definition. Across the 72 files our catalog now holds for both, median similarity is 99.64% and 56 are at least 99% identical. The representative case is reference/adapt.md: 312 lines on each side, with exactly one line differing. It is line 191, and the three copies read differently: the skill/ source leaves an unresolved command_prefix template in double braces ahead of impeccable polish, the built copy under plugin/ renders it as /impeccable polish, and uizze ships /uizze polish.

The front door is the real exception. uizze's own SKILL.md is substantially rewritten rather than renamed, carrying its own product policy and no Bash tooling, so "renamed" describes the playbook library behind it, not the entry point.

And the compliance is careful, more so than the word "rebrand" usually implies. The bundle ships four artifacts for it: the Apache 2.0 licence with "Copyright 2025 Paul Bakaus" intact, impeccable's own third-party NOTICE passed through unaltered, whose subject is ehmo's MIT-licensed platform-design-skills and in which "Impeccable" appears once, in a subordinate clause, the modifications notice quoted above, and a CHECKSUMS.sha256 hashing every file. Apache 2.0 permits redistribution, modification and rebranding provided the notices travel, and here they travel with room to spare. This is a lawful, attributed redistribution, and calling it theft would be wrong.

What is worth your attention is narrower. All four artifacts sit inside the downloaded bundle, where someone browsing a listing never goes, and neither product's page mentions the other. So the practical situation is simple: the rebrand out-installs the original in our catalog, the playbooks are the same, and if you already run one, installing the other buys a second copy of what you have.

Tools it drives: its own bundled scripts via npx impeccable and node .claude/skills/impeccable/scripts/*, scoped in frontmatter, including a context loader, a pin helper, and an optional post-edit design detector hook.

Behavior change, before and after:

The fine print worth knowing:

• It runs a setup script once per session and loads a craft-floor reference before editing UI. That is real context and one shell call before any design work starts.
• Seventeen copies of the SKILL.md ship in the repo, one per agent runtime. Convenient for compatibility, and a reason to check which copy your tool actually loaded.

Should you install impeccable?

Install it if you want an agent that argues for a point of view instead of averaging toward the middle, and the command vocabulary alone is worth it: "bolder", "quieter", "distill" and "harden" turn vague design feedback into routed procedures. Skip it if you need a fast, minimal pass on an existing look, since the setup and craft-floor loads assume real design work is about to happen. And check what you already have installed first, because you may be running a copy of it under another name.

npx skills add https://github.com/pbakaus/impeccable --skill impeccable