Clean UI

Minimalistisches, modernes Interface mit hellem und dunklem Theme, das auf den Bildschirm passt, mit Daten an erster Stelle und einem Look, der von Menschen gemacht aussieht, nicht von KI. Die folgenden Regeln stammen aus echten Änderungswünschen. Jede hat den Benutzer verärgert, als sie verletzt wurde: Behandle sie als Anforderung, nicht als Vorschlag.

Dateien der Skill

Pfade relativ zum Ordner dieser Skill.

Datei	Wann verwenden
`references/informacao.md`	Jeder neue Bildschirm oder jedes Redesign, vor dem Layout. Wie man auswählt, was gezeigt wird, die Reihenfolge der Priorität und die Position jeder Information (Inventar, Benutzerfragen, Stufen, Filter, Positionskarte, schriftlicher Plan).
`references/padroes-aprovados.md`	Blöcke, die der Benutzer genehmigt hat ("viel besser geworden"): Entscheidungskarte, Diagramm der Entscheidungsmessung mit der Grenzlinie, Situationskarte mit Saldo im Zeitverlauf, eigene Benutzerliste, saisonale Unterstützung, Mobilkopfzeile, Reihenfolge nach Priorität, Ultraweitbildschirm. Als Ausgangspunkt für den Inhalt verwenden, nicht als festes Skelett.
`references/armadilhas.md`	Technische Fehler, die bereits Nacharbeit gekostet haben (Tailwind v4, `cn` ohne Merge, Spezifität von `[&>*]:`, next-themes, Server mit altem CSS, Testen von Zuständen, die die lokale Datenbank nicht hat). Vor dem Schreiben des Codes lesen.
`references/migracao.md`	Komplette App neu gestalten (mehrere Bildschirme): zuerst genehmigter Referenzbildschirm, Basis von dir erstellt (Rahmen, Seitenstücke, Tokens im Body, gespeichertes Theme), parallele Fronts mit gemeinsamem Briefing, Integration (Anfragen an das Kit, alten Code erst am Ende löschen, neu starten, alles überprüfen).
`references/exemplos.md`	Reale Beispiele von falsch und richtig. Lesen beim Erstellen eines neuen Bildschirms oder wenn du unsicher bist, ob etwas gut ist.
`references/dashboards.md`	Jeder Bildschirm mit Zahlen, Diagrammen oder Karten. Was Amateur von Profi unterscheidet, Prinzipien (NN/g, Stephen Few, IBM Carbon), 7 Kompositionen (die auswählen, die dem Informationsplan dient), Regeln für breite und Ultraweitbildschirme, Farbe und Finish von Diagrammen.
`references/paletas.md`	Fertige und validierte Paletten (Cobalt, Indigo, Cyan, Coral) mit Grautönen, Akzentfarbe, geordneter Skala und Serienfarben für beide Themes. Hier auswählen, niemals einzelne Farben.
`assets/tokens.css`	Neues Projekt oder ohne Identität: helles und dunkles Theme (folgt dem System, mit manueller Umschaltung), Schriftart, Fokus, Diagramme und Berührung bereits konfiguriert (Tailwind v4). Wird mit der Cobalt-Palette nur als Ausgangspunkt geliefert: durch den vollständigen Block der ausgewählten ersetzen (Ende von `paletas.md`). Enthält die Variante `tall`, positiv/negativ/Warnung und die kleine Hand.
`references/exemplos-dashboards/`	Die 7 Referenzen des Benutzers für moderne Dashboards. Alle öffnen, bevor du ein Dashboard entwirfst.
`references/anatomia-dashboard.md`	Die Referenzen in Maße übersetzt: Karte, Titel, Indikator, Chips, Zahlen oben im Diagramm, Diagramme, Teile eines Ganzen, Messgerät, Tabelle, Mobilgerät und was nicht kopiert werden soll.
`assets/dashboard.tsx`	Dashboard-Kit nach den Referenzen bemessen: DashCard, Kpi, IconCircle, DeltaChip, StatusChip, TrendDot, CountBadge, Tabs, SeriesStat, StatColumns, Dashed, KeyValue, StackedBar, LegendGrid, Gauge, TH/TR-Klassen für Tabellen, TooltipCard, PillMark, Props `chart` für Recharts, ListaAlta (die Liste in einer vertikalen Karte, mit Seiten nach Höhe), Divergentes (was hinzugefügt und was entfernt hat), Quadro100 (von jeweils 100), Colunas (schwebende Spalten; Wasserfall und Trichter wurden als zu schwierig abgelehnt), useFitRows (wie viele Zeilen passen) und useFitHeight (Höhe eines Diagramms basierend auf dem verbleibenden Fensterplatz; misst neu, wenn die Karte darüber wächst).
`assets/painel.tsx`	Helfer für Karten: useMapColumns (Breite der Kartenspalte) und FillMap (Weltkarte, die ausfüllt).
`assets/ui.tsx`	Fertige Basiskomponenten (Card, Section, IconBox, Chip, Pill, Button, BottomActions, ListRow, ListCard, StatCard, DateBlock, FillEmpty, InfoTip, NavLoading, Spinner, ThemeToggle, FitScreen). Wiederverwenden oder anpassen anstatt neu zu erfinden. Wenn das Projekt bereits Äquivalente hat, die des Projekts verwenden.
`scripts/lint-ui.mjs`	`node <skill>/scripts/lint-ui.mjs src`: Durchsucht den geänderten Code (Hover, der verschiebt, Auslassungspunkte, farbige Ränder, schmale Breite, verbotene Schriftarten, feste Farbe, die eines der Themes bricht, "—", " · ", Kleinbuchstabe, "Label: Wert").
`scripts/check-ui.mjs`	`node <skill>/scripts/check-ui.mjs http://localhost:3000/route --out=prints`: Macht Screenshots in 320 und 390 px (mobil) und im nutzbaren Browserbereich in 1366×650, 1536×730 und 1920×950 (Notebooks und Monitor) sowie 2560×960, 2752×1100 (21:9 mit 125% Zoom unter Windows) und 3440×1300 (Ultraweitbildschirm 21:9), in den Themes Dunkel und Hell, und misst horizontalen und vertikalen Überlauf (Karte, die über die untere Kante des ersten Bildschirms hinausgeht oder höher als das Fenster ist), ähnliche sich wiederholende Listen, gestrecktes Diagramm und zu breite Listenzeile, "…", benachbarte Karten mit unterschiedlichen Höhen (auch innerhalb eines Hüllers ohne Hintergrund), Karte mit leerem Zwischenraum oder verteiltem Inhalt, unvollständiges Raster, Symbol ohne Container, Hover, der verschiebt, internes Scrollen, schmaler Inhalt, Schriftart, klickbar ohne kleine Hand, fast ausgerichtete Kartenränder zwischen Zeilen, "i"-Sprechblase außerhalb des Bildschirms (öffnet jede), Bildlaufleiste auf dem Mobilgerät, zu breite Tabellenzeile (jede wiederholte Zeile), gequetschter Text, Listenzeile mit Titel oder Beschreibung, die auf dem Mobilgerät umbricht, und leere oder Fehlerseite (wartet auf das Laden; wenn die Daten nicht gekommen sind, gilt der Check nicht). Jeder Fund kommt mit Größe und Theme. Benötigt Playwright im Projekt; `--user`/`--pass` für Seiten mit Passwort.

