Impeccable: skill, który uczy AI projektować frontend zamiast klepać slop

Poproś dowolnego agenta AI o “ładny landing page”, a dostaniesz to samo. Ciemny granat, jeden akcent w fiolecie, siatka identycznych kart z ikoną i nagłówkiem, wielka liczba na środku z małym podpisem pod spodem, tekst z gradientem. Wygląda znajomo, bo widziałeś to tysiąc razy. To jest slop - estetyka, po której z miejsca poznajesz, że nikt tego nie zaprojektował, tylko wygenerował.

Impeccable to skill, który z tym walczy. Nie przez “ładniejszy prompt”, tylko przez zestaw twardych zasad projektowych, które agent musi przejść, zanim napisze pierwszą linijkę CSS.

Skill, czyli warstwa gustu doklejona do modelu

Krótkie przypomnienie, bo o skillach pisałem osobno przy okazji ponytaila: skill to plik z instrukcjami, który agent wczytuje i traktuje jak zasady na daną sytuację. Ponytail zmieniał odruchy przy pisaniu logiki. Impeccable robi to samo dla warstwy wizualnej.

Różnica względem zwykłego “zrób to ładnie” jest taka, że impeccable nie prosi o efekt. On narzuca proces: najpierw zrozum kontekst produktu, potem zdecyduj o rejestrze, potem o strategii koloru i motywu, i dopiero wtedy koduj. Model nie zgaduje estetyki - przechodzi przez konkretne bramki decyzyjne.

Rejestr: brand vs product

To jest pierwsza i najważniejsza decyzja w impeccable. Każde zadanie projektowe jest jednym z dwóch:

brand - marketing, landing, kampania, portfolio, długi content. Tu design JEST produktem. Ma robić wrażenie, budować tożsamość, zostać w pamięci.
product - UI aplikacji, panel admina, dashboard, narzędzie. Tu design SŁUŻY produktowi. Ma zejść z drogi i pozwolić zrobić robotę.

To rozróżnienie decyduje o wszystkim, co dalej. Landing bez odwagi jest nudny. Dashboard z odwagą landingu jest męczący. Ten sam model potrzebuje dwóch różnych trybów, a impeccable każe mu jawnie wybrać, w którym jest, zanim zacznie.

Skill ładuje pod każdy rejestr osobny plik referencyjny z innymi regułami. Wspólne prawa projektowe obowiązują w obu.

Kontekst: PRODUCT.md i DESIGN.md

Impeccable nie chce projektować w próżni. Zanim ruszy, szuka dwóch plików:

PRODUCT.md (wymagany) - użytkownicy, marka, ton, anty-referencje, zasady strategiczne.
DESIGN.md (opcjonalny, ale mocno zalecany) - kolory, typografia, elewacja, komponenty.

Jeśli PRODUCT.md nie istnieje albo jest pustą wydmuszką, skill najpierw uruchamia tryb teach, który ten kontekst z Tobą buduje, a dopiero potem wraca do właściwego zadania. To ta sama filozofia, co przy systemie kontekstu w Claude Code: AI projektuje lepiej, gdy zna produkt, zamiast strzelać w ogólniki.

Kluczowa w PRODUCT.md jest sekcja anty-referencji - “na co NIE ma to wyglądać”. Bo połowa walki ze slopem to nie “bądź kreatywny”, tylko “nie idź w pierwszy oczywisty schemat dla tej kategorii”.

Strategia koloru: OKLCH i cztery poziomy odwagi

Tu impeccable robi się konkretny. Kolory w przestrzeni OKLCH, nigdy czysta czerń #000 ani biel #fff - każdy neutralny ma być leciutko podbarwiony w stronę koloru marki.

Ale najciekawsza jest oś commitmentu. Zanim wybierzesz kolory, wybierasz strategię:

Restrained - podbarwione neutrale + jeden akcent do 10% powierzchni. Domyślny dla product i minimalizmu brandowego.
Committed - jeden nasycony kolor niesie 30-60% powierzchni. Domyślny dla stron budujących tożsamość.
Full palette - 3-4 nazwane role koloru, każda użyta świadomie. Kampanie, wizualizacje danych.
Drenched - powierzchnia JEST kolorem. Hero, strony kampanijne.

Sens tej listy jest taki, żeby model nie sprowadzał każdego projektu odruchowo do “Restrained” (jeden akcent, reszta szara). To bezpieczna nuda. Czasem strona ma być zalana kolorem i to jest właściwa decyzja, nie błąd.

Motyw: dark vs light to nie jest default

To moja ulubiona reguła w całym skillu, bo celuje w najbardziej bezmyślny odruch w branży.

Impeccable zabrania wybierać ciemny motyw “bo narzędzia fajnie wyglądają na ciemno” i jasny “żeby było bezpiecznie”. Zamiast tego każe napisać jedno zdanie fizycznej sceny: kto tego używa, gdzie, przy jakim świetle, w jakim nastroju.

