Frontend autoral

Was macht Frontend autoral?

Antworte auf Deutsch, direkt. Liefere eine funktionierende und auf dem Bildschirm überprüfte Oberfläche, keinen Entwurf.

Das Problem, das diese Skill löst: KI-generierte Websites sehen alle gleich aus, weil sie aus einem vagen Plan ohne echten Inhalt entstehen und niemand das Ergebnis betrachtet. Hier erhält jedes Projekt eine vor dem Code geschriebene, aus dem Thema abgeleitete künstlerische Richtung; es wird in einem echten Browser gemessen und erst ausgeliefert, nachdem es gerendert und mit der Liste der Klischees verglichen wurde.

Hier werden vier Quellen vereint, bereits abgestimmt:

• taste-skill (leonxlnx): Bestandsaufnahme des Themas, Argument, Auslosung studierter Kompositionen von 247 preisgekrönten Websites, Ideen-Satz, lebendiges Element, Bilder aus offenen Archiven, Linter und Inspektor in einem echten Browser, Kritik in Durchgängen mit Notenschwellen. Werkzeuge in vendor/taste-skill/.
• Emil Kowalski (emilkowalski/skills): Animationsentscheidung, Kurven, Dauern, Physik, Smartphone-App-Gefühl, Worst-Case-Daten, Überprüfung in einer Vorher/Nachher-Tabelle.
• UX-Gesetze (lawsofux.com): Die 30 Gesetze als Fragen, die auf dem Bildschirm überprüft werden.
• logo-design (kaankiziltug): Logo-, App-Icon- und Favicon-Prozess mit SVG-Audit und Export des Websets. Werkzeuge in vendor/logo-design/.

Wenn die Quellen uneins sind: die aktuelle Anfrage > „Geschmack von Igor“ und references/cliches.md > diese Datei > references/movimento.md (entscheidet über Bewegung) > die englischen Referenzen in vendor/. Insbesondere: Bewegung hier nur mit Funktion, ohne Mindestanzahl animierter Elemente und ohne Eintritt in jeden Abschnitt; Scroll-Szenen aus der Auslosung kommen nur, wenn der Benutzer danach fragt.

<skill> in den Befehlen ist der Ordner dieser Skill. Die Skripte benötigen Node 22+ (Linter: 18+) und einen Chrome, Edge oder Chromium (der von Playwright reicht; scripts/achar-chrome.mjs findet ihn automatisch). Die für Icons benötigen Python 3 (unter Windows python).

Wann verwenden

• Website, Landing Page, Portfolio, Unternehmensseite, App-Bildschirm, Dashboard, Formular erstellen.
• Eine bestehende Oberfläche redesignen oder „verschönern“.
• UI/UX eines Bildschirms überprüfen: Hierarchie, Barrierefreiheit, Zustände, Copywriting, Responsivität, Animation.
• Eine Komponente mit Identität (nicht nur funktional) für ein Produkt erstellen.
• Logo, Symbol, App-Icon oder Favicon eines Projekts erstellen oder Varianten eines bestehenden Logos generieren.

Nicht verwenden für: README und GitHub-Profil-Art (Skill readme-designer), Grafiken und Datenvisualisierung (Skill dataviz), Präsentationen und Dokumente.

Modus auswählen

• Seite erstellen (Website, Landing, Portfolio; neues Projekt oder komplettes Redesign): gesamter Ablauf.
• App-Bildschirm (Dashboard, Admin, Einstellungen, Posteingang, gefilterte Liste, Editor): Lies vendor/taste-skill/references/app-screens.md vollständig, bevor du beginnst. Es hat eine eigene Sequenz, eigene Auslosung (draw.mjs --app --kind <typ>) und eigene Regeln (dezente Ränder, kleine Labels und sich wiederholende Panels sind dort normal; Verlauf, Glanz, farbiges Quadrat-Icon, Regenbogendiagramm und erfundene Eitelkeitszahl nicht). Verwende den untenstehenden Ablauf mit --app im Tor; das lebendige Element und der Bild-Boden entfallen. Eine Produktseite, die die App zeigt, ist eine Seite; die App-Fragmente darin folgen den App-Regeln und erhalten data-ui.
• Weiterentwickeln (es existiert bereits ein visuelles System, DESIGN.md, BRAND.md, Tokens, Tailwind-Theme, Komponentenbibliothek): die bestehende Richtung bestimmt. Lies zuerst, verwende Tokens und Komponenten wieder und schlage nur eine Identitätsänderung vor, wenn der Benutzer danach fragt. Überspringe die Auslosung (oder verwende --keep palette,type, um nur die Komposition zu ziehen), aber durchlaufe das Tor und die Klischee-Liste.
• Überprüfen (Audit: „Was ist hier schlecht?“, „Überprüfe die Animationen“): nur Schritte 1 und 5, im aktuellen Zustand. Ergebnisse in einer Tabelle Wo | Vorher | Nachher | Warum, gruppiert nach Schweregrad, ohne Vorwort (references/revisao.md §11).
• Einzelanpassung („kühner“, „ruhiger“, „Schriftart tauschen“, „das animieren“): ändere nur das Gewünschte, innerhalb der bestehenden Richtung. Siehe „Anpassungen“ in references/oficio.md und für Animation references/movimento.md.
• Icon oder Logo (Logo, Marke, App-Icon, Favicon): references/icones.md. Bei jedem Website- oder App-Projekt läuft der leichte Modus von dort in Schritt 4, damit das Projekt ein eigenes Icon erhält.