Die Skripte sind Leitfäden: Überprüfe jeden Fund und öffne vor allem die Screenshots und schau sie dir an.

1. Prozess (was am meisten Nacharbeit verursacht)

Mach nur, was verlangt wurde. Entferne, ersetze oder "vereinfache" niemals vorhandene Elemente ohne ausdrückliche Aufforderung. Wenn der Vorschlag erfordert, etwas zu entfernen, frage vorher. Im Zweifelsfall behalte es.
Respektiere den angefragten Breakpoint. Wurde eine Anpassung für Mobilgeräte angefragt: Das Web ändert sich nicht (verwende sm:/md:, um das Web zu erhalten, und umgekehrt).
Zeige vor dem Veröffentlichen, indem du alle Größen ansiehst. Bevor du sagst, dass es gut ist, öffne den Screenshot von jeder Größe des Checks (einschließlich 1366, 1536 und 2752, wo die Tabelle bricht und die Karte überläuft), nicht nur 390 und 1920. Auch für delegierte Agentenarbeit: Überprüfe selbst. Führe lokal aus, mache Screenshots auf dem Mobilgerät (390 px, und überprüfe 320 px) und im Web (1366×650, 1536×730 und 1920×950, dem tatsächlichen nutzbaren Browserbereich), in beiden Themes, schau dir jeden Screenshot wirklich an und mache nur mit ausdrücklicher Zustimmung Commit/Push/Deploy.
Neuer Bildschirm oder Redesign: zuerst die Informationen, dann das Layout. Folge references/informacao.md (und sieh dir die Blöcke von references/padroes-aprovados.md und die Fehler von references/armadilhas.md an): Inventar dessen, was das Produkt weiß (einschließlich allem, was der alte Bildschirm gezeigt hat), Benutzerfragen in der Reihenfolge der Dringlichkeit, Prioritätsstufen, Filter für jede Information, Positionskarte und den schriftlichen Plan. Die Komposition ergibt sich aus diesem Plan. Wähle selbst die Komposition und die Palette (die der Marke, wenn das Projekt eine hat; ansonsten die aus paletas.md, die zum Thema passt). Erstelle nicht mehrere Versionen oder Ansichten des Bildschirms, aus denen der Benutzer wählen kann. Baue einen, den besten, und sage in wenigen Zeilen, warum jedes Ding wo ist. Gehe niemals vom Skelett eines vorherigen Projekts aus und wiederhole nicht standardmäßig "4 Indikatoren + Raster von Karten + Listen".
Zweimal abgelehntes Detail = Optionen nebeneinander. Nur wenn der Benutzer dasselbe Detail (Position eines Chips, Schriftart) zweimal abgelehnt hat, zeige 2 oder 3 Variationen dieses Details in einem Screenshot. Niemals für den gesamten Bildschirm.
Nach dem Löschen oder Neuerstellen von Dateien starte den Entwicklungsserver neu (oder speichere das CSS erneut) vor dem Check: Tailwind könnte das alte CSS ohne die neuen Klassen weiter ausliefern.
Überprüfe mit der Checkliste (Abschnitt 10) vor jedem Screenshot. Wenn es keine Symmetrie gibt, ist es nicht fertig.

