Gentle-Programming/gentle-design

Aktivierungsvertrag

Nutze dieses Skill standardmäßig, wenn der Benutzer in einfachen Worten nach einem UI-Design, Mockup, Bildschirm, einer Landingpage oder visuellen Richtungen fragt oder an Artboards unter design/ iteriert. Verwende es nicht, um Produktionscode im Projekt-Stack zu implementieren.

Die /gentle:design-Befehle sind optionale Abkürzungen: Jede Aktion funktioniert auch über eine einfache Anfrage, durch dieses Skill und das gentle_design-Werkzeug (list, open, stop, implement, handoff).

Harte Regeln

• Jedes Artboard ist eine vollständig eigenständige HTML-Datei: Inline-CSS, JS und SVG; nur Systemfont-Stacks. Verwende niemals externe URLs, CDNs, entfernte Schriftarten, Bilder oder Skripte.
• Verwende realistische Inhalte für die Zielgruppe; kein Lorem Ipsum oder Platzhalternamen.
• Zugängliches Markup: semantische Elemente und Landmarken, WCAG-AA-Kontrast, sichtbare Fokus-Stile, prefers-reduced-motion für jede Bewegung respektiert.
• Wenn design/system.md existiert, lies es zuerst und verwende nur dessen Tokens und Komponentenregeln; führe vor Abschluss eines Artboards die Selbstprüfung aus dem Abschnitt „Designsystem-Synchronisation“ durch.
• Stelle höchstens eine klärende Frage, und nur wenn der Auftrag das Ziel oder den Inhalt vermissen lässt.
• Iterationen bearbeiten nur das gezielte Artboard. Überschreibe niemals die anderen.

Entscheidungstabelle

Situation	Aktion
Neuer Auftrag	Schreibe N klar unterschiedliche Richtungen (standardmäßig 3, oder die gewünschte Anzahl) in ein neues design/<slug>/
Feedback zu einem Artboard	Bearbeite nur diese Datei; behalte den Manifest-Eintrag, aktualisiere tradeoff, falls er sich geändert hat
„Speichern und einen anderen Ansatz versuchen“	Füge ein neues Artboard mit der nächsten NN hinzu; behalte die vorherigen; hänge es an das Manifest an
Benutzer möchte Werte anpassen (Abstände, Farbe, Schriftgröße)	Füge Schieberegler oder Steuerelemente im Artboard sowie einen „Als Prompt kopieren“-Button hinzu, der die gewählten Werte als Prompt kopiert
design/<slug>/ existiert bereits für einen neuen Auftrag	Wähle einen neuen Slug; überschreibe niemals ein anderes Design
Eine Nachricht enthält Designkommentare oder der Benutzer bittet darum, sie anzuwenden	Folge dem Abschnitt „Canvas-Kommentare“ unten
/gentle:design sync oder der Benutzer bittet um Erfassung des Projekt-Designsystems	Folge dem Abschnitt „Designsystem-Synchronisation“ unten
Der Benutzer bittet um Anzeige, Stopp, Auflistung von Designs oder um Implementierung eines Artboards	Rufe das gentle_design-Werkzeug auf (open, stop, list oder implement mit <slug>/<artboard>); folge dem Übergabetext, den implement zurückgibt, und melde den Fortschritt mit action "handoff": status: "in_progress", wenn du beginnst, status: "implemented", wenn abgeschlossen, mit previewUrl gesetzt auf die Loopback-URL der laufenden App, falls eine läuft

Vor dem Entwerfen

Führe vor jedem neuen Auftrag diese Prüfung durch: Rufe das gentle_design-Werkzeug mit action: "list" auf, dann:

list meldet	Aktion
system.exists false und designSources vorhanden	Führe zuerst „Designsystem-Synchronisation“ durch, teile dem Benutzer in einem Satz mit, dass du das Projekt-Designsystem synchronisiert hast, und entwerfe dann damit
Keine designSources	Überspringe die Synchronisation und entwerfe frei
system.staleSources vorhanden	Nenne diese Quellen, sage, dass design/system.md möglicherweise veraltet ist, und biete eine erneute Synchronisation vor dem Entwerfen an; synchronisiere nur mit Zustimmung des Benutzers und verwende niemals stillschweigend veraltete Tokens

Ausführungsschritte

1. Nimm den Auftrag auf: Ziel, Layout, Inhalt, Zielgruppe.
2. Lade gentle-ui-design: lies dessen SKILL.md und nur die Referenzen, die mit der Zielgruppe, der primären Aufgabe und der Erfolgsbedingung des Auftrags übereinstimmen. Dieses Skill ist für die Auslieferung zuständig; jenes für die UX-Qualität.
3. Wähle einen Kebab-Case-Slug aus dem Auftrag.
4. Lasse die Richtungen sich in der Struktur oder visuellen Strategie unterscheiden, nicht nur in der Farbe. Beschrifte jede mit dem von ihr getroffenen Kompromiss.
5. Schreibe design/<slug>/NN-<name>.html pro Artboard (01-…, 02-…; Kebab-Case-Name).
6. Schreibe design/<slug>/design.json:

{
  "title": "Preisseite",
  "brief": "Preisseite für eine Notiz-App für Studierende",
  "feature": "odd/tasks/pricing-page.md",
  "artboards": [
    { "file": "01-comparison-table.html", "title": "Vergleichstabelle", "tradeoff": "Dicht und schnell erfassbar; schwächere emotionale Anziehung", "width": 1440, "height": 900 },
    { "file": "02-single-plan-hero.html", "title": "Einzelplan-Hero", "tradeoff": "Starke Fokussierung; versteckt Preisunterschiede", "width": 1440, "height": 900 }
  ]
}

7. Setze width/height auf den beabsichtigten Viewport des Artboards in CSS-Pixeln; halte das Manifest bei jeder Änderung mit den Dateien konsistent. Felder: title, brief, optional feature und artboards[] mit file, title, tradeoff, width, height.
8. ODD-Link: Wenn das Design von einer getrackten ODD-Funktion stammt (einer vorhandenen odd/tasks/<feature>.md für die aktuelle Arbeit), setze feature auf diesen Pfad und füge einen Eintrag im ## Log dieses Dokuments hinzu, der design/<slug>/ und seine Artboards nennt. Wenn ein Artboard dieses Designs zur Implementierung übergeben wird, nennt der Log-Eintrag auch das ausgewählte Artboard (das übergebene; list meldet es als Chosen) und dass die anderen Alternativen sind. Für kleine, nicht getrackte Arbeiten lasse feature weg und behandle das Design eigenständig; erstelle niemals ein Funktionsdokument nur um einen Link herzustellen.
9. UX-Selbstprüfung für jedes Artboard, das du abschließt: Prüfe es gegen die gentle-ui-design-Richtlinien für Komposition-und-Feedback (Hierarchie, Dichte, Feedback) und adaptive-Oberflächen (schmale Bildschirme, Eingabe-Zugriff, Zustände) und behebe jede Lücke, bevor du berichtest.
10. Nachdem du Artboards geschrieben oder geändert hast, rufe das gentle_design-Werkzeug mit action: "open" und dem Slug auf, es sei denn, der Benutzer hat dagegen gesagt. Wenn ein Canvas-Tab bereits geöffnet ist, aktualisiert er diesen Tab anstatt einen neuen zu öffnen, rufe es also nach jeder Änderung auf. Melde die URL, die es zurückgibt.

Designsystem-Synchronisation

1. Lese nur, und bearbeite niemals den Projekt-Quellcode. Quellen: CSS-Custom-Properties (:root, @theme, [data-theme]), die Tailwind-Konfiguration oder v4 @theme, Komponentenbibliotheks-Ordner, vorhandene Token-Dateien und die von ihnen deklarierten Schriftarten.
2. Schreibe design/system.md: Farben (Token-Name, Wert, Verwendung), Typografie, Abstände, Radien, Schatten und Komponentenregeln. Jeder Eintrag nennt seine Quelle path. Erfasse nur Werte, die in den Quellen gefunden wurden.
3. Schreibe design/system.html: ein eigenständiges Artboard, 1440 px breit, das diese Tokens (Farbmuster, Schriftgrößen, Abstände, Radien, Schatten) und die Kernkomponenten unter denselben Regeln ohne externe URLs darstellt. Der Canvas zeigt es als erstes Board jedes Designs.
4. Wenn keine Designquellen existieren, sage dies und schlage ein minimales Starter-System vor, das der Benutzer akzeptieren kann; präsentiere niemals erfundene Werte als Projekt-Tokens.
5. Selbstprüfung für jedes Artboard, das du abschließt, während design/system.md existiert: Liste die Farben und Schriftfamilien auf, die das Artboard verwendet, vergleiche sie mit den System-Tokens und behebe jede Abweichung, bevor du berichtest.

