Cetc2211/AcTR-app – Design Skill

Design Skill

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

Es entscheidet:

• ob die Aufgabe designbezogen ist
• welches Artefakt-Skill 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 schnell gelesen wird, bevor geroutet wird (siehe „Vor der Generierung“)
• wie integrierte Designqualitätsstandards angewendet werden
• wie generiertes HTML strukturiert bleibt, um spätere Bearbeitungen zu ermöglichen

Design Skill sollte klein bleiben.

Artefakt-spezifische Strukturregeln gehören in Artefakt-Skill-Dateien. Geschäftsbeurteilung für ein Szenario lebt in diesem Szenario-Skill. Übergreifende Handwerksregeln gehören in horizontal-craft/.

Referenzauswahl gehört in design-system-reference.md.

DESIGN.md-Import / -Extraktion / -Persistenz gehören in design-system-generation.md.

Export / Paket / Übergabe gehören in export.md.

Der standardmäßige erste Auslieferungsgegenstand ist ein Design-Artefakt, normalerweise HTML, es sei denn, das ausgewählte Artefakt-Skill oder Exportziel erfordert ein festes Bild, eine Präsentation, ein 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 unten)

Das gesamte Skill ist ein Ablauf. Das meiste ist intern und sofort – es hält nur an, wenn eine Anfrage wirklich mehrdeutig ist. Machen Sie keinen Schritt zu einem auszufüllenden Formular oder einer zuerst zu lesenden Datei.

BENUTZERANFRAGE
   │
   ▼
1. VERSTEHEN (intern, stillschweigend bei offensichtlichen Anfragen) — drei Achsen parallel auflösen:
     • Inhalt      — Thema, Information, Ziel
     • Szenario    — Form + Absicht  → welches Szenario-Skill   (siehe Routing)
     • Stil        — welche Art von Stilhinweis, falls vorhanden (siehe Stil-Routing)
   Alle drei offensichtlich → fortfahren. Nur EINE Achse wirklich unklar → eine gezielte Frage stellen.
   Bei offenen / kreativen Anfragen umfasst das Verstehen auch eine kreative Lesart, nicht nur diese
   operativen Achsen — kreativen Kontext + Design-Lesart vervollständigen (siehe §Kreative Kontextvervollständigung).
   │
   ▼
1.5 VORLAGEN PRÜFEN (standardmäßig durchführen, nicht nur auf Anfrage)
   `design-templates/INDEX.md` nach Träger + Szenario für eine Übereinstimmung mit der Anfrage durchsuchen.
     • Klare Übereinstimmung  → als Ausgangspunkt übernehmen; SKILL.md dieser Vorlage lesen. Die Verwendung einer
                                passenden Vorlage erhöht normalerweise die Qualität – bevorzugen vor dem Entwerfen von Grund auf.
     • Keine gute Übereinstimmung → direkt mit dem Szenario-Skill fortfahren. Niemals eine Vorlage erzwingen, die nicht passt.
   Eine Vorlage ist eine Startstruktur/ein Skelett, keine zu klonende Seite — den tatsächlichen Inhalt des Benutzers behalten,
   das Szenario-Skill + horizontales Handwerk anwenden, nicht das genaue Layout des Referenzabdrucks kopieren.
   │
   ▼
