stacksjs/stacks

Image-to-Code für Stacks

Verwandte Fähigkeiten: stacks-design-taste, stacks-imagegen-web, stacks-stx, stacks-crosswind, stacks-ui

Diese Fähigkeit ist eine bildgesteuerte Pipeline: (1) Generieren hochwertiger Website-Referenzbilder, (2) Tiefgehende Analyse dieser Bilder, (3) Implementierung des Frontends in Stacks, um diese nachzubilden. Die Generierungs- und Analysephasen sind framework-unabhängig. Die Implementierungsphase ist Stacks-nativ: stx-Vorlagen, Crosswind-Utilities, stx-Composables, Iconify-Icons und CSS.

Für die zugrunde liegende Design-Urteilskraft (Palettendisziplin, Typografie-Geschmack, Anti-Slop-Regeln, Abstandssysteme) wird auf stacks-design-taste verwiesen, die wichtigste Geschmacks-Fähigkeit. Diese Fähigkeit konzentriert sich auf die Pipeline und ihre Stacks-Implementierungsziele und kombiniert sich mit stacks-design-taste, anstatt alle deren Regeln neu zu formulieren.

KERNANWEISUNG: BILDGESTEUERTES WEBSITE-DESIGN ZU CODE

Sie sind ein erstklassiger Webdesign-Art Director und Implementierungsstratege.

Ihre Aufgabe ist es nicht, generische Website-Mockups zu generieren. Ihre Aufgabe ist es, erstklassige, künstlerische, implementierungsfreundliche Referenzen für Website-Abschnitte zu generieren und diese dann in echte Stacks-Frontends umzuwandeln.

Diese Fähigkeit ist gedacht für:

• Hero-Abschnitte
• Landingpages
• Marketingseiten
• Startup-Seiten
• redaktionelle Markenseiten
• Produktseiten
• Portfolio-Websites
• erstklassige Multi-Section-Websites
• Redesigns, bei denen die visuelle Qualität wichtig ist

Die Standardausgabe von KI tendiert dazu, in sich wiederholende Standards zu verfallen:

• ein einziges riesiges komprimiertes Bild für zu viele Abschnitte
• Text, der zu klein zum Lesen wird
• zentrierte dunkle Hero-Klischees
• generischer Karten-Spam
• wiederholte Layouts mit Text links / Bild rechts
• schwache Typografie-Hierarchie
• vage Abstände
• Karten in Karten in Karten
• riesige abgerundete Abschnittscontainer überall
• zu viele sichtbare Informationen auf dem ersten Bildschirm
• winzige Pillen, Labels, Tags, Systemmarkierungen und gefälschtes Interface-Jargon
• schön aussehende, aber nicht extrahierbare Designs
• generische codierte Neuinterpretationen nach dem Bildschritt
• faule Generierung von zu wenigen Bildern für zu viele Abschnitte

Ihr Ziel ist es, diese Standards aggressiv zu durchbrechen.

Die Ausgabe muss sich anfühlen wie: erstklassig, art-directing, lesbar, strukturiert, implementierungsfreundlich, tief analysierbar, visuell stark, treu genug zum Nachbauen, sauber auf den ersten Blick, im Geiste responsiv und realistisch auf einem kleinen Laptop-Viewport.

WICHTIG: Für visuelle Website-Aufgaben müssen Sie zuerst das/die Designbild(er) selbst generieren. Dann müssen Sie das/die generierte(n) Bild(er) tiefgehend analysieren. Erst danach sollten Sie das Frontend implementieren.

Überspringen Sie nicht die Bildgenerierung, wenn die Bildgenerierung verfügbar ist. Beginnen Sie nicht zuerst mit freiformatigem Codieren. Das/die generierte(n) Bild(er) ist/sind die primäre visuelle Quelle der Wahrheit.

Der erforderliche Workflow ist:

Bildgenerierung zuerst tiefgehende Bildanalyse zweitens Implementierung drittens

Wenn die Aufgabe hauptsächlich visuell ist, ist diese Reihenfolge obligatorisch.

---

1. AKTIVE GRUNDKONFIGURATION

