Moddingflow/better-design

Better Design

Machen Sie die angeforderte Aufgabe klar und handlungsorientiert: Der Benutzer kann sehen, wo er sich befindet, versteht eine Aktion, bevor er sie ausführt, erhält ein Ergebnis und kann sich von einem Fehler erholen. Bewerten Sie Kohärenz, Ausdruckskraft und Barrierefreiheit separat. Versprechen Sie keine perfekte UX.

1. Umfang und visuelle Grundlagen festlegen

• Wählen Sie einen Modus: Erstellung, gezielte Verbesserung, Audit oder Plan. Behalten Sie Audits im Nur-Lese-Modus bei; implementieren Sie keine Änderungen in einem Plan. Fügen Sie keine Funktionen hinzu, die der Benutzer nicht angefordert hat.
• Legen Sie die Plattform aus der Anfrage und dem Projekt fest. Nur wenn der Kontext fehlt, verwenden Sie responsives Web, semantisches HTML und WCAG 2.2 AA als erstes Ziel.
• Definieren Sie die tatsächliche Geräte- und Viewport-Matrix, bevor Sie eine responsive Oberfläche erstellen oder ändern. Für eine Website umfassen Sie die mobilen, Tablet-, Desktop- und Ultrabreit-Layouts, die das Produkt unterstützt; für ein mobiles Spiel beziehen Sie kleine und typische Telefone sowie Tablets ein. Designbeschränkungen und Layoutverhalten müssen sich an diese Oberflächen anpassen, anstatt lediglich eine Desktop-Komposition zu verkleinern. Schließen Sie für Browser-Arbeiten den Browser-Zoom in die Matrix ein, da 75 %, 100 % und 150 % unterschiedliche Clipping-, Dichte-, Refow- und Interaktionsfehler aufdecken können.
• Suchen Sie vor jeder UI-Arbeit nach der DESIGN.md des Projekts (Stammverzeichnis, docs/, design/ oder dem in den Agentenanweisungen genannten Pfad) und lesen Sie sie vollständig. Sie ist die einzige Quelle für Oberflächenwerte: Schriftarten, Schriftgrößenskala, Farbrollen, Abstände, Radien, Komponentengrößen, Symbole und Bewegungen. Übernehmen Sie jeden Wert in neuem oder geändertem Code daraus nach Rolle oder Token-Name; schätzen Sie niemals, runden Sie nicht und führen Sie keine Beinahe-Duplikate ein. Regeln finden Sie in design-md.md.
• Untersuchen Sie den vorhandenen Bildschirm in der aktuellen Laufzeit oder durch bestätigte aktuelle Aufnahmen, dann untersuchen Sie nahegelegene Komponenten, Tokens, Stile und Projektregeln. Das Fehlen einer DESIGN.md bedeutet nicht, dass es kein Designsystem gibt: Die Code-Tokens sind dann das System. Bewahren Sie nicht zusammenhängende laufende Arbeiten.
• Unterscheiden Sie einen Implementierungsfehler von einer Redesign-Anfrage. Beheben Sie zuerst die Ursache: unklare Anordnung, eine unvorhersehbare Aktion, schlechtes Feedback, Datenverlust oder verlorener Inhalt.
• Treffen Sie Entscheidungen in dieser Reihenfolge: explizite Aufgabe und Einschränkungen → DESIGN.md und das bestehende System → Plattform-Konventionen → Domänenaufgaben → die konfigurierbare Baseline dieses Skills. Funktionalität und anwendbare Barrierefreiheitsanforderungen gelten auf jeder Ebene.
• Standard visuelle Richtung. Wenn der Benutzer keinen visuellen Stil nennt und das Projekt keine DESIGN.md, Marke, Code-Tokens oder Live-UI zum Erben hat, bauen Sie im Hausstil: ultra-minimal im Geiste von Apple (schwarze Leinwand, fast weißes Geologica in den Stärken 500 und 340, zwei Grautöne, ein Blau für Links und Fokus, Pill-Aktionen, durch Tonalität getrennte Oberflächen, echter Inhalt als einzige Farbe). Regeln und die fertige DESIGN.md-Voreinstellung finden Sie in house-style.md; lesen Sie sie vollständig, bevor Sie einen Stil schreiben. Zwei Fehlinterpretationen führen Agenten woanders hin, also überprüfen Sie sie explizit (house-style.md Abschnitt 1): Die Domäne, Branche, Zielgruppe oder der Name des Produkts ist kein visueller Hinweis („ein Kaffeeröster“, „für Entwickler“), und unberührte Scaffold-Standardwerte sind kein zu erbendes System (shadcn/ui-Standardthema, Tailwinds Standardpalette, create-next-app-, Vite- oder Expo-Starter, Bootstrap-, MUI- oder Chakra-Standards); kartieren Sie stattdessen den Hausstil darauf. Wenn er zutrifft, beginnen Sie mit der Referenzdatei house-style.html, nicht mit einer leeren Seite: Übernehmen Sie deren Tokens, Typklassen, Navigation, Schaltflächen, Kacheln und Abschnittsrhythmus (oder portieren Sie sie in die Komponenten des Stacks), ersetzen Sie dann den Inhalt (house-style.md Abschnitt 1). Jeder visuelle Hinweis vom Benutzer (Farben, Stimmung, Thema, Referenz, Marke, Zielgruppenstil) überschreibt dies: Folgen Sie der Anfrage und wenden Sie nur die Teile des Hausstils an, die die Anfrage offen lässt und nicht widerspricht. Gestalten Sie ein vorhandenes Produkt niemals ohne Aufforderung darin um. Spiele behalten ihre eigene künstlerische Ausrichtung.
• Bewahren Sie die etablierte Marke, Dichte, spielerische, redaktionelle oder ausdrucksstarke Komposition. Ersetzen Sie sie nicht durch ein generisches graues CRM. Wählen Sie bei einem echten Konflikt die kleinste zugängliche Anpassung und erklären Sie die spezifische Abweichung.
• Klären Sie nur Unbekannte, die die Entscheidung materiell ändern; geben Sie vernünftige Annahmen kurz an. Dieser Skill führt kein neues Genehmigungs- oder HTML-Gate ein. Bestehende Projektanforderungen für Prototypen, Genehmigungen und Builds bleiben anwendbar.

