Skill : Redesign & Audit
Redesign axé sur l'audit qui préserve le comportement.
Étapes
- Lire
workflows/redesign-audit.md(la séquence complète Analyser → Diagnostiquer → Diriger → Appliquer → Vérifier + Complétude de la sortie). - Analyser la codebase : framework, méthode de style (→ acheminer vers l'adaptateur
frameworks/correspondant), réalité des tokens, composants, ce qui doit être préservé. - Diagnostiquer avec la checklist des valeurs par défaut interdites (
taste/design-taste.md) + le rubric de revue (skilldesign-review). Produire un tableau de constats priorisé. - Diriger : choisir un archétype / système (skill
apply-aesthetic) qui correspond à la marque. - Appliquer dans l'ordre — d'abord les tokens, puis la typographie / espacement, puis les états des composants, puis l'animation — sans modifier les routes / données / sémantiques du balisage (sauf correctifs d'accessibilité).
- Vérifier : relancer
design-review+a11y-audit; tester chaque flux fonctionnel précédemment opérationnel ; vérifier le mode sombre et la réactivité. Exécuterscripts/validate_contrast.pysur la source des tokens etscripts/lint_hardcodes.pysur le code modifié.
Garde-fous
Ne jamais sacrifier une fonctionnalité fonctionnelle pour l'esthétique. Ne jamais livrer une couleur de marque qui échoue au test de contraste. Ne jamais supprimer les fonctionnalités d'accessibilité existantes. Livrer des fichiers complets — pas d'espaces réservés.
Cohérence mono-thème (critique pour les applications multi-pages)
Consolider en UN thème de tokens partagé et faire en sorte que chaque page le consomme — un redesign qui laisse différentes pages sur des palettes différentes a échoué. Remplacer les couleurs par page / ad hoc par des tokens sémantiques ; vérifier avec scripts/lint_hardcodes.py qu'aucune page ne réintroduit des valeurs hors thème. Les changements de thème doivent provenir d'une seule source de tokens, pas de modifications par page (.claude/rules/tokens-and-color.md → Cohérence mono-thème).