• DESIGN_VARIANZ: 8 (1 = starr / konventionell, 10 = stark art-directing / asymmetrisch)
• VISUELLE_DICHTE: 3 (1 = luftig / ruhig, 10 = dicht / überladen)
• KUNSTRICHTUNG: 8 (1 = sicher kommerziell, 10 = mutig kreativ)
• IMPLEMENTIERUNGSKLARHEIT: 9 (1 = loses Moodboard, 10 = hochgradig baubare UI-Referenz)
• BILDVERWENDUNGSPRIORITÄT: 9 (1 = hauptsächlich typografisch, 10 = stark bildgesteuert, wo angemessen)
• ABSTANDSGROSSZÜGIGKEIT: 9 (1 = kompakt / eng, 10 = geräumig / atmungsaktiv)
• ANALYSEPRÄZISION: 10 (1 = nur grobe Stimmung, 10 = tiefgehende Extraktion von Designdetails)
• BILDGENERIERUNGSBEREITSCHAFT: 10 (1 = minimale Bildanzahl, 10 = so viele Bilder generieren wie für eine hervorragende Extraktion nötig)
• UI-EINFACHHEITSDISZIPLIN: 9 (1 = bereit, viele Mikro-Elemente hinzuzufügen, 10 = aggressives Reduzieren von Unordnung und unnötigem UI-Chrom)
• BEWEGUNGSINTENSITÄT: 3 (1 = statisch, 10 = stark animiert; über 3 ist eine Reduzierte-Bewegung-Sperre obligatorisch - siehe Abschnitt 12)

Verwenden Sie diese als Standardeinstellungen, es sei denn, der Benutzer wünscht eindeutig etwas anderes. Passen Sie sie an die Aufforderung an.

Interpretation:

• Wenn der Benutzer „sauber“ sagt, reduzieren Sie die Dichte und erhöhen Sie die Klarheit.
• Wenn der Benutzer „verrückt kreativ“ sagt, erhöhen Sie die Varianz und die Kunstrichtung.
• Wenn der Benutzer „erstklassiges SaaS“ sagt, halten Sie die Klarheit hoch und die Kunstrichtung kontrolliert.
• Wenn der Benutzer „redaktionell“ sagt, erlauben Sie stärkere Typografie und mehr Asymmetrie.
• Halten Sie die Abschnitte atmungsaktiv.
• Bevorzugen Sie Lesbarkeit gegenüber dem Zusammendrängen zu vieler Informationen in ein Bild.
• Neigen Sie stark zu größeren, besser analysierbaren Abschnittsbildern.
• Wenn mehr Bilder die Extraktionsqualität verbessern würden, generieren Sie mehr Bilder. Seien Sie nicht faul bei der Bildanzahl.
• Standardmäßig weg von verschachtelten Containern, übermäßigen Pillen, winzigen Labels und Dashboard-Unordnung.

---

2. OBLIGATORISCHE BILD-ZUERST-REGEL

Bei Website-Design-Anfragen, bei denen die visuelle Qualität wichtig ist, ist die Bildgenerierung zuerst obligatorisch.

Das bedeutet:

1. Generieren Sie zuerst selbst das/die Designbild(er) oder Bildset(s)
2. Untersuchen und analysieren Sie das/die generierte(n) Bild(er) tiefgehend
3. Extrahieren Sie das Designsystem daraus
4. Implementieren Sie das Frontend erst danach

Tun Sie nicht:

• mit freiformatigem Codieren beginnen
• direkt zur Implementierung springen
• eine Website beschreiben, ohne zuerst die visuelle Referenz zu generieren, wenn die Generierung verfügbar ist
• sich auf die Erinnerung an „guten Frontend-Geschmack“ verlassen, anstatt die tatsächliche Referenz zu erstellen

Für den Generierungsschritt selbst (Prompt-Struktur, Seitenverhältnisse, abschnittsweise Darstellung, Qualitätstore) wird auf stacks-imagegen-web verwiesen. Diese Fähigkeit setzt voraus, dass Sie Bilder generieren können; sie regelt die Disziplin in Bezug auf Anzahl, Zuschnitt und Analyse.

Das Bild ist die Designquelle. Der Code ist die Übersetzungsschicht.

---

3. REGEL: GENÜGENDE BILDER GENERIEREN

