Impeccable: design rules for AI coding agents, run without an LLM

The problem Impeccable targets: the same five visual tells on every project

Models trained on the same SaaS templates converge. The README names the symptoms directly: Inter for everything, purple-to-blue gradients, cards nested in cards, gray text on colored backgrounds, and the rounded-square icon tile above every heading. Those are not bugs in any single generation. They are the default output of a model with no design context, repeated across a codebase until the product looks like everything else.

Impeccable is aimed at people who generate frontend code with an AI coding agent and want to steer the result. The README credits Anthropic's frontend-design skill as the starting point and says Impeccable started from there. The audience is narrow on purpose: you need a supported harness such as Cursor, Claude Code, Gemini CLI, Codex CLI or Grok Build, because the product ships as commands your agent invokes, not as a standalone design tool.

Two layers: a skill your agent reads, and a Rust engine that checks the output

The repository splits into a skill layer and an engine. The skill layer lives under skill/ and is installed into harness folders such as ~/.claude, ~/.codex, ~/.grok or a project-local .cursor. It is what makes /impeccable init, /impeccable audit and the other commands available inside your agent.

The engine is a Cargo workspace at the repository root. Cargo.toml describes it as "the impeccable runtime: one Cargo workspace next to the skill it powers," and notes that cargo build --release -p impeccable produces the engine binary the launcher (skill/scripts/impeccable) runs. The crates are split by concern: impeccable-detect, impeccable-html, impeccable-browser, impeccable-live, impeccable-context, impeccable-hook, impeccable-bundle and others. That structure is the reason the CLI and browser extension can run the 61 deterministic detector rules with no LLM and no API key, while critique-style checks stay with the model.

The data flow follows from that split. Your agent reads PRODUCT.md and DESIGN.md, which /impeccable init writes, and uses them as context when generating or revising UI. The deterministic rules then run over the resulting markup independently, so a rule either fires or it does not, regardless of which model produced the code.

Installing Impeccable and running a first audit

The README gives the CLI installer as the recommended path. Run it from the root of the project you want to affect. It detects harness folders, lets you keep or customize the provider set, and then asks whether to install into the current project or globally.

npx impeccable install

In scripts you can skip both prompts. The README documents the flags as --providers and --scope, with scope accepting project or global.

npx impeccable install --providers=claude,codex,cursor,grok --scope=project

After installing, reload your harness. The first real step is the setup command, which the README says asks whether the surface is brand (marketing, landing, portfolio) or product (app UI, dashboard, tool), then writes design context that later commands read. It writes PRODUCT.md and offers DESIGN.md.

/impeccable init

With that context in place, a command like audit takes a named target and runs the technical quality checks (accessibility, performance, responsive). The README's own examples use page names such as blog or landing.

/impeccable audit blog

To refresh an existing install later, the README documents npx impeccable update. Codex users should open /hooks after an install or update and approve the project hook when prompted, because Codex tracks trust by hook definition and a changed .codex/hooks.json can require approval again. Grok Build users need project folder trust through /hooks-trust or by launching with --trust before .grok/hooks/ scripts run.

The 23 commands are a vocabulary, not a pipeline

The command list is the part most likely to be misread. craft, shape, critique, audit, polish, bolder, quieter, distill, harden, onboard, animate, colorize, typeset, layout, delight, overdrive, clarify, adapt, optimize and live are separate entry points, and the README does not present them as an ordered sequence. You pick the one that matches the problem in front of you: bolder amplifies a design that reads as boring, quieter tones down one that overshoots, harden covers error handling, i18n, text overflow and edge cases.

That design has a cost. There is no documented dependency graph, so nothing tells you that running polish before typeset is wasted effort or that distill will undo colorize. The shared vocabulary is the value: when you and the agent both know what quieter means, the instruction stops being a paragraph of prose. The README also documents /impeccable pin <command>, which creates a standalone shortcut such as /audit.

The live command is the other structural piece. The README describes it as a visual variant mode for iterating on elements in the browser, and the repository carries a browser-bundle/ directory and an extension/ directory alongside the CLI, which is consistent with a browser-side path for the same rules.

Where Impeccable gets in the way

The install model is the first constraint. Impeccable writes into harness folders and, on Claude Code, Cursor, Codex, GitHub Copilot and Grok Build, installs a provider-native hook manifest for the current project. Hooks execute inside your editor, and Codex and Grok Build both gate them behind explicit trust approval. Teams with locked-down development environments, or anyone unwilling to approve a project hook, lose part of the product.

The Node requirement is explicit in package.json: engines sets node to >=22.18.0. That is a recent runtime, and a project pinned to an older Node cannot use the npx path at all. The git submodule route exists for that reason, but it is more work: you add the repository as .impeccable, run npx impeccable link with --source and --providers, and commit .gitmodules along with the linked harness folders. The README notes that link leaves existing real skill directories untouched unless you pass --force, which is safer but also means a stale skill folder will silently win.

Finally, the deterministic layer is a rule engine. It can catch a nested card or a gray-on-color text pair, but the README's own framing separates those 61 rules from the LLM-only critique checks. If your problem is that a layout is conceptually wrong rather than rule-violating, the no-LLM path will not find it.

How it differs from Anthropic's frontend-design skill

Anthropic's frontend-design skill is a prompt-level artifact: a set of instructions the model reads. Impeccable began from that skill, and the difference is what got added around it. The first addition is persistent project context. /impeccable init writes PRODUCT.md and DESIGN.md so later commands know the audience, brand or product lane, voice, anti-references, colors, type and components, instead of re-deriving taste from scratch on each run.

The second addition is the detector. The CLI and browser extension run 61 deterministic rules with no LLM and no API key, so a check produces the same result on the same input every time and can run without a model call. That is a different mechanism from asking a model whether a design looks generic. It is also narrower: a rule set can only encode what someone wrote a rule for.

The third is packaging. Impeccable ships as an npm package with a bin entry, plus a Claude Code plugin marketplace path and a Grok Build plugin path, and it supports a long provider list including claude, cursor, gemini, codex, github, grok, opencode, pi, qoder, trae, trae-cn, rovo-dev and vibe. A single skill markdown file has none of that distribution machinery.

Maintenance, releases and the Apache-2.0 terms

The repository is not archived, and the last push was on 2026-08-26. Three packages were released that day: skill-v4.1.2, ext-v1.3.3 and cli-v3.6.1. Note that package.json at the repository root still carries version 4.1.0 while the skill release tag is 4.1.2, so the root manifest is not the version you should read when checking what shipped.

Upgrade cost depends on install path. The npx path is one command, npx impeccable update. The submodule path needs git submodule update --remote .impeccable followed by npx impeccable link with the same provider list. Hook-based installs carry the extra step described in the README: Codex tracks trust by hook definition, so an update that changes .codex/hooks.json can require re-approval.

The project is Apache-2.0, stated in both package.json and the Cargo workspace metadata. The NOTICE.md file at the repository root is the place to read for attribution requirements. Redistribution and modification are permitted under those terms, but this is not legal advice, and the Cargo.toml sets publish = false for the workspace crates, so the engine is not published to crates.io.

Editorial conclusion

Adopt Impeccable if your team builds frontend UI inside Claude Code, Cursor, Codex, Gemini CLI, Grok Build or another listed harness and keeps hitting the same template look. Skip it if you have no agent harness, or if you need a rule engine that you can wire into CI without the skill layer. Before rolling it out, run npx impeccable install in one project, approve the hook where Codex or Grok Build asks for trust, and confirm that the installed skill folders land where your harness actually reads them.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes