Conception Graphique Gentle (gentle-design)

Contrat d'activation

Utilisez cette compétence par défaut chaque fois que l'utilisateur demande, en langage clair, une conception d'interface utilisateur (UI), une maquette, un écran, une page d'atterrissage ou des directions visuelles, ou qu'il itère sur des planches de travail sous design/. Ne l'utilisez pas pour implémenter du code de production dans la stack du projet.

Les commandes /gentle:design sont des raccourcis facultatifs : chaque action fonctionne également à partir d'une demande simple, via cette compétence et l'outil gentle_design (list, open, stop, implement, handoff).

Règles strictes

• Chaque planche de travail est un fichier HTML autonome : CSS, JS et SVG inline ; uniquement des piles de polices système. Ne référencez jamais d'URL externes, de CDN, de polices distantes, d'images ou de scripts.
• Utilisez un contenu réaliste pour le public cible ; pas de lorem ipsum ou de noms de substitution.
• Balisage accessible : éléments sémantiques et points de repère, contraste WCAG AA, styles de focus visibles, prefers-reduced-motion respecté pour tout mouvement.
• Lorsque design/system.md existe, lisez-le d'abord et utilisez uniquement ses jetons et ses règles de composants ; exécutez l'auto-vérification issue de "Synchronisation du système de design" avant de terminer toute planche de travail.
• Posez au plus une question de clarification, et seulement lorsque le brief manque d'objectif ou de contenu.
• L'itération ne modifie que la planche de travail ciblée. Ne réécrivez jamais les autres.

Portes de décision

Situation	Action
Nouveau brief	Écrivez N directions clairement différentes (3 par défaut, ou le nombre demandé) dans un nouveau dossier design/<slug>/
Retour sur une planche de travail	Modifiez ce fichier uniquement ; conservez son entrée dans le manifeste, mettez à jour tradeoff si elle a changé
"Enregistrer et essayer une approche différente"	Ajoutez une nouvelle planche de travail avec le NN suivant ; conservez les précédentes ; ajoutez-la au manifeste
L'utilisateur souhaite ajuster les valeurs (espacement, couleur, échelle typographique)	Ajoutez des curseurs ou des contrôles dans la planche de travail ainsi qu'un bouton "Copier comme prompt" qui copie les valeurs choisies sous forme de prompt
design/<slug>/ existe déjà pour un nouveau brief	Choisissez un nouveau slug ; n'écrasez jamais une autre conception
Un message contient des commentaires de conception, ou l'utilisateur demande de les appliquer	Suivez "Commentaires sur le canevas" ci-dessous
/gentle:design sync, ou l'utilisateur demande de capturer le système de design du projet	Suivez "Synchronisation du système de design" ci-dessous
L'utilisateur demande d'afficher, d'arrêter ou de lister les conceptions, ou d'implémenter une planche de travail	Appelez l'outil gentle_design (open, stop, list, ou implement avec <slug>/<artboard>) ; suivez le texte de transmission que implement retourne, et rapportez la progression avec action "handoff" : status: "in_progress" quand vous commencez, status: "implemented" quand c'est fait, avec previewUrl défini sur l'URL de bouclage de l'application en cours d'exécution lorsqu'elle est active

Avant de concevoir

Exécutez cette porte avant chaque nouveau brief : appelez l'outil gentle_design avec action: "list", puis :

list rapporte	Action
system.exists false et designSources présent	Exécutez d'abord "Synchronisation du système de design", dites à l'utilisateur en une ligne que vous avez synchronisé le système de design du projet, puis concevez avec celui-ci
Pas de designSources	Ignorez la synchronisation et concevez librement
system.staleSources présent	Nommez ces sources, dites que design/system.md est peut-être obsolète et proposez de synchroniser à nouveau avant de concevoir ; ne resynchronisez qu'avec l'accord de l'utilisateur, et n'utilisez jamais les jetons obsolètes en silence

Étapes d'exécution

1. Prenez le brief : objectif, mise en page, contenu, public cible.
2. Chargez gentle-ui-design : lisez son SKILL.md et uniquement les références qui correspondent au public cible, au travail principal et à la condition de succès du brief. Cette compétence assure la livraison ; la compétence gentle-ui-design assure la qualité UX.
3. Choisissez un slug en kebab-case à partir du brief.
4. Faites en sorte que les directions diffèrent par la structure ou la stratégie visuelle, pas seulement par la couleur. Étiquetez chacune avec le compromis qu'elle fait.
5. Écrivez design/<slug>/NN-<name>.html par planche de travail (01-…, 02-… ; nom en kebab-case).
6. Écrivez design/<slug>/design.json :

{
  "title": "Page de tarifs",
  "brief": "Page de tarifs pour une application de prise de notes destinée aux étudiants",
  "feature": "odd/tasks/pricing-page.md",
  "artboards": [
    { "file": "01-comparison-table.html", "title": "Tableau comparatif", "tradeoff": "Dense et scrutable ; attrait émotionnel plus faible", "width": 1440, "height": 900 },
    { "file": "02-single-plan-hero.html", "title": "Héros plan unique", "tradeoff": "Forte concentration ; masque les différences entre les plans", "width": 1440, "height": 900 }
  ]
}

