31 skills, 72 systems : comment fonctionne la bibliothèque Open Design

Open Design, mécaniquement, ce sont quatre primitives empilées les unes sur les autres :

1. Skills — ce que l'agent doit faire
2. Systems — à quoi la sortie doit ressembler
3. Adaptateurs — quel agent effectue le travail
4. Le daemon — la boucle qui les relie ensemble

Chaque primitive est un dossier de fichiers. Aucune ne nécessite de base de données, d'environnement d'exécution de plugins ou de service hébergé. C'est toute la bibliothèque — il n'y a pas de cinquième concept caché derrière un mur de connexion. Cet article parcourt chacune tour à tour et montre ce qui se passe lorsque vous pointez votre agent vers un vrai brief. Si vous voulez l'argument expliquant pourquoi nous l'avons façonné ainsi avant le comment, commencez par pourquoi nous avons conçu Open Design comme une couche de skills, pas un produit.

Skills : l'unité de capacité

Un skill est un dossier contenant un SKILL.md et zéro ou plusieurs fichiers de support. Le fichier Markdown est le contrat de l'agent — tout le reste du dossier est là pour aider l'agent à l'honorer.

Anatomie d'un dossier de skill

Un skill typique ressemble à ceci :

skills/
  guizang-ppt/
    SKILL.md
    templates/
      magazine.html
    examples/
      product-launch.html
      pitch-deck.html

SKILL.md déclare le nom du skill, les conditions de déclenchement, la forme de l'entrée, la forme de la sortie et toute consigne en ligne pour l'agent. Les dossiers templates/ et examples/ sont optionnels mais portent beaucoup de poids : les exemples sont des artefacts reconnus comme bons sur lesquels l'agent peut s'aligner, ce qui fait la différence entre « fais-moi un deck » qui produit quelque chose de cohérent et quelque chose d'improvisé.

Le front matter est la partie que le daemon lit pour enregistrer le skill ; le corps est la partie que l'agent lit pour l'exécuter :

---
name: guizang-ppt
trigger: a deck, slide presentation, or pitch
output: HTML (exportable to PDF, PPTX)
---

Build a horizontal slide deck. One idea per slide.
Lead with a cover, close with a call to action.
Respect the locked-in design system for color, type, and spacing.
Pattern-match against examples/ for layout density and rhythm.

Pourquoi le fichier est le registre

Au démarrage du daemon, celui-ci scanne skills/ et enregistre chaque dossier contenant un SKILL.md. Il n'y a aucun manifeste de plugin. Il n'y a aucun champ de version. Il n'y a aucune étape d'upload, aucune file de revue, aucun build. Il y a le fichier, et le fichier est la source de vérité. Déposez un nouveau dossier, redémarrez le daemon, et le skill apparaît dans le sélecteur. Supprimez-le, et il disparaît — aucune entrée de registre orpheline pointant vers du code qui n'existe plus.

Nous livrons actuellement 31 skills. Certains sont des générateurs de decks, certains produisent des maquettes mobiles, certains construisent des pages éditoriales, certains rédigent des documents bureautiques (Word, Excel, PowerPoint). Chacun est un dossier que vous pouvez forker, éditer ou remplacer. Parce que le contrat est en texte brut, « écrire un skill » et « lire un skill pour comprendre ce qu'il fait » sont la même activité — vous l'auditez en l'ouvrant.

Systems : l'unité de goût

Si un skill décrit ce qu'il faut faire, un system décrit à quoi cela doit ressembler. Un system est un fichier DESIGN.md plus des actifs de référence optionnels. Il décrit une identité visuelle sous forme lisible par machine :

• Couleur — valeurs OKLch pour le premier plan, l'arrière-plan, l'accent, l'erreur, etc.
• Typographie — pile de polices, graisses, l'échelle typographique, conventions d'interlignage
• Espace — unité de base, échelle d'espacement, largeurs de conteneur, règles de gouttière
• Posture de mise en page — choix de grille, règles d'asymétrie, préférences de densité
• Voix — typographie des mots : ton, vocabulaire, rythme des phrases

