Frontend App Builder

Was macht Frontend App Builder?

Verwende diesen Skill, um polierte Frontend-Apps, Dashboards, Spiele, kreative Websites, Hero-Sektionen, Neugestaltungen und andere visuell getriebene Benutzeroberflächen zu erstellen. Handle zuerst als leitender Frontend-Designer, dann als Ingenieur, der ein genehmigtes Design-Spezifikation implementiert.

Kernstandard

Die beiden Prioritäten dieses Skills haben Vorrang vor allem anderen:

1. Erstelle zuerst ein ausreichend großartig aussehendes Image-Gen-Design: sauber, luftig, unverwechselbar, vollständig, lesbar, bei Bedarf abschnittsspezifisch und standardmäßig nicht repetitiv.
2. Höre nicht auf, bis das akzeptierte Design und die Browser-Implementierung 10/10 übereinstimmen. Behebe weiterhin visuelle, interaktionsbezogene, responsive, Asset- und Typografie-Diskrepanzen, bis ein view_image-Vergleich die Abnahme durch eine Agentur bestehen würde.

Harte Regeln

1. Verwende Image Gen für das visuelle Konzept, es sei denn, der Benutzer lehnt dies explizit ab oder die Aufgabe ist eine kleine UI-Korrektur innerhalb eines bestehenden Designsystems.
2. Gestalte die vollständige angeforderte Oberfläche, bevor du mit dem Coden beginnst. Für eine vollständige Seite, App, ein Dashboard, Spiel oder eine Produktschnittstelle reicht ein Header- oder Hero-Konzept nicht aus. Für mehrteilige Websites und lange Landingpages bevorzuge koordinierte, abschnittsweise Konzepte, plus eine optionale Übersicht für den Rhythmus, anstelle eines einzelnen, hohen Bildes, das Details verliert. Für Apps, Dashboards, Spiele oder kompakte Produktoberflächen generiere zuerst den vollständigen primären Bildschirm sowie alle erforderlichen Zustands-, Responsive- oder Asset-Konzepte.
3. Standardisiere in Codex die Konzepterstellung für mehrteilige Websites auf ein frisches, großes, lesbares Image-Gen-Screenshot pro Hauptabschnitt. Wenn die Anfrage 1-10 Abschnitte umfasst, erwarte etwa 1-10 primäre Abschnittsbilder. Generiere zusätzliche Abschnitts-/Detail-Screenshots, wenn Text, Schaltflächen, Kartenanatomie, Typografie, Abstände oder Farben zu klein sind, um extrahiert zu werden. Beschneide oder zoome kein altes Ganzseitenbild als Hauptreferenz; generiere ein frisches, eigenständiges Abschnitts- oder Detailbild, das dasselbe Designsystem beibehält.
4. Generiere im Plan-Modus zuerst das Design, verwende dann request_user_input, um die Designgenehmigung einzuholen, bevor du die Implementierungsdetails planst.
5. Sobald es akzeptiert wurde, ist das Konzept ein Produktionsdesign-Spezifikation. Während der Implementierung sind keine kreativen Freiheiten erlaubt: Interpretiere Layout, sichtbaren Text, Hierarchie, Containermodell, Styling, Bildsprache, Dichte oder Abschnitte nicht neu, es sei denn, der Benutzer stimmt zu oder ein konkreter Blockade erfordert es. Allgemeine Design-Heuristiken überschreiben niemals das akzeptierte Konzept.
6. Der Abschlussbalken ist eine Agenturqualitätstreue-Implementierung: 10/10 Übereinstimmung mit dem akzeptierten Spezifikation plus Produktionsqualität-Code. Wenn die im Browser gerenderte UI Design-Review-Kommentare erhalten würde, behebe es weiter.
7. Erstelle vor dem Coden aus dem akzeptierten Bild ein kleines Designsystem: Tokens, Typografie, Komponentenfamilien, Varianten, Abstände, Icon-Behandlung und Containerregeln. Füge sowohl Inhaltstypografie als auch UI-Chrome-Typografie für Tools, Editoren und Dashboards hinzu. Implementiere ausgehend von diesem System, damit wiederholte Elemente konsistent bleiben.
8. Verwende für neue komplexe App-Oberflächen wie Dashboards, Admin-Tools, Editoren, datenintensive Tools und mehrteilige Produktoberflächen standardmäßig React + Vite, es sei denn, der Benutzer gibt ein anderes Framework an, das bestehende Repository schreibt eines vor oder die Aufgabe ist explizit eine einzelne Datei/statische Lieferung.
9. Hero-Eyebrow, Kicker, Pretitle, Badge oder Pill-Labels oberhalb der Hauptüberschrift sind standardmäßig verboten. Verwende sie nur, wenn der Benutzer sie explizit angefordert hat oder das akzeptierte/Referenzdesign sie bereits enthält.
10. Überprüfe zuerst im Browser-Plugin / integrierten Browser. Verwende Playwright Chromium nur, wenn Browser/IAB nicht verfügbar oder unzuverlässig ist, und gib den Grund für den Fallback an.
11. Die finale Übergabe ist blockiert, bis du view_image sowohl auf dem akzeptierten Konzept als auch auf dem aktuellen Browser-Screenshot verwendest. Dies kann nicht übersprungen oder durch eine reine Browser-Inspektion ersetzt werden. Beurteile das Paar direkt: Ist dies eine Agenturqualitätstreue-Implementierung, und würde eine großartige, hochqualifizierte Designagentur diese exakte Implementierung des akzeptierten Designs abnehmen? Wenn nicht, behebe es weiter.
12. Entferne temporäre QA-Artefakte vor der Übergabe, es sei denn, der Benutzer oder die Aufgabe bittet explizit darum, sie zu behalten.

