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

One skill, and every action is a slash command

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

/impeccable <command> <target>

Twenty-four commands share that prefix, from shape, which plans UX before code, through audit for technical quality checks on accessibility, performance and responsive behaviour, to polish for the final pass 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 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: 62 deterministic rules, which the CLI and browser extension run with no LLM and no API key. That makes the two halves behave differently in practice. The CLI detector needs no agent, so npx impeccable detect can run in CI or a terminal on a machine with no model access. Critique is a scored UX review against usability heuristics that ranks what to fix first, so it runs on whatever model your harness is configured with and carries 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:

/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 README names the tells directly: 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, which show up again and again across models and projects when an agent gets no other guidance. 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 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:

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. The README says the design hook is available on Claude Code, Cursor, Codex, GitHub Copilot, Grok Build, and Hermes Agent, and the installer sets it up there. Veto 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 62 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/ LICENSE and skill/scripts/engine-checksums.txt, maps the bin to cli/bin/cli.js, and declares node >=18.19.0 in engines (>=22.18.0 only in devEngines, which warns), so the npm artifact is a launcher rather than the tool. The real work is the engine binary that the skill launcher skill/scripts/impeccable runs. The engine is a Cargo workspace over crates/ with foundation, common, core, detect, html, browser, live, context, hook, comp, comp-verbs and bundle, built with cargo build --release -p impeccable, and its workspace version is 0.1.18. Two version lines therefore run in parallel, the npm package at 4.8.0 and the engine tags at engine-v0.1.18. When something behaves oddly, knowing which line a bug belongs to saves a wasted upgrade.

Editorial 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 or on cards, 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.

Frequently asked questions

Official sources

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