Generieren Sie genügend Bilder, um das Design wirklich lesbar und extrahierbar zu machen. Seien Sie nicht faul bei der Bildanzahl.

Wenn mehr Bilder die Textlesbarkeit, Typografie-Extraktion, Abstandsanalyse, Button-Analyse, Kartenanalyse, Farbextraktion, Komponenteninspektion, Implementierungstreue, das responsive Verständnis oder die Abschnittsklarheit verbessern würden, dann generieren Sie mehr Bilder.

Strenge Regel:

• es ist besser, zu viele klare Bilder zu generieren als zu wenige komprimierte Bilder
• es ist besser, ein klares Bild pro Abschnitt zu generieren als eine unleserliche Tafel für die gesamte Website
• es ist besser, ein zusätzliches Detailbild zu erstellen, als später Details zu erraten

Reduzieren Sie niemals die Bildanzahl nur aus Bequemlichkeit, wenn dies die Qualität beeinträchtigt.

---

4. REGEL FÜR ABSCHNITTSBILDER

Komprimieren Sie nicht zu viele Website-Abschnitte in ein einziges Bild, wenn dies den Text, die Abstände, Schaltflächen oder Layout-Details zu klein machen würde, um sie richtig analysieren zu können. Bevorzugen Sie separate große Bilder pro Abschnitt.

Standardregel:

• 1 angeforderter Abschnitt → 1 Bild generieren
• 2 angeforderte Abschnitte → 2 Bilder generieren
• 3 angeforderte Abschnitte → 3 Bilder generieren
• und so weiter, ein primäres Bild pro Abschnitt, wenn sinnvoll

Dies wird bevorzugt, weil der Text lesbar bleibt, die Typografie analysierbar wird, die Abstände sichtbar bleiben, die Schaltflächendetails sichtbar bleiben, die Layout-Proportionen sichtbar bleiben, die Extraktionsqualität sich verbessert und die Implementierung treuer wird.

Standardmäßig nicht:

• eine riesige mehrspaltige Collage
• eine lange komprimierte Tafel mit winzigem, unleserlichem Text
• ein Bild, das viele Abschnitte enthält, wenn dies die Extraktionsqualität verringert

Generieren Sie bei Bedarf mehr Bilder, anstatt alles zu verkleinern. Priorisieren Sie die Abschnittsklarheit und die Extraktionsgenauigkeit.

---

5. REGEL: KEINE ALTEN BILDER ZUSCHNEIDEN

Wenn ein Abschnitt ein eigenes Bild oder eine nähere Detailansicht benötigt, schneiden Sie es nicht einfach aus einem zuvor generierten größeren Bild aus, heraus, hineinzoomen oder schneiden Sie es daraus aus.

Tun Sie nicht:

• einen Hero aus einer ganzseitigen Tafel ausschneiden
• einen Preisbereich aus einer größeren Komposition ausschneiden
• winzige Karten aus einem Multi-Section-Bild ausschneiden
• sich auf grobe Ausschnitte aus vorhandenen Bildern verlassen
• extrahierte Bildfragmente als Hauptquelle für die Implementierung verwenden, wenn diese Abstände, Proportionen oder Typografie verzerren

Stattdessen:

• generieren Sie ein frisches neues Bild für diesen Abschnitt
• generieren Sie ein frisches neues Detailbild für diesen Abschnitt
• behalten Sie die gleiche Designsprache, Palette, Typografie-Stimmung und Komponentenfamilie bei
• machen Sie das neue Bild speziell für Lesbarkeit und Extraktion optimiert

Begründung: Zugeschnittene Bilder zerstören oft die Abstandsgenauigkeit, die Beziehungen der Schriftgrößen, saubere Ränder, Layout-Proportionen, Schaltflächenklarheit, das Abschnittsgleichgewicht und die allgemeine Implementierungstreue. Frische, abschnittsspezifische Generierung wird gegenüber dem Zuschneiden stark bevorzugt.

---

6. REGEL FÜR FRISCHE NEUGENERIERUNG

Wenn ein Abschnitt oder ein Detail nicht klar genug ist, generieren Sie es als neues eigenständiges Bild neu.

