Figma Make : 3 custom skills pour verrouiller un design system

Figma Make : le build livré hors charte

Le build présenté en revue était presque juste. C’est précisément ce qui le rendait dangereux. Les boutons affichaient un rayon de 12px dans un système verrouillé à 8px depuis la refonte de la marque. L’accent principal ressemblait à du #18C5DA : visuellement proche du #06B6D4 du client, mais un simple collage dans le sélecteur de couleurs de Figma révélait immédiatement l’écart. Au troisième écran, l’échelle typographique utilisait un corps de 18px là où le système en prévoit 16px.

Le prompt écrit ce matin-là n’avait rien de mauvais. Le problème venait de celui rédigé six prompts plus tôt. Figma Make conserve le contexte pendant une session, mais les règles du design system s’effacent à mesure que l’on s’éloigne du moment où elles ont été saisies. Quand vient le réglage de la troisième variante du hero, le modèle finit par improviser des tokens plausibles. Les notes de version de mai 2026 présentent justement les custom skills comme la réponse à ce manque : un jeu d’instructions empaqueté, appelable dans chaque prompt sans nouveau copier-coller. (Récapitulatif des notes de version Figma, mai 2026)

J’ai relancé le même brief dans Make après avoir créé le pack ci-dessous. Rayon des boutons : 8px. Accent : #06B6D4. Corps du texte : 16px. Le skill n’a pas rendu Make plus intelligent ; il a rendu les règles impossibles à oublier.

Le cahier des charges : ce que le design system client impose vraiment

Le système présenté ici appartient à un vrai client. En voici les tokens, anonymisés :

• Couleurs : arrière-plan #0A0E14, premier plan #E6EDF3, accent unique #06B6D4. Aucun accent secondaire. Aucun dégradé.
• Espacements : base de 8px. Échelle autorisée : 8 / 16 / 24 / 40. Aucune valeur intermédiaire ou extérieure.
• Échelle typographique : 14 / 16 / 20 / 32 / 48. Le corps est à 16. Jamais 18.
• Rayons : 8px sur chaque surface interactive. 0 sur les cartes. Sans exception.
• Bouton : un composant, trois états — par défaut, survol, désactivé. L’accent remplit l’état par défaut ; l’état désactivé utilise le premier plan avec une opacité de 30%.

Un prompt générique du type « respecte notre marque » échoue sur chacun de ces points, car les adjectifs laissent trop de latitude. « Froid, minimaliste, un seul accent » pourrait décrire un millier de systèmes. Le modèle n’a pas besoin du moodboard, mais du tableau. L’objectif est simple : chaque build Make destiné à ce client doit être validé par rapport à ce tableau, sans avoir à le ressaisir à chaque session.

Le pack de 3 skills : les vrais fichiers .md

Dans Figma Make, un custom skill est un simple fichier Markdown conforme à l’Agent Skills specification. La propriété name du frontmatter devient la commande slash. Les skills s’installent au niveau du compte, restent disponibles dans tous les fichiers Make dont vous êtes propriétaire et — point essentiel — doivent être autonomes : aucun dossier scripts/, references/ ou assets/. Tout ce que le modèle doit utiliser figure directement dans les instructions. (Custom skills pour Figma Make, aide de Figma)

Trois skills couvrent 90% de ce que je devais jusqu’ici copier-coller.

/follow-ds-guidelines

Le tableau de tokens brut, intégré aux instructions. Aucune interprétation, aucun adjectif.

---
name: follow-ds-guidelines
description: Enforce the client design system on every generated frame.
---

You are building inside a locked design system. Use these exact values.
Do not improvise alternates, do not interpolate, do not soften.

## Color
- background: #0A0E14
- foreground: #E6EDF3
- accent: #06B6D4 (single accent, no secondary)

## Spacing (8px base)
- allowed: 8, 16, 24, 40
- forbidden: any value not in the allowed list

## Type ramp
- 14 / 16 / 20 / 32 / 48
- body is 16. never 18.

## Radius
- interactive surfaces: 8
- cards: 0

## Button (one component, three states)
- default: fill #06B6D4, foreground #0A0E14
- hover: fill #06B6D4 at 90% opacity
- disabled: foreground #E6EDF3 at 30% opacity

If a request would produce a value outside this table, return the closest
allowed value and flag the substitution in a comment.

/design-crit

Le skill de revue. Make contrôle l’écran actif par rapport au tableau de tokens et renvoie une liste de réussites et d’échecs, avec chaque valeur fautive indiquée en hexadécimal ou en pixels.

---
name: design-crit
description: Audit the current frame against the client design system.
---

Walk the current frame top to bottom. For every visual element, check:
- color hex against the allowed palette
- spacing values against the 8 / 16 / 24 / 40 scale
- type size against the 14 / 16 / 20 / 32 / 48 ramp
- radius against 8 (interactive) or 0 (cards)

Return a table:
| Element | Property | Found | Expected | Pass/Fail |

End with a one-line verdict: PASS if all rows pass, FAIL otherwise.
Do not auto-fix. The human decides which deviations are intentional.

/insert-sample-data

Le skill de données d’exemple injecte des textes de remplacement validés par le client. Les builds de revue cessent ainsi d’embarquer du lorem ipsum ou des noms d’entreprise inventés par le modèle que l’équipe juridique signalera plus tard. (Récapitulatif des notes de version de mai 2026)

---
name: insert-sample-data
description: Replace placeholder text with approved sample data.
---

When asked for sample content, use only this set:

## Names
Sarah Chen, Marcus Okafor, Priya Raman, Diego Alvarez

## Company names (fictional, cleared)
Northwind Labs, Apex & Vine, Halcyon Group, Stratus Co

