anti-ai-design — 36-Stil-UI-Gate (kein KI-Chrome)

anti-ai-design

Auto-orchestrierende UI-Design-Skill mit verbindlichen Anti-KI-Regeln. Erzeugt unmöglich schöne, visuell eigenständige Bildschirme – niemals die generische KI-Ergebnisse.

Wann verwenden

Aktivieren Sie diese Fähigkeit, wenn der Benutzer Folgendes verlangt:

• Eine Landing Page, einen Hero-Bereich oder einen Marketing-Bildschirm
• Ein Dashboard, Admin-Panel oder eine datenreiche Oberfläche
• Einen mobilen App-Bildschirm (iOS, Android) oder eine responsive Web-UI
• Einen Onboarding-Flow, ein Anmeldeformular oder einen Produkt-Rundgang
• Einen Bildschirm für eine Komponentenbibliothek oder ein Designsystem
• „Mach es besser aussehen", „gestalte dies neu", „erstelle eine UI für …"

Nicht verhandelbare Interaktionsvereinbarung

Bevor Sie ein Design-Ergebnis generieren, MÜSSEN Sie diese drei Entscheidungen in der angegebenen Reihenfolge klären:

1. Plattform-Umfang – Fragen Sie den Benutzer, für welche Plattformen generiert werden soll: mobile, tablet, desktop.
   • Mehrfachauswahl ist erlaubt.
   • Wenn der Benutzer nur mobile und desktop auswählt, generieren Sie NICHT tablet.
   • Wenn die Plattform bereits explizit und eindeutig genannt wurde, bestätigen Sie dies durch Wiederholung und fahren fort.
2. Farbrichtung – Klären Sie die Farbrichtung der Marke gemäß dieser Reihenfolge:
   • Wenn der Benutzer genaue Farben angegeben hat, verwenden Sie diese.
   • Andernfalls, wenn der Benutzer eine Marken-/Themenstimmung angegeben hat, bieten Sie 2–3 geeignete Palettenrichtungen an und bitten Sie ihn, eine auszuwählen.
   • Andernfalls wählen Sie automatisch eine Palette aus, die zur Produktkategorie passt, und teilen Sie klar mit, dass sie automatisch ausgewählt wurde.
3. Stilrichtung – Präsentieren Sie 2–3 Stiloptionen und lassen Sie den Benutzer eine auswählen.

Überspringen Sie diese Entscheidungen nicht, es sei denn, die Konversation enthält bereits eine eindeutige Antwort.

Ausführungsmodus

Interaktiv (Standard)

• Fragen Sie den Benutzer nacheinander nach jeder fehlenden Wahl: Plattform → Farbe → Stil.
• Warten Sie auf seine Antwort, bevor Sie mit der nächsten Phase fortfahren.
• Präsentieren Sie Optionskarten für die Stilrichtung mit einem EMPFOHLEN-Label.

Nicht interaktiv

Aktivieren Sie diesen Modus, wenn der Benutzer:

• die Fähigkeit mit mode: non_interactive oder einem gleichwertigen Flag aufruft,
• einen einmaligen CLI-Befehl, einen Hintergrund-Codex-Job oder eine scriptgesteuerte Pipeline ausführt, oder
• eine Eingabeaufforderung ohne vorherigen Gesprächskontext bereitstellt (keine Chat-Runden vor der Anfrage).

Automatische Auswahlregeln (in der angegebenen Reihenfolge angewendet):

1. Plattform – falls nicht angegeben, standardmäßig desktop. Wenn Mobile-First-Signale vorhanden sind (Mobile-App-Beschreibung, React Native-Erwähnung, „Telefon“-Kontext), standardmäßig mobile.
2. Farbrichtung – wählen Sie die am besten geeignete Palette für den erkannten Projekttyp aus, ohne Alternativen anzubieten.
3. Stilrichtung – wählen Sie aus den 2–3 Kandidatenstilen für diesen Projektkontext denjenigen aus, der als EMPFOHLEN markiert wäre. Präsentieren Sie keine Optionskarten.

Erforderlicher Ausgabe-Header vor der Generierung (nur für nicht interaktiv):

