All 23 impeccable commands — what each one does, and when to reach for it

Follow this StackScout guide in my project: "All 23 impeccable commands — what each one does, and when to reach for it"
https://stackscout.app/guides/impeccable-commands

Read it, then set up what it describes. When you're done, give me a one-line summary.

Most people install impeccable and then type "use impeccable and build me a landing page." That loads the skill and runs none of it. This is the reference we wished existed: every command, the argument it takes, and the words that should make you reach for it.

Everything quoted here comes from the skill's own shipped metadata (skill/scripts/command-metadata.json) and the README of pbakaus/impeccable, Apache-2.0 by Paul Bakaus, read at the source on 31.07.2026. We link the skill, we don't rehost it.

---

Why "use impeccable" does nothing

The skill ships one skill, 23 commands, live browser iteration and 59 deterministic detector rules. Naming the skill in a sentence does none of that:

• No command runs. The commands are the product. A mention isn't a call.
• There is no context to read. Every command starts by reading PRODUCT.md and DESIGN.md. Until init has written them, there is nothing to read, so the agent falls back to its own default taste — which is the thing you installed impeccable to escape.
• You skipped the argument. Every command except init, document and live takes one: [target], [area (feature, page, component…)], [feature to shape]. The argument is where your precision goes. /impeccable audit is a request. /impeccable audit the checkout form on mobile is an instruction.

The uncomfortable part: you have to understand the tool to direct it. No skill fixes a vague brief. What follows is the understanding.

---

1 · Once per project: /impeccable init

"Sets up a project for impeccable. Runs a multi-round discovery interview when context is missing and writes PRODUCT.md (strategic: users, brand, principles); offers DESIGN.md (visual: colors, typography, components) when code exists; pre-configures live mode; then recommends the best commands to run next. Every other command reads these files before doing work. Use once per project."

Read that last-but-one sentence again — it's the whole reason init comes first. init is not a config step, it's the interview that turns "make it look good" into two files an agent can actually follow.

The README adds what the interview opens with: init "asks whether the surface is brand (marketing, landing, portfolio) or product (app UI, dashboard, tool)". Those two answers pull the rest of the session in different directions, which is why it asks before anything else.

What you get:

Run it when: you start a project, or you inherit one. Nothing else first.

⚠️ Name collision worth knowing: DESIGN.md is also written by other tools with a different schema. Decide who owns that file before you run two of them in one repo.

Already have a codebase and no DESIGN.md? Use /impeccable document instead — it "auto-extracts colors, typography, spacing, radii, and component patterns from the codebase" and follows the Google Stitch DESIGN.md format so the file stays tool-compatible.

---

2 · Before you write code: /impeccable shape [feature to shape]

"Plan UX and UI before code. Runs a required multi-round discovery interview, uses visual probes when available, and produces a user-confirmed design brief for implementation."

"Required" is doing work in that sentence. shape will not let you skip the interview, which is exactly the point: the questions are the value. You end with a brief you have confirmed — so when the build comes back wrong, you can point at the line where it diverged.

/impeccable shape the pricing page for a solo-developer plan

Skip it and you are letting the model guess. That guess is a good guess — it is also the same guess it gives everyone else.

---

3 · The one nobody knows: /impeccable live

"Interactive live variant mode. Select elements in the browser, pick a design action, and get AI-generated HTML+CSS variants hot-swapped via HMR. Requires a running dev server. Use when you want to visually experiment with design alternatives in real time."

This is the part that changes how the whole thing feels. You are not describing a button in chat and waiting for a diff. Your dev server is running, you click the actual button on localhost, choose what should change, and variants swap in live through hot module reload.

Requires a running dev server. init pre-configures live mode, which is one more reason to run init first.

Reach for it when you can see the problem but can't name it. Describing a spacing problem in prose is hard; pointing at it is easy.

---

4 · Before shipping: three passes, three different questions

Run them in this order. They are not interchangeable — each asks something the other two don't.

/impeccable critique [area]

"Evaluate design from a UX perspective, assessing visual hierarchy, information architecture, emotional resonance, cognitive load, and overall quality with quantitative scoring, persona-based testing, automated anti-pattern detection, and actionable feedback."

Asks: is this the right design? → "Use when the user asks to review, critique, evaluate, or give feedback on a design or component."

/impeccable audit [area]

"Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0–P3 severity ratings and actionable plan."

Asks: is this built correctly? → "Use when the user wants an accessibility check, performance audit, or technical quality review."

/impeccable polish [target]

"Performs a final quality pass fixing alignment, spacing, consistency, and micro-detail issues before shipping."

Asks: is this finished? → "Use when the user mentions polish, finishing touches, pre-launch review, something looks off, or wants to go from good to great."

If you pin one command to a shortcut, the README shows how: /impeccable pin audit gives you a standalone /audit.

---

5 · The fixers — pick by symptom

Each of these takes a [target]. The right-hand column is quoted from the shipped metadata: these are the words the skill itself expects to hear. Say them. They are the routing.

---

6 · What craft actually is

The README lists /impeccable craft as "Full shape-then-build flow with visual iteration." The skill's own shipped metadata says something different:

"Deprecated compatibility alias for an ordinary Impeccable new-work request. It adds no behavior; natural build and redesign requests use the same flow."

So: you don't need it. Once the skill is installed and init has run, describing the work you want goes down the same path. We flag it because a command list is exactly the kind of thing people copy without reading, and this one is a leftover.

---

7 · The part that runs without you

Separate from all 23 commands, the design hook watches direct edits to UI files and runs 59 deterministic detector rules — no LLM, no API key. Deterministic means the same input gets the same verdict, every time. The README lists what it looks for: AI-slop tells (side-tab borders, purple gradients, bounce easing, dark glows) and general quality (line length, cramped padding, small touch targets, skipped headings).

You can run the same rules yourself, outside any agent:

npx impeccable detect      # scan files or URLs for anti-patterns
npx impeccable ignores     # manage waivers for the ones you accept

The honest limit: it only checks what someone wrote down as a rule. Whether the direction is any good is not a rule, and it will never tell you. A clean detector run on a boring direction gives you a clean boring page.

---

8 · The routine, end to end

npx impeccable install          # once, per machine
/impeccable init                # once, per project → PRODUCT.md + DESIGN.md

/impeccable shape the onboarding flow for first-time users
# …build it — no /craft needed…
/impeccable live                # click the real thing on localhost, try variants

/impeccable critique the onboarding flow    # right design?
/impeccable audit the onboarding flow       # built correctly?
/impeccable polish the onboarding flow      # finished?

Three habits that separate this from "use impeccable":

1. Always pass the argument. /impeccable audit is a wish. /impeccable audit the checkout form on mobile is a job.
2. Use the words from the table. The descriptions literally say "Use when the user mentions…". Those words route your request. Saying "make it nicer" routes nowhere.
3. Run init before you judge the output. Everything else reads those two files. Without them you are grading the model's default taste, not the skill.

---

Sources

• skill/scripts/command-metadata.json — all 23 command descriptions and argument hints
• README.md — "1 skill, 23 commands, live browser iteration, and 59 deterministic detector rules for AI-generated frontend design"; "Start every new project with: /impeccable init"; the CLI commands; /impeccable pin
• Repo: github.com/pbakaus/impeccable · Apache-2.0 · Paul Bakaus · read at the source 31.07.2026

impeccable is not ours. We link the author's own install command so updates and security stay with him. What's ours is this guide: every line above is traced to a file in that repo, with the date we read it. Where we say something the README doesn't — that craft is a deprecated alias, that the argument is where your precision goes — the source is named so you can check it.