## Numbers
Use round numbers in product UI: 1,240 / 3,500 / 12,800.
Avoid revenue-shaped numbers unless asked.

Never use lorem ipsum. Never invent a real-sounding brand name not on this list.

Trois fichiers. Chacun remplace un élément que je recopiais auparavant.

Connecter Notion pour que le skill lise le design system à jour

La méthode des tokens statiques de /follow-ds-guidelines convient à un système figé. Dès qu’un client modifie un token — et cela arrivera — le tableau intégré devient obsolète. La solution consiste à associer le skill à un connecteur pour que Make récupère la source à jour. (Connecteurs dans Figma Make, aide de Figma)

Dans le fichier utilisé pour ce client, le design system tient sur une seule page Notion, structurée avec les mêmes rubriques que le skill (Color, Spacing, Type ramp, Radius, Button). J’appelle le skill et le connecteur dans le même prompt.

Use the /follow-ds-guidelines skill, but pull the current token values
from @Notion "Halcyon – Design System v3" and override the inline table
where they differ. Then build the pricing section per the attached spec.

Le même prompt peut récupérer un PRD dans Drive selon le même principe — @Drive "Halcyon pricing PRD" — puis Make rassemble en une seule fois le contexte du design system et celui des spécifications. (Récapitulatif des notes de version de mai 2026)

Mon arbitrage dépend de chaque client : tokens intégrés pour les systèmes qui n’ont pas bougé depuis un trimestre, alimentation par connecteur pour ceux qui évoluent encore. Le fichier .md du skill reste le même dans les deux cas ; seul le prompt change. C’est volontaire. Je ne veux pas multiplier les skills par client, mais disposer d’un seul skill qui sait accepter des valeurs prioritaires.

À noter : le skill /prototype-to-figma du serveur MCP de Figma appartient à une autre couche. Il est préinstallé pour les allers-retours du code vers le canvas, et vous ne l’écrivez pas. Les custom skills de Make suivent la logique inverse : vous les rédigez, ils vivent dans Make et ne touchent pas à la couche MCP.

Ce qui coince : non-déterminisme et coût du partage

L’annonce a passé trois points sous silence.

La compatibilité avec les modèles est plus limitée que ne le suggère la documentation. À l’heure actuelle, les custom skills ne fonctionnent qu’avec le modèle par défaut de Figma Make et Claude Opus 4.7. Si votre équipe a standardisé un autre modèle dans Make, le skill ne s’applique pas et aucune erreur claire ne s’affiche : les règles cessent simplement d’être respectées. (Custom skills pour Figma Make, aide de Figma) Sur un build d’équipe, c’est le premier point que je vérifie avant de chercher « pourquoi ce rayon est encore incorrect ».

Les résultats sont cohérents « très souvent », pas identiques. C’est la formulation même de la documentation de Figma. Le modèle étant non déterministe, /design-crit peut parfois rater un écart dans un écran complexe ou signaler comme anomalie un choix volontaire. (Custom skills pour Figma Make, aide de Figma) Pour moi, ce skill fournit une première passe rapide, jamais une validation finale.

Le coût du partage est le vrai problème opérationnel. Aujourd’hui, les custom skills sont liés à chaque compte. Pour transmettre le pack à un collègue, il faut exporter les fichiers .md, puis lui demander de les importer dans son propre compte. Il n’existe pas de publication à l’échelle de l’organisation. (Custom skills pour Figma Make, aide de Figma) Pour un studio qui gère plusieurs systèmes clients, la friction est bien réelle : chaque nouvelle recrue implique une installation manuelle de chaque skill actif, et chaque mise à jour exige un nouvel export. La parade est peu spectaculaire, mais efficace : versionner les fichiers .md dans le dépôt du client — les nôtres côtoient les design tokens dans le même monorepo — et taguer les releases. L’import dispose alors d’une source de vérité au lieu de dépendre d’un message Slack.

Pour les designers qui travaillent sur des plateformes facturant ce type de coût par siège, le sujet relève directement des opérations du studio. C’est aussi la raison pour laquelle j’ai détaillé le calcul du tarif de l’offre premium de Webflow : les outils facturent la surface visible, tandis que vous assumez la friction d’intégration cachée.

En pratique : ce qui relève d’un skill et ce qui reste humain

Après quelques semaines d’utilisation chez DVNC.studio, ma règle est simple : tout ce que j’ai dû ressaisir plus de deux fois finit dans un skill. Les tableaux de tokens, les checklists de revue, les conventions de données d’exemple, le modèle standard des annotations d’accessibilité. Rien de tout cela n’est créatif. Tout cela représentait une taxe.

La décision, elle, reste humaine. /design-crit signale une valeur hors système ; il ne peut pas décider s’il s’agit d’une erreur ou d’une exception volontaire pour une page marketing unique. Le skill sait dire « ce rayon vaut 12, la valeur attendue est 8 ». Il ne sait pas conclure « ce rayon vaut 12 parce que le concept de campagne exigeait une carte plus douce et que nous l’avons validé mardi ». C’est précisément là que se trouve le travail.

Dès mardi prochain, prenez le système client que vous utilisez le plus. Ouvrez un fichier .md. Collez-y le tableau de tokens comme je l’ai fait ci-dessus pour Halcyon. Enregistrez-le sous follow-ds-guidelines.md, importez-le comme custom skill, lancez un vrai build, puis exécutez /design-crit sur le résultat et comparez-le manuellement au tableau. Si le skill repère ce que vous auriez repéré, vous venez de supprimer une heure de reformulation de prompts par client et par semaine. S’il manque une anomalie évidente, la correction se trouve dans le fichier .md, pas dans l’historique de vos prompts.