pretty-ui

Was macht pretty-ui?

KI-erstellte Bildschirme sehen gleich aus, weil niemand eine Wahl getroffen hat. Das Modell füllt jede Lücke mit der häufigsten Antwort, die es gesehen hat, und das Ergebnis ist eine Seite, die zu jedem beliebigen Produkt gehören könnte.

pretty-ui behebt das in der Reihenfolge, die ein Designer wählen würde: eine Richtung auswählen, sie aufschreiben, dann überall anwenden und das Ergebnis prüfen. Die Wahl trifft die Person anhand von echten Optionen, die sie sehen kann, nicht der Agent allein.

Der Ablauf

Folge diesen Schritten der Reihe nach. Teile dem Benutzer mit, in welchem Schritt du dich befindest.

1. Das Projekt lesen

• Finde heraus, was gebaut wird: eine Seite, die gelesen und gescrollt wird (Landingpage, Marketingseite, Portfolio), ein Web-App-Bildschirm, in dem Leute arbeiten (Dashboard, Einstellungen, Posteingang) oder eine mobile App.
• Finde den Stack: einfaches HTML, Tailwind, shadcn/ui, React, Vue, Svelte, React Native, SwiftUI, Compose oder Flutter. Arbeite in diesem Stack. Migriere ihn niemals.
• Suche nach einem vorhandenen visuellen System: DESIGN.md, AGENTS.md oder CLAUDE.md Designnotizen, Tailwind- oder shadcn-Theme-Variablen, ein Markenleitfaden, ein Logo. Wenn die Marke bereits Farben und Schriftarten hat, behalte sie bei. Die Richtungen in Schritt 3 variieren dann Layout, Schriftskalierung, Dichte und Akzente innerhalb der Marke, nicht die Marke selbst.
• Sammle echte Inhalte: den Produktnamen, was es tut, für wen es ist, echte Zahlen, echte Screenshots. Platzhalterinhalte lassen jedes Design generisch aussehen.

2. Prüfung (nur wenn bereits eine UI existiert)

Lies references/tells.md. Führe den Prüfer auf den Dateien aus, die die UI rendern:

node <skill>/scripts/check.mjs <dateien oder ordner>

Liste die Ergebnisse für den Benutzer auf, gruppiert nach Schweregrad, mit Datei und Zeile. Füge alles hinzu, was der Prüfer nicht sehen kann, indem du den Code liest: drei identische Karten, alles zentriert, kein klarer Brennpunkt, Fülltext. Wenn der Bildschirm bereits gut gestaltet ist, sage das und schlage zwei oder drei kleine Verbesserungen anstelle eines Redesigns vor.

3. Drei Richtungen anbieten

Lies references/systems.md. Es listet 24 vollständige Designsysteme auf, 12 für das Web und 12 für mobile Apps, jedes mit einer öffentlichen DESIGN.md.

1. Wähle drei Systeme, die sich bewusst unterscheiden: zum Beispiel eines leicht und redaktionell, eines dunkel und dicht, eines weich und freundlich. Passe sie an die Plattform (Web oder App) und die Welt des Produkts an. Biete niemals drei Variationen desselben Looks an.
2. Rufe die DESIGN.md jedes Systems von seiner URL ab.
3. Baue denselben Hauptbildschirm in jeder Richtung, mit denselben echten Inhalten, als eigenständige HTML-Dateien:
   • pretty-ui/directions/a-<slug>.html, b-<slug>.html, c-<slug>.html
   • Webseiten bei 1440×900, mobile Bildschirme bei 390×844. Inline-CSS, Google Fonts-Links, keine externen Bilder.