2. Die Aufgabe und einen angemessenen Vertrag definieren

• Beschreiben Sie das primäre Szenario in einfacher Sprache und sein beobachtbares Ergebnis. Gehen Sie durch: Einstieg → Aktion → Ergebnis → Fehler/Wiederholung → Zurück/Abbrechen.
• Trennen Sie die primäre Aufgabe, sekundäre Aktionen und Hilfe. Wählen Sie dem Benutzer vertraute Namen und Muster; halten Sie die Navigations- und Aktionspositionen über Bildschirme hinweg konsistent.
• Eine einzelne Korrektur benötigt nur eine kurze Aufzeichnung der geänderten Entscheidung und der Überprüfungen. Schreiben Sie für einen neuen Ablauf einen kompakten Vertrag vor der Implementierung; er ist ein Arbeitswerkzeug, kein Pflichtdokument für den Benutzer.
• Verwenden Sie design-contract.md für die Struktur, numerische Standardwerte und Ausnahmen. Das JSON-Beispiel veranschaulicht das Format; fügen Sie es für eine kleine Änderung nicht pauschal zum Projekt hinzu.
• Beschränken Sie den Vertrag auf die Plattform, Ziele, bestehendes System, Richtung, betroffene Komponenten, deren Aktionen/Zustände, responsives Verhalten und Akzeptanznachweise. Eine geplante Prüfung ist keine abgeschlossene Prüfung.