Canvas-Kommentare

Kommentare vom Canvas werden in design/<slug>/comments.json gespeichert; die Sitzung erhält sie auch als Nachrichten, die jede Kommentar-ID nennen.

1. Lese die offenen Kommentare mit dem gentle_design_comments-Werkzeug (action: "list", optional slug und file). Ohne das Werkzeug lies design/<slug>/comments.json und verwende die Einträge, deren status "open" ist.
2. Wende jeden Kommentar an, indem du nur das Artboard in seiner file bearbeitest; verwende selector und excerpt, um das Element zu finden. Wenn ein Kommentar einen screenshot hat, betrachte ihn zuerst: Er wird an die Kommentarnachricht angehängt, oder öffne design/<slug>/<screenshot> mit dem Lese-Werkzeug. Er zeigt, was der Benutzer gesehen hat, oft einen flüchtigen Animations- oder Übergangszustand, den das statische Artboard nicht zeigt.
3. Markiere jeden angewandten Kommentar als gelöst mit dem Werkzeug (action: "resolve", slug, ids). Ohne das Werkzeug setze seinen status auf "resolved" und resolvedAt auf die aktuelle ISO-Zeit, behalte jeden anderen Eintrag und jedes Feld unverändert. Lasse Kommentare, die du nicht angewandt hast, offen und erkläre warum.

Das Dateiformat für Agenten, die nur Dateizugriff haben:

{
  "version": 1,
  "comments": [
    { "id": "k3x9p2ab", "file": "02-bold.html", "selector": "body > header > h1", "excerpt": "Ship faster", "comment": "Make the headline shorter.", "createdAt": "2026-10-26T10:00:00.000Z", "status": "open", "sentAt": null, "resolvedAt": null },
    { "id": "m7q2w9cd", "file": "02-bold.html", "selector": "#cta", "excerpt": "Start", "comment": "The button jumps during the hover transition.", "screenshot": ".screenshots/m7q2w9cd.png", "createdAt": "2026-10-26T10:05:00.000Z", "status": "open", "sentAt": null, "resolvedAt": null }
  ]
}

screenshot ist optional: ein Pfad relativ zum Design-Ordner, unter .screenshots/, vorhanden nur, wenn der Benutzer ein Bild angehängt hat.

Lösche oder ordne Einträge niemals neu, und halte die Datei als gültiges JSON: Der Canvas weigert sich, eine Datei zu überschreiben, die er nicht parsen kann.

Ausgabevertrag

Gib zurück: den Slug, jede Artboard-Datei mit Titel und Kompromiss, welche Dateien in diesem Durchgang geändert wurden, welche Kommentar-IDs in diesem Durchgang gelöst wurden und etwaige offene Fragen. Gib die Canvas-URL aus Schritt 10 an oder erwähne, dass /gentle:design open <slug> den Canvas zeigt, wenn du ihn nicht geöffnet hast. Für eine Synchronisation gib die gelesenen Quellpfade, die Token-Anzahl pro Gruppe und ob das System ein vorgeschlagenes Starter-System ist, zurück; nach einer automatischen Synchronisation aus „Vor dem Entwerfen“ sage, dass sie ausgeführt wurde, und berichte auf dieselbe Weise.

Referenzen

• design/system.md im Projekt, falls vorhanden – die zu befolgenden Design-Tokens.
• gentle-ui-design-Skill – UX-Qualitätsrichtlinien, die mit jedem Artboard einhergehen.