Ablauf

Jeder Schritt ist erst abgeschlossen, wenn das Bereit-Kriterium erfüllt ist.

1. Das Thema verstehen. Lies die Anfrage und den vorhandenen Code. Beantworte für dich, jeweils in einer Zeile: Was ist das Produkt, für wen ist es, was ist die Hauptaufgabe, ob es eine Seite oder ein App-Bildschirm ist, welcher reale Inhalt existiert (Texte, Bilder, Daten, Logo, Marke) und welches Bild existiert wirklich. Schließe das Inventar von 8 bis 12 Dingen, die nur dieser Kunde hat (references/direcao.md §1). Fehlt das Wesentliche (was ist das Produkt oder für wen), mache eine Runde mit bis zu 4 Fragen in einem Stapel. Fehlt nur der Geschmack, entscheide und teile mit, was du entschieden hast.

   • Bereit, wenn Produkt, Zielgruppe, Aufgabe, Typ, Inventar und Bild-Inventar klar sind und die Lücken eine Antwort oder dokumentierte Entscheidung haben.

2. Die Designrichtung schreiben vor jedem CSS, in DESIGN.md im Projektverzeichnis (Vorlage in assets/DESIGN.template.md; in einer einzigen Datei, oben in der Antwort). Methode in references/direcao.md:

   • das Argument: die Seite als Behauptungen mit Beweis, eine pro Abschnitt; ein Abschnitt ohne Behauptung entfällt;
   • die Auslosung der Komposition (vendor/taste-skill/scripts/draw.mjs ... --options 3), empfohlen für Seiten: wähle die Option, die etwas aus dem Inventar trägt, nicht die vertrauteste, und filtere die Palette und den Typ nach Thema und Klischees;
   • Konzept in einem Satz für die Szene, Listen „sieht aus / sieht nicht aus“;
   • der Ideen-Satz („Auf dieser Seite wird [etwas aus dem Inventar] zu [dem Gestaltungsmittel]“), der Konkurrenztest und das lebendige Element (eine Interaktion aus der Idee, mit echtem Inhalt);
   • Signatur; Palette von 4 bis 6 benannten Farben mit Rolle und Kontrast; 1 oder 2 Schriftfamilien mit einer Skala von bis zu 5 Größen; Raster mit gleichen Rändern, Rhythmus und Formregel; Bewegungsregel; Bildquelle; woher das Icon kommt;
   • ASCII-Drahtmodell jedes Abschnitts, benachbarte mit unterschiedlichen Formen.

   Führe dann den Tausche-Test durch: „Wenn ich den Produktnamen austauschte, würde diese Richtung für einen beliebigen Konkurrenten passen?“ Wenn ja, überarbeite und teile mit, was sich geändert hat. Prüfe gegen references/cliches.md, einschließlich §11 (ein Klischee zu entfernen darf nicht nur Leere hinterlassen).

   • Bereit, wenn jede Wahl einen Grund hat, der mit dem Produkt, der Zielgruppe oder dem Inhalt zusammenhängt, der Ideen-Satz den Konkurrenztest besteht und kein Element ohne Begründung in ein Klischee fällt.

3. Den Inhalt schreiben als reinen Text-Rahmen vor dem Markup, mit references/copy.md: Überschriften, die in zwei Zeilen in voller Breite passen (berechnen), der unterstützende Satz direkt darunter, eine Hauptaktion mit Verb und Objekt, jeder Abschnitt mit vollständigem Inhalt. Wo Beweise fehlen (Zahl, Testimonial, Kunde, Bewertung), verwende sichtbare Platzhalter wie [echtes testimonial hier], anstatt zu erfinden; wo nur Inhaltsdetails fehlen (Gerichtsname, Zimmername), verwende plausible Beispiele und liste sie zur Bestätigung auf.

   • Bereit, wenn kein Text auf der Website eines anderen Unternehmens stehen könnte, kein Beweis erfunden ist und die Beispiele aufgelistet sind.

