# Impeccable puts 61 design rules and 24 slash commands in front of a coding agent

> Impeccable is a design skill for AI coding agents: one installed skill, 24 commands reached through /impeccable, and 61 deterministic detector rules that run in the CLI and browser extension with no LLM and no API key. The critique half of the tool still needs a model, one supported harness receives the skill without the edit hooks, and the rules encode a house style that some brands will fight.

**pbakaus/impeccable** — The design language that makes your AI harness better at design. The CLI and browser extension run the deterministic rules with no LLM and no API key.

- Repository: https://github.com/pbakaus/impeccable
- Website: https://impeccable.style
- Stars: 71,092 · Forks: 4,310
- Language: JavaScript
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/pbakaus-impeccable

## One skill, and every action is a slash command

Installation gives an agent a single skill, and the whole vocabulary hangs off it:

```bash
/impeccable <command> <target>
```

Twenty-four commands share that prefix, from craft, which runs a shape-then-build flow with visual iteration, through audit for technical quality checks on accessibility, performance and responsive behaviour, to polish for design system alignment before shipping. Others do specific things: bolder amplifies a boring design, quieter tones down one that is too loud, distill strips a surface to its essence, and harden covers error handling, i18n, text overflow and edge cases. Two more work in a live browser, live for iterating on elements and generate for producing variants of a named element without manual picking. There is also pin, which creates a standalone shortcut so pin audit exposes /audit directly. The consequence is that the tool is inert until a command is named. Nothing runs on its own, and an agent that never issues /impeccable has installed nothing but a file.

## The 61 rules need no model, and the critique always does

The split is the most useful thing in the repository, because the README states it plainly: 61 deterministic detector rules plus LLM-only critique checks, where the CLI and browser extension run the deterministic rules with no LLM and no API key. That makes the two halves behave differently in practice. Audit is a technical pass over accessibility, performance and responsive behaviour, and because the rules are fixed it can run anywhere, including CI on a machine with no model access. Critique is a UX design review of hierarchy, clarity and emotional resonance, and the README classes it as LLM-only, so it inherits whatever model your harness is configured with and its cost. So the phrase no API key describes the detectors, not the tool. If you are budgeting for this, price the critique half separately.

## init writes PRODUCT.md so later commands stop inventing an audience

The one-time setup command is the piece everything else leans on:

```bash
/impeccable init
```

init inspects the project, asks only for material gaps in durable product truth, and writes PRODUCT.md, recording the audience, purpose, operating context, constraints, voice and evidence. The stated reason is that later commands should know those facts without confusing them with surface-level visual direction. Visual systems are kept out of that file on purpose, since an incumbent or newly built system is recorded separately in DESIGN.md, and /impeccable document will generate a root DESIGN.md from existing project code. The consequence is a file your team now owns. Every later command reads it, and nothing validates that it is still true, so a PRODUCT.md written before a pivot will quietly misdirect polish, craft and onboard until somebody rewrites it.

## The anti-pattern list names Inter, cards and bounce easing as defects

This is the part to read before installing. The skill's explicit guidance rejects overused fonts, naming Arial, Inter and system defaults, and says not to use gray text on colored backgrounds, not to use pure black or gray because color must always be tinted, not to wrap everything in cards or nest cards inside cards, and not to use bounce or elastic easing because it feels dated. The reasoning is stated just above it: every model trained on the same SaaS templates produces the same handful of tells, among them Inter for everything, purple-to-blue gradients, cards nested in cards, gray text on colored backgrounds, and a rounded-square icon tile above every heading. The consequence for a reader is direct. These are house rules, not accessibility standards, so a brand whose identity is built on Inter, on a card grid, or on a lively easing curve will spend its time fighting the detectors rather than benefiting from them.

## Each harness needs a folder, and the trust step is manual

The recommended installer detects what you have and asks where to put it:

```bash
npx impeccable install
```