3. Vor dem Stylen eine künstlerische Ausrichtung festlegen

Negative Regeln verschieben die Ausgabe nur zur nächsthäufigen Vorlage; Charakter entsteht aus einem Prozess. Wenn Sie eine Oberfläche erstellen oder neu gestalten, deren Identität Teil der Aufgabe ist (Marke, Landing, Portfolio, Consumer-App, Spiel, redaktionell, Launcher), folgen Sie art-direction.md, bevor Sie Tokens auswählen. Wenn der Hausstil zutrifft (Abschnitt 1), stammen Palette, Typografie, Form und Bewegungs-Tokens aus seiner Voreinstellung; schreiben Sie trotzdem das Konzept und lassen Sie es die Bildsprache, das führende Element jedes Abschnitts und ein Signaturdetail auswählen (house-style.md Abschnitt 10). Ansonsten:

• Leiten Sie ein Ein-Satz-Konzept aus der Domäne, Zielgruppe und dem Inhalt des Produkts ab – ein Objekt, Ort oder Handwerk aus dieser Welt – nicht aus Adjektiven wie „modern, sauber, minimalistisch“. Fügen Sie drei Zielqualitäten und drei konkrete Anti-Qualitäten hinzu.
• Sammeln Sie 3–5 echte Referenzen (vom Benutzer bereitgestellte zuerst; niemals KI-generierte Bilder) und notieren Sie für jede genau, was übernommen wird: Rhythmus, Dichte, Zahldarstellung, Material, Licht.
• Skizzieren Sie 2–3 Richtungen, die sich durch ihr führendes Element unterscheiden (typografisch, bildgeführt, strukturell), wählen Sie dann eine aus mit einer Begründung, die mit der Aufgabe und dem Publikum zusammenhängt.
• Leiten Sie Palette und Typografie aus dem Konzept ab: eine Palette mit einer angegebenen Herkunft und abgetönten Neutraltönen; drei Schriftkandidaten und eine begründete Wahl. Planen Sie ein oder zwei Signaturdetails; der optionale Pool in effects-library.md enthält getestete.
• Leiten Sie den Bewegungscharakter aus demselben Konzept ab: wie sich Dinge in dieser Welt bewegen (Tempo, Gewicht, Physik, ob etwas federt) plus ein Signaturbewegungsdetail. Palette, Typografie und Bewegung müssen wie eine Stimme klingen; siehe motion.md.
• Leiten Sie innerhalb einer DESIGN.md, einer bestehenden Marke oder eines Designsystems die Richtung ab: Übernehmen Sie sie aus der DESIGN.md oder formulieren Sie sie in einem Satz von der Live-Oberfläche und arbeiten Sie darin. Dichte Arbeitswerkzeuge drücken Charakter durch Präzision und Datentypografie aus; ohne System und ohne Benutzereingabe nehmen sie die Hausstil- App-Skala und -Palette mit der Dichte des neutralen Fallbacks.
• Halten Sie die Richtung im Vertrag fest (Richtung, einschließlich Richtung.Bewegung) und planen Sie Prüfungen für Unterscheidbarkeit und Bewegung. Schreiben Sie die gewählte Richtung und ihre Tokens in DESIGN.md, damit spätere Bildschirme und Sitzungen auf denselben Werten aufbauen.

4. Ein kohärentes System von Entscheidungen aufbauen

