ui-design-system-builder

Création de design systems cohérents avec tokens, composants et guidelines. Se déclenche avec "design system", "composants UI", "tokens", "style guide", "atomic design", "Figma components", "UI library", "thème", "design tokens". Also triggers on "component library".

仓库: khalilbenaz/claude-skills-collection
最近来源活动: 2026年8月6日 22:12
检测到的 SKILL.md 语言: 法语
星标: 21
分支: 6

安装方式

默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。

检查来源文件

决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。

返回搜索返回安装

name	ui-design-system-builder
description	Création de design systems cohérents avec tokens, composants et guidelines. Se déclenche avec "design system", "composants UI", "tokens", "style guide", "atomic design", "Figma components", "UI library", "thème", "design tokens". Also triggers on "component library".

UI Design System Builder

Étapes du workflow

1. Audit de l'existant

Avant de créer quoi que ce soit, inventorier :

- Compter les valeurs de couleur uniques dans le CSS (grep -r "color:" src/ | sort -u)
- Lister les font-size utilisées
- Identifier les composants Button/Card/Modal dupliqués entre équipes
- Mesurer l'écart design (Figma) ↔ implémentation (DOM)

Critère de go/no-go : si > 5 composants identiques avec des styles différents coexistent → design system prioritaire. Sinon, un simple tokens file suffit peut-être.

2. Design Tokens — single source of truth

Définir les tokens en JSON (style-dictionary) ou en CSS custom properties.

Structure recommandée (style-dictionary 4.x) :

{
  "color": {
    "brand": { "primary": { "value": "#1A73E8" } },
    "neutral": {

npx style-dictionary build --config sd.config.json

# Vérification rapide
npx @adobe/leonardo-contrast-colors --bg "#FFFFFF" --fg "#1A73E8"

// Variants: primary | secondary | ghost | destructive
// Sizes: sm | md | lg
// States: default | hover | active | disabled | loading

interface ButtonProps {
  variant?: 'primary' | 'secondary' | 'ghost' | 'destructive';
  size?: 'sm' | 'md' | 'lg';
  loading?: boolean;
  disabled?: boolean;
  leftIcon?: React.ReactNode;
  onClick?: () => void;
  children: React.ReactNode;
}

npx storybook@latest init
# stories colocalisées : Button.stories.tsx à côté de Button.tsx

export default {
  title: 'Atoms/Button',
  component: Button,
  argTypes: { variant: { control: 'select' } },
};

export const AllVariants = () => (
  <div style={{ display: 'flex', gap: '8px' }}>
    {['primary','secondary','ghost','destructive'].map(v => (
      <Button key={v} variant={v as any}>{v}</Button>
    ))}
  </div>
);

// tailwind.config.js
module.exports = {
  theme: {
    colors: require('./tokens/colors.json'),
    spacing: require('./tokens/spacing.json'),
    borderRadius: require('./tokens/radius.json'),
  },
};

:root {
  --color-primary:   #1A73E8;
  --spacing-md:      16px;
  --radius-md:       8px;
  --font-size-base:  1rem;
}

# Semantic versioning : MAJOR.MINOR.PATCH
# MAJOR = breaking change (renommage token, suppression composant)
# MINOR = nouveau composant ou token
# PATCH = bug visuel, ajustement d'état

npm version minor -m "feat(button): add loading state"

Anti-pattern	Conséquence	Correctif
Valeurs en dur (`color: #1A73E8` dans un composant)	Impossible de theming	Toujours passer par un token
Trop de variants dès le début	Complexity overhead	Commencer avec 3 variants max, ajouter sur usage réel
Composants trop couplés (Card qui contient une Table)	Impossible à réutiliser	Composer via props/slots
Aucun test d'accessibilité	Non-conformité WCAG	Ajouter axe-core dans les tests CI
Design tokens sans owner	Dérive silencieuse	Désigner un DX/Design Lead responsable
Dark mode ajouté après coup	Refactoring massif	Planifier les alias sémantiques dès le départ
Storybook non maintenu	Décalage doc ↔ réalité	PR bloquante si story manquante