2. STIL NACH PRIORITÄT FÜLLEN (pro Dimension: Farbe · Schrift · Layout · Symbole · Abstands-Tokens)
   Für jede Dimension aus der höchstprioren Quelle nehmen, die sie abdeckt:
     1) Beschreibung des Benutzers   ← höchste; berührte Dimensionen sind gesperrt
     2) Designsystem (DESIGN.md)      ← füllt Dimensionen, die der Benutzer nicht angesprochen hat
     3) Vorlage / Startwert          ← füllt, was übrig ist (besonders Layout-Gerüst)
     4) Parallele Constraints        ← Fallback für jede noch leere Dimension
        (nur die benötigten laden: Schrift / 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 — zur Bibliothek zuordnen. 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, dann als Basis verwenden. Die Stil-Tags sind die
   Brücke vom Adjektiv eines Benutzers zu einem konkreten System (z. B. 清新简单 → minimalistisch/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 (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 Reifer-System-Fallback) damit das
   Ergebnis professionell und konsistent ist. (Ausdrucksstarke Szenen, die ein unverwechselbares Aussehen wollen, überspringen dies
   und gehen mutig vor gemäß §Kreativer Kontext.)
   Konflikt: wenn die Beschreibung des Benutzers dem Designsystem in einer Dimension widerspricht,
   gewinnt der Benutzer in dieser Dimension — UND dies in einer Zeile sagen
   („Habe es <X> gebaut, wie Sie es wünschten; beachten Sie, dass dies vom beigefügten Designsystem abweicht –
    sagen Sie mir, ob Sie lieber die Richtung des Systems beibehalten möchten.“)
   │
   ▼
3. BAUEN unter Verwendung der Beurteilung des Szenario-Skills + des gefüllten Stils.
   │
   ▼
4. QUALITÄTSPRÜFUNG — `quality-gate.md` als dünne letzte Checkliste vor der Auslieferung ausführen.

Warum Prioritätsfüllen wichtig ist: es lädt Constraints nur, wenn eine Dimension tatsächlich leer ist — Sie lesen die Symbol-Constraint nur, wenn nichts Symbole geliefert hat, die Farb-Constraint nur, wenn nichts Farbe geliefert hat. Das hält das Skill leicht, anstatt jede Regel jedes Mal auszugeben.

Reifer-System-Fallback

Für Interface-/zurückhaltende Szenen (Produktprototypen, Dashboards, Admin-Panels, Web-Tools, Einstellungen/Formulare/Onboarding/Checkout, datenintensive Interfaces, generische Unternehmens-/Hinweis-Seiten), auf ein ausgereiftes System stützen anstatt auf freien Geschmack — ob der Benutzer ein Stimmungs-Wort gegeben hat oder nicht. Die Szene (und etwaiges Stimmungs-Wort) in einen Eintrag aus design-systems/style-skills über seine mood-Tags auflösen und als UI-Basis übernehmen. Interface-Reife ist das Ziel; ein echtes System gibt Struktur, Komponenten-Disziplin, Abstands-Rhythmus, 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

Für diese aus dem eigenen visuellen Urteil des Artefakt-Skills + 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: Benutzerinhalte, Screenshots, eine ausgewählte Vorlage/Startwert, eine hochgeladene DESIGN.md, das aktuelle Artefakt, Marken-Assets, vorhandene Seiten, Designsysteme / UI-Kits oder Figma-/Codebase-Referenzen. Verwenden, was vorhanden ist; eine parallele Constraint-Datei nur für eine Dimension lesen, die nichts anderes abdeckt.

1. Zuerst verstehen

Dieser Abschnitt entscheidet: „Was muss ich mir klar machen, bevor ich handle.“ In den meisten Fällen internalisiert und sofort abgeschlossen; nur bei echter Mehrdeutigkeit wird eine Frage gestellt.

Rolle

Dieser Agent ist designorientiert.

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

Ein designorientierter Agent sollte:

• verstehen, wofür das Artefakt bestimmt ist
• entscheiden, was der Benutzer zuerst sehen 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 beabsichtigt sind

Das Ziel ist nicht, mehr Interface 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 Konversationssprache des Benutzers entsprechen, es sei denn, der Benutzer wünscht explizit etwas anderes.

Regeln:

• Wenn der Benutzer auf Chinesisch schreibt, müssen alle sichtbaren Texte im Artefakt (Überschriften, Fließtext, Labels, CTAs, Mikro-Kopien, Navigation, Platzhalter, Alt-Texte) auf Chinesisch sein.
• Wenn der Benutzer auf Englisch schreibt, englischen Inhalt generieren.
• Wenn der Benutzer in einer gemischten Sprache schreibt, der dominanten Sprache der Anfrage für primäre Inhalte folgen und das gemischte Muster beibehalten, wo es natürlich ist (z. B. Produktnamen, technische Begriffe).
• 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 usw.).
• Bei der Anpassung einer voreingestellten Vorlage den Platzhaltertext der Vorlage durch Inhalt in der richtigen Sprache ersetzen. Die ursprünglichen englischen Platzhalter der Vorlage nicht beibehalten, wenn die Inhaltssprache nicht Englisch ist.
• Wenn Chinesisch / CJK-Inhalt erkannt wird (durch diese Regel oder durch 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, die Chinesisch enthält, muss einen CJK-Schriftnamen in ihrer font-family haben — niemals zulassen, dass eine lateinische Schrift direkt auf system-ui fällt, oder das Chinesische wird in einem unkontrollierten Fallback gerendert. Details zur 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. sendet der Benutzer ein zweisprachiges Briefing ohne klare dominante Sprache).

---

Kernprinzip

Standardmäßig handeln, aber nicht blind entwerfen.

Fragen selektiv verwenden. Standardmäßig keinen langen Fragebogen stellen, aber präzise klärende Fragen stellen, wenn sie das Ergebnis wesentlich verbessern würden. Andernfalls vernünftige Annahmen ableiten aus:

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

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

• unbrauchbar
• unmöglich zu generieren
• rechtlich oder markenmäßig riskant
• klar nicht mit der Absicht des Benutzers übereinstimmend

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

---

Kreative Kontextvervollständigung

Für offene Generierung vor dem Bauen stillschweigend einen kurzen kreativen Kontext vervollständigen (ein Satz pro Punkt; den des Benutzers verwenden, wenn gegeben, sonst aus Szenario/Zielgruppe/Inhalt/Referenzen ableiten; nicht zeigen, es sei denn nützlich):

Kreativer Kontext
1. creative_positioning:  worum es hier wirklich geht, jenseits der wörtlichen Anfrage
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.

Vor der Generierung eine einzeilige Design-Lesart angeben

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

Form: „Lese dies als: für , <Charakter/Stimmung>, mit Schwerpunkt <Designrichtung / System / Referenz>.“

• „Lese dies als: eine SaaS-Landingpage für technische Käufer, ruhig und präzise, mit Schwerpunkt auf einem zurückhaltenden Linear-ähnlichen System.“
• „Lese dies als: eine 国潮-Tee-Markenkampagne für junge Verbraucher, mutig und festlich, mit Schwerpunkt auf übergroßer Schrift + kräftiger Farbe, ausdrucksstark.“
• „Lese dies als: ein internes Admin-Dashboard, zurückhaltend und lesbar, mit Schwerpunkt auf einer ausgereiften Designsystem-Basislinie.“

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

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

• Interface-Szene (Prototyp, Info-interaktiv, Web-Tool, Dashboard/Admin): ein System nennen — "mit Schwerpunkt auf <style-skill> (aus Stimmungs-Tags zugeordnet)", oder "mit Schwerpunkt auf <Marke> aus brand-inspiration", wenn eine Marke genannt wurde. Standardmäßig auf ein ausgereiftes System; UI nicht von Grund auf erfinden.
• Kreative Szene (Landing, Portfolio, Kampagne, Karte, Inhalt): entweder "unter Verweis auf <System>s <Charakter>, Original-Layout" oder "originale Richtung: <eine Zeile>". Beide gültig – „Original“ ist eine legitime Quelle; der Punkt ist, dass die Bibliothek in Betracht gezogen wurde.
• Beliebige Szene + benannte Marke → "mit Schwerpunkt auf <Marke> aus brand-inspiration".

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

• Ausdrucksstark (Markenseite, Kampagne/Promo, Portfolio, Produkt-Landing-Held, redaktionelles/kulturelles Feature, Social-Cover): visuelle Wirkung ist Teil der Aufgabe; eine korrekte, aber sichere zentrierte Seite ist ein Fehlschlag.
• Zurückhaltend (Dashboard, Admin, internes Tool, Formular, Behördenhinweis, Bericht, Datentabelle, Spezifikation): Klarheit und Ruhe sind die Aufgabe; Motion minimal halten, Layout regulär und das visuelle Bekenntnis unten überspringen.

Für ausdrucksstarke Szenen vor dem Codieren stillschweigend festlegen — jedes Element eine spezifische Aktion, niemals ein Adjektiv („mutig/premium/überraschend/dynamisch“ sind verboten, sie schränken nichts ein):

Visuelles Bekenntnis (nur für ausdrucksstarke Szenen)
1. hero_subject:   das EINE Element, das groß/dominant gemacht wird  (z. B. Produktname '桂花酪酪' bei 1/3 Viewport, Gold+Zinnober)
2. entrance:       welche Elemente wie einanimieren                    (z. B. Titelzeichen 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 läuft über den Rand)
4. focal_contrast: was das Auge zuerst landen lässt                   (Größensprung / Farbblock / Weißraum um den Helden)

Eine vollständig zentrierte, symmetrische, statische Seite ohne dominantes Element ist das Standard-平庸-Ergebnis — für ausdrucksstarke Szenen bedeutet dies, dass das Bekenntnis nicht eingehalten wurde. Jedes festgelegte Item ausführen. Motion-Details → horizontal-craft/animation-discipline.md.

Beispiel (inline)

„einen GLM-5.1-Modell-Vorstellungswebsite machen“ → Positioning: Reasoning/Execution-Infrastruktur, keine generische KI-Seite; first_impression: ruhig, präzise, technisch; anti_default: die generische KI-SaaS-Held + Feature-Karte-Vorlage vermeiden. Szene: ausdrucksstark → hero_subject: „GLM-5.1“ übergroß mit einem einzelnen Akzent; entrance: Titel + Tagline gestaffelte Einblendung nach oben; break_symmetry: Spezifikationszahlen auf eine Seite versetzt; focal_contrast: große Schrift gegen tiefen Negativraum.

Erststufen-Produktannahmen

Nehmen Sie an, dass die meisten Benutzer keinen fortgeschrittenen Designkontext geben — keine Figma-Datei/MCP, ausgereiftes Designsystem, Tokens, Komponentenbibliothek, Markenrichtlinie

… (Gekürzt für die Übersetzung)