frontend-design-director

Frontend Design Director

Orchestrator that drives a complete frontend design pipeline — from diagnosis to deliverable — by coordinating three specialized skills in the right order.

When to Use This vs Individual Skills

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.

---

Step 0 — Unified Brief

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.

---

Step 1 — Déterminer le Mode

Mode A — Site existant

Déclenché quand l'utilisateur fournit du code HTML/CSS existant ou référence un site à améliorer.

Mode B — Nouveau site

Déclenché quand l'utilisateur part d'un brief sans code existant, ou demande explicitement de créer la fondation.

Mode C — Refonte

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.

---

Step 2 — Pipeline par Mode

Mode A — Site existant

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

Mode B — Nouveau site

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é

Mode C — Refonte

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

---

Step 3 — Synthèse Croisée

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.

Patterns de chevauchement courants

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

Format de la synthèse

## 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

Barème de scoring

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.

---

Step 4 — Livrable

Structure du livrable

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 → tailwind.config.js + @layer components au lieu de fichiers CSS séparés
• Bootstrap → fichier de variables Sass + overrides CSS

Format compact (si le projet est simple)

Pour les petits projets, tout consolider dans un seul fichier design-system.css avec des commentaires de section clairs.

---

Step 5 — Validation Finale

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

---

Notes pour l'agent

1. Lire les 3 SKILL.md au début du pipeline, pas à la volée. Les charger en Phase 1 pour avoir la vision complète.
2. Ne jamais produire les rapports des 3 skills comme 3 blocs séparés sans synthèse. La valeur du Director est la synthèse croisée. Sans elle, autant utiliser les skills individuellement.
3. Le scoring doit être honnête. Un score de 7/10 sur l'accessibilité d'un site sans skip link ni ARIA est mensonger. Le barème est objectif.
4. Adapter la profondeur au volume. Un site d'une page ne nécessite pas le même niveau de détail qu'une application à 20 vues. Ajuster le nombre d'audits en conséquence.
5. Le brief unifié est non négociable. C'est la première chose à produire. Les 3 skills en dépendent — un audit sans direction produit des recommandations génériques.
6. Commencer par le token system, toujours. Même en Mode A (site existant), la première correction est d'extraire ou créer les tokens. Tout le reste s'appuie dessus.
7. Le livrable est du CSS exécutable. Pas un document théorique. L'utilisateur doit pouvoir copier-coller et voir le résultat.