n0ctx/tavern-aesthetic

Tavernen-Ästhetik — Immersives narratives Frontend-Design

Was dieser Skill produziert

Eine funktionierende Benutzeroberfläche, die wie ein Artefakt aus der Erzählwelt wirkt – kein umgestyltes Dashboard und kein Haufen generischer Game-HUD-Utensilien. Der Maßstab ist die polierte Frontend-Karte: Ein Blick identifiziert das Werk, jede Oberfläche folgt einer einheitlichen Art Direction, Details sind ausgearbeitet, und die Interaktion wirkt natürlich.

Poliert ≠ komplex. Poliert bedeutet, dass jede sichtbare Wahl beabsichtigt ist und jeder sichtbare Bereich denselben Qualitätsstandard erfüllt.

Dieser Skill umfasst die visuelle Gestaltung und die Implementierungsmethode. Er ist nicht von SillyTavern, einem Hilfsplugin, MVU oder einem Framework abhängig. Verwende den vorhandenen Stack, die Komponenten, Assets und Interaktionsmuster des Projekts. Wenn der Benutzer nur ein Design anfordert, bearbeite keinen Code.

Referenzen (auf Abruf lesen, niemals alle auf einmal)

• references/design-knowledge.md — Entscheidungsleitfaden nach Dimension (narrative Identität, Farbe, Typografie, Form, Licht/Material, Bild, Layout, Komponenten, Bewegung, Adaption) plus Tabellen mit Fehlermodi. Konsultiere den Abschnitt, der zur aktuellen Entscheidung passt.
• references/workflow.md — gestaffelter Prozess, Bestehen/Durchfallen-Gates, Überprüfungsmethode, Rollback-Regeln, Design-Record-Vorlage. Vor jeder mittleren oder komplexen Aufgabe lesen.
• references/asset-sources.md — Quellen und Lizenzprüfungen für Illustrationen, Texturen, Icons, Schriftarten. Beim Sammeln von Assets online lesen.
• references/research.md — Evidenz und Einschränkungen hinter diesem Skill. Nicht für die Ausführung erforderlich.

Aufgabenniveaus

Beurteile nach Designschwierigkeit, nicht nach Codeumfang:

• Einfach: eine Komponente, eine Detailkorrektur, eine kleine Funktion innerhalb einer bestehenden visuellen Sprache. Verwende die Sprache wieder; nach der Implementierung einmal per Screenshot prüfen.
• Mittel: eine einzelne Seite/ein Panel oder eine Neugestaltung eines vorhandenen Bildschirms. Führe eine kurze Richtungsbestimmung durch, baue zuerst den Fokusbereich, dann vervollständige die Seite; 1–2 Überprüfungsrunden.
• Komplex: Multiscreen-Fluss, gamifiziertes System, Aufbau von Grund auf, benötigt ein eigenes Key Visual, oder der Benutzer wünscht Endproduktqualität. Führe die sechs Phasen in workflow.md durch und führe ein Design-Record.

Anti-Drift-Regeln (bindend)

Diese existieren, weil die Ausführung über mehrere Schritte hinweg driftet. Befolge sie wörtlich:

1. Das Design-Record ist die alleinige Quelle der Wahrheit. Erstelle es bei der Richtungsbestimmung für mittlere und komplexe Aufgaben (Vorlage in workflow.md) und lies es zu Beginn jedes weiteren Schritts/Moduls erneut. Jeder neue Farb-, Radius-, Schrift- oder Bewegungswert muss vor der Verwendung in das Token-Register des Records aufgenommen werden. Wenn ein Wert nicht im Register ist, ist er im Code nicht erlaubt.
2. Friere das Token-Register ein, nachdem die Kernprobe bestanden wurde. Spätere Module dürfen nur registrierte Token wiederverwenden. Neue Token erfordern einen expliziten Vermerk im Record, der erklärt, warum das bestehende Set das Bedürfnis nicht ausdrücken kann.
3. Jedes Modul wird per Screenshot nebeneinander mit der Kernprobe verglichen, bevor es weitergeht. Keine Ausnahmen; ein verbaler Vergleich reicht nicht aus.
4. Maximal zwei Korrekturrunden pro Phase. Wenn immer noch fehlgeschlagen, führe ein Rollback durch und diagnostiziere gemäß der Rollback-Tabelle in workflow.md, anstatt weitere Korrekturen zu schichten.
5. Immer nur eine aktive Richtung zur Zeit. Halte keine alternativen Richtungen über mehrere Schritte hinweg am Leben. Wähle eine aus, zeichne sie auf, verwerfe den Rest.

