Impeccable: 62 regole deterministiche contro lo slop dell'IA

Le pagine costruite da un modello hanno un'aria inconfondibile. L'hai vista: Inter dappertutto, un gradiente dal viola al blu nell'hero, card dentro le card, testo grigio su sfondo colorato e una mattonella quadrata con angoli arrotondati che galleggia sopra ogni titolo. Paul Bakaus ha dato un nome a quell'aria e poi ha scritto un linter per inseguirla.

Impeccable è una skill di design per agenti di programmazione. Questa settimana ha raccolto circa 6.700 stelle e viaggia intorno alle 91.500 complessive. Lo slogan — «il vocabolario di design per il tuo agente di programmazione» — sottovaluta proprio la parte insolita: 62 dei suoi controlli girano come regole deterministiche, senza alcun modello coinvolto.

Che cos'è, concretamente

Una skill, 24 comandi e un rilevatore. È nata come estensione della skill frontend-design di Anthropic e poi è cresciuta fino ad avere opinioni proprie.

L'installazione è un solo comando nella radice del progetto:

npx impeccable install
/impeccable init

Il secondo passaggio è quello che tutti saltano. init ti intervista sul prodotto — pubblico, scopo, vincoli, tono — e scrive le risposte in PRODUCT.md. Un comando document separato genera DESIGN.md dal codice che hai già. La separazione conta: i fatti di prodotto e il sistema visivo sono artefatti diversi, che cambiano con cadenze diverse, e fonderli in un unico file è il modo più rapido per far invecchiare un documento di design.

Poi ci sono i 24 comandi. Sono più un vocabolario che un flusso di lavoro:

craft esegue l'intera sequenza forma-poi-costruisci con iterazione visiva. critique esamina gerarchia, chiarezza e registro emotivo. audit controlla accessibilità, prestazioni e adattività. polish allinea al design system prima del rilascio. bolder e quieter sono aggiustamenti direzionali: amplificare o contenere. harden gestisce stati di errore, i18n, testo che straborda e casi limite. typeset e layout correggono le due cose che le interfacce generate dagli agenti sbagliano più spesso. live apre un browser e genera varianti di un elemento indicato, sul posto.

Ognuno può essere fissato come scorciatoia autonoma:

/impeccable pin audit

Il che crea /audit come comando di primo livello. Funzione minuscola, differenza enorme su se il vocabolario viene poi davvero usato.

Il rilevatore è l'ingegneria interessante

Ecco cosa separa Impeccable dal mucchio di repository che sono solo raccolte di prompt: le 62 regole non richiedono un modello, né una chiave API, né un agente.

npx impeccable detect src/
npx impeccable detect index.html
npx impeccable detect --json .
npx impeccable detect --list-rules

Vuol dire che gira in CI. Una pull request che reintroduce un easing con rimbalzo, o un gradiente viola sfuggito, o una didascalia grigia da 14px su verde acqua, può fallire il controllo senza che nessuno paghi token. C'è un flag --github che emette annotazioni per GitHub Actions, ed è l'unico dettaglio d'integrazione che conta per la maggior parte dei team.

Il set di regole è schierato, al punto da infastidire, e la documentazione lo ammette. La lista degli anti-pattern bandisce Arial, Inter e i font di sistema predefiniti; bandisce il nero puro e il grigio puro (sempre tinti); bandisce le card intorno a ogni cosa e le card dentro le card; bandisce gli easing a rimbalzo ed elastici in quanto datati; bandisce il testo grigio su sfondi colorati.

Alcuni di questi sono argomenti di mestiere difendibili. Un paragrafo con contrasto insufficiente su uno sfondo saturo è un difetto di accessibilità che, per caso, sembra anche economico. Il divieto di Inter è moda, e le regole di moda invecchiano male: lo stesso documento che bandisce Inter, fra tre anni, sembrerà un pezzo d'epoca. Ma un linter senza opinioni è solo un formattatore, e il punto di questo è avere una posizione.

Proprio perché è deterministico, è anche aggirabile. Qualunque team intenzionato a pubblicare il suo gradiente viola può aggiungere un'esenzione inline:

<!-- impeccable-disable overused-font: exported brand doc -->

Oppure gestire le esclusioni a livello globale con npx impeccable ignores add-value overused-font Inter --reason "Brand font". Il flag --reason fa un discreto lavoro sociale: rende l'eccezione visibile in un diff.

Come si aggancia all'agente

Il percorso d'installazione che scegli determina quanto diventa invadente. Per Claude Code, Copilot, Codex, Cursor e Grok Build, install scrive un manifest di hook nativo del fornitore. In Claude Code è .claude/settings.local.json, ignorato da git e locale alla macchina. In Copilot è .github/hooks/impeccable.json, versionato e condiviso con gli agenti cloud. In Cursor è .cursor/hooks.json, che scatta su postToolUse quando viene scritto un file.

L'effetto è che il rilevatore gira sulle modifiche dell'agente stesso e rimanda i risultati nel suo ciclo. È un meccanismo sostanzialmente diverso da «lancia il comando di audit quando te ne ricordi». Intercetta la sciatteria al momento della generazione, non in revisione.

Il compromesso è quello di sempre: gli hook che scrivono nella configurazione del repository sono hook che compaiono in code review, e chi usa Codex deve approvare esplicitamente gli hook di progetto con /hooks dopo l'installazione. Se il tuo team ha opinioni forti sulla configurazione degli strumenti versionata, la via del submodule esiste esattamente per questo: git submodule add più npx impeccable link --source=.impeccable --providers=claude,cursor tiene lo strumento versionato accanto al codice che governa.

Quello che non sistemerà

Tre limiti da nominare.

Non può dirti se la pagina è buona. Le 62 regole colgono segnali di superficie. Una pagina può passarle tutte e restare senza alcun punto di vista, che è la versione profonda del problema dello slop IA e quella che nessun linter ha risolto.

La modalità live funziona solo su un checkout locale. Non si inietta in un sito in produzione, né con HTTPS. È ragionevole, ma significa che il ciclo di iterazione visiva è uno strumento di sviluppo, non di revisione.

E il vocabolario serve solo se l'agente lo legge. La stessa impostazione di Impeccable è onesta in merito: se ogni modello produce lo stesso design è perché ogni modello è stato addestrato sugli stessi template SaaS. Un file di skill è una spinta contro una distribuzione di addestramento, e le spinte perdono contro le distribuzioni più spesso di quanto chiunque vorrebbe.

Perché non scrivere semplicemente una checklist?

Domanda legittima. Una guida di stile in un file markdown non costa nulla e fa più o meno lo stesso lavoro.

La differenza è l'applicazione. Una checklist dentro un prompt è un suggerimento: il modello la legge, annuisce, e poi produce un gradiente viola perché quel gradiente era nei suoi dati di addestramento quarantamila volte. Una regola deterministica fa fallire una build. È un'altra categoria di pressione, ed è l'unica che sopravvive a una scadenza.

La seconda differenza è la granularità. Una checklist dice «usa una buona tipografia». Il comando typeset di Impeccable affronta gerarchia, scala e abbinamenti in modo specifico, e il rilevatore ha regole singole per singoli errori: il feedback può quindi indicare una riga di CSS invece di gesticolare verso il gusto. È tutto l'argomento a favore degli strumenti rispetto alla documentazione, e qui vale per la stessa ragione per cui valeva per i linter vent'anni fa.

La terza è che il vocabolario è condiviso. bolder, quieter, distill, harden: sono parole su cui un designer e un agente possono entrambi agire. «Rendilo più pop» no.

Perché sta emergendo adesso

Perché è arrivato il problema del volume. Un anno fa un agente generava una landing page ogni tanto. Oggi un team ne produce quaranta prima di pranzo, e il collo di bottiglia si è spostato da «riusciamo a costruirla» a «riusciamo a capire quali sono buone, abbastanza in fretta».

Un verificatore deterministico degli errori a basso costo è l'unica parte di quel problema che scala. Il gusto non scala. Sessantadue regole a forma di espressione regolare su font ed easing sì, e distribuirle come qualcosa che gira in CI senza una chiamata al modello è la decisione meno glamour e più utile del repository.