2. Typografie

Verboten (KI-Look): Inter, Roboto, Arial, Helvetica, system-ui als Markenschriftart, Geist, Poppins, Montserrat, Space Grotesk, Open Sans, Lato.
Gut und von KI wenig genutzt: Plus Jakarta Sans (bevorzugt und bereits genehmigt), Manrope, Onest, Figtree, Hanken Grotesk, Schibsted Grotesk, Instrument Sans, Albert Sans, Familjen Grotesk. Für hervorgehobene Titel: Bricolage Grotesque. Eine Familie pro App.
Zahlen mit font-variant-numeric: tabular-nums (tabular-nums). Keine Monospace-Schriftart mit durchgestrichener oder gepunkteter Null.
Hierarchie durch moderate Gewichtungen und Größen. Kleines Label oben (12 px, gedämpfte Farbe) und Wert darunter (16 px, semibold). Werte nebeneinander mit derselben Schriftgröße. Kein riesiger farbiger Text.
Jeder sichtbare Text beginnt mit einem Großbuchstaben, einschließlich einzelner Abkürzungen ("Do", "Fr"). Mitten im Satz normal schreiben: "Vs vorherigen Di", nicht "Vs Vorherigen Di". Titel in Satzfall, niemals GROSSBUCHSTABEN.

3. Farbe und Theme

