BIGboss248/nextjs-wordpress

Fähigkeit zur Komponenten- und UI-Gestaltung (component-design)

Ein strukturierter UX/UI-Discovery- und Spezifikationsworkflow für die Gestaltung von Web- und Anwendungskomponenten, -abschnitten und -seiten. Generiert produktionsreife Design-Spezifikationen (design-spec.md), die von visuellen Prototyping-Tools wie stitch-design und Code-Implementierungs-Workflows konsumiert werden können.

---

Leitplanken & Kernprinzipien

[!IMPORTANT] 1. Null-Code-Leitplanke (Reiner Design-Umfang): Diese Fähigkeit beschäftigt sich ausschließlich mit UX, UI, Layout-Architektur, Typografie und visuellen Tokens. Gib niemals React-Komponenten, Next.js-Direktiven, TypeScript-Prop-Schnittstellen oder Paketinstallationsbefehle aus (keine shadcn/Radix-CLI-Befehle). Die Code-Implementierung erfolgt in nachgelagerten Entwicklungsworkflows.

[!CAUTION] 2. Design-Token-Voraussetzungstor (Tokens-Zuerst-Regel): Keine Komponente kann ohne verifizierte kanonische Design-Tokens in docs/projekt.json designt werden. Fehlende Tokens müssen hinterfragt und gespeichert werden, bevor Komponentendesigns entworfen werden. Siehe token-verification-matrix.md.

[!TIP] 3. Token-Erhaltungsregel (Keine direkte Bildgenerierung im Skill): Rufe generate_image niemals direkt auf. Formuliere strukturierte Bildgenerierungsprompts für den Benutzer, die dieser in die Projektverzeichnisse generieren und ablegen kann.

[!NOTE] 4. Selektive Muster-Nachschlage (Token-Erhaltung): Überprüfe die Routing-Tabelle in references/component-design-patterns.md und lade NUR die übereinstimmende Komponentendatei unter references/patterns/ (z.B. hero.md). Falls eine Übereinstimmung gefunden wird, befrage den Benutzer während der adaptiven Befragung, ob dieses Muster implementiert werden soll.

---

Workflow-Übersicht

flowchart TD
    Start["Aufruf /component-design<br/>(Seite + Komponentenname)"] --> Schritt1["Schritt 1: Dynamischer Kontext & Token-Tor<br/>(Scanne docs/**, CONTEXT.md, Tokens & gezieltes Muster)"]
    Schritt1 --> PrüfeTokens{"Sind Design-Tokens<br/>vollständig in docs/projekt.json?"}
    PrüfeTokens -- "Fehlende Tokens" --> BefrageTokens["Fehlende Tokens abfragen<br/>(3 kontextbezogene Optionen)"]
    BefrageTokens --> SpeichereTokens["Speichere in docs/projekt.json"]
    SpeichereTokens --> Schritt2
    PrüfeTokens -- "Verifiziert" --> Schritt2["Schritt 2: Mehrstufige adaptive Befragung<br/>(Runden 1–3 + gezielte Musterabfrage)"]
    Schritt2 --> Schritt3["Schritt 3: Formulierung von visuellen Asset-Prompts<br/>(Bereitstellung gebrauchsfertiger Bild-Prompts)"]
    Schritt3 --> Schritt4["Schritt 4: Gerüst & Schreiben von design-spec.md<br/>(docs/design/components/[seite]/[komponente]/)"]
    Schritt4 --> Schritt5["Schritt 5: Subagenten-Prüfung & automatische Reparatur<br/>(invoke_subagent prüft Leitplanken & Tokens)"]
    Schritt5 --> Fertig["Spezifikation bereit für die Weiterleitung<br/>(Visuelles Prototyping / Implementierung)"]

---

Ausführungsrunbook

Schritt 1: Dynamische Kontexterkennung & Design-Token-Verifikationstor

1. Projektkontext scannen: Untersuche dynamisch alle Dateien in docs/ und die CONTEXT.md im Stammverzeichnis, um Ziel-Personas, Geschäftsziele und vorhandene Design-Lesezeichen zu extrahieren.
2. Unterstützte Sprachen scannen: Lese project_context_and_metadata.supported_languages in docs/projekt.json.
3. Design-Tokens verifizieren: Prüfe docs/projekt.json unter "design_system" gemäß token-verification-matrix.md.
4. Fehlende Tokens abfragen: Wenn Tokens fehlen, formuliere 3 projektangepasste Optionen (eine als (Empfohlen) markieren), befrage den Benutzer und speichere sie unter "design_system".
5. Gezielte Designmuster-Nachschlage: Scanne die Routing-Tabelle in references/component-design-patterns.md und zeige NUR die spezifische Komponentenmusterdatei unter references/patterns/ an, sofern ein Muster für die zu desigende Komponente übereinstimmt.