7. Définissez width/height comme la fenêtre d'affichage prévue de la planche de travail en pixels CSS ; maintenez le manifeste synchronisé avec les fichiers à chaque modification. Champs : title, brief, feature optionnel, et artboards[] avec file, title, tradeoff, width, height.
8. Lien ODD : lorsque la conception provient d'une fonctionnalité ODD suivie (un odd/tasks/<feature>.md existant pour le travail en cours), définissez feature sur ce chemin et ajoutez une entrée à la ## Log de ce document en nommant design/<slug>/ et ses planches de travail. Lorsqu'une planche de travail de cette conception est transmise pour implémentation, l'entrée du journal nomme également la planche de travail choisie (celle transmise ; list la rapporte comme Chosen) et que les autres sont des alternatives. Pour un petit travail non suivi, omettez feature et laissez la conception autonome ; ne créez jamais un document de fonctionnalité juste pour la lier.
9. Auto-vérification UX, pour chaque planche de travail que vous terminez : évaluez-la par rapport aux directives de composition-et-feedback (hiérarchie, densité, feedback) et d'interfaces-adaptatives (écrans étroits, accès aux entrées, états) de gentle-ui-design, et corrigez chaque écart avant de faire votre rapport.
10. Après avoir écrit ou modifié des planches de travail, appelez l'outil gentle_design avec action: "open" et le slug, sauf si l'utilisateur a dit de ne pas le faire. Lorsqu'un onglet du canevas est déjà ouvert, il rafraîchit cet onglet au lieu d'en ouvrir un nouveau, donc appelez-le après chaque modification. Rapportez l'URL qu'il retourne.

Synchronisation du système de design

1. Lisez uniquement, et ne modifiez jamais le code source du projet. Sources : propriétés personnalisées CSS (:root, @theme, [data-theme]), la configuration Tailwind ou @theme v4, les dossiers de bibliothèques de composants, les fichiers de jetons existants et les polices qu'ils déclarent.
2. Écrivez design/system.md : couleurs (nom du jeton, valeur, utilisation), typographie, espacement, rayon, ombres et règles de composants. Chaque entrée nomme sa source path. Enregistrez uniquement les valeurs trouvées dans les sources.
3. Écrivez design/system.html : une planche de travail autonome, large de 1440 px, qui rend ces jetons (échantillons, échelle typographique, espacement, rayon, ombres) et les composants principaux, sous les mêmes règles de non-URL externes. Le canevas l'affiche comme la première planche de chaque conception.
4. Lorsqu'aucune source de design n'existe, dites-le et proposez un système de démarrage minimal à l'utilisateur pour qu'il l'accepte ; ne présentez jamais de valeurs inventées comme des jetons du projet.
5. Auto-vérification, pour chaque planche de travail que vous terminez alors que design/system.md existe : listez les couleurs et les familles de polices que la planche de travail utilise, comparez-les avec les jetons du système, et corrigez chaque écart avant de faire votre rapport.

Commentaires sur le canevas

Les commentaires du canevas sont stockés dans design/<slug>/comments.json ; la session les reçoit également sous forme de messages qui nomment chaque identifiant de commentaire.

1. Lisez les commentaires ouverts avec l'outil gentle_design_comments (action: "list", slug et file optionnels). Sans l'outil, lisez design/<slug>/comments.json et utilisez les entrées dont status est "open".
2. Appliquez chaque commentaire en modifiant uniquement la planche de travail dans son file ; utilisez selector et excerpt pour trouver l'élément. Lorsqu'un commentaire a une screenshot, regardez-la d'abord : elle arrive jointe au message du commentaire, ou ouvrez design/<slug>/<screenshot> avec l'outil de lecture. Elle montre ce que l'utilisateur a vu, souvent un état d'animation ou de transition transitoire que la planche de travail statique n'affiche pas.
3. Marquez chaque commentaire appliqué comme résolu avec l'outil (action: "resolve", slug, ids). Sans l'outil, définissez son status sur "resolved" et resolvedAt sur l'heure ISO actuelle, en conservant toutes les autres entrées et champs tels quels. Laissez ouverts les commentaires que vous n'avez pas appliqués, et dites pourquoi.

Le format du fichier, pour les agents qui n'ont qu'un accès fichier :

{
  "version": 1,
  "comments": [
    { "id": "k3x9p2ab", "file": "02-bold.html", "selector": "body > header > h1", "excerpt": "Livrer plus vite", "comment": "Raccourcissez le titre.", "createdAt": "2026-10-26T10:00:00.000Z", "status": "open", "sentAt": null, "resolvedAt": null },
    { "id": "m7q2w9cd", "file": "02-bold.html", "selector": "#cta", "excerpt": "Démarrer", "comment": "Le bouton saute pendant la transition au survol.", "screenshot": ".screenshots/m7q2w9cd.png", "createdAt": "2026-10-26T10:05:00.000Z", "status": "open", "sentAt": null, "resolvedAt": null }
  ]
}

screenshot est optionnel : un chemin relatif au dossier de conception, sous .screenshots/, présent uniquement lorsque l'utilisateur a joint une image.

Ne supprimez jamais et ne réordonnez jamais les entrées, et conservez le fichier en JSON valide : le canevas refuse d'écraser un fichier qu'il ne peut pas analyser.

Contrat de sortie

Retournez : le slug, chaque fichier de planche de travail avec son titre et son compromis, les fichiers modifiés lors de ce tour, les identifiants de commentaires résolus lors de ce tour, et toute question ouverte. Donnez l'URL du canevas issue de l'étape 10, ou mentionnez que /gentle:design open <slug> affiche le canevas lorsque vous ne l'avez pas ouvert. Pour une synchronisation, retournez les chemins sources lus, le nombre de jetons par groupe, et si le système est un système de démarrage proposé ; après une synchronisation automatique issue de "Avant de concevoir", dites qu'elle a été effectuée et rapportez-la de la même manière.

Références

• design/system.md dans le projet, lorsqu'il est présent — les jetons de design à suivre.
• Compétence gentle-ui-design — directives de qualité UX associées à chaque planche de travail.