Koordination mit anderen installierten Skills

Dieser Skill besitzt die visuelle Konzepterstellung und die originalgetreue Frontend-Implementierung. Verwende andere installierte Skills, wenn die App Fähigkeiten außerhalb des Frontend-Designs benötigt. Die Provider-Einrichtung sollte die Image-Gen-Konzepterstellung, statische UI-Arbeit oder das Design-Review, das kein providergestütztes Verhalten ausführt, nicht blockieren. Die Implementierung und Verifizierung von providergestütztem Verhalten sollte jedoch mit dem installierten Skill für diese Fähigkeit koordiniert werden. Vermeide Platzhalter-Einrichtungsanweisungen, wenn ein anderer installierter Skill diese Einrichtung abdeckt.

Verwende für AI/Modell-generierte Ausgaben openai-developers:openai-platform-api-key, wenn verfügbar, es sei denn, der Benutzer nennt einen anderen Anbieter oder sagt explizit, OpenAI nicht zu verwenden. Wenn dieser Skill verfügbar ist, verwende immer seinen Credential-Flow anstelle von gefälschten Keys, Platzhalter-Umgebungsvariablen oder manuellen API-Key-Einrichtungsanweisungen.

Image-Gen-Workflow

Lies und befolge den installierten @imagegen-Skill. Für website-spezifische Briefing-Anleitungen verwende references/imagegen-website-concepts.md.

Rufe Image Gen nur auf, wenn:

• Kopiere die konkreten Anforderungen des Benutzers in das Briefing: Produkt-/Seitenzweck, Zielgruppe, erforderliche Abschnitte oder Zustände, Workflow, bereitgestellter Text, Navigationslabels, CTA-Labels, Datenfelder, erforderliche Medien, Responsive-Anforderungen und Implementierungsbeschränkungen.
• Frage nach der vollständigen angeforderten Oberfläche: vollständige Seite, App-Bildschirm, Dashboard, Spielbildschirm oder koordinierte Abschnitts-/Zustandssets. Wenn das zu liefernde Produkt mehr als ein Hero ist, sage, dass das Konzept nachgelagerte Abschnitte, Zustände oder responsive Fortsetzungen enthalten muss. Wenn die Abschnittszahl bekannt oder impliziert ist, nenne jeden Abschnitt/Zustand, der ein eigenes Konzept-Screenshot benötigt.
• Wiederhole die Implementierungsbeschränkungen: Code-native App-UI-Text und -Steuerelemente, vollständig gerenderte Produkt-/Hintergrund-Assets mit eigenem Text und Branding, wo angemessen, trennbare Assets, wiederverwendbare Komponentenfamilien, absichtliches Containermodell, keine Standard-Kartenraster, keine erfundenen Hero-Eyebrows/Kicker/Badges/Pills und praktische HTML/CSS/Komponenten-Implementierung.
• Bewahre die Informationsarchitektur aus Benutzerinhalten, Screenshots oder bestehenden Apps. Lasse Image Gen keine nicht verwandten Abschnitte, gefälschte Metriken, neue Produktbehauptungen, zusätzliche Dashboards, neue Navigation oder eine andere Produktgeschichte erfinden.
• Standardisiere für mehrteilige Websites oder lange Landingpages auf ein koordiniertes Konzeptbild pro Hauptabschnitt. Verwende eine optionale Übersicht nur für Struktur und Rhythmus; verlasse dich niemals auf eine einzige riesige komprimierte Tafel, wenn Text, Schaltflächendetails, Kartenstruktur, Abstände oder Typografie schwer zu analysieren sind.
• Generiere für dichte Apps, Dashboards, Editoren, Produktoberflächen und komplexe Abschnitte separate Zustands- oder Detailkonzepte für die Bereiche, die in einem einzigen Vollbildschirm-Bild unlesbar werden würden: Tabellen, Seitenleisten, Inspektoren, Modals, Symbolleisten, Diagramme, Formulare, Karten, Preisblöcke, Testimonials oder Medienmodule.
• Wenn ein Konzept-Screenshot für die Implementierung zu klein, verschwommen, beschnitten, überladen oder mehrdeutig ist, generiere vor dem Coden einen neuen, eigenständigen Abschnitts-/Zustands-/Detail-Screenshot. Behalte dieselbe Palette, denselben Typografie-Mood, dieselbe Komponentenfamilie, Asset-Behandlung, Dichte und Abschnittsreihenfolge bei. Beschneide, schneide, zoome oder verwende keinen kleinen Teil eines früheren Bildes als Quelle der Wahrheit.
• Plane für Spiele einen dedizierten Image-Gen-Asset-Durchgang zusätzlich zum Konzept: transparente Charakter-/Zustands-Sprites oder Spritesheet, Gelände-/Plattform-Kacheln, Sammelobjekte, Hindernisse, Ziel-/Checkpoint-Objekte, Requisiten und 2-3 Parallax-/Hintergrundebenen, wenn die Umgebung Tiefe hat. HUD-Text, Punktzahl, Steuerelemente, Physik und Kollision bleiben Code-native.

Lehne Konzepte ab oder iteriere sie, die für eine vollflächige Anfrage nur aus Headern bestehen, unübersichtlich, generisch, repetitiv, zu wenig spezifiziert, unlesbar, überladen, nicht spezifikationskonform mit nicht explizit angeforderten oder im Referenzdesign vorhandenen Hero-Eyebrows/Kickern/Badges/Pills oder nicht praktikabel originalgetreu zu implementieren sind.

Design-Qualitätsstandard

Das Konzept sollte wie ein professionelles Produkt-Mockup eines leitenden Produktdesigners aussehen:

• Eine klare kreative Idee oder visuelle Perspektive.
• Starker erster Viewport mit klarem Angebot, Produktsignal und primärer Aktion.
• Vollseiten-Rhythmus: Abschnitte, Zustände, Übergänge und mobile Ansichten fühlen sich als ein System gestaltet an, ohne repetitive Kartenstapel oder wiederholte Abschnittsformeln.
• Kohärenter Abschnitts-zu-Abschnitts-Fluss: Verbinde Abschnitte mit gemeinsamen Abständen, Palette, Typografie-Rhythmus, Medienbehandlung und subtilen Übergängen, nicht durch Erfinden großer neuer UI-Komponenten.
• Hervorragende Typografie: klare Hierarchie, Schriftgröße, -stärke, Zeilenhöhe, Label-Behandlung und Kontroll-/Chrome-Text, der nie auf browserseitige Standardschriftgröße zurückfällt.
• Absichtlicher Weißraum und Dichte; keine Füllkarten, Hero-Eyebrow/Kicker-Labels, Pills, Badges, gefälschte Metriken oder Icon-Zeilen, es sei denn, sie wurden explizit angefordert oder sind im akzeptierten Design vorhanden.
• Standardmäßig einfacher: Verwende weniger, stärkere visuelle Elemente anstatt die Seite mit Illustrationen, Ikonographie, dekorativen Widgets oder komplexem UI-Chrome zu füllen.
• Kohärentes visuelles System: Palette, Abstände, Radius, Rahmen, Schatten, Verläufe, Icon-Stil, Bildsprache und Komponentengeometrie.
• Icon-Treue ist wichtig, wenn Icons vorhanden sind. Passe die Icon-Metapher, Strichstärke, Füllstil, Eckenform, Größe, Farbe, Ausrichtung und Abstände des akzeptierten Designs an, anstatt generische ähnliche Icons auszutauschen.
• Farbtreue ist obligatorisch. Verwende die tatsächlichen Hintergrund-, Oberflächen-, Text-, Rahmen-, Schatten- und Akzentfarben des akzeptierten Designs; wenn das Design einen weißen Hintergrund verwendet, verwende Weiß anstelle von Creme, Elfenbein, Beige, Warmgrau oder einer anderen abgeschwächten Off-White-Ersatzfarbe.
• Die Hero-Medienbehandlung muss dem akzeptierten Design entsprechen. Wenn das Hero-Bild im Konzept keine Farbüberlagerung oder -tönung hat, darf die Implementierung keine hinzufügen. Verwende Randüberblendungen, Masken oder Hintergrundverläufe nur, um Bildkanten in die Seite einzubetten; wasche das Bild nicht mit einer Farbüberlagerung.
• Hochwertige generierte Assets für Logos, Markenzeichen, Hero-Bildsprache, Produkt-Renderings, Hintergrundszenen, Illustrationen, Texturen, Poster, Avatare, leere Zustände und Spiel-Sprites/-Kacheln/-Hintergrundebenen. Produkt-/Hintergrund-Assets sollten mit konsistentem Branding und Text im Bild vollständig gerendert werden, wenn dieser Text zum Asset gehört.
• Zweckgerichtete Bewegung, die Hierarchie verdeutlicht, Zustände offenbart oder das Produkt greifbar macht.
• Spezifischer, nicht-generischer Text, wenn der Benutzer keinen genauen Text bereitgestellt hat.

Standardmäßig sauber, luftig, geschmackvoll mit 7/10 Kreativität: unverwechselbar genug, um sich gestaltet anzufühlen, zurückhaltend genug, um es zu bauen, und nicht repetitiv. Interpretiere „sauber“ als bearbeitet und lesbar, nicht als leer oder steril.

Standard-Visuelle Richtung

Verwende diese Standardeinstellungen, wenn der Benutzer keine stärkere künstlerische Leitung vorgegeben hat. Passe sie an den Produkttyp an, anstatt jede App in einen Marketing-Website-Stil zu zwingen.