4. Mache sie einfach vergleichbar:
   • Wenn die Codex Design Canvas-Werkzeuge verfügbar sind (z. B. create_canvas und add_node), platziere die drei Dateien nebeneinander auf einer Leinwand und öffne sie.
   • Andernfalls führe node <skill>/scripts/compare.mjs pretty-ui/directions/*.html --out pretty-ui/directions/index.html aus und sage dem Benutzer, er solle diese Datei öffnen.
5. Frage den Benutzer, eine auszuwählen oder Teile zu kombinieren ("As Typografie mit Cs Farben"). Wenn er dich gebeten hat zu entscheiden, wähle diejenige, die am besten zum Produkt passt, und begründe dies in einem Satz.

Wenn die Marke festgelegt ist, verwenden die drei Richtungen die Farben und Schriftarten der Marke und unterscheiden sich stattdessen in Layout, Skalierung und Dichte.

4. Das System aufschreiben

• Speichere das gewählte System als DESIGN.md im Projektstamm. Behalte sein Format: YAML-Frontmatter mit Tokens, dann Übersicht, Farben, Typografie, Layout, Formen, Komponenten und Dinge, die man tun und lassen sollte.
• Wende alle Änderungen, die der Benutzer gewünscht hat (eine Markenfarbe, eine andere Überschriftenschriftart), auf die Datei an, nicht nur auf den Code.
• Füge eine Zeile zu AGENTS.md (und CLAUDE.md, falls das Projekt eine hat) hinzu: Folge DESIGN.md für jeden Bildschirm: Farben, Typografie, Abstände, Radien und Komponenten. Codex liest AGENTS.md automatisch, aber nicht DESIGN.md.
• Für shadcn- oder Tailwind-Projekte, ordne die Tokens den Theme-Variablen zu (--background, --primary, --radius und die restlichen). Jede Systemseite verlinkt ein fertiges shadcn-Theme: npx shadcn@latest add https://codexdesign.io/r/<slug>.json.

5. Anwenden, Durchgang für Durchgang

Arbeite den gesamten Bildschirm eine Ebene nach der anderen ab, wie die Überprüfung eines Designers. Behalte die Funktionen, Inhalte und die Reihenfolge der Abschnitte bei, es sei denn, der Benutzer wünscht etwas anderes.

1. Tokens. Ersetze fest codierte Farben, Größen und Radien durch die Tokens des Systems.
2. Typografie. Höchstens zwei Schriftfamilien. Verwende die Skalierung des Systems. Stelle die eine wichtigste Zeile auf dem Bildschirm klar als die größte dar. Tabellenziffern für Zahlen, die ausgerichtet werden.
3. Abstände und Layout. Eine Abstandseinheit aus dem System und ihre Vielfachen. Richte alles am Raster oder Bildschirm-Padding aus. Gruppiere zusammengehörige Dinge eng und trenne Gruppen großzügig.
4. Farbe. Neutrale Farben tragen den Bildschirm. Die Primärfarbe erscheint dort, wo der Benutzer handelt, etwa einmal pro Ansicht. Diagramme verwenden die Diagrammfarben des Systems in der richtigen Reihenfolge.
5. Komponenten. Schaltflächen, Eingabefelder, Karten, Listen und Navigation folgen dem Abschnitt Komponenten des Systems. Echte Symbole (Lucide, Phosphor, SF Symbols, Material Symbols), niemals Emojis als Symbole.
6. Texte. Klare, spezifische Wörter aus dem Produkt. Entferne Füllwörter ("nahtlos", "freischalten", "optimieren"). Überschriften sagen, was die Sache ist oder tut.
7. Details. Hover-, Fokus- und Gedrückt-Zustände; leere, Lade- und Fehlerzustände; Kontrast von mindestens 4,5:1 für Text.
8. Bewegung. Nur wo sie etwas erklärt: eine Zustandsänderung, ein Übergang zwischen Bildschirmen. Kein Einblenden bei jedem Abschnitt, keine pulsierenden Dekorationen.

Für mobile Apps lies auch references/app.md.

6. Prüfen

• Führe den Prüfer erneut auf den geänderten Dateien aus und behebe jeden Fehler sowie so viele Warnungen wie sinnvoll.
• Betrachte das Ergebnis. Wenn Playwright oder ein Browser-Werkzeug verfügbar ist, erstelle einen Screenshot bei 1440 und 390 Breite (oder der Gerätegröße für Apps) und behebe, was falsch aussieht: kein Brennpunkt, beengte Gruppen, schlecht umbrechender Text, niedriger Kontrast.
• Erstelle für ein Redesign eine Vorher-Nachher-Seite, die der Benutzer teilen kann:

node <skill>/scripts/compare.mjs before.html after.html --labels "Vorher,Nachher" --out pretty-ui/before-after.html

7. Bericht

Teile dem Benutzer kurz mit: die gewählte Richtung und warum, die geänderten Dateien, was der Prüfer vorher und nachher gefunden hat, und alles, was noch seine Entscheidung erfordert (echte Fotos, ein Logo, Texte, die nur er schreiben kann).

Regeln, die immer gelten

• Zeige Optionen, bevor du dich auf eine festlegst. Wähle niemals stillschweigend einen Stil.
• Behalte die Marke, den Inhalt und den Stack des Benutzers bei.
• Ein Designsystem pro Produkt, festgehalten in DESIGN.md, überall befolgt.
• Keine violetten oder lila Farbverläufe, Text mit Farbverlauf, Glasmoorphismus-Panels, leuchtende Schatten, Emoji-Symbole, Pill-Badges über jeder Überschrift oder Reihen identischer Symbolkarten, es sei denn, der Benutzer wünscht sie ausdrücklich.
• Ersetze nicht ein Klischee durch ein anderes. Creme mit einer Serifenschrift und einem Terrakotta-Akzent oder fast schwarz mit einem säuregrünen Akzent sind die neuen Standardeinstellungen; verwende sie nur, wenn die Welt des Produkts sie erfordert.
• Dekoration zu entfernen ist die halbe Arbeit. Fülle den Raum mit echten Inhalten, größerer Schrift für das Wichtige und einem einprägsamen Element, das aus dem Produkt selbst stammt.

Dateien

• references/systems.md: die 24 Designsysteme, mit Plattform, Stil und DESIGN.md-URL.
• references/tells.md: was eine UI KI-gemacht aussehen lässt und was man stattdessen tun sollte.
• references/app.md: Regeln für iOS-, Android- und plattformübergreifende App-Bildschirme.
• scripts/check.mjs: ein statischer Prüfer für KI-typische Merkmale in HTML, CSS, JSX, TSX, Vue und Svelte-Dateien. Node 18+, keine Abhängigkeiten.
• scripts/compare.mjs: schreibt eine HTML-Seite, die mehrere Bildschirme nebeneinander anzeigt, um eine Richtung auszuwählen oder Vorher und Nachher zu zeigen.