Un DESIGN.md est un contrat, pas une bibliothèque de composants

En pratique, un DESIGN.md se lit comme un brief de marque court et affirmé qu'un agent ne peut pas mal interpréter :

## Color
--bg: oklch(98% 0.01 95);
--ink: oklch(20% 0.02 260);
--accent: oklch(72% 0.19 35);

## Type
Display — Albert Sans, 600, -0.02em
Body — Albert Sans, 400, 1.7 line-height

## Posture
Generous whitespace. One accent, used sparingly. No drop shadows.

Les couleurs sont en OKLch afin qu'elles restent perceptuellement homogènes sur les surfaces claires et sombres ; l'échelle typographique est une échelle dont l'agent ne déviera pas ; les règles de posture font la différence entre dix écrans générés qui donnent l'impression d'un seul produit et dix qui donnent l'impression de dix stagiaires différents. L'agent lit ceci une fois et le respecte pour tout le travail.

Un system n'est pas une bibliothèque Figma. Il n'y a pas de composants, pas de variantes, pas d'instances imbriquées, pas de format binaire entre vous et les règles. C'est un contrat que n'importe quel agent peut lire et que n'importe quel humain peut auditer. Nous livrons 72 systems prêts à l'emploi, dont des versions portables de Linear, Vercel, Stripe, Apple, Cursor, Figma, et une longue traîne de systems éditoriaux et de marque.

Mélanger, forker, posséder

Parce qu'un system n'est que du texte, vous pouvez en forker un et l'éditer sur place, livrer une variante, ou écrire le vôtre de zéro en environ 30 minutes de travail concentré. Vous pouvez même mélanger des systems en cours de projet — la typographie de Linear, la logique de couleur de Vercel, la mise en page d'une spécification interne — parce que rien n'est enfermé dans un binaire propriétaire. La séparation entre les dossiers skills/ et design-systems/ est délibérée : capacité et goût sont orthogonaux, donc n'importe quel skill peut s'exécuter sous n'importe quel system, et n'importe quel system peut piloter n'importe quel skill.

Adaptateurs : l'unité d'agent

Les skills et les systems sont du texte inerte. Les adaptateurs sont la petite quantité de code qui les relie à l'agent qui effectue réellement le travail. Un adaptateur est un court fichier TypeScript dans adapters/ qui sait comment :

• détecter si l'agent est installé sur le $PATH de l'utilisateur
• démarrer une session avec cet agent
• y acheminer une invocation de skill
• récupérer la sortie

Nous livrons aujourd'hui des adaptateurs pour 12 agents : Claude, Codex, Gemini, Cursor, Copilot, OpenCode, Devin, Hermes, Pi, Kimi, Kiro, Qwen. Le daemon détecte automatiquement ceux qui sont présents et les propose dans un menu déroulant au premier démarrage — vous ne configurez rien, vous voyez simplement les agents que vous avez déjà.

Primitive	Réside dans	Fichier	Source de vérité
Skill	skills/	SKILL.md	le fichier sur le disque
System	design-systems/	DESIGN.md	le fichier sur le disque
Adaptateur	adapters/	un fichier .ts	un appel register()

Si vous voulez ajouter un nouvel adaptateur, le fichier fait environ 80 lignes de TypeScript et un seul appel register(). Aucun SDK à apprendre, aucune permission à demander, aucun registre central où publier. Le même agent auquel vous faites déjà confiance sur votre ordinateur portable devient le moteur — Open Design ne le remplace jamais. (Le pendant Workflow de design BYOK explique comment pointer un adaptateur vers votre propre clé.)

Le daemon : la boucle qui relie le tout

Le daemon est le seul processus en cours d'exécution dans le système. C'est un petit processus Node que vous démarrez avec pnpm tools-dev, et il fait quatre choses en séquence :

