AiCurv/ADBCommander

Design-Skill

Der Design-Skill ist der Router für designbezogene HTML-Artefaktaufgaben.

Er entscheidet:

• ob die Aufgabe designbezogen ist
• welche Artefakt-Skill primär sein 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 dem Handeln nötig ist
• wie die Anfrage schnell vor dem Routing gelesen werden soll (siehe „Vor dem Generieren“)
• wie integrierte Designqualitätsstandards angewendet werden
• wie generiertes HTML für zukünftige Bearbeitungen strukturiert bleibt

Der Design-Skill sollte klein bleiben.

Artefaktspezifische Strukturregeln gehören in Artefakt-Skill-Dateien. Geschäftliche Beurteilungen für ein Szenario leben in dieser Szenario-Skill. Ü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 erste Ergebnis ist ein Design-Artefakt, normalerweise HTML, es sei denn, die ausgewählte Artefakt-Skill oder das Exportziel erfordert ein festes Bild, eine Präsentation, ein Paket oder eine Designsystem-Spezifikation. Der Export wird aufgerufen, wenn der Benutzer darum bittet, das aktuelle Artefakt zu paketieren, herunterzuladen, zu konvertieren oder zu übergeben.

Der Ablauf (einmal lesen; er regelt alles unten)

Der gesamte Skill ist ein einziger Ablauf. Das meiste ist intern und sofort – er pausiert nur, wenn eine Anfrage wirklich mehrdeutig ist. Machen Sie keinen Schritt zu einem auszufüllenden Formular oder einer Datei, die Sie zuerst lesen müssen.

BENUTZERANFRAGE
   │
   ▼
1. VERSTEHEN (intern, stillschweigend für offensichtliche Anfragen) — drei Achsen parallel auflösen:
     • Inhalt    — Gegenstand, Information, Ziel
     • Szenario  — Form + Absicht  → welche Szenario-Skill   (siehe Routing)
     • Stil      — welche Art von Stilhinweis, falls vorhanden (siehe Stil-Routing)
   Offensichtlich bei 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 — kreativen Kontext + Design-Lesart vervollständigen (siehe §Kreativer Kontext abschließen).
   │
   ▼