Immer zwei Themes, hell und dunkel. Jede App wird mit beiden geboren: Folgt dem System-Theme (prefers-color-scheme) und hat einen Button zum Umschalten (ThemeToggle in assets/ui.tsx), wobei die Auswahl gespeichert wird. E-Mails und Vorschauen reagieren ebenfalls auf prefers-color-scheme. Kein Bildschirm darf nur in einem Theme existieren.
Farben immer über Token (var(--card), bg-card, text-muted-foreground). Nichts von #000, #fff, bg-black, text-white oder einzelnes Hex in Komponente, Diagramm oder SVG: Das bricht das andere Theme.
Dunkel: Sehr dunkler Hintergrund (nahe Schwarz), Karte eine Stufe höher, dezenter Rand, fast weißer Text. Hell: Sehr hellgrauer Hintergrund, weiße Karte, leichter Rand, fast schwarzer Text. Beide mit derselben Sorgfalt und in Screenshots überprüft.
Palette ist nicht fest, aber auch nicht lose. Es gibt kein Standard-"Schwarz + Orange": Verwende eine vollständige Palette aus references/paletas.md (Grautöne, Akzent, Skala und Serien, die zusammenpassen und bereits auf Kontrast und Farbenblindheit validiert wurden), ausgewählt nach Thema und gerendert gezeigt. Kein Zusammenfügen einzelner Farben (das Blau von einem Ort, das Gelb von einem anderen, das Rot von einem anderen). Ein Projekt mit Marke folgt seiner eigenen (z. B. hat MegaLab Orange gewählt); neue Farbe nur mit einem Kontrast von mindestens 3:1 gegen die Karte in beiden Themen und für Farbenblinde unterscheidbar (wenn der Agent den Leitfaden dataviz hat, verwende dessen Validierer).
Neutrale Basis, Farbe mit Zweck. Grautöne machen ~90% des Bildschirms aus. Eine Akzentfarbe pro App (Version pro Theme). Geordnete Daten (Größenordnung, Stufe, Bereich) verwenden die Skala einer einzigen Farbe (--seq-1..4), niemals ein Regenbogen aus Grau, Blau, Gelb und Rot. Serien ohne Ordnung verwenden --cat-1..3 in fester Reihenfolge. Rot/Gelb für Warnungen nur für echten Status, mit Symbol und Label. Grün ist niemals eine Markenfarbe, kann aber in Daten erscheinen: Chip für "verbessert"-Variation, guter Status und die kategoriale Serie 3 der validierten Paletten. Kein zufälliges Lila, kein Braun.
Zahl niemals farbig. Werte und Labels bleiben in der Textfarbe; die Datenfarbe geht in eine kleine Markierung daneben (Punkt, dünner Balken, neutrales Siegel mit farbigem Balken).
Variation nach oben und unten (wie in den Benutzerreferenzen): sanfter grüner Chip und sanfter roter Chip, immer mit Pfeil für diejenigen, die die Farben nicht unterscheiden können (DeltaChip). Gleich: grauer Chip.
Ähnliche Zustände (z. B. Falsch, Schwer, Gut, Leicht) benötigen klar unterschiedliche Farben voneinander.
Keine farbigen Ränder oder Ringe zum Hervorheben von Karten. Hervorhebung nur mit sanftem Hintergrund in der Farbe (bg-primary/10).
Text immer in beiden Themes lesbar, einschließlich Legenden und Tooltips von Diagrammen nach dem Klicken.

4. Layout und Symmetrie

