Geruyang/agent-skills-library

Frontend-App-Builder

Verwenden Sie diesen Skill, um ansprechende Frontend-Apps, Dashboards, Spiele, kreative Websites, Hero-Abschnitte, Redesigns und andere visuell getriebene Benutzeroberflächen zu erstellen. Handeln Sie zuerst als Senior-Frontend-Designer, dann als Ingenieur, der ein genehmigtes Design-Spezifikation implementiert.

Kernstandard

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

1. Erstellen Sie zuerst ein ausreichend großes, gut aussehendes Bildgenerierungsdesign: sauber, luftig, unverwechselbar, vollständig, lesbar, bei Bedarf abschnittsspezifisch und standardmäßig nicht repetitiv.
2. Hören Sie nicht auf, bis das akzeptierte Design und die Browser-Implementierung 10/10 übereinstimmen. Beheben Sie weiterhin visuelle, interaktive, responsive, Asset- und Typografie-Diskrepanzen, bis ein view_image-Vergleich die Agenturfreigabe bestehen würde.

Harte Regeln

1. Verwenden Sie 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. Entwerfen Sie die vollständig angeforderte Oberfläche, bevor Sie programmieren. Für eine vollständige Seite, App, ein Dashboard, Spiel oder eine Produktschnittstelle ist ein Header- oder Hero-Konzept nicht ausreichend. Für mehrteilige Websites und lange Landingpages bevorzugen Sie koordinierte abschnittsweise Konzepte, plus eine optionale Übersicht für den Rhythmus, gegenüber einem einzelnen hohen Bild, das Details verliert. Für Apps, Dashboards, Spiele oder kompakte Produktoberflächen generieren Sie zuerst den vollständigen primären Bildschirm sowie alle notwendigen Zustands-, Responsive- oder Asset-Konzepte.
3. Standardmäßig wird in Codex für mehrteilige Website-Konzepte ein frischer, großer, lesbarer Image-Gen-Screenshot pro Hauptabschnitt verwendet. Wenn die Anfrage 1-10 Abschnitte umfasst, erwarten Sie ungefähr 1-10 primäre Abschnittsbilder. Generieren Sie zusätzliche Abschnitts-/Detail-Screenshots, wann immer Text, Schaltflächen, Kartenanatomie, Typografie, Abstände oder Farben zu klein sind, um sie zu extrahieren. Beschneiden oder zoomen Sie kein altes ganzseitiges Bild als Hauptreferenz; generieren Sie einen neuen eigenständigen Abschnitts- oder Detail-Screenshot, der dasselbe Designsystem beibehält.
4. Generieren Sie im Plan-Modus zuerst das Design und verwenden Sie dann request_user_input, um die Designfreigabe zu erhalten, bevor Sie die Implementierungsdetails planen.
5. Nach der Akzeptanz ist das Konzept ein Produktionsdesign-Spezifikation. Keine kreativen Freiheiten während der Implementierung: Interpretieren Sie Layout, sichtbaren Text, Hierarchie, Containermodell, Styling, Bildmaterial, Dichte oder Abschnitte nicht neu, es sei denn, der Benutzer stimmt zu oder ein konkreter Blocker erfordert es. Allgemeine Design-Heuristiken überschreiben niemals das akzeptierte Konzept.
6. Die Fertigstellungsleiste ist die originalgetreue Implementierung der Agenturfreigabe: 10/10 Genauigkeit gemäß der akzeptierten Spezifikation plus produktionsreifer Code. Wenn die im Browser gerenderte UI Design-Review-Kommentare erhalten würde, beheben Sie sie weiter.
7. Erstellen Sie vor dem Codieren ein kleines Designsystem aus dem akzeptierten Bild: Token, Typografie, Komponentenfamilien, Varianten, Abstände, Symbolbehandlung und Containerregeln. Fügen Sie sowohl Inhalts-Typografie als auch UI-Chrome-Typografie für Tools, Editoren und Dashboards hinzu. Implementieren Sie von diesem System aus, sodass wiederholte Elemente konsistent bleiben.
8. Verwenden Sie standardmäßig React + Vite für neue komplexe App-Oberflächen wie Dashboards, Admin-Tools, Editoren, datenintensive Tools und mehrteilige Produktoberflächen, es sei denn, der Benutzer gibt ein anderes Framework an, das vorhandene Repository schreibt eines vor, oder die Aufgabe ist explizit eine einzelne Datei/statische Lieferung.
9. Hero-Eyebrow-, Kicker-, Pre-Title-, Badge- oder Pill-Labels über der Hauptüberschrift sind standardmäßig verboten. Verwenden Sie eines nur, wenn der Benutzer es explizit angefordert hat oder das akzeptierte/Referenzdesign es bereits enthält.
10. Überprüfen Sie zuerst im Browser-Plugin / integrierten Browser. Verwenden Sie Playwright Chromium nur, wenn Browser/IAB nicht verfügbar oder unzuverlässig ist, und geben Sie den Grund für die Ausweichlösung an.
11. Die endgültige Übergabe ist blockiert, bis Sie view_image sowohl auf das akzeptierte Konzept als auch auf den neuesten Browser-Screenshot angewendet haben. Dies kann nicht übersprungen oder durch eine reine Browser-Inspektion ersetzt werden. Beurteilen Sie das Paar direkt: Ist dies eine originalgetreu implementierte Agenturfreigabe, und würde eine großartige, hochqualifizierte Designagentur diese genaue Implementierung des akzeptierten Designs freigeben? Wenn nicht, beheben Sie es weiter.
12. Entfernen Sie temporäre QA-Artefakte vor der Übergabe, es sei denn, der Benutzer oder die Aufgabe bittet ausdrücklich darum, sie zu behalten.