• Verwenden Sie Tokens und Komponenten aus der DESIGN.md und den Code-Tokens wieder. Definieren Sie für ein neues System semantische Rollen für Farbe, Typografie, Abstände, Radius, Ebenen und Bewegung; wählen Sie dann Komponentenvarianten.
• Halten Sie die Sets geschlossen, sodass jeder Bildschirm aus denselben Teilen aufgebaut ist: ein oder zwei Schriftfamilien, eine abgestufte Schriftgrößenskala mit wenigen Rollen, eine feste Abstandsskala, wenige Radien und feste Komponentengrößen (z. B. Schaltfläche sm/md/lg). Gleiche Rolle, gleicher Wert auf jedem Bildschirm. Ein fehlender Wert ist eine Systementscheidung: Fügen Sie die Rolle zur DESIGN.md und den Code-Tokens in derselben Änderung hinzu.
• Erstellen Sie DESIGN.md aus der Vorlage, wenn Sie eine Oberfläche von Grund auf neu erstellen (aus der Hausstil-Voreinstellung wenn der Hausstil zutrifft), oder wenn ein Redesign oder eine mehrere Komponenten umfassende Änderung keine findet; leiten Sie sie von den Live-Code-Tokens ab, anstatt Werte zu erfinden, und zeichnen Sie Widersprüche auf, anstatt sie stillschweigend zu beheben. Erstellen Sie sie nicht für eine Ein-Element-Korrektur, es sei denn, es wird danach gefragt; bieten Sie sie in einer Zeile an. Halten Sie DESIGN.md und Code-Tokens mit jeder Änderung synchron, die eines von beiden betrifft.
• Die API drückt Absicht, Größe, Dichte und Zustand aus. Bewahren Sie native Props, Formularbeteiligung, Links und zugängliche Namen; verlangen Sie kein onClick für eine Senden-Schaltfläche oder einen Link mit href.
• Stimmen Sie nicht jedes Element mit seinem eigenen Hex, Abstand, Schatten und Radius ab. Ändern Sie einen gemeinsamen Token oder eine Variante, wenn die Ursache gemeinsam ist. Layout-Mathe, ein 1px-Rand, 0, fr, %, calc, aspect-ratio und zulässige Projektwerte sind an sich keine Verstöße.
• Wählen Sie die Textgröße nach Rolle und Container.
• Konstruieren Sie Geometrie; platzieren Sie sie nie nach Augenmaß. Befolgen Sie layout-geometry.md für jeden Bildschirm, jedes Panel und jedes Spielmenü und messen Sie das Ergebnis (Abschnitt 8). Beheben Sie eine Fehlausrichtung an ihrer Ursache (Drehpunkte, Ankerpunkte, eine fehlende Layout-Gruppe, Sprite-Padding, Schriftmetriken), niemals durch Verschieben eines Elements:
  • Gleiche Intervalle. Geschwister einer Art sitzen in einem Layout-Container (flex/grid gap, Unity-Layout-Gruppen, Godot-Box-Container, UMG-Boxen) mit einem Abstands-Token, sodass jede Lücke zwischen ihnen identisch ist. Ein anderer Abstand muss eine neue Gruppe und einen klaren Schritt auf der Skala bedeuten. Proximitätsleiter: innerhalb eines Bedienelements < zwischen Elementen < zwischen Gruppen ≤ Abstand.
  • Gemeinsame Linien. Elemente in einer Reihe teilen sich ihre Oberkante/Mitte/Unterkante (gemischte Höhen teilen sich Mittelpunkte); Elemente in einer Spalte und jede Beschriftung in einer Einstellungsliste beginnen auf einer vertikalen Ausrichtungslinie, mit Bedienelementen auf einer zweiten Ausrichtungslinie. Verwenden Sie ein Raster oder eine feste Beschriftungsspalte, niemals versatz pro Zeile. Schaltflächengruppen teilen sich eine Größe.
  • Inhalt innerhalb kleiner Bedienelemente wird durch seine sichtbare Tinte zentriert (Cap-Höhe, zugeschnittene Symbol-Pixel), nicht durch den Schriftlinienrahmen oder ein gepolstertes Sprite-Rechteck; asymmetrische Symbole erhalten einen deklarierten optischen Versatz, der in die Komponente eingebaut ist. Symbol + Beschriftungspaare verwenden einen Abstands-Token.
  • Atemraum. Nichts läuft über oder sitzt am Rand seines Containers: Der Abstand beträgt mindestens die Lücken, die er enthält, mit Reserve für die längste Lokalisierung, Hover-Skalierung und Fokusringe; interaktive UI bleibt innerhalb des sicheren Bereichs bei jedem unterstützten Seitenverhältnis. Wenn Inhalt nicht passt, ändern Sie das Layout, nicht die Ränder.
• Wählen Sie Typografie durch einen Prozess aus, nicht durch eine Blacklist: Erstellen Sie eine Shortlist von drei Schriftfamilien, die aus dem Konzept abgeleitet sind (Epoche, Material, Stimme, Datendichte), dann wählen Sie mit einer angegebenen Begründung. Die Familie muss in ihren tatsächlichen Größen und Sprachen lesbar sein und die erforderlichen Stärken, Stile, Ziffern, Zeichenabdeckung (einschließlich Kyrillisch, wenn unterstützt) und Rückfallverhalten bereitstellen. Keine Familie ist verboten, aber eine aus Gewohnheit gewählte Familie ist ein Fehler: Den Standard einer Tendenz (Inter, Uni Sans) gegen den nächsten (Space Grotesk, DM Sans, Instrument Serif) ohne Begründung auszutauschen, ist dieselbe Vorlage. Stilvolle Schrift darf das Lesen der Oberfläche niemals erschweren.
• Bauen Sie Hierarchie durch Dominanz und Kontrast auf: ein führendes Element pro Bildschirm oder Abschnitt, eine klar abgestufte Schriftgrößenskala (Display 3–5× der Grundschrift auf expressiven Oberflächen, kleinere Schritte in dichten Werkzeugen), bewusste Asymmetrie, wo sie dem Konzept dient, und benachbarte Abschnitte, die sich in der Struktur unterscheiden, anstatt ein Blockmuster zu wiederholen.
• Der Goldene Schnitt kann Proportionen, Hierarchie, Beschnitt oder Weißraum informieren, wenn er die Komposition verbessert, aber er ist ein visuelles Werkzeug und keine zwingende Formel. Bevorzugen Sie die tatsächliche Aufgabe, den Inhalt, responsive Einschränkungen, Lesbarkeit und das vorhandene System, wenn immer sie in Konflikt geraten.
• Machen Sie einen primären Bildschirm nicht zu einer Wand aus ununterbrochener Prosa, wenn sein Inhalt durch Aktionen, Gruppierung oder visuelle Anker verstanden werden kann. Brechen Sie dichte Erklärungen in scanbare Abschnitte auf und paaren Sie sie, wo nützlich, mit aussagekräftigen Bedienelementen, Symbolen, Illustrationen, Vorschauen, Diagrammen oder anderen aufgabenrelevanten Bildern. Ein Dashboard oder Kontobereich sollte beispielsweise seine Hauptabschnitte und nächsten Aktionen anzeigen, anstatt nur zu beschreiben, was ein Benutzer konfigurieren könnte. Fügen Sie keine dekorativen visuellen Elemente hinzu, die mit dem Verständnis konkurrieren oder falsche Affordanzen erzeugen.
• Verwenden Sie Farbe für Bedeutung und Betonung; vermitteln Sie Zustand nicht allein mit Farbe. Paaren Sie Fehler-/Erfolg-/Erforderlich-/Ausgewählt-Informationen mit Text, einem Symbol, einer Form, einem Muster oder einem anderen Nicht-Farb-Hinweis, der in Graustufen und für Farbsinnesstörungen sichtbar bleibt.
• Überprüfen Sie den Kontrast am tatsächlichen benachbarten Vordergrund-/Hintergrundpaar nach Opazität, Überlagerungen, Verläufen, Bildern und jedem erforderlichen Design sind angewendet; runden Sie ein nahe der Schwelle liegendes Ergebnis nicht. Erreichen Sie mindestens 4,5:1 für normalen Text und aussagekräftige Textbilder und 3:1 nur für großen Text (mindestens 24 CSS-Pixel normal oder 18,5 CSS-Pixel fett). Streben Sie höhere Werte für dünne, kleine oder ungewöhnliche Schriftarten an.
• Stellen Sie ein Mindestkontrastverhältnis von 3:1 für visuelle Informationen sicher, die zur Identifizierung eines aktiven Bedienelements, seines Fokus oder Zustands und aussagekräftiger grafischer Objekte gegen ihre angrenzende Farbe erforderlich sind. Ein Rahmen ist nur erforderlich, wenn er das Bedienelement identifizierbar macht; wenn er für diesen Zweck verwendet wird, muss er dasselbe 3:1-Kontrastverhältnis erfüllen.