Automatisch ausgewählt:
- Plattform: [ausgewählte Plattform(en)]
- Palette: [Palettenname] — Primärfarbe [Hex-Wert]
- Stil: [Stilname] — [ein Satz zur Stimmung]
Fahre mit der Bundle-Generierung fort.

Stellen Sie keine klärenden Fragen. Präsentieren Sie keine Optionskarten. Fahren Sie nach dem Header direkt mit Phase 3 fort.

Ausgabe-Vereinbarung – CJX-Bundle, keine einzelne lose HTML-Datei

Die Standardausgabe ist ein Bundle-Verzeichnis für das Projekt, keine einzelne lose HTML-Datei.

<app-slug>-design/
  html/
    landing-page.html
    mobile-<screen>.html
    tablet-<screen>.html
    desktop-<screen>.html
  css/
    foundation.css
    shared.css
    landing-page.css
    mobile-<screen>.css
    tablet-<screen>.css
    desktop-<screen>.css
  js/
    app.js
    landing-page.js
    mobile-<screen>.js
    tablet-<screen>.js
    desktop-<screen>.js

Bundle-Regeln

• html/ enthält eine HTML-Datei pro generierter Bildschirm-/Plattformkombination.
• css/foundation.css enthält ausschließlich die eingefrorenen Design-Tokens.
• css/shared.css enthält gemeinsame Primitive, Dienstprogramme, Bewegung, Glas-Rezepte, Fokus-Zustände und gemeinsame Layout-Muster.
• Bildschirmspezifisches CSS wird in eine bildschirmspezifische Datei eingefügt.
• js/app.js enthält gemeinsame UI-Helfer, State-Toggles, Mock-Daten-Handling und barrierefreie Interaktionen.
• Bildschirmspezifisches JS wird nur bei Bedarf in eine bildschirmspezifische Datei eingefügt.
• Wenn der Benutzer später einen Export als einzelne Datei wünscht, können Sie zusätzlich einen eigenständigen HTML-Export bereitstellen, aber die Standardvereinbarung ist das CJX-Bundle.

Plattform-Dateinamensregeln

• Landing Pages bleiben semantisch: landing-page.html, landing-page.css, landing-page.js
• App-Bildschirme verwenden Plattform-Präfixe:
  • mobile-<screen>.html
  • tablet-<screen>.html
  • desktop-<screen>.html
• Generieren Sie Dateien nur für die ausgewählten Plattformen.
• Wenn der Benutzer mobile und desktop ausgewählt hat, darf das Ausgabe-Bundle keine tablet-*-Dateien enthalten.

Warum separate Dateien statt einer einzigen responsiven HTML-Datei

Verwenden Sie standardmäßig separate Plattformdateien, weil:

• jede Plattform eine materiell andere IA, Navigation, Dichte und CTA-Platzierung haben kann,
• Überprüfung und Übergabe einfacher sind, wenn jedes Ziel isoliert ist,
• die CJX-Überprüfung klarer ist, wenn die Bildschirmabsicht explizit ist,
• Desktop/Tablet/Mobile oft eine unterschiedliche Hierarchie benötigen, nicht nur unterschiedliche Breakpoints.

Eine einzige responsive HTML-Datei ist nur akzeptabel, wenn der Benutzer explizit die Auslieferung als eine Datei anfordert.

Sub-Skill-Routing

Laden Sie NUR die Referenzdatei, die für den aktuellen Schritt benötigt wird. Laden Sie NICHT alle Dateien auf einmal.