Koordination mit anderen installierten Skills

Dieser Skill ist Eigentümer des visuellen Konzepts und der originalgetreuen Frontend-Implementierung. Verwenden Sie andere installierte Skills, wenn die App Fähigkeiten außerhalb des Frontend-Designs benötigt. Die Provider-Einrichtung sollte das Image-Gen-Konzept, statische UI-Arbeit oder das Design-Review, die kein Provider-gestütztes Verhalten ausführen, nicht blockieren, aber die Implementierung und Überprüfung von Provider-gestütztem Verhalten sollte mit dem installierten Skill für diese Fähigkeit koordiniert werden. Vermeiden Sie Platzhalter-Einrichtungsanweisungen, wenn ein anderer installierter Skill diese Einrichtung abdeckt.

Verwenden Sie für KI-/Modell-generierte Ausgaben openai-developers:openai-platform-api-key, wenn verfügbar, es sei denn, der Benutzer nennt einen anderen Provider oder sagt explizit, dass OpenAI nicht verwendet werden soll. Wenn dieser Skill verfügbar ist, verwenden Sie immer dessen Anmeldefluss anstelle von Fake-Keys, Platzhalter-Umgebungsvariablen oder manuellen API-Key-Einrichtungsanweisungen.

Image-Gen-Workflow

Lesen und befolgen Sie den installierten @imagegen-Skill. Verwenden Sie für website-spezifische Briefing-Anleitungen references/imagegen-website-concepts.md.

Vor dem Aufruf von Image Gen:

• Kopieren Sie die konkreten Anforderungen des Benutzers in das Briefing: Produkt-/Seitenzweck, Zielgruppe, erforderliche Abschnitte oder Zustände, Workflow, bereitgestellter Text, Navigationsbezeichnungen, CTA-Bezeichnungen, Datenfelder, erforderliche Medien, responsive Anforderungen und Implementierungseinschränkungen.
• Fragen Sie nach der vollständigen angeforderten Oberfläche: Vollständige Seite, App-Bildschirm, Dashboard, Spielbildschirm oder koordinierter Abschnitts-/Zustandssatz. Wenn die Lieferung mehr als ein Hero ist, sagen Sie, dass das Konzept nachgelagerte Abschnitte, Zustände oder responsive Fortsetzung enthalten muss. Wenn die Abschnittsanzahl bekannt oder impliziert ist, nennen Sie jeden Abschnitt/Zustand, der seinen eigenen Konzept-Screenshot benötigt.
• Wiederholen Sie die Implementierungseinschrä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, beabsichtigtes Containermodell, keine standardmäßigen Kartenraster, keine erfundenen Hero-Eyebrows/Kicker/Badges/Pillen und praktische HTML/CSS/Komponenten-Implementierung.
• Bewahren Sie die Informationsarchitektur aus Benutzerinhalten, Screenshots oder vorhandenen Apps. Lassen Sie Image Gen keine irrelevanten Abschnitte, gefälschten Metriken, neuen Produktbehauptungen, zusätzliche Dashboards, neue Navigation oder eine andere Produktgeschichte erfinden.
• Standardmäßig ein koordiniertes Konzeptbild pro Hauptabschnitt für mehrteilige Websites oder lange Landingpages. Verwenden Sie eine optionale Übersicht nur für Struktur und Rhythmus; verlassen Sie sich niemals auf eine einzige riesige komprimierte Tafel, wenn sie Text, Schaltflächendetails, Kartenstruktur, Abstände oder Typografie schwer analysierbar macht.
• Generieren Sie für dichte Apps, Dashboards, Editoren, Produktoberflächen und komplexe Abschnitte separate Zustands- oder Detailkonzepte für die Bereiche, die in einem einzigen Vollbildbild unlesbar würden: Tabellen, Seitenleisten, Inspektoren, Modals, Werkzeugleisten, Diagramme, Formulare, Karten, Preisblöcke, Testimonials oder Medienmodule.
• Wenn ein Konzept-Screenshot zu klein, unscharf, beschnitten, überfüllt oder mehrdeutig für die Implementierung ist, generieren Sie vor dem Codieren einen frischen eigenständigen Abschnitts-/Zustands-/Detail-Screenshot. Behalten Sie dieselbe Palette, Typografie-Stimmung, Komponentenfamilie, Asset-Behandlung, Dichte und Abschnittsreihenfolge bei. Beschneiden, schneiden, zoomen Sie keinen winzigen Teil eines früheren Bildes als Quelle der Wahrheit wieder.
• Planen Sie für Spiele einen dedizierten Image-Gen-Asset-Durchlauf zusätzlich zum Konzept: transparente Charakter-/Zustands-Sprites oder Sprite-Board, Gelände-/Plattformkacheln, Sammelobjekte, Gefahren, Ziel-/Checkpoint-Objekte, Requisiten und 2-3 Parallax-/Hintergrundebenen, wenn die Umgebung Tiefe hat. HUD-Text, Punktzahl, Steuerelemente, Physik und Kollision bleiben Code-nativ.