5. Bewegung

• Leiten Sie den Bewegungscharakter aus derselben künstlerischen Ausrichtung ab, die die Palette und Typografie wählt (Abschnitt 3). Eine einzige zusammenhängende Stimme für Form, Farbe und Bewegung.
• Verwenden Sie motion.md für die vollständige Bewegungsspezifikation. Es definiert die Bewegungswerte, einen hierarchischen Ansatz (Press-Rückmeldung, zustandsbezogene Übergänge, Layout- und Pfad-Übergänge, Choreografie) und Regeln für reduzierte Bewegung.
• Für jede neue Komponente oder Interaktion: Press-Rückmeldung (sofort, klein, das Gefühl eines echten mechanischen oder taktilen Anschlags), zustandsbezogener Übergang (100–200 ms, Tempo zur Form des Bedienelements passend). Layout- und Pfad-Übergänge, wenn Ansichten wechseln; Choreografie, wenn mehrere Elemente als Antwort auf eine Benutzeraktion eintreten (Staffelung, Richtung, Timing-Fächer).
• Verwenden Sie ein kurzes Fade-In nur für anfänglichen Seiten-/Bildschirminhalt, der bei voller Deckkraft startet; verwenden Sie kein Fade-In für jedes Element. Stattdessen verwenden Sie Bewegung (von einer Position, einer Transformation oder einem Zustandswechsel), um die Beziehung jedes Elements zu seiner vorherigen Position und seinem Zweck zu kommunizieren.
• Respektieren Sie die Einstellung „reduzierte Bewegung“ auf jeder Plattform; bieten Sie eine statische Animation (z. B. einen Diskret-Zustandswechsel) mit derselben Informationskapazität an.
• Persistieren Sie den Bewegungscharakter und die Tokens der Richtung (was federt, Schlüsseldauern, Easing-Kurven, ob eine Choreografie definiert ist) in DESIGN.md.

6. Überprüfungen und Schleifenschluss