Aufgabe	Laden	Details
Design-Stil / künstlerische Richtung wählen	references/design-styles-catalog.md	36 Stile in 11 Kategorien
Trend / Kunst-Pack auswählen	references/design-trends.md	6 Trends, 3 Kunst-Richtungspakete
Ein Design-Rezept anwenden	references/design-recipes-catalog.md	15 vollständige Design-Rezepte
Plattform-Layout-Regeln anwenden	references/platform-rules.md	Regeln für Mobile/iOS 26/Desktop/Tablet
Foundation-Tokens einfrieren und einfügen	references/foundation-tokens.md	Anleitung zum Einfrieren von Tokens und Format
Radius-Grammatik + Verschachtelungshierarchie durchsetzen	references/radius-choreography.md	Semantische Radius-Rollen, Regeln für verschachtelte Oberflächen, Radius-Grammatik der Stilfamilie
UX / Customer-Journey-Regeln anwenden	references/ux-guidelines.md	UX-Durchsetzung, CJX-Muster
Bewegungs-Choreografie + Interaktionsabsicht durchsetzen	references/motion-choreography.md	Bewegungszweck, Hover-Richtlinie, Zustandsübergänge, plattformspezifische Bewegungsregeln
Bundle-Asset-Besitz + Manifest-Prüfung durchsetzen	references/output-bundle-rules.md	Regeln für gemeinsame vs. bildschirmspezifische Assets, Manifest, Selbstprüfung
Ausgabe-Bundle generieren	references/output-template.md	Bundle-Struktur, HTML-Vorlage, Datei-Vereinbarung

---

Auto-Orchestrierungs-Flow

Führen Sie diese Phasen nacheinander aus. Jede Phase enthält bedingte Logik – befolgen Sie diese genau.

Phase 1 — KONTEXT-ERKENNUNG

1. Durchsuchen Sie die Konversation und alle angehängten Dateien nach: Projektname, vorhandenen Markenfarben, Schriftarten, Tech-Stack, Zielplattform und Bildschirmzweck.

2. Klassifizieren Sie den Projekttyp als einen von: SaaS-Produkt · E-Commerce · Mobile-App · Portfolio · Dashboard · Marketing-Site · Sonstiges.

3. Extrahieren Sie die angeforderten Bildschirme und zählen Sie sie.

4. Ermitteln Sie den Plattform-Umfang als einen oder mehrere von: mobile, tablet, desktop.

5. Wenn der Plattform-Umfang fehlt oder mehrdeutig ist: Stellen Sie genau eine Frage zur Plattformauswahl mit Mehrfachauswahl-Optionen:

   • Mobile
   • Tablet
   • Desktop

6. Wenn der Benutzer bereits Plattformen angegeben hat, fragen Sie nicht erneut nach – übernehmen Sie diese genau so.

7. Notieren Sie alle vorhandenen Marken-Tokens (Farben, Schriftarten, Abstandsskala), die im Projekt gefunden wurden – Sie werden sie später beim Einfrieren der Tokens verwenden.

8. Ermitteln Sie die FarbSchema-Priorität basierend auf dem Projekttyp:

   Dark-Mode-first (dunkel ist die primäre Leinwand; hell ist die optionale Überschreibung):

   • Dashboard · Admin-Panel · datenreiches SaaS · Fintech · Entwickler-Tools · Analytik · Überwachung · Krypto/Web3 · Medien/Streaming · Gaming

   Light-Mode-first (hell ist die primäre Leinwand; dunkel ist die optionale Überschreibung):

   • E-Commerce · Marketing-Site · Portfolio · Gesundheitswesen · Bildung · Gastronomie & Getränke · Lebensstil

   Wenn der Projekttyp mehrdeutig ist oder in keine der beiden Listen passt, standardmäßig Light-Mode-first und bieten Sie den Dunkelmodus als Add-on an.

   Tragen Sie diese Entscheidung als color_scheme_priority: dark_first | light_first weiter. Die Palettenoptionen in Phase 2 und das Einfrieren der Tokens in Phase 4 müssen diese Priorität widerspiegeln.

Phase 2 — FARB- + DESIGN-RICHTUNG

1. Klären Sie die Farbrichtung vor der Stilauswahl.

2. Wenn der Benutzer keine explizite Palette angegeben hat, bieten Sie 2–3 Palettenrichtungen an, die zur Produktkategorie passen und die color_scheme_priority aus Phase 1 widerspiegeln:

   • Für dark_first-Projekte: führen Sie mit dunklen Palettenoptionen (z. B. OLED-Dark-Luxury, Electric Slate, Deep Navy), fügen Sie eine helle Option nur als letzte Wahl hinzu.
   • Für light_first-Projekte: führen Sie mit hellen Palettenoptionen (z. B. Commerce Warm-Energy, Trust Cool-Neutral), fügen Sie eine dunkle Option nur hinzu, wenn sie zur Marke passt.
   • Bitten Sie den Benutzer, eine auszuwählen.