Kernprinzipien

1. Design für das Werk, nicht für das Genre.
   • Beantworte zuerst: Welches Objekt oder System ist diese UI innerhalb der Geschichte, wer hat es gemacht, wer liest es, wann.
   • Wähle dann einen Erinnerungspunkt, der zu diesem spezifischen Werk gehört.
   • Die visuelle Identität stammt von konkreten Charakteren, Orten, Epochen, Fraktionen, Ereignissen, Requisiten. Genreformeln (Post-Apokalypse = schwarz/gelbes Radar; Kultivierung = tintengrün + gold) sind nur Ausgangspunkte und müssen konkretisiert werden.
   • Selbsttest: Gib die gleiche Genre-Anfrage an einen Agenten – wenn er nahezu dieselbe UI produzieren würde, ist die Richtung nicht spezifisch genug.
   • Vergleiche intern einige Richtungen, liefere genau eine aus. Liste dem Benutzer keine Optionen für Routineaufgaben auf.
2. Ein Konzept bestimmt jede Designentscheidung.
   • Farbe kommt von Materialien und Lichtquellen; Typografie von Schreib-/Druckmethoden; Form vom Handwerk; Bewegung von den physischen Aktionen des Objekts.
   • Zusammengehörige Dimensionen werden gemeinsam entschieden, nicht nacheinander („alle Farben zuerst, dann alle Schriftarten“ ist falsch).
   • Für jedes Element musst du angeben können, welchen Teil des Konzepts es ausdrückt.
3. Konkrete Kunst verwendet Illustrations-Assets; Code-gezeichnete Kunst ist nur Platzhalter.
   • Personen, Szenen, Objekte: Die endgültige Version verwendet Illustrations-Assets. Bezugsquellen: vorhandene Projekt-Assets → KI-Generierung → lizenzierte Websammlung.
   • CSS/SVG-gezeichnete Szenen, Personen, Objekte sind nur für die Kompositions-/Konzeptvalidierung erlaubt und müssen vor der Auslieferung ersetzt werden (spätestens in der Kernprobenphase bei komplexen Aufgaben). Sie wirken wie Programmierer-Kunst und ziehen die gesamte UI herunter.
   • Code besitzt die Schnittstelle selbst: Layout, Typografie, Rahmen, Texturen, ornamentale Muster, Icons, abstrakte und Daten-Grafiken.
4. Illustration führt die Komposition an.
   • Die Illustration setzt den Schwerpunkt des Layouts; Text und Komponenten ordnen sich darum an. Verkleinere sie niemals zu einem oberen Banner oder einer Kartenminiatur.
   • Jeder Hauptbildschirm muss wie ein Bild wirken: Mit zusammengekniffenen Augen sollte der Bildschirm größtenteils aus Illustration bestehen, nicht aus dunklen Panels + dünnen Linien + Text.
   • Die Präsenz von Kunst setzt sich auf Funktionsseiten fort (Illustration als niedrigkontrastreiche Schicht unter Panels, Charaktere, die Panelkanten überschreiten, Szene, die sich mit Zeit/Ort verschiebt). „Wunderschöner Einstieg, dann langweilige dunkle Formularseiten“ ist der häufigste Qualitätseinbruch.
   • Ein Hero-Bild pro Bildschirm. Sekundäre Bilder fügen sich in dasselbe Bild ein oder bilden einen einheitlich behandelten Satz; stelle niemals unterschiedlich bebilderte Quellen in Kästchen nebeneinander.
5. Informationen übernehmen weltinterne Formate, mit Requisitenzurückhaltung.
   • Informationen verwenden die nativen Formate und das Vokabular der Welt (Hauptbuchspalten, Listenlayout, weltinterne Verben/Nomen) und enthüllen sich im narrativen Tempo.
   • Ein primärer Träger für die gesamte UI. Gib nicht jedem Modul eine andere CSS-simulierte Requisite (Klebebandnotizen, schiefe Stempel, Tags, Abakus-Perlen) – gestapelte Requisiten wirken billig.
   • Halte dich zurück bei Requisiten und Ornamenten, nicht bei Bildern und Farben. Der durch Requisiten freigewordene Raum geht an Illustration und Typografie, nicht an dunkle Textformulare.
   • Nicht alles ist „Label: Wert“ + Fortschrittsbalken. Ablaufseiten (Onboarding, Einstellungen) sind keine Formulare; Schlüsseloptionen können Illustrationen tragen.