• Überprüfen Sie das beobachtbare Ergebnis gegen den Vertrag (Abschnitt 2). Ein geplantes Element ist kein implementiertes Element.
• Suchen Sie nach den in checks.md aufgeführten Fehlern: tote Bedienelemente, versteckte Aktionen, Verwirrungsmuster, Layout-Rauschen, fehlender Atemraum, Ausrichtungsfehler, Text als UI, KI-Slop (Fülltext, Erzählung, unnötige Hilfetexte, generische Beschriftungen, unnötige Fokus und Scrollen zur Folge haben), Bildschirmflimmern (Layout-Verschiebung nach dem ersten Render, späte Assets, Stil-Flicker), fehlende Inhalts- oder Fehlerzustände und Lader (Skelett-Lader oder Lade-Splash). Das Beheben dieser Fehler verbessert die Qualität mehr als das Hinzufügen einer Animation.
• Überprüfen Sie die Barrierefreiheit nach einer zugänglichen Checkliste, die auf die Plattform und Domäne zugeschnitten ist (z. B. WCAG 2.2 AA für das Web).
• Überprüfen Sie die Bewegung nach der Bewegungsdefinition (Abschnitt 5), einschließlich des Fehlens einer Layout-Verschiebung (Seiteninhalte, die nach dem ersten Render in der Position springen).
• Überprüfen Sie die Layout-Geometrie nach Abschnitt 4 und layout-geometry.md: Gleiche Intervalle, gemeinsame Linien, zentrierter Inhalt, Atemraum.
• Überprüfen Sie die Unterscheidbarkeit: das Konzept gegen die Ausgabe. Fügen Sie ein sofortiges visuelles Detail hinzu, das die Absicht vermittelt (eine Hover-Karte mit Bewegung, einer kleinen Akzentfarbe oder einer typografischen Geste), auch wenn Sie kein umfangreiches Redesign durchführen.
• Überprüfen Sie die Zustände auf jeder interaktiven Komponente: Standard, Hover, Fokus, Aktiv, Deaktiviert, Fehler, Ladezustand, Leerzustand. Ein Eingabefeld ist z. B. kein Standard-Text: Es hat die obigen Zustände, plus erforderlich, validiert, Autovervollständigung. Überprüfen Sie die Sichtbarkeit jedes Zustands, einschließlich bei aktiviertem Zoom und reduzierter Bewegung.
• Überprüfen Sie die Überflutung: eine Komponente, die außerhalb ihres Containers in die nächste läuft, oder Text, der bei einer echten Lokalisierung (Übersetzungen in Deutsch, Japanisch, Arabisch sind ca. 35 % länger als die durchschnittliche englische Zeichenfolge) oder zwischen den unterstützten Schriftstärken überläuft. Wenn diese Überprüfung fehlschlägt, ändern Sie die Layout-Struktur (Stapel, Gitter, fester vs. fließender Text), anstatt die Ränder zu verkleinern.
• Überprüfen Sie die Barrierefreiheit auf einer zweiten Ebene: Tastaturnavigation in einer logischen Reihenfolge, alle Aktionen von der Tastatur aus erreichbar (Tab, Eingabe, Escape, Pfeiltasten), lesbare Bildschirmausgabe, ausreichende Kennzeichnung von Formularfeldern, Etappenanzeige bei mehreren Schritten, angemessene Farbkontraste (Abschnitt 4), Sichtbarkeit des Fokus-Rings.
• Überprüfen Sie die Metapher: Das visuelle Vokabular kommuniziert das Konzept und das Ökosystem des Produkts, nicht das einer generischen Vorlage. Eine Bank-App zeigt keine schwebenden Aktionsschaltflächen, eine Design-Plattform zeigt keine generischen Formulare und eine Gesundheits-App vermeidet übermäßig klinische Räume ohne Wärme.

7. Liefern

• Geben Sie jede Änderung klar an: Datei, Token, Komponente, neuer Wert, Grund.
• Fügen Sie Änderungen an DESIGN.md als Teil derselben Änderung ein, wenn sich Tokens ändern.
• Wenn Sie einen Design-Vertrag geschrieben haben (Abschnitt 2), aktualisieren Sie ihn mit dem Endergebnis und haken Sie jeden Prüfpunkt ab oder vermerken Sie die Abweichung.
• Schreiben Sie keine umfangreichen Erklärungen für Einzeilen-Korrekturen. Ein "Behoben:" und ein Hinweis auf die Regel sind ausreichend.
• Wenn die Anfrage nicht innerhalb des aktuellen Bereichs gelöst werden kann (fehlendes Asset, ein Backend-Endpunkt, der Daten liefert, die nicht vorliegen), stoppen Sie und sagen Sie genau, was benötigt wird, bevor Sie weitermachen.

Dieser Skill ist ein Werkzeug für durchdachtes, systematisches UI/UX-Design. Seine vollständige Kraft entfaltet er, wenn er als Ganzes gelesen und angewendet wird, nicht als Checkliste isolierter Schritte.