Przykład wprost ze skilla:

“Dashboard observability” nie wymusza odpowiedzi. “SRE zerkający na severity incydentu na 27-calowym monitorze o 2 w nocy w ciemnym pokoju” - wymusza.

Jeśli zdanie nie narzuca odpowiedzi, znaczy że nie jest dość konkretne. Dodawaj detali, aż narzuci. Motyw wynika ze sceny, nie z kategorii.

Twarde zakazy anty-slopowe

Impeccable ma listę rzeczy, których po prostu nie wolno napisać. Jak agent ma właśnie coś takiego wygenerować, ma to przepisać inną strukturą. To jest esencja “anty-slopu”:

Boczne paski (side-stripe borders) - kolorowy border-left grubszy niż 1px jako akcent na kartach, alertach, callout-ach. Nigdy celowe.
Tekst z gradientem - background-clip: text na gradiencie. Dekoracyjne, nigdy znaczące.
Glassmorphism jako default - rozmyte szklane karty na wszystkim. Rzadko i celowo, albo wcale.
Szablon hero-metric - wielka liczba, mały podpis, statystyki obok, gradientowy akcent. Klisza SaaS.
Identyczne siatki kart - te same karty ikona + nagłówek + tekst w nieskończoność.
Modal jako pierwsza myśl - modale to zwykle lenistwo. Najpierw wyczerp warianty inline.

Do tego dochodzi zakaz em-dashów w copy (tej samej pauzy, po której poznaje się teksty pisane przez AI) i zasada “każde słowo zarabia na swoje miejsce”.

Test na slop: “czy to wygląda jak zrobione przez AI”

Cała ta lista sprowadza się do jednego pytania, które impeccable nazywa AI slop test:

Jeśli ktoś mógłby spojrzeć na ten interfejs i bez wahania powiedzieć “to zrobiła AI” - projekt oblał.

I tu jest niuans, który podnosi poprzeczkę. Skill każe uruchomić ten test na dwóch poziomach:

Pierwszy rząd - czy da się zgadnąć motyw i paletę z samej kategorii? “Observability → ciemny niebieski”, “healthcare → biel + turkus”, “fintech → granat + złoto”, “crypto → neon na czarnym”. Jeśli tak, to pierwszy odruch z danych treningowych. Przerób.
Drugi rząd - czy da się zgadnąć rodzinę estetyczną z kategorii plus anty-referencji? “Narzędzie AI, ale nie SaaS-owe → pewnie edytorsko-typograficzne”. To pułapka o piętro głębiej. Pierwszy odruch ominięty, drugi nie.

Przerabiasz, aż obie odpowiedzi przestają być oczywiste. To jest różnica między “ominąłem najgorszą kliszę” a “faktycznie zaprojektowałem coś swojego”.

Komendy: to nie jest jeden przycisk

Impeccable to nie pojedyncza akcja “zrób ładnie”. To zestaw komend na różne etapy pracy z UI. Kilka najużyteczniejszych:

craft [feature] - zaprojektuj i zbuduj feature end-to-end (z etapem planowania przed kodem).
shape [feature] - zaplanuj UX/UI, zanim padnie linijka kodu.
critique [target] - review UX z punktacją heurystyk.
audit [target] - twarde checki techniczne: dostępność, performance, responsywność.
polish [target] - finalny przebieg jakościowy przed wysyłką.
bolder / quieter - podkręć nudny projekt albo wycisz przestymulowany.
live - tryb wizualny: wskazujesz element w przeglądarce, dostajesz warianty.

Jest tego więcej (animate, colorize, typeset, harden, distill…), ale wzorzec jest jeden: każda komenda ładuje własny plik referencyjny i pilnuje konkretnego etapu, zamiast wrzucać wszystko do jednego promptu.

Dla kogo to jest

Impeccable ma sens wtedy, gdy jakość wizualna faktycznie się liczy, a nie masz pod ręką designera na każdy ekran. Landing, który ma sprzedawać. Panel produktowy, który ma nie męczyć. Komponent, który ma wyglądać jak dopracowany, a nie jak wygenerowany.

Nie jest to skill do prototypu na kolanie, gdzie liczy się tylko, żeby “działało”. Tam narzut decyzji o rejestrze, kolorze i motywie będzie przeszkadzał. Ale w momencie, gdy coś ma pójść przed prawdziwe oczy - impeccable jest różnicą między “AI to zrobiła” a “kto to projektował?”.

Bo najlepszy komplement dla wygenerowanego frontendu to ten, w którym słowo “wygenerowany” w ogóle nie pada.

EfektywnyDev pisze o AI w praktyce - o tym, jak wyciskać z narzędzi robotę na poziomie, a nie tylko demo.