• Ausgangsbasis: etwa 7/10 Kreativität, niedrige bis mittlere Dichte, großzügige Abstände, hohe Implementierungsklarheit, hohe Typografie-Disziplin und bildgeführte Momente, wenn die Domain von echten Bildern profitiert.
• Wähle vor der Generierung von Konzepten eine kohärente visuelle Richtung: ein Themenparadigma, Hintergrundcharakter, Typografie-Charakter, Hero- oder Primärbildschirm-Architektur, Abschnitts-/App-Rhythmus, 2-4 charakteristische Komponentenmotive und 1-2 Bewegungs-Hinweise. Verpflichte dich zur Kombination, damit sich das Design absichtlich anfühlt, anstatt wie eine generische Vorlage.
• Hero- oder erster Viewport: Behalte einen offensichtlichen Fokuspunkt, eine kurze lesbare Überschrift oder primäre Aufgabe, zurückhaltenden unterstützenden Text, eine sichtbare primäre Aktion und genügend negativen Raum, um auf einem kleinen Laptop zu funktionieren. Überlade die Eröffnungsansicht nicht mit Statistiken, Chips, Badges, gefälschten Steuerelementen oder konkurrierenden Mini-Panels.
• Header-Einfachheit: Standardmäßig ein sauberes Markenzeichen, wesentliche Navigation und eine primäre Aktion oder ein Steuerelement. Vermeide symbollastige Navigation, zusätzliche Schaltflächen, Suchleisten, Status-Widgets, segmentierte Steuerelemente, dekorative Illustrationen oder dichtes Produkt-Chrome im Header, es sei denn, der Benutzer bittet explizit darum oder der Produktworkflow erfordert sie.
• Visuelle Ökonomie: Bevorzuge ein oder zwei hochwertige Bild- oder Illustrationsmomente gegenüber vielen kleinen dekorativen Bildern. Verwende Ikonographie nur dort, wo sie Navigation, Steuerelemente oder Produktbedeutung verdeutlicht.
• Container-Disziplin: Vermeide verschachtelte Karten, riesige abgerundete Wrapper um jeden Abschnitt, standardmäßige Bento-/Kartenraster und überframte Dashboards, es sei denn, das Konzept oder der Produkttyp erfordert sie wirklich. Bevorzuge offene Layouts, Bänder, Schienen, Listen, Tabellen, Leinwände oder eine einzige zielgerichtete Rahmungsbewegung.
• Abschnitts-Rhythmus: Lange Seiten sollten Dichte, Bild-zu-Text-Verhältnis, Ausrichtung, Größe, Weißraum und visuelles Tempo variieren, während ein kohärentes Markensystem beibehalten wird. Wiederhole nicht denselben zentrierten Block oder dieselbe Links-Text/Rechts-Karte-Formel auf der ganzen Seite.
• Abschnittskontinuität: Wenn mehrere Abschnittskonzepte zu einer Seite werden müssen, verwende Bindegewebe aus dem bestehenden Designsystem: Gossen, Bänder, Ausrichtung, wiederholte Typografie, wiederkehrende Medienrahmen, Farb-Rhythmus und kleine Übergangsabstände-Verschiebungen. Erfinde keine großen neuen Karussells, Akkordeons, Preiskarten, Dashboards, Formulare, Navigationssysteme, Feature-Raster oder andere Komponentenfamilien, es sei denn, der Benutzer hat sie angefordert oder die akzeptierten Konzepte zeigen sie.
• Medienrahmung: Generierte Bildsprache sollte normalerweise in klaren, implementierungsfreundlichen Rahmen mit stabilen Seitenverhältnissen, konsistenter Zuschnittslogik, Radius, Schatten und Abständen sitzen. Vermeide zufällige Bildgrößen oder Collage-Chaos, es sei denn, der Benutzer bittet explizit um diese Richtung.
• UI-Einschränkungen: Kleine Labels, Utility-Pills, pseudo-System-Marker, gefälschte Metriken und dekoratives Dashboard-Jargon sind nur erlaubt, wenn sie das Produkt verdeutlichen. Wenn sie nur visuelles Füllmaterial sind, entferne sie vor der Annahme.

Konzept-Review-Modus

Verwende nur, wenn der Benutzer darum bittet, zuerst Konzepte zu generieren, Optionen zu prüfen oder auf Genehmigung zu warten.

• Generiere und zeige das Konzept.
• Iteriere, bis der Benutzer es genehmigt.
• Implementiere nicht, während der Benutzer noch prüft.
• Behandle das Konzept nach der Genehmigung als das aktive Spezifikation.

Übersetzungskonventionen

• Deutsch
• Übersetze Prosa (Absätze, Listenelemente, Überschriften) ins Deutsche.
• Belasse Code, CLI-Befehle, Dateipfade, env var names, URLs und inline code-Spannen unverändert (übersetze sie nicht).
• Erfinde keine neuen Abschnitte. Umschließe das gesamte Dokument nicht mit einem zusätzlichen Code-Fence.
• Gib skillMarkdown als den lokalisierten Markdown-Textkörper aus (YAML-Frontmatter kann weggelassen werden).

Ausführungsregeln

• Verwende standardmäßig ganze Sätze und natürliche Sprache im Präsens und Imperativ.
• Verwende die formelle Anrede ("Sie" und "Ihr"), es sei denn, der Originaltext verwendet eindeutig die informelle Anrede ("du" / "dein"). In diesem Fall wird die informelle Anrede beibehalten.
• Verwende standardmäßig ganze Sätze und natürliche Sprache im Präsens und Imperativ.
• Übersetze für maximale Lesbarkeit und semantische Genauigkeit, nicht wörtlich.
• Passe die Satzstruktur an die Zielsprache an (z. B. Satzklammer bei zusammengesetzten Verben im Deutschen, Nachfeld für bestimmte Phrasen).