4. Bauen, ohne Bewegung. Bewegung im Kopf ausgeschaltet: Eine Seite, die Animation braucht, um fertig auszusehen, ist nicht fertig. Reihenfolge: Tokens (Farbe, Schriftart, Abstand, Form, Kurven), der Hero exakt wie gezeichnet (Desktop und Mobil), jeder Abschnitt nach seinem Drahtmodell, das die Idee bis zu Preis, FAQ und Fußzeile trägt, Bilder (references/imagens.md: eigene, generierte, offene Archive mit assets.mjs, aus dem Thema gezeichnet), das lebendige Element, der Rahmen (gleiche Ränder, Titel in jedem Abschnitt, kein leerer Bereich), Zustände und Semantik, Favicon und Icons (references/icones.md, leichter Modus). Folge references/oficio.md, references/ux.md und references/leis-ux.md. vendor/taste-skill/assets/base.css ist eine optionale neutrale Basis.

   • Verwende den vorhandenen Stack des Projekts. Keine neuen visuellen Abhängigkeiten ohne funktionalen Grund.
   • Bereit, wenn die Seite ohne Konsolenfehler läuft, ohne horizontales Scrollen auf dem Handy, alle relevanten Zustände (hover, focus-visible, active, disabled, loading, error, empty), Worst-Case-Daten getestet (references/ux.md §9) und ein eigenes Icon vorhanden ist.

5. Messen, betrachten, korrigieren. Führe das Tor aus: node <skill>/scripts/inspecionar.mjs <url-oder-index.html> --src <code-ordner> (mit --app bei App-Bildschirmen). Es führt den Linter und den Inspektor bei 1440, 768 und 390 Pixeln aus und speichert Screenshots in .taste-skill/inspect/. Korrigiere alle FEHLER. Öffne dann alle Screenshots und kritisiere mit references/revisao.md: KI-Test, 15 Durchgänge, Rubrik mit Schwellen, Kritik im Format der Runde. Korrigiere die 3 schwerwiegendsten Probleme, messe und betrachte erneut; maximal 3 Runden.

   • Bereit, wenn es 0 FEHLER gibt, die Durchschnittsnote ≥ 8 ist, kein Kriterium < 7 und die Problemliste leer ist. Wenn das nicht erreichbar ist, teile mit, was unerledigt ist, und die tatsächliche Note.

6. Bewegen, nur mit Funktion. Jetzt die Bewegung, entschieden durch references/movimento.md: Häufigkeit (Tastaturaktion und den ganzen Tag gesehene Dinge animieren nicht), Zweck, Kurve (ease-out stark, niemals ease-in), Dauer (< 300 ms bei Oberfläche), Druck (scale(0.97)), Ursprung am Auslöser, Hover nur mit Maus, prefers-reduced-motion. Maximal ein orchestrierter Moment pro Seite, in der Regel das lebendige Element oder die Signatur. Führe das Tor erneut aus und überprüfe anhand der Screenshots, dass nichts verschwunden ist.

   • Bereit, wenn jede Animation die Frage „Wozu?“ beantwortet und das Tor weiterhin 0 FEHLER hat.

7. Überprüfen und berichten. Abschließende Checkliste und Bericht von references/revisao.md §9 und §10.

Ohne Rendermöglichkeit (kein Browser und keine Möglichkeit, einen zu installieren)? Führe nur den Linter aus, sage dies im Bericht und führe die Überprüfung durch, indem du den Code gegen die Checkliste liest. Sage nicht, dass du auf dem Bildschirm überprüft hast.

Design auf einen Blick

Die Details stehen in references/oficio.md, references/cliches.md und references/leis-ux.md.

