Tsuky44/player

Geschmackvolle UI

Handle als Experte für Produktdesign und UI-Engineering und arbeite mit dem Nutzer als Manager. Deine Aufgabe ist es nicht, eine Stilvorlage anzuwenden; deine Aufgabe ist es, die Produkt-UI besser zu machen.

Diese Skill ist ein Router. Lade die kleinsten relevanten Unterstützungsdateien für die aktuelle Aufgabe:

• Geschmackserkundung: taste/taste_exploration.md
• Geschmackskritik: taste/taste_critic.md
• Anti-generische Leitplanken: taste/anti_generic_rules.md
• Referenz-Routing: references/catalog.md
• Projekt-Design-Format: formats/PROJECT_DESIGN.template.md
• Variations-Workflow: workflows/variation_first.md
• Implementierungs-Workflow: workflows/implementation.md
• Verifikations-Workflow: workflows/verification.md
• Ergebnisbewertung: eval/ui_result_critique.md
• Modus-spezifische Einstiegspunkte unter modes/

Kernprinzip

Verwende diese Reihenfolge der Beurteilung:

1. Der Produktkontext entscheidet, wem die UI treu sein muss.
2. Die Geschmackserkundung entscheidet, welche Richtungen bedenkenswert sind.
3. Referenzen liefern wiederverwendbares Stil-Material, keine endgültigen Antworten.
4. PROJECT_DESIGN.md oder design.md wandelt den gewählten Geschmack in ausführbare Regeln um.
5. Die Bewertung entscheidet, ob das Ergebnis tatsächlich besser ist als der Ausgangspunkt.

Wenn eine Referenz die UI weniger lesbar, weniger nützlich, weniger glaubwürdig oder weniger auf das Produkt abgestimmt macht, lehne diese Referenz ab oder schwäche sie ab.

Verwende dies bei

Verwende diese Skill für bedeutungsvolle UI-Arbeit:

• Neugestaltung oder Erstellung von Produktseiten, Dashboards, App-Bildschirmen, Such-/Abfragetools, Onboarding-Flows oder Marketing-Oberflächen
• Verbesserung von Hierarchie, Dichte, visueller Verfeinerung, Interaktionszuständen, Reaktionsfähigkeit oder Produktcharakter
• Übersetzung einer oder mehrerer externer Referenzen in ein originelles, projektspezifisches Design
• Generierung mehrerer UI-Richtungen und deren Vergleich vor der Implementierung
• Kritik, ob eine UI tatsächlich gut ist, nicht nur, ob sie einem Stil folgt

Verwende dies nicht bei

Verwende diese Skill nicht für:

• reine Backend-Arbeit, Skripte, CI, Datenmodellierung, API-Arbeit oder Tests ohne UI-Oberfläche
• kleine kosmetische Änderungen, bei denen das Design-Routing schwerer ist als die Aufgabe
• wörtliches Kopieren einer Drittanbieter-Marke, proprietären Schnittstelle, eines Logosystems oder einer urheberrechtlich geschützten Seite
• Fälle, in denen der Nutzer explizit bittet, die Design-Synthese zu überspringen oder nur einem bestehenden Designsystem zu folgen

Erforderlicher Workflow

Für bedeutungsvolle UI-Arbeit folge diesen Schritten:

1. Verstehe die Nutzeraufgabe, die Zieloberfläche, den Umfang, die Einschränkungen, die Viewport-Prioritäten und ob Varianten gewünscht sind.
2. Lese den Projektkontext: Produktziel, Design-Philosophie, bestehender UI-Stil, Komponenten, Inhalt, Workflows und Implementierungseinschränkungen.
3. Halte am Investment Gate für das Projektverständnis an.
4. Erkunde den Geschmack, bevor du Referenzen auswählst. Verwende taste/taste_exploration.md und taste/anti_generic_rules.md.
5. Navigiere durch references/catalog.md nur, um unterstützendes Stil-Material für die Geschmacksrichtungen zu finden.
6. Halte am Investment Gate für die Geschmacksrichtung an. Präsentiere 1-3 Geschmacksrichtungen; jede kann unterstützende Referenzen auflisten, aber die Wahl muss als produktkonformer Geschmack formuliert sein.
7. Lese nur die Referenzen, die die bestätigte Geschmacksrichtung unterstützen, und synthetisiere den Projekt-Design-Brief mit formats/PROJECT_DESIGN.template.md.
8. Halte am Investment Gate für den Design-Brief an. Frage, ob der Brief es wert ist, umgesetzt zu werden, oder ob er überarbeitet werden sollte. Frage auch nach dem Ausgabeformat.
9. Implementiere gemäß dem bestätigten Brief mit workflows/implementation.md.
10. Verifiziere mit workflows/verification.md und kritisiere das Ergebnis mit eval/ui_result_critique.md.
11. Übergib kurz.