Lehnen Sie Konzepte ab oder iterieren Sie daran, die nur Header für eine vollflächige Anfrage sind, überladen, generisch, repetitiv, unterspezifiziert, unlesbar, überdekoriert, nicht spezifikationskonform mit Hero-Eyebrows/Kickern/Badges/Pillen, die nicht explizit angefordert oder in der Referenz vorhanden sind, oder nicht praktisch originalgetreu implementierbar.

Designqualitätsmaßstab

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

• Eine klare kreative Idee oder visuelle Sichtweise.
• Starker erster Viewport mit klarem Angebot, Produktsignal und primärer Aktion.
• Vollseitiger 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 Abschnittsfluss: Verbinden Sie Abschnitte mit gemeinsamen Abständen, Palette, Typografie-Rhythmus, Medienbehandlung und subtilen Übergängen, nicht durch Erfinden großer neuer UI-Komponenten.
• Ausgezeichnete Typografie: Klare Hierarchie, Skalierung, Gewicht, Zeilenhöhe, Beschriftungsbehandlung und Steuer-/Chrome-Text, der nie auf Browser-Standardgrößen zurückfällt.
• Absichtliche Leerräume und Dichte; keine Füllkarten, Hero-Eyebrow/Kicker-Beschriftungen, Pillen, Badges, gefälschte Metriken oder Symbolzeilen, es sei denn, sie wurden explizit angefordert oder sind im akzeptierten Design vorhanden.
• Standardmäßig einfacher: Verwenden Sie weniger, stärkere visuelle Elemente, anstatt die Seite mit Illustrationen, Ikonografie, dekorativen Widgets oder komplexer UI-Chrome zu füllen.
• Kohärentes visuelles System: Palette, Abstände, Radius, Rahmen, Schatten, Verläufe, Symbolstil, Bildmaterial und Komponentengeometrie.
• Symboldetailtreue ist wichtig, wenn Symbole vorhanden sind. Passen Sie die Symbolmetapher, Strichstärke, Füllstil, Eckform, Größe, Farbe, Ausrichtung und Abstände des akzeptierten Designs an, anstatt generische naheliegende Symbole auszutauschen.
• Farbtreue ist obligatorisch. Passen Sie die tatsächlichen Hintergrund-, Oberflächen-, Text-, Rahmen-, Schatten- und Akzentfarben des akzeptierten Designs an; wenn das Design einen weißen Hintergrund verwendet, verwenden Sie Weiß anstelle von Creme, Elfenbein, Beige, Warmgrau oder einem anderen abgemilderten Off-White-Ersatz.
• Die Hero-Medienbehandlung muss mit dem akzeptierten Design übereinstimmen. Wenn das Hero-Bild im Konzept keine Farbüberlagerung oder Tönung hat, darf die Implementierung keine hinzufügen. Verwenden Sie Kantenüberblendungen, Masken oder Hintergrundverläufe nur, um Bildkanten in die Seite einzufügen; waschen Sie das Bild nicht mit einer Farbüberlagerung.
• Hochwertige generierte Assets für Logos, Markenzeichen, Hero-Bildmaterial, Produktdarstellungen, Hintergrundszenen, Illustrationen, Texturen, Poster, Avatare, leere Zustände und Spiel-Sprites/Kacheln/Hintergrundebenen. Produkt-/Hintergrund-Assets sollten vollständig gerendert sein mit konsistentem Branding und Text im Bild, wenn dieser Text zum Asset gehört.
• Zielgerichtete Bewegung, die Hierarchie verdeutlicht, Zustand offenbart oder das Produkt greifbar macht.
• Spezifischer, nicht-generischer Text, wenn der Benutzer keinen genauen Text bereitgestellt hat.

Standardmäßig zu sauberer, luftiger, geschmackvoller 7/10-Kreativität: unverwechselbar genug, um sich gestaltet anzufühlen, zurückhaltend genug, um es zu bauen, und nicht repetitiv. Interpretieren Sie „sauber“ als bearbeitet und lesbar, nicht als leer oder steril.

Standardeinstellungen für die visuelle Ausrichtung

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

• Grundlinie: ungefähr 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ählen Sie vor dem Generieren 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 Bewegungshinweise. Verpflichten Sie sich zur Kombination, damit sich das Design absichtlich anfühlt und nicht wie eine generische Vorlage.
• Hero oder erster Viewport: Behalten Sie einen offensichtlichen Brennpunkt, eine kurze lesbare Überschrift oder Hauptaufgabe, zurückhaltenden unterstützenden Text, eine sichtbare primäre Aktion und genügend negativen Raum, um auf einem kleinen Laptop zu funktionieren. Überladen Sie den ersten Blick nicht mit Statistiken, Chips, Badges, Fake-Steuerelementen oder konkurrierenden Mini-Panels.
• Header-Einfachheit: Standardmäßig ein sauberes Markenzeichen, wesentliche Navigation und eine primäre Aktion oder Steuerung. Vermeiden Sie symbolreiche Navigation, zusätzliche Schaltflächen, Suchleisten, Status-Widgets, segmentierte Steuerelemente, dekorative Illustrationen oder dichte Produkt-Chrome im Header, es sei denn, der Benutzer bittet explizit darum oder der Produktworkflow erfordert sie.
• Visuelle Ökonomie: Bevorzugen Sie ein oder zwei hochwertige Bild- oder Illustrationsmomente gegenüber vielen kleinen dekorativen Bildern. Verwenden Sie Ikonografie nur, wo sie Navigation, Steuerelemente oder Produktbedeutung verdeutlicht.
• Container-Disziplin: Vermeiden Sie verschachtelte Karten, riesige abgerundete Wrapper um jeden Abschnitt, standardmäßige Bento-/Kartenraster und überframte Dashboards, es sei denn, das Konzept oder der Produkttyp benötigt sie wirklich. Bevorzugen Sie offene Layouts, Bänder, Schienen, Listen, Tabellen, Leinwände oder eine einzige zielgerichtete Rahmenbewegung.
• Abschnittsrhythmus: Lange Seiten sollten Dichte, Bild-zu-Text-Verhältnis, Ausrichtung, Skalierung, Leerräume und visuelles Tempo variieren, während ein kohärentes Markensystem beibehalten wird. Wiederholen Sie nicht denselben zentrierten Block oder die Formel „Links Text/Rechts Karte“ auf der gesamten Seite.
• Abschnittskontinuität: Wenn mehrere Abschnittskonzepte zu einer Seite werden müssen, verwenden Sie Verbindungsgewebe aus dem vorhandenen Designsystem: Rinnen, Bänder, Ausrichtung, wiederholte Typografie, wiederkehrende Medienrahmen, Farbrhythmus und kleine Übergangsverschiebungen bei den Abständen. Erfinden Sie 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 Bilder sollten normalerweise in klaren, implementierungsfreundlichen Rahmen mit stabilen Seitenverhältnissen, konsistenter Beschneidungslogik, Radius, Schatten und Abständen sitzen. Vermeiden Sie zufällige Bildgrößen oder Collage-Chaos, es sei denn, der Benutzer bittet explizit um diese Richtung.
• UI-Einschränkungen: Kleine Beschriftungen, Utility-Pillen, Pseudo-Systemmarkierungen, gefälschte Metriken und dekoratives Dashboard-Jargon sind nur erlaubt, wenn sie das Produkt verdeutlichen. Wenn sie nur visuelle Füllung sind, entfernen Sie sie vor der Annahme.

Konzept-Review-Modus

Nur verwenden, wenn der Benutzer darum bittet, zuerst Konzepte zu generieren, Optionen zu prüfen oder auf Freigabe zu warten.

• Generieren und zeigen Sie das Konzept.
• Iterieren Sie, bis der Benutzer es freigibt.
• Implementieren Sie es nicht.

Benutzerdefinierte Instruktionen

• Bei der Erstellung einer vollständigen App oder eines vollständigen Dashboards priorisieren Sie die vollständige Designkonzeption aller Bildschirme, bevor Sie Code generieren.
• Wenn der Benutzer ein Upgrade, Redesign oder Restyling einer vorhandenen Website/App anfordert, stellen Sie sicher, dass das Image-Gen-Konzept die bestehende Informationsarchitektur und den vorhandenen Workflow beibehält.
• Für Landingpages: Standardmäßig klar, nicht überladen. Jeder Abschnitt sollte einen Zweck haben; vermeiden Sie Füllabschnitte.
• Für Dashboards und Tools: Bevorzugen Sie einen leistungsstarken primären Bildschirm mit klaren visuellen Hierarchien.
• Wenn der Benutzer explizit „kein Redesign“ sagt, verwenden Sie diesen Skill nicht.

Implementierungsqualität

• Verwenden Sie moderne, saubere, semantische, zugängliche HTML/CSS-Standards.
• Implementieren Sie die volle Absicht des Designs: Animationen, Übergänge, Hover-/Fokus-Zustände, responsive Verhalten, Schatten, Verläufe, Bilder und Symbole.
• Verwenden Sie echten Text und reale Inhalte, wo immer möglich; verwenden Sie Platzhalter nur, wenn die Daten nicht verfügbar sind.
• Stellen Sie sicher, dass die Seite oder App im ausgewählten Browser-Plugin korrekt geladen und korrekt gerendert wird.
• Beheben Sie alle Unterschiede zwischen dem Bild und der implementierten Version, bis sie visuell identisch sind.

Browser-Plugin-Test / Verifikation

• Plugin-Reihenfolge: Browser-Plugin zuerst, dann Playwright als Fallback.
• Verwendung des Browser-Plugins: Verwenden Sie das integrierte Tool browser oder Browser für die gesamte Vorschau, das Debugging und den Test der generierten HTML-Seiten/Apps.
• Ablauf: Nach der Generierung der UI-Implementierung fordern Sie sofort eine Vorschau der Ausgabe im Browser an. Verwenden Sie view_source und interagieren Sie nach Bedarf.
• Fallback: Wenn das Browser-Plugin nicht verfügbar ist, dokumentieren Sie den Grund und wechseln Sie zu Playwright (siehe).
• Endkontrolle: Vor der Übergabe: Rufen Sie view_image auf das akzeptierte Konzept auf und fordern Sie dann einen neuen Browser-Screenshot der implementierten Seite an. Vergleichen Sie die beiden visuell, um sicherzustellen, dass sie 10/10 übereinstimmen. Dokumentieren Sie das Ergebnis.

Design-Update-Zyklus

• Wenn der Benutzer nach der Implementierung um eine designbezogene Änderung bittet, aktualisieren Sie zuerst den Konzeptentwurf (verwenden Sie Image Gen entsprechen), lassen Sie ihn sich visuell zeigen, holen Sie die Freigabe ein und implementieren Sie dann.
• Aktualisieren Sie immer das Design-System-Token, wenn Sie ein Konzept ersetzen oder aktualisieren.
• Dokumentieren Sie visuelle Unterschiede zwischen Iterationen (optional).

Wichtiger Hinweis: Dieser Skill priorisiert das visuelle Design und die originalgetreue Implementierung gegenüber der Länge des Textes oder der Code-Effizienz, um die visuelle Qualität und den Maßstab zu erreichen. Das Designkonzept sollte vor dem Codieren fertiggestellt werden.

Koordination mit anderen installierten Skills

Dieser Skill ist Eigentümer des visuellen Konzepts und der originalgetreuen Frontend-Implementierung. Verwenden Sie andere installierte Skills, wenn die App Fähigkeiten außerhalb des Frontend-Designs benötigt. Die Provider-Einrichtung sollte das Image-Gen-Konzept, statische UI-Arbeit oder das Design-Review, die kein Provider-gestütztes Verhalten ausführen, nicht blockieren, aber die Implementierung und Überprüfung von Provider-gestütztem Verhalten sollte mit dem installierten Skill für diese Fähigkeit koordiniert werden. Vermeiden Sie Platzhalter-Einrichtungsanweisungen, wenn ein anderer installierter Skill diese Einrichtung abdeckt.

Verwenden Sie für KI-/Modell-generierte Ausgaben openai-developers:openai-platform-api-key, wenn verfügbar, es sei denn, der Benutzer nennt einen anderen Provider oder sagt explizit, dass OpenAI nicht verwendet werden soll. Wenn dieser Skill verfügbar ist, verwenden Sie immer dessen Anmeldefluss anstelle von Fake-Keys, Platzhalter-Umgebungsvariablen oder manuellen API-Key-Einrichtungsanweisungen.

Image-Gen-Workflow

Lesen und befolgen Sie den installierten @imagegen-Skill. Verwenden Sie für website-spezifische Briefing-Anleitungen references/imagegen-website-concepts.md.

Vor dem Aufruf von Image Gen:

• Kopieren Sie die konkreten Anforderungen des Benutzers in das Briefing: Produkt-/Seitenzweck, Zielgruppe, erforderliche Abschnitte oder Zustände, Workflow, bereitgestellter Text, Navigationsbezeichnungen, CTA-Bezeichnungen, Datenfelder, erforderliche Medien, responsive Anforderungen und Implementierungseinschränkungen.
• Fragen Sie nach der vollständigen angeforderten Oberfläche: Vollständige Seite, App-Bildschirm, Dashboard, Spielbildschirm oder koordinierter Abschnitts-/Zustandssatz. Wenn die Lieferung mehr als ein Hero ist, sagen Sie, dass das Konzept nachgelagerte Abschnitte, Zustände oder responsive Fortsetzung enthalten muss. Wenn die Abschnittsanzahl bekannt oder impliziert ist, nennen Sie jeden Abschnitt/Zustand, der seinen eigenen Konzept-Screenshot benötigt.
• Wiederholen Sie die Implementierungseinschrä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, beabsichtigtes Containermodell, keine standardmäßigen Kartenraster, keine erfundenen Hero-Eyebrows/Kicker/Badges/Pillen und praktische HTML/CSS/Komponenten-Implementierung.
• Bewahren Sie die Informationsarchitektur aus Benutzerinhalten, Screenshots oder vorhandenen Apps. Lassen Sie Image Gen keine irrelevanten Abschnitte, gefälschten Metriken, neuen Produktbehauptungen, zusätzliche Dashboards, neue Navigation oder eine andere Produktgeschichte erfinden.
• Standardmäßig ein koordiniertes Konzeptbild pro Hauptabschnitt für mehrteilige Websites oder lange Landingpages. Verwenden Sie eine optionale Übersicht nur für Struktur und Rhythmus; verlassen Sie sich niemals auf eine einzige riesige komprimierte Tafel, wenn sie Text, Schaltflächendetails, Kartenstruktur, Abstände oder Typografie schwer analysierbar macht.
• Generieren Sie für dichte Apps, Dashboards, Editoren, Produktoberflächen und komplexe Abschnitte separate Zustands- oder Detailkonzepte für die Bereiche, die in einem einzigen Vollbildbild unlesbar würden: Tabellen, Seitenleisten, Inspektoren, Modals, Werkzeugleisten, Diagramme, Formulare, Karten, Preisblöcke, Testimonials oder Medienmodule.
• Wenn ein Konzept-Screenshot zu klein, unscharf, beschnitten, überfüllt oder mehrdeutig für die Implementierung ist, generieren Sie vor dem Codieren einen frischen eigenständigen Abschnitts-/Zustands-/Detail-Screenshot. Behalten Sie dieselbe Palette, Typografie-Stimmung, Komponentenfamilie, Asset-Behandlung, Dichte und Abschnittsreihenfolge bei. Beschneiden, schneiden, zoomen Sie keinen winzigen Teil eines früheren Bildes als Quelle der Wahrheit wieder.
• Planen Sie für Spiele einen dedizierten Image-Gen-Asset-Durchlauf zusätzlich zum Konzept: transparente Charakter-/Zustands-Sprites oder Sprite-Board, Gelände-/Plattformkacheln, Sammelobjekte, Gefahren, Ziel-/Checkpoint-Objekte, Requisiten und 2-3 Parallax-/Hintergrundebenen, wenn die Umgebung Tiefe hat. HUD-Text, Punktzahl, Steuerelemente, Physik und Kollision bleiben Code-nativ.

Lehnen Sie Konzepte ab oder iterieren Sie daran, die nur Header für eine vollflächige Anfrage sind, überladen, generisch, repetitiv, unterspezifiziert, unlesbar, überdekoriert, nicht spezifikationskonform mit Hero-Eyebrows/Kickern/Badges/Pillen, die nicht explizit angefordert oder in der Referenz vorhanden sind, oder nicht praktisch originalgetreu implementierbar.

Designqualitätsmaßstab

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

• Eine klare kreative Idee oder visuelle Sichtweise.
• Starker erster Viewport mit klarem Angebot, Produktsignal und primärer Aktion.
• Vollseitiger 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 Abschnittsfluss: Verbinden Sie Abschnitte mit gemeinsamen Abständen, Palette, Typografie-Rhythmus, Medienbehandlung und subtilen Übergängen, nicht durch Erfinden großer neuer UI-Komponenten.
• Ausgezeichnete Typografie: Klare Hierarchie, Skalierung, Gewicht, Zeilenhöhe, Beschriftungsbehandlung und Steuer-/Chrome-Text, der nie auf Browser-Standardgrößen zurückfällt.
• Absichtliche Leerräume und Dichte; keine Füllkarten, Hero-Eyebrow/Kicker-Beschriftungen, Pillen, Badges, gefälschte Metriken oder Symbolzeilen, es sei denn, sie wurden explizit angefordert oder sind im akzeptierten Design vorhanden.
• Standardmäßig einfacher: Verwenden Sie weniger, stärkere visuelle Elemente, anstatt die Seite mit Illustrationen, Ikonografie, dekorativen Widgets oder komplexer UI-Chrome zu füllen.
• Kohärentes visuelles System: Palette, Abstände, Radius, Rahmen, Schatten, Verläufe, Symbolstil, Bildmaterial und Komponentengeometrie.
• Symboldetailtreue ist wichtig, wenn Symbole vorhanden sind. Passen Sie die Symbolmetapher, Strichstärke, Füllstil, Eckform, Größe, Farbe, Ausrichtung und Abstände des akzeptierten Designs an, anstatt generische naheliegende Symbole auszutauschen.
• Farbtreue ist obligatorisch. Passen Sie die tatsächlichen Hintergrund-, Oberflächen-, Text-, Rahmen-, Schatten- und Akzentfarben des akzeptierten Designs an; wenn das Design einen weißen Hintergrund verwendet, verwenden Sie Weiß anstelle von Creme, Elfenbein, Beige, Warmgrau oder einem anderen abgemilderten Off-White-Ersatz.
• Die Hero-Medienbehandlung muss mit dem akzeptierten Design übereinstimmen. Wenn das Hero-Bild im Konzept keine Farbüberlagerung oder Tönung hat, darf die Implementierung keine hinzufügen. Verwenden Sie Kantenüberblendungen, Masken oder Hintergrundverläufe nur, um Bildkanten in die Seite einzufügen; waschen Sie das Bild nicht mit einer Farbüberlagerung.
• Hochwertige generierte Assets für Logos, Markenzeichen, Hero-Bildmaterial, Produktdarstellungen, Hintergrundszenen, Illustrationen, Texturen, Poster, Avatare, leere Zustände und Spiel-Sprites/Kacheln/Hintergrundebenen. Produkt-/Hintergrund-Assets sollten vollständig gerendert sein mit konsistentem Branding und Text im Bild, wenn dieser Text zum Asset gehört.
• Zielgerichtete Bewegung, die Hierarchie verdeutlicht, Zustand offenbart oder das Produkt greifbar macht.
• Spezifischer, nicht-generischer Text, wenn der Benutzer keinen genauen Text bereitgestellt hat.

Standardmäßig zu sauberer, luftiger, geschmackvoller 7/10-Kreativität: unverwechselbar genug, um sich gestaltet anzufühlen, zurückhaltend genug, um es zu bauen, und nicht repetitiv. Interpretieren Sie „sauber“ als bearbeitet und lesbar, nicht als leer oder steril.

Standardeinstellungen für die visuelle Ausrichtung

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

• Grundlinie: ungefähr 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ählen Sie vor dem Generieren 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 Bewegungshinweise. Verpflichten Sie sich zur Kombination, damit sich das Design absichtlich anfühlt und nicht wie eine generische Vorlage.
• Hero oder erster Viewport: Behalten Sie einen offensichtlichen Brennpunkt, eine kurze lesbare Überschrift oder Hauptaufgabe, zurückhaltenden unterstützenden Text, eine sichtbare primäre Aktion und genügend negativen Raum, um auf einem kleinen Laptop zu funktionieren. Überladen Sie den ersten Blick nicht mit Statistiken, Chips, Badges, Fake-Steuerelementen oder konkurrierenden Mini-Panels.
• Header-Einfachheit: Standardmäßig ein sauberes Markenzeichen, wesentliche Navigation und eine primäre Aktion oder Steuerung. Vermeiden Sie symbolreiche Navigation, zusätzliche Schaltflächen, Suchleisten, Status-Widgets, segmentierte Steuerelemente, dekorative Illustrationen oder dichte Produkt-Chrome im Header, es sei denn, der Benutzer bittet explizit darum oder der Produktworkflow erfordert sie.
• Visuelle Ökonomie: Bevorzugen Sie ein oder zwei hochwertige Bild- oder Illustrationsmomente gegenüber vielen kleinen dekorativen Bildern. Verwenden Sie Ikonografie nur, wo sie Navigation, Steuerelemente oder Produktbedeutung verdeutlicht.
• Container-Disziplin: Vermeiden Sie verschachtelte Karten, riesige abgerundete Wrapper um jeden Abschnitt, standardmäßige Bento-/Kartenraster und überframte Dashboards, es sei denn, das Konzept oder der Produkttyp benötigt sie wirklich. Bevorzugen Sie offene Layouts, Bänder, Schienen, Listen, Tabellen, Leinwände oder eine einzige zielgerichtete Rahmenbewegung.
• Abschnittsrhythmus: Lange Seiten sollten Dichte, Bild-zu-Text-Verhältnis, Ausrichtung, Skalierung, Leerräume und visuelles Tempo variieren, während ein kohärentes Markensystem beibehalten wird. Wiederholen Sie nicht denselben zentrierten Block oder die Formel „Links Text/Rechts Karte“ auf der gesamten Seite.
• Abschnittskontinuität: Wenn mehrere Abschnittskonzepte zu einer Seite werden müssen, verwenden Sie Verbindungsgewebe aus dem vorhandenen Designsystem: Rinnen, Bänder, Ausrichtung, wiederholte Typografie, wiederkehrende Medienrahmen, Farbrhythmus und kleine Übergangsverschiebungen bei den Abständen. Erfinden Sie 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 Bilder sollten normalerweise in klaren, implementierungsfreundlichen Rahmen mit stabilen Seitenverhältnissen, konsistenter Beschneidungslogik, Radius, Schatten und Abständen sitzen. Vermeiden Sie zufällige Bildgrößen oder Collage-Chaos, es sei denn, der Benutzer bittet explizit um diese Richtung.
• UI-Einschränkungen: Kleine Beschriftungen, Utility-Pillen, Pseudo-Systemmarkierungen, gefälschte Metriken und dekoratives Dashboard-Jargon sind nur erlaubt, wenn sie das Produkt verdeutlichen. Wenn sie nur visuelle Füllung sind, entfernen Sie sie vor der Annahme.

