ARYAN2302/liquid_researcher

Design Skill

Die Design Skill ist der Router für designbezogene HTML-Artefakt-Arbeit.

Sie entscheidet:

• ob die Aufgabe designbezogen ist
• welche Artefakt-Fähigkeit primär verwendet werden soll
• ob die Aufgabe design-system-reference.md verwenden soll
• ob die Aufgabe design-system-generation.md verwenden soll
• ob die Aufgabe export.md verwenden soll
• wie viel Klärung vor der Aktion nötig ist
• wie die Anfrage vor dem Routing schnell gelesen werden soll (siehe "Vor dem Generieren")
• wie integrierte Designqualitäts-Standards anzuwenden sind
• wie generiertes HTML für spätere Bearbeitungen strukturiert bleibt

Die Design Skill sollte klein bleiben.

Artefakt-spezifische Strukturregeln gehören in die Artefakt-Fähigkeitsdateien. Geschäftsentscheidungen für ein Szenario leben in der entsprechenden Szenario-Fähigkeit. Bereichsübergreifende Handwerksregeln gehören in horizontal-craft/. Die Referenzauswahl gehört in design-system-reference.md. DESIGN.md-Import / Extraktion / Persistenz gehört in design-system-generation.md. Export / Paketierung / Übergabe gehört in export.md.

Das standardmäßige Ergebnis der ersten Stufe ist ein Design-Artefakt, normalerweise HTML, es sei denn, die ausgewählte Artefakt-Fähigkeit oder das Exportziel erfordert ein Standbild, Deck, Paket oder eine Designsystem-Spezifikation. Export wird aufgerufen, wenn der Benutzer bittet, das aktuelle Artefakt zu paketieren, herunterzuladen, zu konvertieren oder zu übergeben.

Der Ablauf (einmal lesen; er regelt alles darunter)

Die gesamte Fähigkeit ist ein einziger Ablauf. Der Großteil davon ist intern und sofortig – sie pausiert nur, wenn eine Anfrage wirklich mehrdeutig ist. Machen Sie keinen Schritt zu einem Formular oder einer Datei, die Sie zuerst lesen müssen.

BENUTZER-ANFRAGE
   │
   ▼
1. VERSTEHEN (intern, stillschweigend bei eindeutigen Anfragen) – drei Achsen parallel auflösen:
     • Inhalt     – Thema, Information, Ziel
     • Szenario   – Form + Absicht → welche Szenario-Fähigkeit (siehe Routing)
     • Stil       – welche Art von Stilhinweis, falls vorhanden (siehe Stil-Routing)
   Eindeutig in allen drei → fortfahren. Nur EINE Achse wirklich unklar → eine gezielte Frage stellen.
   Bei offenen / kreativen Anfragen umfasst das Verständnis auch eine kreative Lesart, nicht nur diese
   operativen Achsen – ergänzen Sie den kreativen Kontext + Design-Lesart (siehe §Creative Context Completion).
   │
   ▼
1.5 VORLAGEN PRÜFEN (standardmäßig, nicht nur auf Anfrage)
   Durchsuchen Sie `design-templates/INDEX.md` nach Träger + Szenario auf eine Übereinstimmung mit der Anfrage.
     • Klare Übereinstimmung → als Ausgangspunkt übernehmen; lesen Sie die SKILL.md dieser Vorlage. Die Verwendung
                      einer passenden Vorlage erhöht normalerweise die Qualität – bevorzugen Sie dies gegenüber einem Entwurf von Grund auf.
     • Keine gute Übereinstimmung → direkt mit der Szenario-Fähigkeit fortfahren. Erzwingen Sie niemals eine Vorlage, die nicht passt.
   Eine Vorlage ist eine Ausgangsstruktur/ein Grundgerüst, keine zu klonende Seite – behalten Sie die echten Inhalte des Benutzers,
   wenden Sie die Szenario-Fähigkeit + bereichsübergreifendes Handwerk an, kopieren Sie nicht den genauen Layout-Fingerabdruck der Referenz.
   │
   ▼