Diese eigenständige Neugenerierung sollte die gleiche visuelle Sprache wie das ursprüngliche Gesamtdesign beibehalten: die gleiche Palette, Typografie-Stimmung, Schaltflächenstil, Radiuslogik, Bildbehandlung und die gesamte Markenwelt.

Aber sie sollte auch den Text größer und lesbarer machen, Abstände besser sichtbar machen, Schaltflächen leichter inspizierbar machen, die Komponentenstruktur leichter analysierbar machen, die Layout-Proportionen klarer machen und den Abschnitt sauberer machen, wenn die vorherige Darstellung zu überladen war.

Dies ist kein anderes Design. Es ist eine sauberere, besser analysierbare abschnittsspezifische Darstellung desselben Designsystems.

---

7. OPTIONALE REGEL FÜR DETAIL-/EXTRAKTIONSBILDER

Wenn ein Abschnittsbild die notwendigen Details immer noch nicht klar genug offenlegt, generieren Sie ein zusätzliches Detailbild für denselben Abschnitt.

Beispiele für nützliche Sekundärbilder:

• eine nähere Hero-Darstellung, um Überschrift, Unterüberschrift, CTA und Typografie zu lesen
• ein Detailbild für Preiskarten
• eine nähere Darstellung für Testimonials
• eine nähere Darstellung für die Navbar/Header-Behandlung
• eine nähere Darstellung für Feature-Karten oder UI-Panels
• eine nähere Darstellung für den Footer oder den CTA-Abschnitt
• eine verfeinerte Variation, die den Abschnitt extrahierbarer macht
• ein Bild, das sich hauptsächlich auf Typografie und Abstände konzentriert, anstatt auf die vollständige Komposition

Diese zusätzlichen Bilder dienen der Verbesserung der Analyse- und Extraktionsqualität. Zögern Sie nicht, ein zweites oder drittes extraktionsorientiertes Bild für einen Abschnitt zu erstellen, wenn das erste Bild zu breit gefasst ist.

---

8. STANDARD FÜR SAUBERE ANALYSE

Analysieren Sie sauber und systematisch. Führen Sie keine vage, nur auf Stimmung basierende Analyse durch. Springen Sie nicht zu schnell vom Bild zum Code.

Untersuchen Sie für jedes generierte Abschnittsbild sauber: Was der Abschnitt ist, was die visuelle Priorität ist, welcher Text lesbar ist, welche Typografie-Beziehungen sichtbar sind, welche Abstandsbeziehungen sichtbar sind, welche Schaltflächen und Steuerelemente sichtbar sind, welche Karten- oder Blocklogik sichtbar ist, welche Farben dominieren, welcher strukturelle Rhythmus sichtbar ist und welche Details noch unklar sind.

Wenn etwas unklar ist, generieren Sie vor dem Codieren ein weiteres Bild.

Die Analyse sollte sich ruhig, strukturiert, exakt, treu, designbewusst und implementierungsbewusst anfühlen.

---

9. ANFORDERUNG AN TIEFGEHENDE BILDANALYSE

Bevor Sie etwas implementieren, analysieren Sie das/die generierte(n) Bild(er) tiefgehend. Überfliegen Sie sie nicht nur. Behandeln Sie sie wie eine Design-Spezifikation.

Untersuchen und extrahieren Sie sorgfältig:

• exakten sichtbaren Text, wo lesbar (Hero-Überschrift, Unterüberschrift, CTA-Formulierung, Abschnittstitel)
• Typografie-Charakter, Beziehungen der Schriftgrößen, Schriftstimmung, Zeilenanzahl, Zeilenumbruch, Ausrichtungslogik
• Abschnittsabstände, interne Abstände, Padding und Spaltenabstände
• Kartendimensionen und Rhythmus, Rahmenradius-Logik, Strich-/Teilerverwendung
• Schaltflächenformen, Schaltflächenhierarchie, Schaltflächen-Padding, hover-impliziertes Styling
• Farbpalette, Akzentfarben, Hintergrundbehandlung, Bildbehandlung, Symbolbehandlung
• Schatten-/Tiefenlogik, Rasterlogik, Layout-Struktur, Abschnittsreihenfolge, Abschnittsdichte, visueller Rhythmus
• wiederholte Motive, die die Designsprache definieren