Volle Breite im Web. Nichts von schmalem zentriertem Inhalt (max-w-* + mx-auto auf der Seite). Verwende Raster, um den Bildschirm zu füllen.
Breiter Bildschirm bekommt Spalten, nicht Strecken. Ab 1920 px und auf Ultraweitbildschirm 21:9 (2560 und 3440 px) erhöhe die Anzahl der Spalten mit 3xl: (1920 px) und 4xl: (2560 px), definiert im tokens.css; niemals min-[1920px]: (in Tailwind v4 verliert es gegen lg:), öffne Panels, die zuvor versteckt waren (Detail daneben, Tabelle neben dem Diagramm) und begrenze das Seitenverhältnis: Zeitdiagramm bis ~4:1, Balken und Karten bis ~2,5:1, Listenzeile bis ~720 px. Siehe references/dashboards.md Abschnitt 4.
Mobile First. Bequemer seitlicher Abstand (16 px), nichts Gedrängtes, Karussell mit horizontalem Atem, erstes Element mit Abstand oben.
Passt in die Bildschirmhöhe. Der Inhalt passt sich dem Fenster in beide Richtungen an, nicht nur in der Breite. Keine Karte, kein Diagramm, kein Bild und keine Karte mit fester Größe überschreitet die untere Kante des ersten Bildschirms oder ist höher als das Fenster (nur Listen setzen sich darunter fort und scrollen die Seite): Karten, Diagramme und große Bilder haben ihre Höhe durch das Fenster begrenzt (max-h-[calc(100dvh-<Kopfzeile>)], h-[min(…,60dvh)], SVG mit preserveAspectRatio="xMidYMid meet" innerhalb eines Containers mit definierter Höhe). Bemaße ein breites Visual niemals nur nach der Breite (w-full h-auto, aspect-[2/1]): Auf einem breiten Monitor oder einem Notebook überläuft es nach unten. Der erste Bildschirm (Kopfzeile, Indikatoren und der Hauptblock) passt vollständig in 390×844, 1366×650, 1536×730 und 1920×950 (nutzbarer Browserbereich, bereits abzüglich der Leisten; der gesamte Bildschirm ist kein geeignetes Maß). Verwende FitScreen aus assets/ui.tsx.
Bildschirm immer gefüllt. Der letzte Block dehnt sich bis zum Ende aus (flex-1). Keine halbe leere Bildschirmhälfte: Verwende echten Inhalt oder einen leeren visuellen Zustand (Symbol im Container + 1 Zeile).
Symmetrie ist obligatorisch:
- Karten nebeneinander mit derselben Höhe (items-stretch, h-full), und der innere Inhalt (Diagramm, Tabelle) wächst mit und nimmt die gesamte Höhe ein;
- gleiche Anzahl von Textzeilen links und rechts;
- durch das Raster gestreckte Karte hat innen keinen Hohlraum: Listenzeilen mit fester Höhe und der Block (Titel + Zeilen) vertikal zentriert, niemals justify-around/justify-between, das die Zeilen verteilt; vergleichbare Spalten (A x B) mit derselben Zeilenhöhe, damit die Zeilen ausgerichtet sind (siehe references/armadilhas.md, "Karte, die streckt");
- vollständige Rasterzeilen (keine 3 + 1 übrig);
- in derselben Spalte haben Elemente und Chips dieselbe Breite;
- Spalten von Tabellen mit fester Breite, ohne willkürliche Textumbruch. Tabelle passt in den Bildschirm: Horizontales Scrollen ist verboten.
Geschachtelte Flexbox-Raster haben keine Ränder oder Abstände, die visuelles Rauschen erzeugen.
Kartongrenzen unsichtbar, es sei denn, der Kartenhintergrund ist anders als der Seitenhintergrund. Niemals zwei benachbarte Karten mit sichtbarem Rand dazwischen: Entferne den Rand von einer (border-0) oder verwende einen gemeinsamen Container.
Auf Mobilgeräten haben Karten normalerweise 100% Breite (eine Spalte). Ausnahme: horizontales Karussell von kleinen Karten (2 bis 4 pro Zeile) mit seitlichem Scrollen.
Listenzeile hat eine maximale Breite von ~720 px für die Lesbarkeit, selbst im Raster. Bei größeren Karten ist die Listenzeile zentriert (mx-auto) oder mit max-w-*.

5. Dashboards und Daten

Die 7 Kompositionen aus references/dashboards.md wählen, die dem Informationsplan dient. Referenzbilder in references/exemplos-dashboards/ vor dem Zeichnen öffnen.
Diagramme sind das letzte Mittel. Eine Tabelle oder Liste mit Zahlen reicht in 70% der Fälle. Diagramm nur, wenn der Vergleich visuell schwer fällt (Trend über mehrere Punkte / Anteil eines Ganzen / Verteilung zwischen Gruppen).
Diagramm passt in eine Karte und hat einen Titel, der die Frage beantwortet ("Entwicklung der letzten Tage", nicht "Linienchart"). Kein Dashboard ohne Karten, nur das nackte Diagramm.
Das Messgerät (Gauge) ist das einzige Radialdiagramm erlaubt und sollte sparsam verwendet werden (eine Karte, die den Gesamtfortschritt zeigt). Kreise und Tortendiagramme sind verboten (schlecht für den Vergleich und nehmen viel Platz). Anteile eines Ganzen in horizontalen gestapelten Balken (StackedBar) mit einer direkten Lesart: "Von 100, 65".
Jeder Indikator hat einen Vergleich (vorherige Periode, Grenze, Ziel). Alleinstehende Zahl ohne Kontext ist keine Information.
Zahlen oben im Diagramm (chart Prop des DashCard-Kits). Das menschliche Auge vergleicht präzise über Zahlen, nicht über die Höhe von Balken. Jeder Balken/jeder Punkt erhält seinen Wert darüber.
Diagramm ohne Netzgitter, sauber, direkt im Weißraum der Karte. Gitternetz nur auf Karten, wenn die horizontale Referenz kritisch ist (Grenze, Ziel).
Farbcodierung in Diagrammen nach der ausgewählten Palette: geordnete Serie in --seq-1..4 (eine einzige Farbe mit Intensitätsstufen), kategoriale Serie in --cat-1..3 (bis zu 3 unterschiedliche Farben; mehr als 3 Serien in der Legende gruppieren). Kein zufälliges Blau. Balken derselben Serie haben dieselbe Farbe.
Listenzeile hat feste Höhe (in assets/dashboard.tsx, ListRow mit h-10), andernfalls Symmetrie zwischen benachbarten Karten verloren (siehe Abschnitt 4). Wenn der Inhalt größer ist, akzeptieren, dass er unterbrochen wird oder Beschreibung in einem Tooltip.
Tooltip beim Hover auf dem Datenpunkt im Diagramm, niemals fest sichtbar. Verwendung von TooltipCard aus assets/dashboard.tsx, die alle relevanten Informationen zeigt (Datum, Wert, Variation, Stichprobe).
Karte hat einen Titel, der die gemessene Größe identifiziert ("Tägliche aktive Benutzer", nicht "DAU"). Untertitel optional für Kontext.

