Communitygithub.com

frogg435/frontend-design-styles

Implémentation et reproduction fidèle des langages de design d'interface (MIUIX/HyperOS, Apple HIG, Material Design 3, Fluent 2). Génération ou analyse de code frontend (HTML/CSS/JS, React, Vue, Tailwind, Compose/Kotlin) avec tokens de design sémantiques.

Qu'est-ce que frontend-design-styles ?

Cette compétence permet de reproduire fidèlement en code frontend l'un des quatre principaux langages de design d'interface : Xiaomi MIUIX/HyperOS, Apple HIG, Material Design 3 et Microsoft Fluent 2. Elle s'utilise lorsqu’un utilisateur demande un style spécifique pour une page ou un composant, ou pour comparer ces styles. Le processus repose sur une méthodologie en cinq étapes : identification du style, lecture des tokens sémantiques via des références dédiées, application des tokens (couleurs, typographie, espacement, coins arrondis, ombres, animations) sous forme de variables CSS, construction des composants selon un playbook, et enfin ajout des animations et validation automatique. La compétence génère du code exécutable (HTML/CSS/JS simple, ou avec React, Vue, Tailwind, Compose) et impose des règles strictes : pas de mélange de styles, pas de valeurs littérales dans le CSS, double thème clair/sombre, respect des contraintes d'accessibilité (contraste, focus, réduction de mouvement) et gestion spécifique de la typographie chinoise avec des polices de secours comme MiSans, PingFang ou Source Han Sans.

Compatible avec~Claude Code~Codex CLI~Cursor
Part ofDesign & UI
npx skills add frogg435/frontend-design-styles
Voir l'original→Voir toutes les compétences

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentation

Frontend Design Styles

Transposer fidèlement les quatre langages de design dominants dans du code frontend. Le cœur n'est pas de "faire ressemblant", mais d'assurer une cohérence à trois niveaux — tokens sémantiques + morphologie des composants + courbes d'animation — pour que le résultat soit immédiatement reconnaissable par les utilisateurs de la plateforme cible : "ça, c'est iOS / c'est Material / c'est Windows".

Quand l'utiliser / Ne pas l'utiliser

À utiliser : générer ou modifier une interface avec un style de design spécifique ; comparer les quatre styles ; produire des tokens de design et des fichiers de thème ; réaliser un audit visuel selon un langage de design.

Ne pas utiliser : l'utilisateur n'a pas de préférence de style, veut juste une "belle page" rapidement → demander d'abord s'il souhaite un style, ou suivre la logique de recommandation de references/style-router.md ; les tâches purement back-end / algorithmiques ne relèvent pas de cette compétence.

Aperçu rapide des quatre styles

Voici les caractéristiques les plus distinctives. Avant toute implémentation, consultez ce tableau, puis référez-vous aux documents dédiés pour les détails.

| | MIUIX / HyperOS | Apple HIG | Material Design 3 | Fluent 2 | |---|---|---|---| | Couleur principale | #3482FF (clair) / #277AF7 (sombre) | #007AFF / #0A84FF | Rôle, base #6750A4 | #0F6CBD | | Police | MiSans | SF Pro (<20pt Text, ≥20pt Display) | Roboto / Roboto Flex | Segoe UI Variable | | Taille de corps de texte | 16–17px | 17pt | 16sp (body-large) | 14px (body-1) | | Langage des coins arrondis | 16dp uniforme + squircle (même origine qu'iOS, pas de pilule pour les boutons) | Coins arrondis à courbure continue (squircle), conteneurs 10–20pt | 12dp pour les cartes / 28dp pour FAB & fenêtres modales / boutons ronds | Petits rayons, contrôles 4px, fenêtres modales 8px, imbrication −2px | | Technique de hiérarchie | Calques de niveaux de gris (#FFFFFF / #F7F7F7 / #E8E8E8), presque pas d'ombres fortes | Flou de matière (translucency) + listes groupées + contenu au-dessus de l'UI | Superposition tonale (tonal overlay) en priorité, ombres en second plan | Matière (Mica / Acrylic) + ombres multiples discrètes | | Animation | Légère, avec rebond élastique, 200–300ms | Physique à ressort, 200–300ms, pas de linear | Courbe accentuée cubic-bezier(0.2,0,0,1), gradation par durée token | Rapide et sobre, 150–250ms, easyEase | | Cible tactile/click | ≥ 48dp | ≥ 44×44pt | ≥ 48dp | Hauteur du contrôle 32px (mode compact/comfort) | | Ambiance en une phrase | Rond, transparent, technologie bleue | Sobriété, espace vide, contenu d'abord | Forte expression colorée, hiérarchie par tonalité | Productivité, clarté, natif bureau |

Flux de travail

Étape 1 · Définir le style. Utilisateur a spécifié → l'utiliser directement. Non spécifié → lire references/style-router.md, donner 1 recommandation + 1 alternative selon le type de produit/plateforme/densité, puis demander confirmation.

Étape 2 · Lire les tokens. Ouvrir le document de référence correspondant, lire intégralement couleurs, échelles typographiques, espacements, coins arrondis, ombres, animations avant d'écrire du code — ne pas se fier à sa mémoire :

  • MIUIX / HyperOS → references/miuix-hyperos.md
  • Apple HIG → references/apple-hig.md
  • Material Design 3 → references/material-design-3.md
  • Fluent 2 → references/fluent-2.md

Étape 3 · Appliquer les tokens. Copier directement assets/tokens/<style>.css comme couche de tokens sémantiques (déjà avec thèmes clair/sombre). Ne pas écrire de valeurs hexadécimales dans les styles de composants. Le mode sombre se bascule via [data-theme="dark"] ou prefers-color-scheme.