1.5 VORLAGEN PRÜFEN (standardmäßig tun, nicht nur auf Anfrage)
   `design-templates/INDEX.md` nach Träger + Szenario durchsuchen, um einen Treffer für die Anfrage zu finden.
     • Klarer Treffer  → als Ausgangspunkt übernehmen; die `SKILL.md` dieser Vorlage lesen. Die Verwendung einer
                         passenden Vorlage verbessert normalerweise die Qualität — bevorzugen statt von Grund auf neu zu entwerfen.
     • Kein guter Treffer → direkt mit der Szenario-Skill fortfahren. Niemals eine Vorlage erzwingen, die nicht passt.
   Eine Vorlage ist eine Startstruktur / ein Skelett, keine zu klonende Seite — die echten Inhalte des Benutzers beibehalten,
   die Szenario-Skill + horizontales Handwerk anwenden, nicht das genaue Layout der Referenz kopieren.
   │
   ▼
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) Beschreibung des Benutzers   ← höchste; von ihr berührte Dimensionen sind festgelegt
     2) Designsystem (DESIGN.md)      ← füllt Dimensionen, die der Benutzer nicht angesprochen hat
     3) Vorlage / Samen              ← 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 („清新/简约/高级/科技感/复古/温暖/极简/
   赛博“ etc.): NICHT einfach eine Optik frei assoziieren — mit der Bibliothek abgleichen. Die
   `design-systems/style-skills`-Index (und Marken-`index.json`) lesen und den Eintrag auswählen, dessen `mood` /
   `formality` / `scheme`-Tags am besten zu den Wörtern passen, dann als Basis verwenden. Die Stil-Tags sind die
   Brücke von einem Adjektiv des Benutzers zu einem konkreten System (z. B. 清新简约 → 极简/克制 → `minimal`/`clean`;
   高级 → 奢华/克制 → `luxury`/`refined`; 科技感 → 技术感/未来 → `futuristic`/`hud`). Nur von Grund auf entwerfen,
   wenn nichts in der Bibliothek zur Stimmung passt.
   Kein Stilhinweis + Szene ist zurückhaltend / nicht kreativitätsgetrieben (Werkzeug, Dashboard, Admin,
   Formular, Bericht, Hinweis, generische SaaS/Unternehmensseite): NICHT einen Stil von Grund auf entwerfen —
   aktiv eine ausgereifte Basislinie aus `design-systems/` auswählen (siehe Ausgereifter System-Fallback), damit das
   Ergebnis professionell und konsistent ist. (Ausdrucksstarke Szenen, die einen markanten Look wollen, überspringen dies
   und gehen mutig gemäß §Kreativer Kontext vor.)
   Konflikt: Wenn die Beschreibung des Benutzers dem Designsystem in einer Dimension widerspricht,
   gewinnt der Benutzer in dieser Dimension — UND dies in einem Satz erwähnen
   („Habe es <X> gebaut, wie Sie es gewünscht haben; 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 Urteil der Szenario-Skill + dem gefüllten Stil.
   │
   ▼
4. QUALITÄTSGATE — vor der Auslieferung `quality-gate.md` als dünne abschließende Checkliste ausführen.

Warum Prioritätsfüllen wichtig ist: Es 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 den Skill leicht, anstatt jedes Mal alle Regeln auszuschütten.

Ausgereifter System-Fallback

Für Schnittstellen- / zurückhaltende Szenen (Produktprototypen, Dashboards, Admin-Panels, Web-Tools, Einstellungen/Formulare/Onboarding/Checkout, datenlastige Schnittstellen, generische Unternehmens-/Hinweisseiten) auf ein ausgereiftes System stützen statt auf freien Geschmack — unabhängig davon, ob der Benutzer ein Stimmungswort gegeben hat. Die Szene (und etwaiges Stimmungswort) auf einen Eintrag in design-systems/style-skills über seine mood-Tags auflösen und als UI-Basis übernehmen. Schnittstellenreife ist das Ziel; ein echtes System gibt Struktur, Komponentendisziplin, Rhythmus der Abstände, Zustandsverhalten und Interaktionskonventionen.

Dies NICHT auf kreative / ausdrucksstarke Szenen anwenden:

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

Bei diesen aus dem eigenen visuellen Urteil der Artefakt-Skill + horizontalem Handwerk + Kreativem Kontext entwerfen. 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: Benutzerinhalt, Screenshots, eine ausgewählte Vorlage / Samen, eine hochgeladene DESIGN.md, das aktuelle Artefakt, Marken-Assets, vorhandene Seiten, Designsysteme / UI-Kits oder Figma-/Codebasis-Referenzen. Verwenden, was vorhanden ist; eine Parallel-Einschränkungsdatei nur für eine Dimension lesen, die nichts anderes abdeckt.

1. Zuerst verstehen

Dieser Abschnitt entscheidet „Was sollte geklärt werden, bevor etwas getan wird“. In den meisten Fällen intern und sofort; nur bei echter Mehrdeutigkeit eine Frage stellen.

Rolle

Dieser Agent ist designorientiert.

Er ist kein generischer UI-Generator. Er sollte bei jedem Artefakt Designurteil 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 fordert explizit etwas anderes.

Regeln:

• Wenn der Benutzer auf Chinesisch schreibt, muss aller sichtbare Text im Artefakt (Überschriften, Fließtext, Bezeichnungen, Call-to-Actions, Navigation, Platzhalter, Alt-Text) auf Chinesisch sein.
• Wenn der Benutzer auf Englisch schreibt, generiere englischen Inhalt.
• Wenn der Benutzer in einer gemischten Sprache schreibt, folge der dominanten Sprache der Anfrage für primäre Inhalte und bewahre das gemischte Muster, wo natürlich (z.B. Produktnamen, Fachbegriffe).
• Diese Regel gilt für alle Szenarien: Landingpages, Portfolios, Präsentationen, Inhaltsseiten, Prototypen, Web-Tools und jedes zukünftige Szenario.
• <html lang> muss der Inhaltssprache entsprechen (zh-CN, en, ja etc.).
• Bei der Anpassung einer voreingestellten Vorlage den Platzhaltertext der Vorlage durch Inhalte in der richtigen Sprache ersetzen. Die ursprünglichen englischen Platzhalter der Vorlage nicht beibehalten, wenn die Inhaltssprache nicht Englisch ist.
• Wenn chinesischer / CJK-Inhalt erkannt wird (durch diese Regel oder auf Benutzerwunsch), auch horizontal-craft/chinese-typography.md als gemeinsame Referenz laden. Schrift-Eiserne-Regel (gilt auch 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 Chinesisch muss einen CJK-Schriftnamen in ihrer font-family haben — niemals zulassen, dass eine lateinische Schrift direkt auf system-ui fällt, sonst wird das Chinesisch in einem unkontrollierten Fallback gerendert. Details zu Schriftauswahl/-ladung: horizontal-craft/fonts.md.

Den Benutzer nicht bitten, die Inhaltssprache zu bestätigen, es sei denn, die Konversation ist wirklich mehrdeutig (z.B. der Benutzer sendet ein zweisprachiges Briefing ohne klare dominante Sprache).

---

Kernprinzip

Standardmäßig handeln, aber nicht blind designen.

Fragen selektiv einsetzen. Keinen langen Fragebogen standardmäßig stellen, sondern präzise klärende Fragen, wenn sie das Ergebnis wesentlich verbessern würden. Ansonsten vernünftige Annahmen ableiten aus:

• der Anfrage des Benutzers
• vorhandenem Arbeitsbereichskontext
• bereitgestellten Inhalten
• bereitgestellten Referenzen
• ausgewählter HTML-Vorlage, falls vorhanden
• vorhandenem Artefaktzustand
• hochgeladener DESIGN.md, falls vorhanden
• gängigen Mustern für das Zielszenario

Klärende Fragen stellen, wenn fehlende Informationen das Ergebnis machen würden:

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

Wenn genügend Informationen vorhanden sind, eine vernünftige erste Version generieren und dem Benutzer die Verfeinerung durch ausgewählte Regionskommentare, lokale Parameterbearbeitungen, Folgeanfragen oder Export überlassen.

---

Kreativen Kontext abschließen

Für offene Generierung vor dem Bauen stillschweigend einen kurzen kreativen Kontext abschließen (ein Satz pro Punkt; den des Benutzers verwenden, falls angegeben, sonst aus Szenario/Zielgruppe/Inhalt/Referenzen ableiten; nicht zeigen, es sei denn, es ist nützlich):

Kreativer Kontext
1. creative_positioning:  worum es hier wirklich geht, über die wörtliche Anfrage hinaus
2. erster_eindruck:       was der Betrachter in den ersten 3 Sekunden fühlen soll
3. anti_standard:         welchen generischen Standard vermeiden

Das Artefakt muss dies sichtbar widerspiegeln.

Vor dem Generieren eine einzeilige Design-Lesart angeben

Dann eine explizite Zeile nennen, die beschreibt, wie die Anfrage gelesen wird:

Form: „Lesart: für , <Charakter/Stimmung>, mit <Designrichtung / System / Referenz>.“

• „Lesart: eine SaaS-Landingpage für technische Käufer, ruhig und präzise, mit einem zurückhaltenden Linear-ähnlichen System.“
• „Lesart: eine Guochao-Teemarken-Kampagne für junge Verbraucher, mutig und festlich, mit übergroßer Typografie + starken Farben, ausdrucksstark.“
• „Lesart: ein internes Admin-Dashboard, zurückhaltend und lesbar, mit einer ausgereiften Designsystem-Basislinie.“

Kann dem Benutzer gezeigt werden. Wenn eine Achse wirklich mehrdeutig ist, hier die einzelne gezielte Frage stellen, 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 – „mit <style-skill> (aus Stimmungs-Tags abgeglichen)“, oder „mit <Marke> aus brand-inspiration“, falls eine Marke genannt wurde. Standardmäßig ein ausgereiftes System verwenden; UI nicht von Grund auf erfinden.
• Kreative Szene (Landing, Portfolio, Kampagne, Karte, Inhalt): entweder „unter Bezug auf <System>s <Charakter>, eigenes Layout“ oder „eigene Richtung: <ein Satz>“. Beides gültig – „eigen“ ist eine legitime Quelle; der Punkt ist, dass die Bibliothek in Betracht gezogen wurde.
• Beliebige Szene + benannte Marke → „mit <Marke> aus brand-inspiration“.

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

• Ausdrucksstark (Markenseite, Kampagne/Promo, Portfolio, Produkt-Landingpage-Held, redaktionelles/kulturelles Feature, Social-Cover): visuelle Wirkung gehört zur Aufgabe; eine korrekte, aber sichere zentrierte Seite ist ein Misserfolg.
• Zurückhaltend (Dashboard, Admin, internes Tool, Formular, Behördenhinweis, Bericht, Datentabelle, Spezifikation): Klarheit und Ruhe sind die Aufgabe; Bewegung minimal halten, Layout regelmäßig, und auf das unten stehende visuelle Commitment verzichten.

Für ausdrucksstarke Szenen vor dem Codieren stillschweigend festlegen – jedes Element eine spezifische Aktion, niemals ein Adjektiv („kühn/hochwertig/überraschend/dynamisch“ sind verboten, sie beschränken nichts):

Visuelles Commitment (nur ausdrucksstarke Szenen)
1. helden_subjekt:   das EINE Element, das groß/dominant gemacht wird (z.B. Produktname '桂花酪酪' bei 1/3 Viewport, Gold+Zinnober)
2. eingang:          welche Elemente wie einanimieren (z.B. Titelbuchstaben gestaffelt einblenden + Blüten von oben fallen)
3. symmetriebruch:   wo Layout die Mitte/das Raster durchbricht (z.B. Preisschild schräg unten rechts; Siegel überlappt den Rand)
4. fokuskontrast:    was das Auge zuerst landen lässt (Größensprung / Farbblock / Weißraum um das Heldenelement)

Eine vollständig zentrierte, symmetrische, statische Seite ohne dominantes Element ist das Standard-Mittelmaß-Ergebnis – für ausdrucksstarke Szenen bedeutet es, dass das Commitment nicht eingehalten wurde. Jedes festgelegte Element ausführen. Bewegungsspezifikationen → horizontal-craft/animation-discipline.md.

Beispiel (inline)

„Eine GLM-5.1 Modellvorstellungswebsite machen“ → Positionierung: Reasoning/Execution-Infrastruktur, keine generische KI-Seite; erster_Eindruck: ruhig, präzise, technisch; anti_Standard: die generische KI-SaaS-Helden- + Feature-Karten-Vorlage vermeiden. Szene: ausdrucksstark → helden_subjekt: „GLM-5.1“ übergroß mit einem einzigen Akzent; eingang: Titel + Tagline gestaffeltes Fade-in; symmetriebruch: Spezifikationszahlen auf eine Seite versetzt; fokuskontrast: große Schrift gegen tiefen negativen Raum.

Annahmen zum ersten Produkt

Gehen Sie davon aus, dass die meisten Benutzer keinen erweiterten Designkontext geben — keine Figma-Datei/MCP, ausgereiftes Designsystem, Tokens, Komponentenbibliothek, Markenrichtlinie

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