1. Détecter — scanne $PATH à la recherche d'agents installés et skills/ à la recherche de skills installés, au démarrage
2. Découvrir — ouvre un formulaire de questions interactif pour préciser la surface, le public, le ton, l'échelle et le contexte de marque du brief en cours
3. Diriger — présente 5 directions visuelles déterministes (palette en OKLch, pile de polices, indices de posture de mise en page) et demande à l'utilisateur d'en choisir une
4. Livrer — invoque le skill sélectionné avec le system verrouillé, laisse l'agent écrire sur le disque et prévisualise la sortie dans une iframe en bac à sable

Toute la boucle tient en environ 1500 lignes de code. Elle est intentionnellement petite. L'intelligence est dans les skills, pas dans l'environnement d'exécution — le travail du daemon consiste à scanner des dossiers, acheminer un brief à travers les quatre étapes et rester à l'écart. Cette petitesse est l'enjeu : il y a très peu de choses ici qui peuvent pourrir, et presque rien qui puisse prendre votre travail en otage.

Ce que cela donne en pratique

Supposons que vous vouliez un deck de lancement pour une nouvelle fonctionnalité de produit. Voici le déroulé :

1. Vous lancez pnpm tools-dev dans un terminal. Le daemon démarre sur localhost:7780.
2. Vous ouvrez l'URL. Le daemon vous montre les agents qu'il a trouvés (p. ex. Claude, Cursor, Codex).
3. Vous choisissez guizang-ppt dans la liste des skills.
4. Un formulaire de questions de 30 secondes apparaît : qui est le public, quel est le ton, quel est le contexte de marque.
5. On vous montre 5 directions visuelles — différentes palettes, associations typographiques, postures de mise en page. Vous en choisissez une.
6. L'agent écrit sur le disque. Une iframe en bac à sable montre le résultat. Vous pouvez exporter en HTML, PDF, PPTX, ZIP ou Markdown.

Retracez-le à travers les primitives et le tout devient lisible : l'étape 3 a choisi un skill, l'étape 5 a verrouillé un system, l'agent derrière est passé par un adaptateur, et le daemon a exécuté la boucle en quatre étapes. La sortie est réelle. Les fichiers sont les vôtres. Vous pouvez les éditer dans n'importe quel éditeur, les confier à un designer, ou les réinjecter dans un autre skill.

Pourquoi des fichiers, et non une base de données

Chaque primitive — skills, systems, adaptateurs — est un dossier de fichiers texte. Il n'y a aucune base de données centrale. Il n'y a aucun « compte Open Design ». Il n'y a aucun service hébergé qui doive continuer à fonctionner pour que votre travail continue de fonctionner.

C'est un compromis délibéré. Nous renonçons à la capacité de faire des analyses transversales astucieuses entre utilisateurs, de la mémoire inter-projets ou de la collaboration hébergée. En échange nous obtenons : la portabilité, la longévité, l'auditabilité, et la possibilité pour quiconque de forker toute la bibliothèque et de livrer sa propre variante. Un SKILL.md écrit aujourd'hui se lira à l'identique pour un agent dans deux ans et pour un humain sans aucun outillage — on ne peut pas en dire autant d'un plugin épinglé à l'API de l'an dernier.

Si vous avez vu une génération d'outils de design mourir en emportant vos fichiers avec eux, vous comprendrez pourquoi ce compromis en vaut la peine.

Lectures associées

• Pourquoi nous avons conçu Open Design comme une couche de skills, pas un produit — le pari derrière les quatre primitives
• Workflow de design BYOK : faites tourner Claude, Codex ou Qwen sur votre propre clé — comment les adaptateurs se connectent à l'agent que vous payez déjà
• La couche de mise en page que le canvas masquait — pourquoi les règles de posture dans un DESIGN.md valent mieux que de faire glisser des boîtes sur un canvas