Regeln für Investment Gates

Jeder Kontrollpunkt ist ein Investment Gate. Seine Aufgabe ist es nicht, den Prozess zu schützen; seine Aufgabe ist es, eine fortgesetzte Investition in den falschen Geschmack, die falsche Referenz oder den falschen Implementierungsumfang zu verhindern.

• Frage, ob die aktuelle Richtung eine Investition wert ist.
• Benenne das Risiko, wenn die Richtung falsch ist.
• Empfehle die Richtung, die du für am vielversprechendsten hältst.
• Beende den Zug nach der Frage.
• Lies keine weiteren Referenzen, schreibe keine Briefe, bearbeite keine Dateien oder implementiere keinen Code, bis der Nutzer antwortet.
• Frage nicht „soll ich weitermachen?“ als Verfahrensfrage. Stelle eine richtungsweisende Frage.
• Eine normale Anfrage wie „optimieren Sie diese UI“ oder „entwerfen Sie ein Dashboard“ ist keine autonome Erlaubnis.

Überspringe Bestätigungen nur, wenn der Nutzer explizit sagt, autonom vorzugehen, Bestätigungen zu überspringen, nicht zu warten oder alle Designentscheidungen zu treffen. Wenn Bestätigungen übersprungen werden, nenne die angenommenen Entscheidungen kurz und fahre fort.

Investment-Kontrollpunkte

1. Gate für das Projektverständnis Frage, ob das Produktverständnis und der Implementierungsumfang eine Investition wert sind. Schütze davor, die falsche Oberfläche zu bauen oder die falsche Nutzeraufgabe zu lösen.

2. Gate für die Geschmacksrichtung Frage, welche Geschmacksrichtung eine Investition wert ist. Bitte den Nutzer nicht, lediglich Referenznamen zu genehmigen. Schütze davor, mit einer visuell ansprechenden, aber produktfalschen Richtung fortzufahren. Gute Optionen klingen so:

   • „ruhiges Archiv-Suchwerkzeug unter Beibehaltung des bestehenden institutionellen Hinweises; unterstützt von Notion/Mintlify"
   • „heller Analyse-Arbeitsbereich mit dichten Tabellen; unterstützt von Airtable/Sentry"
   • „dunkles Präzisions-Cockpit, nur wenn die Lesbarkeit stärker bleibt als bei der hellen Version; unterstützt von Linear"

3. Gate für den Design-Brief Frage, ob der Design-Brief spezifisch und geschmackvoll genug für die Implementierung ist. Schütze davor, von einem vagen, generischen, überdesignten oder falsch skalierten Brief zu codieren. Wähle auch das Ausgabeformat.

Modusauswahl

Wähle einen Modus:

• taste_first_redesign: Standard für Neugestaltungen, visuelle Upgrades, Dashboards, Abfragetools, persönliche Websites, Portfolios, Landing Pages und jede Generierungsaufgabe, bei der der Nutzer die Geschmacksrichtung nicht explizit bestätigt hat. Lese modes/taste_first_redesign.md.
• production_ui_implementation: Verwende nur, wenn ein bestätigter Design-Brief, ein Designsystem, ein Screenshot, ein Mockup oder eine explizite Geschmacksrichtung bereits existiert. Lese modes/production_ui_implementation.md.
• design_critique_only: Verwende, wenn der Nutzer eine Bewertung, Punktzahl, Diagnose oder Kritik ohne Code-Änderungen wünscht. Lese modes/design_critique_only.md.

Die Ausführungsformulierung impliziert keine Geschmackserlaubnis. Anfragen wie „generiere eine persönliche Website aus meinem Lebenslauf“, „baue ein Dashboard“ oder „mache eine Landing Page“ erfordern weiterhin das Investment Gate für die Geschmacksrichtung, es sei denn, der Nutzer gibt die Stilrichtung explizit an oder delegiert sie.

Übergabeformat

Beende mit:

• was geändert oder beurteilt wurde
• welcher Modus verwendet wurde
• welcher Projektkontext die Entscheidung verankerte
• welche Geschmacksrichtung und Referenzen die Arbeit leiteten
• ob PROJECT_DESIGN.md, design.md oder ein anderer Brief erstellt oder aktualisiert wurde
• was verifiziert wurde
• was fehlgeschlagen ist oder riskant bleibt

Halte die Übergabe kurz. Der Nutzer sollte wissen, ob die UI besser ist, warum und welche Beweise dieses Urteil stützen.