3. Wenn der Benutzer sich weigert, auszuwählen, wählen Sie automatisch die am besten geeignete Palette aus und begründen Sie dies in einem Satz.

4. Laden Sie references/design-styles-catalog.md.

5. Wählen Sie aus dem Katalog 2–3 Stile aus, die am besten zum Projekttyp, zur gewählten Palette und zum Kontext passen.

6. Generieren Sie für jeden ausgewählten Stil eine Optionskarte in diesem Format:

   [N]. **Stilname** — EMPFOHLEN (falls zutreffend)
   Stimmung: [ein Satz zur Stimmung/Atmosphäre]
   Hauptästhetik: [3 definierende visuelle Merkmale]
   

7. Markieren Sie GENAU EINE Option als EMPFOHLEN basierend auf der besten Passung.

8. Präsentieren Sie die nummerierte Liste dem Benutzer und bitten Sie ihn, eine auszuwählen. Warten Sie auf seine Antwort, bevor Sie fortfahren.

9. Wenn der Benutzer einen anderen Stil als den in der Liste wünscht, kommen Sie dem nach und fahren fort.

Phase 3 — BUNDLE-GENERIERUNG

1. Laden Sie references/platform-rules.md für die ausgewählten Plattformen.
2. Laden Sie references/output-template.md für das CJX-Bundle-Format.
3. Laden Sie references/output-bundle-rules.md für Asset-Besitz, Shared-Class-Platzierung, Manifest und Bundle-Selbstprüfung.
4. Laden Sie references/radius-choreography.md, um die Radius-Grammatik, die verschachtelte Oberflächenhierarchie und die rollenbasierte Krümmung zu ermitteln, bevor Sie CSS schreiben.
5. Laden Sie references/ux-guidelines.md, wenn Sie die endgültige Ausgabe generieren, da die Vollständigkeit der Zustände obligatorisch ist.
6. Wenden Sie ALLE unten stehenden Anti-KI-Design-Regeln an.
7. Wenden Sie die Plattformregeln für jede ausgewählte Plattform separat an.
8. Ermitteln Sie eine Radius-Grammatik für die gewählte Stilrichtung, bevor Sie Komponenten-CSS schreiben:
   • wählen Sie 2–4 primäre Radius-Stufen plus ggf. Pill,
   • ordnen Sie sie semantischen Rollen zu: Shell, Surface, Inset, Control, Tight, Pill,
   • halten Sie die Grammatik im gesamten Bundle konsistent,
   • stellen Sie sicher, dass verschachtelte Oberflächen aus demselben Material in der Krümmung abgestuft sind.
9. Generieren Sie ein Bundle-Verzeichnis, das Folgendes enthält:
   • html/
   • css/
   • js/
   • manifest.json
10. Generieren Sie ein HTML/CSS/JS-Trio pro erforderlicher Bildschirm-/Plattformkombination.
11. Generieren Sie nur die angeforderten Bildschirme und nur die ausgewählten Plattformen.
12. Landing Pages können plattformübergreifend semantisch bleiben, wenn dieselbe Datei gut funktioniert, aber wenn sich das Layout je nach Plattform wesentlich ändert, generieren Sie auch plattformspezifische Landing-Varianten.
13. Jede HTML-Datei muss:
    • ../css/foundation.css referenzieren
    • ../css/shared.css referenzieren
    • ihre eigene Bildschirm-CSS-Datei referenzieren
    • gemeinsames ../js/app.js referenzieren
    • bei Bedarf ihre eigene Bildschirm-JS-Datei referenzieren
    • data-ai-id auf allen wichtigen Strukturelementen verwenden
    • kontextbezogene, realistische Inhalte verwenden – niemals Lorem Ipsum
14. Jeder generierte App-Bildschirm muss die vier UX-Zustände aus ux-guidelines.md enthalten oder explizit behandeln:
    • laden
    • leer
    • fehler
    • erfolg
