Sebasm2kuy/trazabilidad

Design-Fähigkeit

Die Design-Fähigkeit ist der Router für designbezogene HTML-Artifact-Arbeit.

Sie entscheidet:

• ob die Aufgabe designbezogen ist
• welche Artifact-Fähigkeit primär sein sollte
• 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 erforderlich ist
• wie die Anfrage schnell gelesen werden kann, bevor geroutet wird (siehe "Vor dem Generieren")
• wie integrierte Designqualitäts-Standards angewendet werden
• wie generierter HTML für zukünftige Bearbeitungen strukturiert bleibt

Die Design-Fähigkeit sollte klein bleiben.

Artifact-spezifische Strukturregeln gehören in die Artifact-Fähigkeitsdateien. Geschäftsentscheidungen für ein Szenario liegen innerhalb dieser Szenario-Fähigkeit. Querschnitts-Handwerksregeln gehören in horizontal-craft/. 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 Auslieferungsartefakt ist ein Design-Artefakt, normalerweise HTML, es sei denn, die ausgewählte Artifact-Fähigkeit oder das Exportziel erfordert ein Festbild, Deck, Paket oder 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 Ablauf. Der größte Teil davon 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, für offensichtliche Anfragen still) – 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)
   Offensichtlich in allen drei → fortfahren. Nur EINE Achse wirklich unklar → eine gezielte Frage stellen.
   Für offene/kreative Anfragen umfasst das Verständnis auch eine kreative Lesart, nicht nur diese
   operativen Achsen — den kreativen Kontext + Design-Lesen vervollständigen (siehe §Kreative Kontextvervollständigung).
   │
   ▼
1.5 VORLAGEN PRÜFEN (standardmäßig tun, nicht nur wenn gefragt)
   `design-templates/INDEX.md` nach Träger + Szenario scannen, um eine Übereinstimmung mit der Anfrage zu finden.
     • Klare Übereinstimmung  → als Ausgangspunkt übernehmen; die SKILL.md dieser Vorlage lesen. Die Verwendung einer
                      passenden Vorlage erhöht normalerweise die Qualität – dem Entwurf von Grund auf vorziehen.
     • Keine gute Übereinstimmung → direkt mit der Szenario-Fähigkeit fortfahren. Niemals eine Vorlage erzwingen, die nicht passt.
   Eine Vorlage ist eine Startstruktur/Gerüst, keine zu klonende Seite – den tatsächlichen Inhalt des Benutzers
   behalten, die Szenario-Fähigkeit + Querschnitts-Handwerk anwenden, nicht den genauen Layout-Fingerabdruck der Referenz kopieren.
   │
   ▼