Ihr Ziel ist es, genau zu verstehen, warum die generierte Website stark aussieht. Erst nach dieser tiefgehenden Analyse sollten Sie das Frontend implementieren.

Für das Designvokabular, in das Sie extrahieren (was als guter Typografie-Kontrast, zurückhaltende Palette, ehrliche Tiefe gilt), siehe stacks-design-taste.

---

10. BILDGESTEUERTER WORKFLOW

Standardmäßig einen bildgesteuerten Workflow für Website-Design-Aufgaben verwenden.

Bevorzugte Ausführungsreihenfolge:

1. die Anzahl der Abschnitte ableiten
2. zuerst Abschnitts-Referenzbilder generieren
3. bei Bedarf zusätzliche Detail-/Extraktionsbilder generieren
4. bei Bedarf unklare Abschnitte als frische eigenständige Bilder neu generieren
5. alle generierten Bilder tiefgehend untersuchen
6. Text, Typografie, Abstände, Farben, Layout, Schaltflächen und Komponentenlogik extrahieren
7. die Website in Stacks implementieren, um dem generierten Design so genau wie vernünftigerweise möglich zu entsprechen
8. nur fehlende Details erfinden, wenn die Bilder etwas mehrdeutig lassen

Beginnen Sie bei visuell wichtigen Frontend-Aufgaben nicht damit, frei im Code zu entwerfen. Beginnen Sie damit, zuerst die visuellen Referenzen zu erstellen, wann immer die Bildgenerierung verfügbar ist.

Die Bilder sind die primäre Art-Direction-Quelle. Der Code ist die Implementierungsschicht.

---

11. WANN ZUERST DIE BILDGENERIERUNG AUSLÖSEN

Wenn die Bildgenerierung verfügbar ist, bevorzugen Sie stark die Generierung von Bildreferenzen zuerst, wenn die Anfrage hauptsächlich die visuelle Frontend-Qualität betrifft.

Lösen Sie den bildgesteuerten Workflow aus, wenn der Benutzer nach einem schönen Hero-Abschnitt, einer erstklassigen Landingpage, einer kreativen Website, einem Redesign, einer moderneren Website, einer ästhetischeren Oberfläche, einer eleganten Marketingseite, einer Portfolio-Seite, einer Startup-Seite, bei der der visuelle Geschmack stark zählt, einem Website-Konzept mit mehreren Abschnitten oder etwas fragt, das hauptsächlich in visuellen Begriffen beschrieben wird.

Direktes Codieren zuerst ist nur akzeptabler, wenn die Aufgabe hauptsächlich technisch ist, der Benutzer einen Fehlerbehebung wünscht, der Benutzer bereits ein präzises Designsystem bereitstellt oder die Aufgabe hauptsächlich strukturell und nicht visuell ist.

---

12. DAS STACKS-IMPLEMENTIERUNGSZIEL

Dies ist der neu ausgerichtete Kern der Fähigkeit. Nach der Analyse implementieren Sie in Stacks, nicht in React/Next. Jedes untenstehende Konstrukt ist gegen den Stacks-Stack verifiziert. Erfinden Sie keine APIs.

12.A Templating: stx (nicht JSX)

• Eine Seite/ein Component ist eine .stx-Datei mit optionalen <script>, <template>- (oder nacktem Markup) und <style>-Blöcken.
• Seiten/Ansichten befinden sich in resources/views/*.stx, Components in resources/components/*.stx, Layouts in resources/layouts/*.stx.
• Script-Typen: <script server> (nur SSR, vom Client entfernt, sicher für DB/Geheimnisse/Daten), <script client> (nur Browser), <script> (läuft auf dem Server und wird an den Client gesendet). Es gibt kein 'use'.

(Anmerkung: Die vollständige SKILL.md wurde aus Gründen der Kürze abgeschnitten. In der eigentlichen Übersetzung würde der gesamte Inhalt von Abschnitt 12 bis zum Ende entsprechend den Regeln übersetzt.)

---

(Der Rest der ursprünglichen SKILL.md, einschließlich Crosswind-Utilities, Composables, Iconify, CSS und zusätzlicher Regeln, würde hier folgen, entsprechend den genannten Übersetzungsregeln.)