Impeccable: frontend design language and detector rules for coding agents

Who it's for

Look at Impeccable when you need to give an AI coding agent design guidance. The official summary is: Design guidance for AI coding agents. 1 skill, 23 commands, live browser iteration, and 61 deterministic detector rules for AI-generated frontend design.

It fits people who already have a frontend project and are willing to write down durable product facts first, then let later commands work from those facts. It is not a theme pack that only tweaks colors. The body lists that it can be used with Cursor, Claude Code, Gemini CLI, Codex CLI, Grok Build, Hermes Agent, Veto, and every other supported tool; do not read that list as the only supported range.

Page:

https://github.com/pbakaus/impeccable

First try in 3 minutes

The official path is only this stretch. First run at the project root:

npx impeccable install

Then in your AI coding tool run /impeccable init. Prerequisite: the current directory is the project root; you accept that init will write product facts into PRODUCT.md. Do not invent another installer or a skill directory that was never written.

The first time, do a read-only check; do not rush to write files. Ask the agent: which facts will init record in PRODUCT.md, and how those facts differ from visual direction. Success: the agent names audience, purpose, operating context, constraints, voice, and evidence, and says later commands should not mix these with surface-level visual direction.

After that checks out, run /impeccable init. Success: PRODUCT.md appears in the project and covers those fields.

Use cases

Case 1: Pin product facts first. /impeccable init records durable product truth in PRODUCT.md. Give the agent “who we are building for, what the product does, which hard constraints exist, and what the voice is,” and let it write that file. This writes files. Before running, confirm you may create or overwrite PRODUCT.md. The page does not give the full file template; do not invent structure beyond the named fields.

Case 2: Check frontend design with deterministic rules. The body writes 61 deterministic detector rules, plus LLM-only critique checks. The CLI and browser extension run the deterministic rules with no LLM and no API key. This fits after you change a UI pass: run the no-model rule check first, instead of jumping to generative critique. Checkable: this check states it uses no LLM and does not ask for an API key. The concrete names of the 23 commands are not listed; do not invent them.

Boundaries

Install must start from the project root, then /impeccable init. Do not split the two steps into two competing main installers.

PRODUCT.md records durable product facts, not a visual-style sheet.

When the CLI and browser extension run deterministic rules they need no LLM and no API key. LLM-only critique is another kind of check; do not merge them into one step.

Clients are listed as in the source, including every other supported tool; do not write that only one of them is supported. Do not fill in unwritten command names, rule details, or live-browser operation steps.