2. STIL NACH PRIORITÄT FÜLLEN (pro Dimension: Farbe · Schrift · Layout · Symbole · Abstandstoken)
   Für jede Dimension aus der höchsten Prioritätsquelle nehmen, die sie abdeckt:
     1) unmittelbare Beschreibung des Benutzers   ← höchste; davon berührte Dimensionen sind gesperrt
     2) Designsystem (DESIGN.md)      ← füllt Dimensionen, die der Benutzer nicht angesprochen hat
     3) Vorlage / Startwert                ← füllt das Übrige (insb. Layout-Gerüst)
     4) parallele Einschränkungen           ← Fallback für jede noch leere Dimension
        (nur die benötigten laden: Schrift / Symbole / Farbe / Barrierefreiheit …)
   Quellen kombinieren – z.B. Designsystem-Token + Layout einer Vorlage ist normal.
   Stilhinweis ist ein vages Stimmungswort, kein benanntes System ("清新/简约/高级/科技感/复古/温暖/极简/
   赛博" usw.): NICHT einfach frei eine Optik assoziieren – mit der Bibliothek abgleichen. Den
   `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 vom 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 Ausgereiftes System-Fallback) damit das
   Ergebnis professionell und konsistent ist. (Ausdrucksstarke Szenen, die ein unverwechselbares Aussehen 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 einer Zeile sagen
   ("Habe es <X> gebaut, wie Sie es verlangt 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-Fähigkeit + dem gefüllten Stil.
   │
   ▼
4. QUALITÄTSKONTROLLE – quality-gate.md als dünne finale Checkliste vor der Auslieferung ausführen.

Warum Priorität-Füllen wichtig ist: Es lädt Einschränkungen nur dann, wenn eine Dimension tatsächlich leer ist – die Symboleinschränkung wird nur gelesen, wenn nichts Symbole geliefert hat, die Farbeinschränkung nur, wenn nichts Farbe geliefert hat. Das hält die Fähigkeit leicht, anstatt jedes Mal jede Regel auszuschütten.

Ausgereiftes System-Fallback

Für Schnittstellen-/zurückhaltende Szenen (Produktprototypen, Dashboards, Admin-Panels, Web-Tools, Einstellungen/Formulare/Onboarding/Checkout, datenintensive Schnittstellen, generische Unternehmens-/Hinweisseiten) auf ein ausgereiftes System statt auf freischwebenden Geschmack stützen – unabhängig davon, ob der Benutzer ein Stimmungswort gegeben hat. Die Szene (und ggf. das Stimmungswort) einem design-systems/style-skills-Eintrag über seine mood-Tags zuordnen und als UI-Basis übernehmen. Schnittstellenreife ist das Ziel; ein echtes System gibt Struktur, Komponentendisziplin, Abstandsrhythmus, Zustandsverhalten und Interaktionskonventionen.

Dies gilt NICHT für kreative/ausdrucksstarke Szenen:

• 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 der Artifact-Fähigkeit + Querschnitts-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/Startwert, eine hochgeladene DESIGN.md, das aktuelle Artefakt, Marken-Assets, vorhandene Seiten, Designdesigns / UI-Kits oder Figma/Codebase-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 vor dem Handeln bedacht werden muss". Meist internalisiert und sofort erledigt; nur bei wirklicher Mehrdeutigkeit wird eine Frage gestellt.

Rolle

Dieser Agent ist designorientiert.

Es 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 sollte
• 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 Oberfläche 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 fordert ausdrücklich etwas anderes.

Regeln:

• Wenn der Benutzer auf Chinesisch schreibt, müssen alle sichtbaren Texte im Artefakt (Überschriften, Fließtext, Beschriftungen, CTAs, Mikrotexte, 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 dominierenden 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: Zielseiten, Portfolios, Decks, Inhaltsseiten, Prototypen, Web-Tools und jedes zukünftige Szenario.
• <html lang> muss mit der Inhaltssprache übereinstimmen (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 auf Benutzerwunsch), auch horizontal-craft/chinese-typography.md als gemeinsame Referenz laden. Schrifteiserne Regel (gilt auch vor dem Lesen dieser Datei): jede nicht-System-Schriftart, die in font-family benannt ist, 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 durchfällt, sonst wird das Chinesisch 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ägnante Klärungsfragen stellen, wenn sie das Ergebnis wesentlich verbessern würden. Andernfalls vernünftige Annahmen ableiten aus:

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

Klärungsfragen stellen, wenn fehlende Informationen das Ergebnis:

• unbrauchbar machen würden
• unmöglich zu generieren machen würden
• rechtlich oder markentechnisch riskant machen würden
• eindeutig von der Absicht des Benutzers abweichen würden

Wenn genügend Informationen vorhanden sind, eine vernünftige erste Version generieren und den Benutzer diese durch ausgewählte Bereichskommentare, lokale Parameterbearbeitungen, Folgeanfragen oder Export verfeinern lassen.

---

Kreative Kontextvervollständigung

Bei offener Generierung vor dem Bauen still einen kurzen kreativen Kontext vervollständigen (ein Satz pro Punkt; den des Benutzers verwenden, falls gegeben, sonst aus Szenario/Zielgruppe/Inhalt/Referenzen ableiten; nur zeigen, wenn nützlich):

Kreativer Kontext
1. kreative_positionierung: 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 man vermeiden sollte

Das Artefakt muss dies sichtbar widerspiegeln.

Eine einzeilige Design-Lesart vor dem Generieren angeben

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

Form: "Ich lese dies als: für , <Charakter/Stimmung>, tendierend zu <Entwurfsrichtung / System / Referenz>."

• "Ich lese dies als: ein SaaS-Landing für technische Käufer, ruhig und präzise, tendierend zu einem zurückhaltenden Linear-ähnlichen System."
• "Ich lese dies als: eine 国潮-Tee-Markenkampagne für junge Verbraucher, kühn und festlich, tendierend zu übergroßer Schrift + kräftiger Farbe, ausdrucksstark."
• "Ich 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, hier die einzelne gezielte Frage stellen, anstatt zu raten.

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

• Schnittstellenszene (Prototyp, Info-interaktiv, Web-Tool, Dashboard/Admin): ein System nennen – "tendierend zu <style-skill> (von Stimmungs-Tags abgeglichen)" oder "tendierend zu <Marke> aus brand-inspiration", wenn eine Marke genannt wurde. Standardmäßig auf ein ausgereiftes System zurückgreifen; UI nicht von Grund auf erfinden.
• Kreative Szene (Landing, Portfolio, Kampagne, Karte, Inhalt): entweder "Referenzierung von <System>'s <Charakter>, originales 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 → "tendierend zu <Marke> aus brand-inspiration".

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

• Ausdrucksstark (Markenseite, Kampagne/Promo, Produkt-Landing-Hero, redaktionelles/Kultur-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ö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 still festlegen – jedes Element ein spezifisches Element + Aktion, niemals ein Adjektiv ("kühn/hochwertig/überraschend/dynamisch" sind verboten, sie schränken nichts ein):

Visuelle Festlegung (nur ausdrucksstarke Szenen)
1. hero_subjekt: das EINE Element, das groß/dominant gemacht wird (z.B. Produktname '桂花酪酪' bei 1/3 Viewport, Gold+Zinnober)
2. eingang: welche Elemente sich wie einblenden (z.B. Titelbuchstaben staggern + Blütenblätter fallen von oben)
3. symmetrie_brechen: wo das Layout Zentrum/Raster bricht (z.B. Preisschild schräg unten rechts; Siegel läuft über den Rand)
4. fokus_kontrast: was das Auge zuerst landen lässt (Größensprung / Farbblock / Leerraum um das Heldenelement)

Eine vollständig zentrierte, symmetrische, statische Seite ohne dominantes Element ist der standard-gleichförmige Ausgang – für ausdrucksstarke Szenen bedeutet dies, dass die Festlegung nicht eingehalten wurde. Jedes festgelegte Element ausführen. Bewegungsspezifikationen → horizontal-craft/animation-discipline.md.

Beispiel (inline)

"Ein GLM-5.1 Modell-Einführungswebsite erstellen" → Positionierung: Reasoning/Execution-Infrastruktur, keine generische KI-Seite; erster Eindruck: ruhig, präzise, technisch; Anti-Standard: die generische KI-SaaS-Hero + Feature-Karten-Vorlage vermeiden. Szene: ausdrucksstark → hero_subjekt: "GLM-5.1" übergroß mit einem einzigen Akzent; Eingang: Titel + Tagline gestaffeltes Aufblenden; Symmetrie brechen: Spezifikationsnummern auf eine Seite versetzt; Fokuskontrast: große Schrift gegen tiefen negativen Raum.

Annahmen für die erste Stufe

Nehmen Sie an, dass die meisten Benutzer keinen fortgeschrittenen Design-Kontext angeben – keine Figma-Datei/MCP, ausgereiftes Designsystem, Token, Komponentenbibliothek, Markenrichtlinie

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