It looks for harness folders or installed CLIs such as ~/.claude, ~/.codex, ~/.grok, ~/.hermes and ~/.veto, or a project-local .cursor, lets you keep or customise the set, and then asks whether to install into the current project or globally. Scripts can skip the prompts with --providers=claude,codex,cursor,grok,hermes,veto and --scope=project|global. What makes this more than a copy operation is the trust step, and the README is unusually candid about it. Codex users must open /hooks after install or update and approve the project hook, and because Codex tracks trust by hook definition, an update that changes .codex/hooks.json can require approval again. Grok Build needs project folder trust through /hooks-trust or by launching with --trust before .grok/hooks/ scripts run at all. The consequence for a team is a recurring manual chore: an update that quietly needs re-approval shows up as a hook that has stopped firing.

## Veto receives the skill but not the edit hooks

The installer is explicit that the supported harnesses do not get equal treatment. On Claude Code, Cursor, Codex, GitHub Copilot and Grok Build it also installs the provider-native hook manifest for the current project. Veto is the exception: it receives the packaged skill under ~/.veto/skills/ and does not run native Impeccable edit hooks. So a Veto user can invoke the commands, including the 61 deterministic rules, but does not get the automatic edit-time enforcement the other harnesses provide. That is a defensible boundary rather than a bug, and it still has a cost. If you chose Impeccable specifically to stop generic output at the moment it is written, the harness where you cannot get that is the harness where the benefit is reduced to something you have to ask for.

## npm ships a shim, and the engine behind it is a Rust binary at 0.1.8

The published package is much smaller than the repository. package.json lists files as cli/bin/ and LICENSE, maps the bin to cli/bin/cli.js, and requires node >=22.18.0, so the npm artifact is a launcher rather than the tool. The real work is a self-contained engine binary that either sits next to the launcher or is downloaded once on first run into ~/.impeccable/bin/, which means a fresh install needs network access to fetch it unless you vendor it. The engine is a Cargo workspace over crates/ with foundation, common, core, detect, html, browser, live, context and hook, built with cargo build --release -p impeccable, and its workspace version is 0.1.8. Two version lines therefore run in parallel, the npm package at 4.1.0 and the engine tags at engine-v0.1.8. When something behaves oddly, knowing which line a bug belongs to saves a wasted upgrade, and the node floor rules out older CI images outright.

## Conclusion

Impeccable fits a team that has already decided what good design looks like for its product and wants an agent to stop rediscovering the same generic layout every sprint, because PRODUCT.md plus the detector rules is the mechanism that makes that stick. It is the wrong tool if your brand is built on Inter, on cards, or on bounce easing, since the anti-pattern list names those as defects. Before installing, confirm your harness trusts project hooks without a manual approval each time, because Codex and Grok Build both require a per-project trust step that an update can invalidate.

## FAQ

### how to install impeccable in claude

From the project root run npx impeccable install, which detects ~/.claude and the other harness folders, then run /impeccable init inside your tool. On Claude Code the installer also adds the provider-native hook manifest, and you reload your harness afterwards.

### how to use impeccable skill

Every action is a subcommand of the installed skill: /impeccable init for setup, /impeccable audit for accessibility, performance and responsive checks, /impeccable critique for a UX review, and /impeccable polish before shipping. /impeccable pin <command> creates a standalone shortcut such as /audit.

### how to use impeccable with codex

The installer detects Codex CLI and wires the skill in, but Codex tracks trust by hook definition, so you must open /hooks after an install or update and approve the project hook. An update that changes .codex/hooks.json can require that approval again.

### how to use impeccable in antigravity

Antigravity IDE is one of the tools the installer detects and auto-configures, and it is listed among the supported agents. The provider-native hook manifest is installed for Claude Code, Cursor, Codex, GitHub Copilot and Grok Build, while Veto is the documented exception that receives the skill without native edit hooks.

## Sources

- [Official documentation](https://impeccable.style)
- [Official README](https://github.com/pbakaus/impeccable#readme)
- [Project repository](https://github.com/pbakaus/impeccable)
- [Release notes](https://github.com/pbakaus/impeccable/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pbakaus-impeccable