6. Komponenten

ui.tsx und dashboard.tsx sind die Basis. Vor dem Erstellen einer benutzerdefinierten Komponente prüfen, ob es eine gibt, die angepasst werden kann. Wenn das Projekt bereits Äquivalente hat, die des Projekts verwenden.
Jede Komponente hat ihren Zweck:
- Card: Rahmen für einen Informationsblock. Weißes oder hellgraues (je nach Theme) abgerundetes Rechteck mit sanftem Schatten.
- Section: Horizontaler Abschnitt, der Cards gruppiert. Deckt die gesamte Breite ab (oder die Spalte, wenn es mehrere gibt).
- IconBox: Festes Rechteck, das ein Symbol enthält (Hintergrund in der Akzentfarbe oder neutral).
- Chip: Kleines Etikett mit Kategorie/Wert. Farbig oder neutral, immer abgerundet.
- Pill: Langer Chip, der einen Filter- oder Auswahlzustand darstellt.
- Button: Call-to-Action. Primär (gefüllt), Sekundär (Rahmen) oder Tertiär (Text).
- ListRow: Eine Zeile mit Symbol + Titel + Beschreibung + Wert + Trend. Feste Höhe.
- ListCard: Karte, die ListRows enthält.
- StatCard: Karte mit einem Indikator (Titel + großer Wert + Variation).
- DateBlock: Datumsanzeige ("Heute", "Gestern", "23. Okt"). Klein, gedämpft.
- FillEmpty: Platzhalter für leere Daten (Illustration + Nachricht + Aktion).
- InfoTip: "i"-Symbol, das einen Tooltip öffnet (Positionierung testen, um Überlauf zu vermeiden).
- ThemeToggle: Schalter hell/dunkel.
- FitScreen: Container, der die Höhe auf das Fenster begrenzt.
- Spinner/NavLoading: Ladeindikatoren.
Navigation mit NavLoading, das beim Seitenwechsel kurz erscheint.
Klickbares Element hat die kleine Hand (cursor-pointer). Standard <a> und <button> haben bereits, aber <div>, <span>, <tr> usw. benötigen explizit cursor-pointer.

7. Reaktionsfähigkeit

Breakpoints: sm: (640 px), md: (768 px), lg: (1024 px), xl: (1280 px), 2xl: (1536 px), 3xl: (1920 px), 4xl: (2560 px). Die letzten beiden sind im tokens.css definiert. Niemals benutzerdefinierten Breakpoint wie min-[1920px]: – er verliert gegen lg:, weil Tailwind v4 min-[...] nicht erkennt.
Mobilgerät (390 px) zuerst layouten, dann mit sm:, md: usw. für größere Bildschirme anpassen.
Web-Layout verwendet Raster der Spalten grid-cols-2 lg:grid-cols-3 xl:grid-cols-4 ... (breiter Bildschirm = mehr Spalten).
Ultraweitbildschirm fügt Spalten hinzu, streckt nicht: 4xl:grid-cols-6 4xl:grid-cols-8 und Inhalt wie Panels, die zuvor versteckt waren.
Karte innerhalb des Rasters hat col-span-1 (Standard), kann aber col-span-2 sein, wenn der Inhalt mehr horizontalen Platz benötigt (z. B. eine vollständige Tabelle). Vermeiden, dass eine einzelne Karte 3 oder mehr Spalten einnimmt, es sei denn, es gibt nur eine Karte auf dem Bildschirm.
Listenzeile bricht auf dem Mobilgerät nicht um: Titel und Beschreibung in einer Zeile mit Auslassungspunkten (truncate). Bei zu vielen Informationen in zwei Zeilen aufteilen oder in einem Tooltip verstecken.
Responsives Bild (img, svg) hat max-width: 100% und Höhe automatisch oder begrenzt durch das Fenster.