Konzept-Review-Modus

Nur verwenden, wenn der Benutzer darum bittet, zuerst Konzepte zu generieren, Optionen zu prüfen oder auf Freigabe zu warten.

• Generieren und zeigen Sie das Konzept.
• Iterieren Sie, bis der Benutzer es freigibt.
• Implementieren Sie es nicht.

Benutzerdefinierte Instruktionen

• Bei der Erstellung einer vollständigen App oder eines vollständigen Dashboards priorisieren Sie die vollständige Designkonzeption aller Bildschirme, bevor Sie Code generieren.
• Wenn der Benutzer ein Upgrade, Redesign oder Restyling einer vorhandenen Website/App anfordert, stellen Sie sicher, dass das Image-Gen-Konzept die bestehende Informationsarchitektur und den vorhandenen Workflow beibehält.
• Für Landingpages: Standardmäßig klar, nicht überladen. Jeder Abschnitt sollte einen Zweck haben; vermeiden Sie Füllabschnitte.
• Für Dashboards und Tools: Bevorzugen Sie einen leistungsstarken primären Bildschirm mit klaren visuellen Hierarchien.
• Wenn der Benutzer explizit „kein Redesign“ sagt, verwenden Sie diesen Skill nicht.

Implementierungsqualität

• Verwenden Sie moderne, saubere, semantische, zugängliche HTML/CSS-Standards.
• Implementieren Sie die volle Absicht des Designs: Animationen, Übergänge, Hover-/Fokus-Zustände, responsive Verhalten, Schatten, Verläufe, Bilder und Symbole.
• Verwenden Sie echten Text und reale Inhalte, wo immer möglich; verwenden Sie Platzhalter nur, wenn die Daten nicht verfügbar sind.
• Stellen Sie sicher, dass die Seite oder App im ausgewählten Browser-Plugin korrekt geladen und korrekt gerendert wird.
• Beheben Sie alle Unterschiede zwischen dem Bild und der implementierten Version, bis sie visuell identisch sind.

Browser-Plugin-Test / Verifikation

• Plugin-Reihenfolge: Browser-Plugin zuerst, dann Playwright als Fallback.
• Verwendung des Browser-Plugins: Verwenden Sie das integrierte Tool browser oder Browser für die gesamte Vorschau, das Debugging und den Test der generierten HTML-Seiten/Apps.
• Ablauf: Nach der Generierung der UI-Implementierung fordern Sie sofort eine Vorschau der Ausgabe im Browser an. Verwenden Sie view_source und interagieren Sie nach Bedarf.
• Fallback: Wenn das Browser-Plugin nicht verfügbar ist, dokumentieren Sie den Grund und wechseln Sie zu Playwright (siehe).
• Endkontrolle: Vor der Übergabe: Rufen Sie view_image auf das akzeptierte Konzept auf und fordern Sie dann einen neuen Browser-Screenshot der implementierten Seite an. Vergleichen Sie die beiden visuell, um sicherzustellen, dass sie 10/10 übereinstimmen. Dokumentieren Sie das Ergebnis.

Design-Update-Zyklus

• Wenn der Benutzer nach der Implementierung um eine designbezogene Änderung bittet, aktualisieren Sie zuerst den Konzeptentwurf (verwenden Sie Image Gen entsprechend), lassen Sie ihn sich visuell zeigen, holen Sie die Freigabe ein und implementieren Sie dann.
• Aktualisieren Sie immer das Design-System-Token, wenn Sie ein Konzept ersetzen oder aktualisieren.
• Dokumentieren Sie visuelle Unterschiede zwischen Iterationen (optional).

Wichtiger Hinweis: Dieser Skill priorisiert das visuelle Design und die originalgetreue Implementierung gegenüber der Länge des Textes oder der Code-Effizienz, um die visuelle Qualität und den Maßstab zu erreichen. Das Designkonzept sollte vor dem Codieren fertiggestellt werden.