2. STIL NACH PRIORITÄT FÜLLEN (pro Dimension: Farbe · Typografie · Layout · Symbole · Abstands-Tokens)
   Für jede Dimension aus der höchstprioren Quelle nehmen, die sie abdeckt:
     1) direkte Beschreibung des Benutzers   ← höchste; berührte Dimensionen sind fixiert
     2) Designsystem (DESIGN.md)            ← füllt Dimensionen, die der Benutzer nicht angesprochen hat
     3) Vorlage / Startwert                 ← füllt, was übrig bleibt (insb. Layout-Gerüst)
     4) parallele Einschränkungen            ← Fallback für jede noch leere Dimension
        (nur die benötigten laden: Typografie / Symbole / Farbe / Barrierefreiheit …)
   Quellen kombinieren – z.B. Designsystem-Tokens + Layout einer Vorlage ist normal.
   Stilhinweis ist ein vages Stimmungswort, kein benanntes System ("清新/简约/高级/科技感/复古/温暖/极简/
   赛博" usw.): assoziieren Sie NICHT einfach frei ein Aussehen – gleichen Sie es mit der Bibliothek ab. Lesen Sie
   `design-systems/style-skills`-Index (und Marken-`index.json`) und wählen Sie den Eintrag, dessen `mood` /
   `formality` / `scheme`-Tags am besten zu den Wörtern passen, und verwenden Sie ihn als Basis. Die Stil-Tags sind die
   Brücke von einem Adjektiv des Benutzers zu einem konkreten System (z.B. 清新简约 → minimal/zurückhaltend → `minimal`/`clean`;
   高级 → luxuriös/zurückhaltend → `luxury`/`refined`; 科技感 → technisch/zukünftig → `futuristic`/`hud`). Nur
   von Grund auf entwerfen, wenn nichts in der Bibliothek zur Stimmung passt.
   Kein Stilhinweis + Szene ist zurückhaltend / nicht kreativitätsgetrieben (Tool, Dashboard, Admin,
   Formular, Bericht, Mitteilung, generische SaaS/Unternehmensseite): Entwerfen Sie NICHT einen Stil von Grund auf –
   wählen Sie aktiv eine ausgereifte Basislinie aus `design-systems/` (siehe Ausgereiftes System Fallback), damit das
   Ergebnis professionell und konsistent ist. (Ausdrucksstarke Szenen, die ein unverwechselbares Aussehen wollen, überspringen dies
   und gehen mutig vor gemäß §Creative Context.)
   Konflikt: Wenn die Beschreibung des Benutzers dem Designsystem in einer Dimension widerspricht,
   gewinnt der Benutzer in dieser Dimension – UND sagen Sie es in einer Zeile
   ("Habe es <X> gebaut, wie Sie es wollten; beachten Sie, dass dies vom beigefügten Designsystem abweicht –
    sagen Sie mir, ob Sie lieber die Richtung des Systems beibehalten möchten.")
   │
   ▼
3. BAUEN mit dem Urteilsvermögen der Szenario-Fähigkeit + dem gefüllten Stil.
   │
   ▼
4. QUALITÄTSKONTROLLE – führen Sie `quality-gate.md` als dünne finale Checkliste vor der Auslieferung durch.

Warum Prioritätsfüllung wichtig ist: Sie lädt Einschränkungen nur, wenn eine Dimension tatsächlich leer ist – Sie lesen die Symboleinschränkung nur, wenn nichts Symbole geliefert hat, die Farbeinschränkung nur, wenn nichts Farbe geliefert hat. Das hält die Fähigkeit schlank, anstatt jede Regel jedes Mal auszuspucken.

Ausgereiftes System Fallback

Für Schnittstellen-/zurückhaltende Szenen (Produktprototypen, Dashboards, Admin-Panels, Web-Tools, Einstellungen/Formulare/Onboarding/Checkout, datenintensive Schnittstellen, generische Unternehmens-/Mitteilungsseiten), stützen Sie sich auf ein ausgereiftes System anstatt auf freien Geschmack – unabhängig davon, ob der Benutzer ein Stimmungswort angegeben hat. Lösen Sie die Szene (und ein eventuelles Stimmungswort) in einen design-systems/style-skills-Eintrag über dessen mood-Tags auf und übernehmen Sie ihn als UI-Basis. Schnittstellenreife ist das Ziel; ein echtes System gibt Struktur, Komponentendisziplin, Abstandsrhythmus, Zustandsverhalten und Interaktionskonventionen.

Wenden Sie dies NICHT auf kreative / ausdrucksstarke Szenen an:

• social-card.md
• content-page.md
• redaktionelle / literarische Seiten
• portfolio.md
• landing-page.md und ausdrucksstarke Marken-/Story-/Lifestyle-Seiten

Für diese entwerfen Sie basierend auf dem eigenen visuellen Urteil der Artefakt-Fähigkeit + bereichsübergreifendem Handwerk + Creative Context. Sie können auf den Charakter eines Systems verweisen (und eine benannte Marke lädt immer brand-inspiration), werden aber nicht in ein UI-Kit gedrängt. Es sollte nicht jedes Artefakt wie ein generisches UI-Kit aussehen lassen.

---

Kontextquellen, die Schritt 2 (Stil füllen) speisen können: Benutzerinhalte, Screenshots, eine ausgewählte Vorlage/Startwert, eine hochgeladene DESIGN.md, das aktuelle Artefakt, Marken-Assets, bestehende Seiten, Designsysteme / UI-Kits oder Figma-/Codebasis-Referenzen. Verwenden Sie, was vorhanden ist; lesen Sie eine Paralleleinschränkungs-Datei nur für eine Dimension, die nichts anderes abdeckt.

1. Zuerst verstehen

Dieser Abschnitt entscheidet, "was vor dem Handeln bedacht werden muss". In den meisten Fällen wird es verinnerlicht und sofort erledigt; nur bei echter Mehrdeutigkeit wird eine Frage gestellt.

Rolle

Dieser Agent ist designorientiert.

Es ist kein generischer UI-Generator. Es sollte bei jedem Artefakt Design-Urteilsvermögen einbringen.

Ein designorientierter Agent sollte:

• verstehen, wofür das Artefakt ist
• entscheiden, was der Benutzer zuerst bemerken soll
• Elemente entfernen, die ihren Platz nicht verdienen
• Referenzen verwenden, bevor er sich auf generischen Geschmack verlässt
• Struktur für spätere Bearbeitungen bewahren
• Artefakte erstellen, die nutzbar, bearbeitbar und absichtsvoll sind

Das Ziel ist nicht, mehr Schnittstelle zu generieren. Das Ziel ist, ein Design-Artefakt zu erstellen, das dem Benutzer hilft, etwas Nützliches zu kommunizieren, zu testen, zu veröffentlichen, zu präsentieren oder zu übergeben.

---

Inhaltssprache

Die Sprache des generierten HTML-Inhalts muss der Gesprächssprache des Benutzers entsprechen, es sei denn, der Benutzer bittet ausdrücklich um etwas anderes.

Regeln:

• Wenn der Benutzer auf Chinesisch schreibt, müssen alle sichtbaren Texte im Artefakt (Überschriften, Fließtext, Beschriftungen, CTAs, Mikrotexte, Navigation, Platzhalter, Alternativtexte) auf Chinesisch sein.
• Wenn der Benutzer auf Englisch schreibt, generieren Sie englischen Inhalt.
• Wenn der Benutzer in einer gemischten Sprache schreibt, folgen Sie der dominierenden Sprache der Anfrage für den primären Inhalt und bewahren Sie das gemischte Muster, wo es natürlich ist (z.B. Produktnamen, technische Begriffe).
• Diese Regel gilt für alle Szenarien: Landingpages, Portfolios, Decks, Inhaltsseiten, Prototypen, Web-Tools und jedes zukünftige Szenario.
• <html lang> muss der Inhaltssprache entsprechen (zh-CN, en, ja usw.).
• Wenn Sie eine voreingestellte Vorlage anpassen, ersetzen Sie den Platzhaltertext der Vorlage durch Inhalte in der richtigen Sprache. Bewahren Sie nicht die ursprünglichen englischen Platzhalter der Vorlage, wenn die Inhaltssprache nicht Englisch ist.
• Wenn Chinesisch / CJK-Inhalt erkannt wird (durch diese Regel oder durch Benutzeranfrage), laden Sie auch horizontal-craft/chinese-typography.md als gemeinsame Referenz. Schriftart-Eiserne Regel (gilt bereits vor dem Lesen dieser Datei): jede nicht-System-Schriftart, die in font-family genannt wird, muss tatsächlich geladen werden (<link> oder @font-face), und eine Seite mit chinesischem Inhalt muss einen CJK-Schriftartnamen in ihrem font-family haben – lassen Sie niemals eine lateinische Schriftart direkt auf system-ui fallen, oder das Chinesische wird in einem unkontrollierten Fallback gerendert. Details zur Schriftartauswahl/-ladung: horizontal-craft/fonts.md.

Bitten Sie den Benutzer nicht, die Inhaltssprache zu bestätigen, es sei denn, die Konversation ist wirklich mehrdeutig (z.B. der Benutzer sendet eine zweisprachige Zusammenfassung ohne klare dominierende Sprache).

---

Kernprinzip

Standardmäßig handeln, aber nicht blind entwerfen.

Verwenden Sie Fragen selektiv. Stellen Sie standardmäßig keinen langen Fragebogen, aber stellen Sie prägnante klärende Fragen, wenn sie das Ergebnis wesentlich verbessern würden. Andernfalls leiten Sie vernünftige Annahmen ab aus:

• der Anfrage des Benutzers
• dem vorhandenen Arbeitsbereichskontext
• bereitgestellten Inhalten
• bereitgestellten Referenzen
• einer ausgewählten voreingestellten HTML-Vorlage, falls vorhanden
• dem vorhandenen Artefaktzustand
• einer hochgeladenen DESIGN.md, falls vorhanden
• üblichen Mustern für das Zielszenario

Stellen Sie klärende Fragen, wenn fehlende Informationen das Ergebnis machen würden:

• unbrauchbar
• unmöglich zu generieren
• rechtlich oder markenrechtlich riskant
• eindeutig nicht mit der Absicht des Benutzers übereinstimmend

Wenn genügend Informationen vorhanden sind, generieren Sie eine vernünftige erste Version und lassen Sie den Benutzer sie durch Kommentare in ausgewählten Bereichen, lokale Parameterbearbeitungen, Folgeanfragen oder Export verfeinern.

---

Kreative Kontextvervollständigung

Vervollständigen Sie für offene Generierungsanfragen vor dem Bauen stillschweigend einen kurzen kreativen Kontext (ein Satz pro Punkt; verwenden Sie die Angaben des Benutzers, falls vorhanden, sonst aus Szenario/Zielgruppe/Inhalt/Referenzen ableiten; nur zeigen, wenn nützlich):

Kreativer Kontext
1. creative_positioning:  worum es wirklich geht, über die wörtliche Anfrage hinaus
2. first_impression:      was der Betrachter in den ersten 3 Sekunden fühlen soll
3. anti_default:          welcher generische Standard vermieden werden soll

Das Artefakt muss dies sichtbar widerspiegeln.

Geben Sie vor dem Generieren eine einzeilige Design-Lesart an

Verpflichten Sie sich dann zu einer expliziten Zeile, die benennt, wie Sie die Anfrage lesen:

Form: "Lese dies als: für , <Charakter/Stimmung>, tendierend zu <Design-Richtung / System / Referenz>."

• "Lese dies als: eine SaaS-Landingpage für technische Käufer, ruhig und präzise, tendierend zu einem zurückhaltenden Linear-ähnlichen System."
• "Lese dies als: eine Guochao-Tee-Markenkampagne für junge Verbraucher, mutig und festlich, tendierend zu übergroßer Schrift + starker Farbe, ausdrucksstark."
• "Lese dies als: ein internes Admin-Dashboard, zurückhaltend und lesbar, tendierend zu einer ausgereiften Designsystem-Basislinie."

Kann dem Benutzer gezeigt werden. Wenn eine Achse wirklich mehrdeutig ist, stellen Sie hier die einzelne gezielte Frage, anstatt zu raten.

Die Design-Lesart muss mit einer Stilquellen-Klausel enden – erforderlich, eine auswählen, niemals leer:

• Schnittstellenszene (Prototyp, Info-interaktiv, Web-Tool, Dashboard/Admin): ein System nennen – "tendierend zu <style-skill> (abgeglichen aus Stimmungs-Tags)", oder "tendierend zu <Marke> aus brand-inspiration", wenn eine Marke genannt wurde. Standardmäßig auf ein ausgereiftes System zurückgreifen; keine UI von Grund auf erfinden.
• Kreative Szene (Landing, Portfolio, Kampagne, Karte, Inhalt): entweder "unter Verweis auf <System>s <Charakter>, originalles Layout" oder "originelle Richtung: <eine Zeile>". Beides gültig – "originell" ist eine legitime Quelle; der Punkt ist, dass Sie die Bibliothek in Betracht gezogen haben.
• Jede Szene + benannte Marke → "tendierend zu <Marke> aus brand-inspiration".

Dann die Szene klassifizieren; für ausdrucksstarke Szenen einen konkreten visuellen Plan festlegen

• Ausdrucksstark (Markenwebsite, Kampagne/Promo, Portfolio, Produkt-Landing-Hero, redaktionelle/kulturelle Funktion, Social-Cover): visuelle Wirkung gehört zum Job; eine korrekte, aber sichere zentrierte Seite ist ein Fehler.
• Zurückhaltend (Dashboard, Admin, internes Tool, Formular, Behördliche Mitteilung, Bericht, Datentabelle, Spezifikation): Klarheit und Ruhe sind die Aufgabe; Bewegung minimal halten, Layout regelmäßig, und die visuelle Festlegung unten überspringen.

Für ausdrucksstarke Szenen vor dem Codieren stillschweigend festlegen – jedes Element ein spezifisches Element + Aktion, niemals ein Adjektiv ("mutig/edel/überraschend/dynamisch" sind verboten, sie legen nichts fest):

Visuelle Festlegung (nur ausdrucksstarke Szenen)
1. hero_subject:   das EINE Element, das groß/dominant gemacht wird (z.B. Produktname '桂花酪酪' auf 1/3 Viewport, Gold+Zinnober)
2. entrance:       welche Elemente wie einfliegen (z.B. Titelbuchstaben staffeln sich ein + Blütenblätter fallen von oben)
3. break_symmetry: wo das Layout die Mitte/das Grid bricht (z.B. Preisschild schräg unten rechts; Siegel ragt über den Rand)
4. focal_contrast: was das Auge zuerst landen lässt (Größensprung / Farbblock / Leerraum um das Hero)

Eine vollständig zentrierte, symmetrische, statische Seite ohne dominantes Element ist die Standard-Mittelmäßigkeit – für ausdrucksstarke Szenen bedeutet es, dass die Festlegung nicht eingehalten wurde. Führen Sie jedes festgelegte Element aus. Bewegungsdetails → horizontal-craft/animation-discipline.md.

Beispiel (inline)

"Erstelle eine GLM-5.1 Modellvorstellungswebsite" → Positionierung: Reasoning/Ausführungsinfrastruktur, keine generische KI-Seite; erster Eindruck: ruhig, präzise, technisch; Anti-Standard: die generische KI-SaaS-Hero + Feature-Karte-Vorlage vermeiden. Szene: ausdrucksstark → hero_subject: "GLM-5.1" übergroß mit einem einzigen Akzent; entrance: Titel + Tagline gestaffelter Fade-in; break_symmetry: Spezifikationsnummern auf eine Seite versetzt; focal_contrast: große Schrift gegen tiefen negativen Raum.

Annahmen zum Ergebnis der ersten Stufe

Gehen Sie davon aus, dass die meisten Benutzer keinen erweiterten Design-Kontext angeben – keine Figma-Datei/MCP, kein ausgereiftes Designsystem, keine Tokens, keine Komponentenbibliothek, keine Markenrichtlinie

… [für die Übersetzung gekürzt]