8. Barrierefreiheit und Bedienung

Jedes interaktive Element ist über die Tastatur erreichbar (tabindex, role, aria-label).
Focus-Stil sichtbar und kontrastreich, nicht entfernen (outline: none ohne Ersatz).
Farbe allein vermittelt keine Information. Diagramm: Form+Farbe+Text. Chip: Symbol+Farbe+Text (siehe DeltaChip).
Berührungsziel mindestens 44×44 px (auf Mobilgeräten und Tablets).
Animation deaktiviert, wenn der Benutzer prefers-reduced-motion bevorzugt (motion-safe:).

9. Code und Tests

Tailwind v4 mit @theme im tokens.css. tokens.css importieren (@import "tokens.css";). Nicht @config oder tailwind.config.js.
cn() verwendet clsx + tailwind-merge (twMerge). Nicht classnames oder einfaches join. twMerge() löst zuerst die letzte Klasse auf, also immer cn(baseClass, customClass).
next-themes für das Theme (ThemeProvider, useTheme). Nicht darkMode: 'class' manuell. ThemeToggle aus assets/ui.tsx verwenden.
Test auf dem richtigen Server. Nach dem Starten des Entwicklungsservers warten, bis das CSS geladen ist (1-2 Sekunden vor dem Check). Wenn du das CSS änderst, speichere die Datei erneut, damit Tailwind neu kompiliert.
Karte mit Hover, der Inhalte verschiebt: verboten (transform, transition auf Höhe/Breite/Position, die andere Elemente bewegt). Erlaubter Hover: Schatten vertiefen, Farbe ändern, Rahmen erscheinen, Overlay mit Aktion.
SVG sauber und ohne fill="currentColor", das außerhalb des Kontexts kaputt geht. Wenn das Symbol Teil des Themas ist, Token verwenden (stroke="var(--primary)").
Fehlerzustand hat einen FillEmpty mit Nachricht ("Verbindung fehlgeschlagen") und Aktion ("Erneut versuchen"). Nicht nur leeren Bildschirm anzeigen.
„…“ am Ende von Text (Auslassungspunkte) wird nicht verwendet: Verwende truncate für eine einzelne Zeile oder line-clamp-2 für zwei Zeilen. Nicht manuell ... einfügen.
Tooltip außerhalb des Bildschirms (InfoTip) wird automatisch nach links/rechts/oben/unten verschoben, je nach verfügbarem Platz. Ein Tooltip, der den Rand des Bildschirms überlappt, ist ein Fehler.

10. Checkliste vor dem Screenshot

Kreuze jedes Element an, bevor du den Screenshot zeigst:

Diese Regeln sind das Ergebnis von echtem Benutzerfeedback. Jede wurde aus einem konkreten Fehler gelernt, der den Benutzer gestört hat. Befolge sie als Anforderungen, nicht als Vorschläge.

bruno-baeta/clean-ui

Was ist clean-ui?

In Ihrer bevorzugten KI fragen

Dokumentation

Clean UI

Dateien der Skill

1. Prozess (was am meisten Nacharbeit verursacht)

2. Typografie

3. Farbe und Theme

4. Layout und Symmetrie

5. Dashboards und Daten

6. Komponenten

7. Reaktionsfähigkeit

8. Barrierefreiheit und Bedienung

9. Code und Tests

10. Checkliste vor dem Screenshot

Verwandte Skills

steipete/sag

steipete/oracle

steipete/peekaboo

mattpocock/design-an-interface

mattpocock/prototype

mattpocock/grill-me