# Impeccable: a Generated Interface Is Not a Finished Product

Date: 2026-10-26

A customer onboarding form can look finished in a screenshot and still fail the person filling it out. The type is confident. The error does not say which field failed. On a phone, the label scrolls away from its input. Tab order never reaches submit. Visual polish did not make the form usable, and a usable layout did not make it accessible.

<!--more-->

## Context before taste

Impeccable is design guidance for AI coding agents, created by Paul Bakaus. It started from Anthropic's frontend-design skill and adds product context, a shared command vocabulary, and deterministic checks that run without a model call. The release inspected here is 4.1.0. Commands use `/impeccable` plus a name and an optional target, as in `/impeccable audit the header`.

`/impeccable init` writes `PRODUCT.md`: who the user is, what job they are doing, and which constraints later work must not invent. It does not choose a palette. An existing visual system is recorded separately in `DESIGN.md`. An onboarding form is a task. Scanability and expected behavior outrank a more distinctive look.

## Hierarchy, type, and space

`/impeccable layout` covers spacing, rhythm, and visual hierarchy. `/impeccable typeset` covers type hierarchy and font choice. A step title, a field label, and a primary action are not three equal boxes. Hierarchy is how a reader knows what to do first.

Default guidance flags patterns the skill treats as generic: an overused typeface applied everywhere, gray text on a colored ground, and cards nested inside cards. That is a warning about sameness. It is not a ban on a brand's actual font, or on a card that groups a real set of fields. The skill's rule is that a committed brief wins: pinned fonts, palettes, and materials stay even when they collide with a saturated-pattern warning. A brand exception can be recorded explicitly, including with `npx impeccable ignores add-value overused-font Inter --reason "Brand font"`.

## Responsive behavior, access, and the unhappy path

`/impeccable adapt` covers different devices and sizes. `/impeccable audit` writes a technical report and does not fix the code. On the web it checks accessibility, performance, theming, responsive behavior, and whether the implementation still reads as one product. The access checks include contrast, focus, tab order, input labels, and error messaging. The responsive checks include fixed widths, small touch targets, overflow, and text that breaks the layout as it grows.

`/impeccable harden` is the pass for imperfect use: validation errors, long names, empty states, slow networks, and copy longer than the English in the mock. `/impeccable clarify` is for labels and error text. `/impeccable critique` reviews hierarchy and whether the screen earns the action. `/impeccable polish` is a final alignment pass. None of those commands certifies the result.

## Three different failures

*(Illustrative. No form was generated or audited for this post.)*

Distinctive appearance is the first bar: one accent on the primary action, type that separates the step title from the labels, spacing that groups the address fields. That is not yet a form someone can finish.

Usable interaction is the second. An invalid email is marked on that field, the message says what to correct, and the typed value remains. On a narrow screen the label stays with its input.

Accessible implementation is the third. Every input has a label a keyboard user can reach, focus is visible, the error text meets contrast, and the error is not conveyed by color alone. A mouse-friendly layout can still fail here.

## Who it is for

Front-end developers, product designers, and teams shipping interfaces a customer must complete. A stakeholder can say who the form is for. Someone still has to look at the rendered page.

## What it does not settle

A command is not a guarantee of production-ready design. The project's detector documentation says a clean run is evidence, not proof of visual or accessibility quality, and that it does not replace inspecting the rendered page across the viewports that matter. Automated checks do not replace user feedback.

An existing design system is a constraint to honor. Popular fonts and simple cards are not universally wrong. They fail when they are the unexamined default, or when every region is wrapped the same way and the hierarchy disappears.

## Where this sits

This is design work inside an engineering workflow. The commands run against source, with checks a developer can re-run. A business owner can set the audience and the job. Validating the implementation—keyboard path, error copy, small screens, and the brand rules already committed—remains a person's job.

---

*Source: github.com/pbakaus/impeccable — README, package.json (4.1.0), skill/SKILL.src.md, and the init, critique, audit, and harden references. Retrieved 8 October 2026.*

#ProductDesign #Accessibility #AgentSkills