6. Einheitliche Qualitätslatte.
   • Der Aufwand darf ungleichmäßig sein: Der Fokusbereich erhält die besten Assets und die meisten Details.
   • Kein sichtbarer Bereich darf unter die Latte fallen. Alles Gezeichnete muss der Gesamtpräzision entsprechen; wenn nicht, ersetze es durch Illustration oder drücke es durch Typografie/abstrakte Grafiken aus.
   • Um Kosten zu senken, vereinfache innerhalb derselben Sprache – falle niemals zurück auf Standardkomponenten, browser-native Gestaltung oder Platzhalterbilder.
7. Lesbarkeit und Bedienbarkeit stehen an erster Stelle.
   • Chinesischer Fließtext: ≥14px (15–17px typisch), Zeilenhöhe 1.6–1.9, Zeilenlänge ~20–40 Zeichen, Kontrast Fließtext ≥4.5:1.
   • Stimmung wird durch Farbtemperatur, Licht, Material, Bewegung getragen; Text und Zahlen bleiben klar.
   • Keine winzigen Schriften, geringen Kontraste oder bedeutungsloses Englisch als „Premium“-Abkürzung.
   • Bilder und Texturen liegen niemals auf Fließtext oder Klickzielen.
   • Vollständige Interaktionszustände, tastaturbedienbar, an die Zielbreite angepasst.
8. Standardwerte müssen gewählt, nicht übernommen werden. Behalte eine Standardschriftart, -palette, Komponentenbibliothek oder Browser-Scrollleiste/Fokusring nur, wenn sie bewusst ausgewählt wurden. Das übliche KI-Spiel-UI-Kit (beiges Papier + dunkler Schiefer, roter schiefer Stempel, kleine Tags, Hex-Knotenpunkte, Radarchart) ist ebenfalls ein Standardwert. Einen trendigen Standard durch einen anderen zu ersetzen, ist immer noch ein Standardwert.
9. Technische Zurückhaltung. Verwende vorhandenen Code, Abhängigkeiten und Assets wieder. Generiere/Sammle Assets nur gemäß dem Asset-Plan. Keine neuen schweren Abhängigkeiten, keine Asset-Pipeline, kein Backend-Refactoring.

Ausführungsablauf

1. Szene verstehen

Bestätige: Genre; Charakter-/Weltspezifika; Zielstimmung; Seitenzweck; Kerninformationen und Aktionen; Zielgerät; Host-Umgebung (z. B. eingebettet in Chat). Überprüfe vorhandenen Code und Assets. Benutzerreferenzen: extrahiere die Kunsttechnik, nicht das Bild. Fahre ohne Nachfrage fort, wenn keine kritische Mehrdeutigkeit besteht.

2. Richtung festlegen (alle mittleren+ Aufgaben)

Schreibe in das Design-Record:

• Identität der Schnittstelle: welches Objekt/System, von wem gemacht, von wem gelesen.
• Erinnerungspunkt: ein Satz, muss aus den Besonderheiten dieses Werks stammen.
• Art Direction: Medium, Pinselführung, Lichtrichtung, Palette, Klarheit – eine gemeinsame Stilbeschreibung, die in jeder späteren Generierungsanfrage wörtlich wiederverwendet wird.
• Ausschlussliste: die Genreformeln und Standardwerte, die dieses Werk vermeiden muss.
• Asset-Plan: jedes konkrete Kunstobjekt mit Zweck, Verhältnis, Zuschnitt, Transparenz, Quelle (vorhanden → KI → Web). Überprüfe, ob die Quellen tatsächlich existieren, bevor du dich festlegst; wenn weder KI noch lizenzierte Web-Assets die Richtung unterstützen können, sage dies jetzt.

3. Bauen

Pro Aufgabenniveau:

• Einfach: implementieren, Screenshot, die schlimmsten 1–3 Probleme beheben, fertig.
• Mittel: Fokusbereich auf volle Qualität → Seite vervollständigen → eine kombinierte Überprüfungsrunde.
• Komplex: folge den sechs Phasen in workflow.md (Richtung → Komposition → Kernprobe → modulweise Erweiterung → Polieren → Abnahme). Phasen sind Qualitätsgates, keine Berichtskontrollpunkte; fahre kontinuierlich fort. Bei systemischen Problemen gehe zurück zur relevanten Phase und wiederhole nur den betroffenen Teil.

Während des Bauens:

• Verwende Projektcode und Interaktionsmuster wieder.
• Dekorative Schriftarten nur für Titel; überprüfe CJK-Glyphenabdeckung und setze Fallback-Stapel.
• Alle Zustände: Hover, Fokus, aktiv, ausgewählt, deaktiviert, laden, leer, Fehler – visuell konsistent.
• Bewegung dient Interaktion und Stimmung; gleiche Dauer-/Easing-Familie im gesamten Werk; respektiere prefers-reduced-motion.

4. Assets integrieren

• Platziere zuerst das Hero-Bild, dann ordne unterstützende Informationen an.
• Vereinheitliche Assets durch Zuschnitt, Maske, Farbabstufung, Körnung, Kantenüberblendung, einheitliche Lichtrichtung; lasse ruhige Zonen für Text.
• Konflikte bei gemischten Quellenstilen → durch Abstufung angleichen; wenn immer noch Konflikte → ersetzen, nicht erzwingen.
• Assets sind lokale Projektdateien, keine Hotlinked-URLs. Respektiere Lizenzen/Quellenangaben.

Visuelle Überprüfung (screenshotbasiert, größte Probleme zuerst)

1. Erster Blick (Miniaturansicht, ~1s): Wo landet das Auge; ist es der geplante Fokuspunkt; gibt es etwas, das man sich merken sollte.
2. Zusammenkneifen: Die Wertstruktur liest sich in 2–3 Massen; ist der Bildschirm hauptsächlich Illustration oder hauptsächlich dunkle Panels.
3. Titel abdecken: Immer noch als dieses Werk erkennbar, nicht als jede gleichartige Genre-Vorlage.
4. Nebeneinander: Alle Regionen sehen nach einer Art Direction aus (Licht, Linie, Material, Palette, Typografie).
5. Tatsächliche Größe: Chinesischer Fließtext angenehm lesbar.
6. Ränder: Ausrichtung, Überlauf, Browser-eigene Chrome, leere Zustände, keine übrig gebliebene Code-gezeichnete Kunst oder Platzhalter.
7. Interaktion: Zustände und Bewegung.
8. Zielbreite: Schmales/eingebettetes Layout.

Fix-Priorität: Richtung > Komposition > Kernkunst > Konsistenz > Lesbarkeit > Detail. Behebe nur die besten 1–3 Probleme pro Runde; mache nach jeder Runde einen neuen Screenshot. Maximal zwei Runden pro Phase; halte vor jeder Fix-Sitzung einen Rollback-Punkt bereit.

Diagnostiziere die Ursachenklasse vor der Behebung: fehlende Kernkunst / schwache Konzeptidentität / schwache Kompositionshierarchie / Stilkonflikt / Lesbarkeits- oder Layoutfehler. Jede hat eine andere Lösung.

Wenn das Hauptmodell keine Bilder sehen kann, verwende ein vorhandenes Vision-Tool oder delegiere die Überprüfung an einen visionsfähigen Unteragenten. Berichte nur, was tatsächlich überprüft wurde.

Abnahme-Checkliste (alles muss mit Ja beantwortet werden)

1. Gibt es ein einprägsames Element auf den ersten Blick, das aus dem eigenen Inhalt dieses Werks stammt?
2. Wäre diese UI bei abgedecktem Titel immer noch nicht mit einer gleichartigen Genre-Vorlage verwechselbar?
3. Verwendet der wichtigste visuelle Bereich Illustrations-Assets mit einer Präzision, die seinem Status entspricht – keine Code-gezeichneten Figuren, kein offensichtlich gröberes Element im Bild?
4. Lesen sich Assets, Typografie, Komponenten und Hintergrund als eine Produktion? Ist der schlichteste Bereich immer noch bildhaft und auf dem gleichen Qualitätsniveau?
5. Ist die Seite klar, bedienbar, an die Zielbreite angepasst, ohne dass die Funktion jemals den visuellen Aspekten geopfert wird?

Auslieferung

• Liefere zuerst lauffähige Ergebnisse.
• Komplexe Aufgaben: nenne kurz das Kernkunstkonzept, die tatsächlich verwendeten Assets (mit Lizenzhinweisen), die wichtigsten während der Überprüfung vorgenommenen Korrekturen, die Überprüfungsergebnisse und alles, was noch Platzhalter ist.
• Einfache Aufgaben: nenne nur die wichtigsten Änderungen.
• Keine langen Designdokumente an den Benutzer. Das Design-Record dient der phasen-/sitzungsübergreifenden Kontinuität, nicht als Benutzerbericht.