From frontend-design
Orchestrate a complete frontend design pipeline — audit, diagnose, and build a visual system for a website. Combines frontend-audit-visual, frontend-audit-functional, and content-design-system into a unified workflow with cross-synthesis and a single deliverable. Use when the user wants a full design review, a complete visual overhaul, or a new site's design foundation — or says things like "audit and fix my site", "redesign the frontend", "build the visual layer from scratch", "full design review", "improve everything", "the site needs a complete overhaul", "create the CSS foundation", "make my site professional", "refonte visuelle", "audit complet du frontend". Also triggers when the user's request clearly spans visual + functional + content system concerns. Do NOT use for a single-dimension issue (just colors, just accessibility) — use the individual skills directly instead.
How this skill is triggered — by the user, by Claude, or both
Slash command
/frontend-design:frontend-design-directorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Orchestrator that drives a complete frontend design pipeline — from diagnosis to
Orchestrator that drives a complete frontend design pipeline — from diagnosis to deliverable — by coordinating three specialized skills in the right order.
| Situation | Use |
|---|---|
| "Fix my colors" | frontend-audit-visual directly |
| "Make it accessible" | frontend-audit-functional directly |
| "Build a type scale" | content-design-system directly |
| "Audit and fix my site" | This skill |
| "Build the visual foundation for a new site" | This skill |
| "Full design review" | This skill |
Rule: if the request touches ≥ 2 of {visual, functional, content system}, use this orchestrator.
Collect context once for all three skills. Ask the user if missing.
## Brief Unifié
### Identité
- Nom du projet :
- Ambiance cible : [ex. dark fantasy / éditorial / SaaS / corporate]
- Inspirations : [ex. Stripe, A24, Linear, Notion]
- Émotions recherchées: [ex. confiance, mystère, clarté]
- Anti-patterns : [ex. pastel corporate, gradients violets]
### Audience & Contexte
- Audience : [ex. adultes 25-45, développeurs, clients B2B]
- Cibles appareils : [desktop / desktop+mobile / mobile-first]
- Accessibilité cible : [WCAG AA / AAA / non défini]
### Technique
- Framework CSS : [aucun / Tailwind / Bootstrap / autre]
- Framework JS : [vanilla / React / Vue / autre]
- Thème : [clair / sombre / les deux]
- Polices souhaitées : [ex. Inter + Literata / system fonts / à proposer]
### Contenu
- Type de contenu : [long-form / vitrine / hybride]
- Contenu enrichi : [citations / callouts / code / tableaux / listes / alertes / exemples]
- Densité cible : [aéré / compact / variable]
### État
- État actuel : [existant avec problèmes / nouveau site / refonte]
- Fichiers fournis : [HTML / CSS / les deux / brief seulement]
Si non fourni : inférer du code existant ou du contexte conversationnel, proposer le brief rempli, attendre validation avant de continuer.
Ce brief remplace les Step 0 individuels des trois skills — ne pas les demander à nouveau.
Déclenché quand l'utilisateur fournit du code HTML/CSS existant ou référence un site à améliorer.
Déclenché quand l'utilisateur part d'un brief sans code existant, ou demande explicitement de créer la fondation.
Déclenché quand l'utilisateur a du code existant mais veut repartir de zéro visuellement. Combine l'analyse du code existant (pour comprendre la structure) avec la génération d'un nouveau système.
Phase 1 : DIAGNOSTIC
├── Lire frontend-audit-visual/SKILL.md
│ → Exécuter les 5 audits visuels
│ → Produire les rapports de violations
│
├── Lire frontend-audit-functional/SKILL.md
│ → Exécuter les 6 audits fonctionnels
│ → Produire les rapports de violations
│
└── Synthèse croisée (Step 3)
Phase 2 : FONDATION
├── Lire content-design-system/SKILL.md
│ → Générer le token system + échelle typo + content blocks
│ → Intégrer comme corrections aux violations identifiées
│
└── Produire le CSS corrigé
Phase 3 : VALIDATION
└── Auto-audit du CSS produit contre les checklists des 3 skills
Phase 1 : FONDATION
├── Lire content-design-system/SKILL.md
│ → Générer le design system complet depuis le brief
│ → Token system + échelle typo + rythme + content blocks + prose
│
└── Produire le CSS initial
Phase 2 : VALIDATION
├── Lire frontend-audit-visual/SKILL.md
│ → Auto-auditer le CSS produit (palette, hiérarchie, lisibilité,
│ densité, typo web)
│
├── Lire frontend-audit-functional/SKILL.md
│ → Vérifier les composants générés (états interactifs,
│ accessibilité des content blocks, responsive)
│
└── Corriger les violations trouvées
Phase 3 : LIVRAISON
└── CSS validé + rapport de conformité
Phase 1 : ANALYSE
├── Lire le code existant
│ → Extraire la structure (sections, composants, patterns de layout)
│ → Inventorier ce qui est conservé vs ce qui est remplacé
│
└── Note : on analyse la structure, pas le style
Phase 2–3 : identiques au Mode B, mais informés par la structure existante
Après les audits (Mode A) ou après la validation (Mode B/C), produire une synthèse qui identifie les violations transversales — problèmes qui apparaissent dans plusieurs rapports et doivent être corrigés une seule fois.
| Violation visuelle | Violation fonctionnelle | Correction unifiée |
|---|---|---|
Contraste insuffisant sur .btn | :focus-visible absent sur .btn | Refaire le token --color-primary + ajouter les états |
| Pas de token system | Couleurs d'erreur incohérentes dans les formulaires | Créer les tokens sémantiques (danger, success, etc.) |
| Hiérarchie plate (h2 ≈ h3) | Headings avec sauts de niveau (h1→h3) | Reconstruire l'échelle typo complète |
| Lisibilité faible (line-height 1.3) | Cibles tactiles trop petites | Revoir les tokens d'espacement globaux |
| Pas de dark mode tokens | prefers-reduced-motion absent | Ajouter un système de media queries cohérent |
## Synthèse Croisée
### Score par dimension (0–10)
| Dimension | Score | Statut |
|--------------------|-------|-------------|
| Palette | 4/10 | ⚠️ Faible |
| Hiérarchie | 3/10 | ❌ Critique |
| Lisibilité | 6/10 | ⚠️ Correct |
| Densité | 7/10 | ✅ Bon |
| Typo web | 5/10 | ⚠️ Moyen |
| Interactivité | 2/10 | ❌ Critique |
| Accessibilité | 3/10 | ❌ Critique |
| Responsive | 5/10 | ⚠️ Moyen |
| Formulaires | 4/10 | ⚠️ Faible |
| Motion | 6/10 | ⚠️ Correct |
| Perf CSS | 7/10 | ✅ Bon |
| **Global** | **4.7/10** | **⚠️** |
### Violations transversales (corrections uniques)
1. **Token system absent** → impacte palette + interactivité + formulaires
→ Priorité : créer le token system en premier (content-design-system Step 1)
2. **Échelle typo plate** → impacte hiérarchie + lisibilité + accessibilité
→ Priorité : reconstruire l'échelle (content-design-system Step 1)
3. ...
### Ordre de correction recommandé
1. Token system (fondation de tout)
2. Échelle typographique
3. Accessibilité structurelle (landmarks, ARIA, skip link)
4. États interactifs (:focus-visible)
5. Content blocks
6. Responsive
7. Formulaires
8. Motion
9. Performance CSS
| Score | Signification |
|---|---|
| 0–2 | ❌ Critique — violations majeures, inutilisable ou non conforme |
| 3–4 | ⚠️ Faible — problèmes structurels, corrections urgentes |
| 5–6 | ⚠️ Moyen/Correct — fonctionnel mais améliorable |
| 7–8 | ✅ Bon — quelques ajustements mineurs |
| 9–10 | ✅ Excellent — conforme, cohérent, professionnel |
Le score est basé sur le nombre et la sévérité des violations dans les rapports individuels, pas sur une impression subjective.
livrable/
├── rapport.md — Synthèse croisée + scores + recommandations
├── tokens.css — Variables CSS (ou tailwind.config.js)
├── typography.css — Échelle typo + headings + rythme vertical
├── content-blocks.css — Styles des 7 types de content blocks
├── prose.css — Conteneur .prose + variantes
├── interactive-states.css — :hover, :focus-visible, :active, transitions
├── responsive.css — Media queries + layout adaptatif (si applicable)
└── checklist.md — Checklist fusionnée des 3 skills
Règle : chaque fichier CSS est autonome et importable indépendamment. L'ordre d'import recommandé est celui de la liste ci-dessus.
Adaptation framework :
tailwind.config.js + @layer components au lieu de fichiers CSS séparésPour les petits projets, tout consolider dans un seul fichier design-system.css
avec des commentaires de section clairs.
Exécuter la checklist fusionnée des trois skills. Chaque point doit être coché.
## Checklist Finale
### Tokens & Palette
- [ ] Token system complet, zéro valeur brute
- [ ] Contraste ≥ 4.5:1 sur toutes les combinaisons (tous thèmes)
- [ ] Tokens sémantiques (info, warning, danger, success)
### Typographie & Hiérarchie
- [ ] Ratio documenté, h1/body ≥ 2.0×
- [ ] Chaque paire de headings diffère sur ≥ 2 axes
- [ ] line-height ≥ 1.6 sur le corps, tight sur les titres
### Content Blocks
- [ ] Chaque bloc distingué sur ≥ 3 axes visuels
- [ ] Silhouette test passé
- [ ] Callouts avec couleur + icône
### Lisibilité & Rythme
- [ ] max-width ≤ 70ch, line-height ≥ 1.6
- [ ] Rythme vertical basé sur --rhythm
- [ ] Mode long-form + vitrine couverts (si hybride)
### Interactivité
- [ ] :focus-visible sur tous les éléments focusables
- [ ] :hover + :active + transition sur les boutons
### Accessibilité
- [ ] Landmarks corrects, skip link, hiérarchie h1-h6 sans saut
- [ ] Images avec alt, ARIA correct
### Responsive
- [ ] Breakpoints cohérents, cibles tactiles ≥ 44px
- [ ] Viewport sans user-scalable=no
### Motion & Performance
- [ ] prefers-reduced-motion présent
- [ ] Pas de layout properties animées
- [ ] Sélecteurs ≤ 3 niveaux, < 5 !important
npx claudepluginhub camauger/dev-skills --plugin frontend-designCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.