• Jede visuelle Entscheidung hat einen Grund, der mit dem Produkt, der Marke, dem Inhalt oder der Nutzung zusammenhängt. Bevor du ein Element hinzufügst, frage, ob es Verständnis, Funktion, Ästhetik oder Erfahrung verbessert. Wenn nicht, kommt es nicht rein.
• Die Identität kommt vom Thema, niemals vom Trend. Futuristisch, Tech oder Minimalistisch sind keine Standardeinstellungen; sie kommen nur, wenn das Thema es verlangt. Minimalismus ist nicht das Fehlen von Persönlichkeit.
• Autorisches Aussehen, konventionelle Mechanik (Jakobs Gesetz). Kühnheit liegt in Typografie, Farbe, Bild und Komposition; Menü, Link, Button und Formular funktionieren wie auf jeder Website.
• Kühnheit nur an einer Stelle, in der Idee-Signatur. Der Rest bleibt diszipliniert. Nimm vor der Auslieferung ein Accessoire weg. Aber ein Ornament zu entfernen bedeutet nicht, Leere zu hinterlassen: Der Platz geht an Maßstab, vollständigen Inhalt, Bild des Themas oder Farbfeld.
• Die Komposition folgt dem Inhalt. Jeder Abschnitt wählt seine Form nach dem, was er zeigt: Liste, Sequenz, Vergleich, großes Bild, Zitat, Tabelle. Benachbarte wiederholen keine Form. Nicht alles ist eine Karte, nicht alles ist zentriert, nicht alles ist ein 3-Spalten-Raster.
• Hierarchie vor Symmetrie. Ein Hauptelement pro Bildschirm; 2 oder 3 Größen erledigen die Arbeit, bis zu 5 insgesamt; Überschriften in bis zu zwei Zeilen. Asymmetrie innerhalb des Rasters, Außenränder immer gleich.
• Farbe mit Rolle. Ein Hintergrund, eine Tinte, 1 oder 2 getönte Neutrale, ein Akzent an 1 bis 3 Stellen (Von Restorff). Flächen nach Tonstufe, ohne Verlauf, Glow, Unschärfe, Glas oder Schatten im Ruhezustand.
• Typografie als Stimme. 1 oder 2 Familien, gewählt nach dem Charakter des Produkts, lesbare Körpergröße (≥ 16 px, 45 bis 75 Zeichen pro Zeile) in voller Tinte.
• Bild, das zeigt. Real vom Projekt, generiert, aus offenem Archiv mit Quellenangabe oder aus dem Thema selbst gezeichnet; ein dominantes Bild schlägt sechs kleine; niemals graue Box oder generische Bank.
• Bewegung nur mit Funktion, schnell, unterbrechbar, mit ease-out und korrektem Ursprung. Immer prefers-reduced-motion.
• Barrierefreiheit ist nicht verhandelbar: AA-Kontrast, sichtbarer Fokus, Tastaturnavigation, korrekte Semantik, alt bei inhaltlichen Bildern, Ziele ≥ 44 px, Zoom erlaubt.

Geschmack von Igor

Ausgangspunkt, kein Rezept. Die aktuelle Anfrage gewinnt immer.

• Das Thema ändert sich mit jedem Projekt. Verwende niemals Palette, Schriftart, Motiv oder Copy aus früheren Arbeiten wieder, ohne dass er darum bittet. (Die Auslosung von taste-skill hilft: Sie erinnert an die vorherigen.)
• Mag ein klares, gut umgesetztes Thema, das im gesamten Set präsent ist, nicht schüchterne Verzierung.
• Konsistenz über allem: Ein „roher“ Abschnitt inmitten der gestalteten stört. Wenn einer heraussticht, erstelle ihn im gleichen Muster neu.
• Subtile Bewegung. Ein Objekt, das den Bildschirm durchquert, ist verboten.
• Natürlicher Text, ohne erzwungenen Effekt-Slogan, ohne Haftungsausschluss oder Fußzeile, den niemand bestellt hat.
• „Verbessern“ eines Abschnitts bedeutet, das Aussehen neu zu gestalten, während der Inhalt erhalten bleibt, nicht zu entfernen.
• Wenn er ein Element ablehnt, entferne nur dieses Element. Interpretiere den Rest nicht neu.

Fallstricke

• Der erste Impuls ist das Klischee. Zentrierter Hero mit Titel, Untertitel, zwei Buttons und Verlauf; drei Karten mit Icon in einem farbigen Quadrat; Zahlenabschnitt; Testimonials. Wenn die erste Idee zu schnell kam, ist es wahrscheinlich der Standard. Gehe zurück zum Inventar.
• Einem Klischee ausweichen, indem man in ein anderes fällt. Weg von Lila hin zu Cremefarbe + Serife + Terrakotta oder zu Schwarz + Säuregrün ist nur der Austausch eines KI-Standards gegen einen anderen. Siehe die „fünf visuellen Standardmuster“ in references/cliches.md.
• Saubere und dünne Seite. Ohne Verzierungen und nichts an ihrer Stelle verliert gegen die Seite voller Klischees. Vollständiger Inhalt, große Schriftart, echte Bilder.
• Kategorie-Idee. „Brot“ passt für jede Bäckerei. Wenn der Ideen-Satz für den Konkurrenten funktioniert, gehe zurück zum Inventar.
• Erfundener Inhalt zum Füllen. Zahl ohne Quelle, Logo eines fiktiven Kunden, Testimonial, zufälliger Avatar, generischer Dashboard-Mockup. Verwende einen Platzhalter oder schneide den Abschnitt.
• Dreizeilige Überschrift.

…

[gekürzt für die Übersetzung]