15. Diese Zustände können auf der Hauptleinwand sichtbar sein oder als umschaltbare Mock-Zustände über JS-Steuerelemente implementiert werden, aber sie müssen im ausgelieferten Bundle existieren.
16. Bestimmen Sie den standardmäßig sichtbaren Zustand absichtlich:
    • Generator-Bildschirme sollten standardmäßig leer sein, es sei denn, der Benutzer hat explizit eine vorbelegte/demobereite Erfolgsleinwand angefordert,
    • Ergebnis-/Überprüfungsbildschirme sollten standardmäßig erfolg sein, es sei denn, die Erzählung erfordert explizit zuerst einen anderen Zustand,
    • Lassen Sie niemals einen Generator-Bildschirm ein abgeschlossenes Ergebnis implizieren, bevor der Benutzer eine Eingabe bereitgestellt oder geladen hat.
17. Wenden Sie Utility-Screen-Realismus-Regeln auf Generator-, Ergebnis-, Dashboard- und formularlastige Bildschirme an:
    • optimieren Sie für Vertrauen, Scannbarkeit und Ausrichtung vor Spektakel,
    • halten Sie das primäre Formular, die Zustandsleinwand, das Ergebnisboard und die CTA-Gruppen in stabilen Normalfluss-Layouts,
    • verwenden Sie keine überlappenden oder absolut positionierten inhaltsrelevanten Karten als primäre Struktur eines Utility-Bildschirms,
    • halten Sie dekorative Asymmetrie sekundär, damit sie niemals die Aufgabenklarheit oder die Auffindbarkeit von CTAs schwächt,
    • stellen Sie sicher, dass die Hero-Typografie auf Utility-Bildschirmen am Ziel-Viewport glaubwürdig lesbar ist, anstatt sich auf theatralischen Zeilenumbruch zu verlassen.
18. Bevor Sie die Ausgabe als abgeschlossen erklären, führen Sie die Bundle-Selbstprüfung aus references/output-bundle-rules.md durch:
    • verschieben Sie alle Selektoren, die in 2+ HTML-Dateien wiederverwendet werden, in shared.css
    • stellen Sie sicher, dass keine Seite von einer CSS-Datei einer Geschwisterseite abhängt, um korrekt dargestellt zu werden
    • stellen Sie sicher, dass jedes referenzierte Asset existiert
    • stellen Sie sicher, dass manifest.json exakt mit den generierten Dateien übereinstimmt
    • stellen Sie sicher, dass keine Dateien für nicht ausgewählte Plattformen vorhanden sind
    • stellen Sie sicher, dass die Radius-Hierarchie der gewählten semantischen Grammatik folgt und verschachtelte Oberflächen nicht zu Schichten mit gleichem Radius verflachen
    • stellen Sie sicher, dass Utility-Bildschirme den Layout-Realismus-Audit an ihrem Ziel-Viewport bestehen

Phase 4 — EINFRIEREN DER FOUNDATION-TOKENS

1. Extrahieren Sie nach der Generierung des ersten genehmigten Bildschirms die genauen Token-Werte in css/foundation.css.
2. Frieren Sie nicht nur Farbe/Schriftart/Bewegung ein, sondern auch die semantische Radius-Grammatik für das Bundle.
3. Verwenden Sie dieses genaue Format:

/* EINGEFRORENE FOUNDATION-TOKENS — NICHT ÄNDERN */
:root {
  --color-primary: <genauer Wert>;
  --color-secondary: <genauer Wert>;
  --color-accent: <genauer Wert>;
  --color-bg: <genauer Wert>;
  --color-surface: <genauer Wert>;
  --color-text: <genauer Wert>;
  --color-text-muted: <genauer Wert>;
  --font-heading: <genauer Font-Stack>;
  --font-body: <genauer Font-Stack>;
  --space-base: <genauer Wert>;
  --radius-1: <genauer Wert>;
  --radius-2: <genauer Wert>;
  --radius-3: <genauer Wert>;
  --radius-4: <genauer Wert>;
  --radius-