Schritt 2: Fortschreitende mehrstufige Komponentenbefragung

Führe ein adaptives 3-Runden-Interview mit ask_question (oder interaktivem Chat) durch, wobei zwischen den Runden pausiert wird, um die Antworten des Benutzers aufzunehmen. Konsultiere adaptive-grilling-rounds.md für vollständige Frageformulierungen:

• Falls ein passendes Muster in references/patterns/ gefunden wurde, integriere dessen Fragebogen in Runde 1 oder Runde 2, um den Benutzer explizit zu befragen, ob dieses Muster implementiert werden soll.
• Runde 1 (Absicht & Geschichte): Kläre den Zweck der Komponente, die zu erledigenden Benutzeraufgaben und den emotionalen Ton.
• Runde 2 (Räumliche Hierarchie & Raster): Passe mehrspaltige Layouts, Dichteskalen und den fokalen Blickfluss basierend auf den Antworten von Runde 1 an.
• Runde 3 (Interaktionen & Akzente): Etabliere Hover-/Fokus-Zustandsdynamiken, Medien-Assets und BiDi-/RTL-Nuancen basierend auf den Antworten von Runde 1 & 2.

Schritt 3: Proaktive Formulierung von visuellen Asset-Prompts

Falls die Komponente maßgeschneiderte Grafiken, Hintergründe oder Symbole erfordert, formuliere strukturierte Generierungsprompts für den Benutzer, anstatt generate_image aufzurufen. Siehe Prompt-Blockformat in adaptive-grilling-rounds.md.

Schritt 4: Komponentenordner & design-spec.md anlegen

1. Erstelle das Verzeichnis: docs/design/components/[seitenname]/[komponentenname]/

2. Lege design-spec.md mit dem kanonischen 9-Abschnitts-Layout aus design-spec.template.md an:

   • §1 Zusammenfassung & Geschichte
   • §2 Visuelle Hierarchie & Räumlicher Fluss
   • §3 Layoutraster & Responsive Haltepunkte (Mobil, Tablet, Desktop)
   • §4 Design-Tokens & Farbzuordnung (Hell & Dunkel)
   • §5 Typografieskala (Pro unterstützter Sprache)
   • §6 Interaktionszustandsmatrix (Standard, Hover, Aktiv, Fokus, Deaktiviert, Skelett)
   • §7 Bidirektionale (RTL) Anpassungen
   • §8 Barrierefreiheit & Ergonomie (WCAG AA/AAA, $\ge 44\text{px}$ Touch-Ziele)
   • §9 Empfohlene visuelle Assets & Prompts

Schritt 5: Unabhängige Subagenten-Qualitätsprüfung (invoke_subagent)

Um eine unvoreingenommene Qualität zu gewährleisten, rufe vor der Präsentation der Ergebnisse einen unabhängigen Prüf-Subagenten auf:

1. Starte den Prüf-Subagenten (TypeName: "self", Rolle: "Unabhängiger Design- & UX-Prüfer", Modell: "erb").
2. Verwende die strukturierte Prüfanfrage in subagent-audit-protocol.md.
3. Falls PROBLEME_GEFUNDEN, behebe alle markierten Probleme sofort in design-spec.md, bevor du abschließt.

---

Weiterleitung

Sobald design-spec.md genehmigt und verifiziert ist:

1. Visuelles Prototyping: Löse stitch-design aus, um UI-Bildschirme und Layout-Varianten in Google Stitch zu generieren.
2. Code-Implementierung: Stelle design-spec.md den Komponenten-Implementierungs-Fähigkeiten zur Verfügung (z.B. nextjs-component-dev / nextjs-create-component).

---

Ausführungs-Verifizierungs-Checkliste

Bevor die Ausführung abgeschlossen wird, bestätige:

• Keine Code- oder Bibliotheksinstallationsbefehle (kein React, Next.js, shadcn-CLI) in den Ergebnissen.
• Kanonische Design-Tokens in docs/projekt.json sind verifiziert und vollständig.
• Ausgabeverzeichnis ist strukturiert unter docs/design/components/[seite]/[komponente]/.
• Optionen während der Befragung wurden dynamisch synthetisiert, ohne fest codierte Repository-Annahmen.
• Komponentenbefragung folgte fortschreitenden adaptiven Runden.
• generate_image wurde NICHT direkt aufgerufen; Asset-Prompts wurden dem Benutzer zur Verfügung gestellt.
• design-spec.md enthält alle 9 erforderlichen Abschnitte.
• Unabhängige Subagentenprüfung wurde über invoke_subagent aufgerufen und alle Probleme wurden behoben.