Identity Forge vs getdesign.md

Les deux produits installent un DESIGN.md. La question essentielle est de savoir ce qui else arrive dans le dépôt, car un brief de design ne représente qu'une moitié d'un design system, les tokens constituant l'autre.

Les deuxième et troisième lignes déterminent ce qui se passe réellement dans votre codebase. Si les valeurs de couleur n'existent que dans un fichier Markdown, l'agent les lit puis les écrit dans les composants sous forme de valeurs littérales, car il n'a aucune autre référence. Vous vous retrouvez avec un design documenté mais une feuille de style non documentée, situation précisément ce que les design tokens sémantiques permettent d'éviter.

Ceci n'est pas une critique du format, mais une conséquence de la nature d'une entrée de catalogue. Une analyse du produit d'un tiers ne peut pas vous fournir son fichier de tokens, puisqu'elle ne le possède pas.

Les entrées de getdesign.md sont des analyses de patterns observables publiquement, et ses pages de marque le précisent explicitement via des avis de non-affiliation. Ce cadre est correct et doit être pris au pied de la lettre. La question intéressante est de savoir ce qui survit à cette dérivation.

La troisième ligne est la plus importante, et elle s'applique à tout brief dérivé, quel que soit son auteur. Nous avons analysé 299 fichiers DESIGN.md publiés et avons constaté que 76 % ne contiennent aucune interdiction de quelque nature que ce soit : parallèlement, 86 % spécifient les couleurs en hexadécimal brut sans rôle sémantique et 57 % ne mentionnent aucun motif distinctif. Les interdictions sont le lieu où réside réellement l'identité d'un design, et c'est précisément ce à quoi une analyse externe a le moins accès.

C'est là la limite honnête de la copie de l'apparence d'un produit admiré, et nous l'abordons longuement dans l'analyse de Linear : la palette est la partie la moins distinctive du système, et les contraintes qui le font fonctionner sont celles qui ne survivent pas à l'extraction.

Voici ce que signifie concrètement « générer un système complet » : le kit gratuit ambient-sage, rendu à partir de ses véritables tokens et polices, soit la même charge utile que le CLI écrit dans votre repo :

npx shadcn add https://identityforge.io/r/ambient-sage.json

Après cette commande, votre fichier globals.css contient 28 rôles nommés en modes clair et sombre, et le DESIGN.md y fait référence par leur nom plutôt que de répéter les valeurs hexadécimales. C'est ce couplage qui garantit la fidélité du brief : modifiez un token et le brief reste exact, car il n'en contenait jamais de copie.

• Choisissez getdesign.md si vous souhaitez étudier la rédaction des fichiers DESIGN.md à travers de nombreux produits, ou si vous voulez spécifiquement un brief dérivé d'un design que vous admirez et que vous êtes prêt à fournir vous-même la couche de tokens.
• Choisissez Identity Forge si vous voulez un système original installé sous forme de tokens fonctionnels accompagnés d'un brief correspondant, avec une livraison via MCP, CLI et shadcn, ainsi que des exports pour n'importe quelle stack.
• Ils ne s'excluent pas. Consulter les entrées du catalogue est un excellent moyen de calibrer le niveau de précision d'un brief. Gardez simplement à l'esprit qu'un brief sans tokens laisse la feuille de style inchangée ; associez-le donc systématiquement à une véritable couche de tokens.

Nouveau avec ce format ? Commencez par ce qu'est un DESIGN.md et comment en générer un, puis choisissez votre outil dans le guide pilier.