Étape 4 · Construire les composants. Suivre les spécifications du style dans references/components-playbook.md (variantes de boutons, champs de saisie, cartes, navigation, menus, interrupteurs, listes). Chaque état interactif (hover / focus / pressed / selected / disabled) doit être implémenté, pas seulement l'état par défaut.

Étape 5 · Ajouter animations + auto-vérification. Compléter les transitions selon references/motion-and-accessibility.md, puis exécuter python3 scripts/lint_tokens.py <fichier_produit> --style <style>, et enfin passer en revue la checklist (ci-dessous).

Règles absolues

  1. Ne pas mélanger les styles. Si Fluent est choisi, pas de #007AFF d'iOS, de FAB en pilule de Material ou de grandes cartes arrondies d'HyperOS. Le mélange est le mode d'échec le plus courant.
  2. Tokens d'abord. Dans le CSS des composants, seules les variables var(--xxx) sont autorisées — jamais de valeurs littérales pour couleurs, tailles de police ou rayons.
  3. Faire les deux thèmes clair et sombre ensemble. Les quatre systèmes ont des valeurs sombres officielles, à utiliser via les tables ; ne pas tricher avec filter: invert ou des assombrissements manuels.
  4. Les conventions de plateforme sont immuables. Par exemple : zone de clic minimale iOS 44pt, opacité des calques d'état Material, bordure de 1px en bas des contrôles Fluent, fond sombre HyperOS #242424 (pas un noir pur).
  5. L'accessibilité est un critère dur. Contraste du corps de texte ≥ 4.5:1, éléments d'UI ≥ 3:1, anneau de focus visible, respecter prefers-reduced-motion.
  6. La typographie chinoise doit être traitée à part. Roboto / Segoe UI / SF Pro n'ont pas de glyphes chinois complets ; les interfaces chinoises doivent utiliser des polices de secours comme PingFang, Source Han Sans ou MiSans, et réduire l'espacement entre lettres (letter-spacing latin ne convient pas au chinois).

Spécifications de livraison

  • Par défaut, produire un fichier HTML exécutable unique (<style> + <script> en ligne), les tokens organisés en variables CSS :root, pour prévisualisation et copie faciles.
  • Si l'utilisateur spécifie un framework, basculer selon les règles de references/framework-mappings.md : Taildown avec assets/mappings/tailwind.css ; React/Vue avec objet de tokens + variables CSS ; Compose en priorité avec les bibliothèques officielles (MiuixTheme pour MIUIX, MaterialTheme pour M3).
  • Pour une page de démonstration des composants, se référer à assets/templates/showcase.html (même jeu de composants présenté dans les quatre styles, avec bascule de thème et mode clair/sombre).
  • Validation obligatoire après production : exécuter python3 scripts/lint_tokens.py <fichier_produit> --style <style> ; les trois vérifications (valeurs de couleurs codées en dur / contraste / tokens essentiels) doivent passer, sinon corriger avant livraison.
  • À la livraison, préciser : quel système a été utilisé, les éventuelles déviations volontaires, comment basculer le mode sombre, et la pile de polices de secours.

Checklist d'auto-vérification

Après avoir terminé, cocher chaque point, ne pas livrer si un point échoue :

  • Toutes les couleurs proviennent des tokens, pas de hex codé en dur
  • Hiérarchie typographique ne dépasse pas 4 niveaux, taille de corps de texte conforme au système
  • Système de coins arrondis cohérent (arrondis imbriqués = extérieur − marge intérieure)
  • Utilisation des ombres/matières conforme au système (Material utilise superposition tonale, Fluent Mica/Acrylic, iOS matière floutée, HyperOS niveaux de gris)
  • Tous les états interactifs sont présents : hover / focus-visible / active / disabled / selected
  • Les deux thèmes clair et sombre ont été vérifiés
  • Tailles des cibles de clic conformes
  • Contraste conforme, anneau de focus visible
  • Animations dégradées sous prefers-reduced-motion
  • Polices de secours chinoises correctes, espacement ajusté
  • Aucune interférence d'un autre système

Fichiers de référence

FichierContenu
references/style-router.mdArbre de décision pour le choix des quatre styles, matrice de comparaison, zones interdites de mélange
references/miuix-hyperos.mdTable complète des tokens MIUIX + caractéristiques visuelles HyperOS + spécifications des composants
references/apple-hig.mdTable complète des couleurs système + 12 niveaux Dynamic Type + matières + spécifications des composants
references/material-design-3.mdTable complète clair/sombre des 29 rôles de couleur + 15 niveaux typographiques + formes/altitude/calques d'état
references/fluent-2.mdNeutres / échelles de couleurs de marque + Type Ramp + tailles de contrôles + Mica/Acrylic + tokens d'ombres
references/components-playbook.mdSpécifications détaillées par style pour boutons/saisies/cartes/navigation/menus/interrupteurs/listes
references/motion-and-accessibility.mdCourbes et durées d'animation des quatre systèmes + exigences d'accessibilité + grille d'audit
references/framework-mappings.mdRègles de mapping des tokens pour Tailwind / React / Vue / Compose / SwiftUI
scripts/lint_tokens.pyValidation exécutable : valeurs codées en dur, contraste, exhaustivité des tokens essentiels
assets/mappings/tailwind.cssMapping des tokens pour Tailwind v4 @theme, les quatre systèmes peuvent coexister sur une même page

Skills associés

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community