Huashu Design : produire des prototypes, slides et animations depuis Claude Code

⏱️ Temps de lecture estimé : 5 minutes

https://github.com/alchaincyf/huashu-design

📌 Huashu Design est un “design skill” qui transforme une demande en livrables concrets (prototype cliquable, deck de slides, animation) directement depuis un agent de code, sans ouvrir d’outil graphique. L’idée est simple : écrire une phrase dans Claude Code (ou un autre agent compatible skills.sh), laisser le skill générer une base propre, puis itérer par conversation jusqu’à un rendu qui ressemble à un travail de design réellement livrable.

Ce qui change au quotidien, c’est le passage d’un flux “maquette → export → intégration” à un flux “spécification → génération → ajustements”. Le skill privilégie des sorties qui se manipulent comme du code : beaucoup de livrables sont en HTML (un seul fichier quand c’est possible), ce qui permet de versionner, relire, comparer des variantes et automatiser des vérifications au lieu de dépendre d’un canvas.

Huashu Design se positionne comme une alternative à la “couche outil” : là où une app de design optimise la manipulation visuelle (cliquer, glisser, réarranger), ici l’objectif est de faire disparaître cette couche pour ceux qui préfèrent piloter la création au clavier. Le projet assume d’ailleurs un positionnement “agent-agnostic” : le même skill peut être installé dans différents environnements d’agents tant qu’ils supportent le format skills.sh.

L’installation ressemble à une dépendance : une commande, puis des prompts. Le démarrage est volontairement minimal, et le reste est structuré par des workflows internes (questions au début, première version rapide, puis cycles d’amélioration). Pour les prototypes, l’approche “HTML-first” facilite la livraison : un lien, un fichier, un rendu reproductible.

points clés

• 🧩 Un skill “HTML-native” : prototypes, slides, infographies et animations sortent comme des livrables exploitables.
• 📱 Prototypes cliquables : simulation d’iPhone avec bezel réaliste, navigation multi-écrans et vérifications automatisables.
• 🎞️ Export vidéo : rendu en MP4 et GIF, avec options de cadence (dont 60fps via conversion) et ajout de musique selon les scripts.
• 🖥️ Slides hybrides : deck HTML pour présenter dans le navigateur, plus export en PPTX éditable (pas une simple image aplatie).
• 🧪 Itération guidée : variations côte à côte, réglages (tweaks) et persistance d’options côté front via localStorage.
• 🧭 Anti-slop : règles explicites pour éviter les patterns visuels “IA” trop génériques et pousser une direction graphique assumée.

Dans la pratique, Huashu Design couvre plusieurs familles de livrables. Le premier gros bloc, ce sont les prototypes (app ou web) : l’objectif n’est pas juste une maquette figée, mais un prototype qui se clique, se parcourt et se démontre. Le README met en avant une vérification type Playwright pour parcourir l’interface et éviter les écrans incohérents, ce qui rapproche le design d’une logique de “build vérifiable”.

Deuxième bloc : les slides. Le format HTML est utile pour une présentation immédiate, mais le point intéressant est l’export PPTX “éditable” : le projet explique convertir le DOM et ses styles calculés en objets PowerPoint, pour conserver des zones de texte modifiables. Concrètement, cela vise un vrai usage “je génère un deck solide, puis je fais des retouches rapides dans l’outil de présentation”.

Troisième bloc : l’animation. Le projet décrit un moteur basé sur un modèle “stage + sprites” et un petit set d’API (temps, interpolation, easing) pour couvrir la majorité des besoins de motion design “produit” : révélation d’un logo, timeline explicative, séquences d’onboarding, etc. L’important ici n’est pas de rivaliser avec un moteur 3D, mais de rendre accessible la production de vidéos propres avec un pipeline d’export (MP4/GIF) scriptable.

Le projet insiste aussi sur un comportement “fallback” quand la demande est floue : au lieu de forcer une exécution au jugé, le skill propose plusieurs directions graphiques différenciées, issues de styles/philosophies de design, puis demande un choix avant de poursuivre. Ce type de garde-fou est utile avec des agents : il réduit le risque de partir trop vite dans une direction moyenne et donne une structure pour converger.

Sur la partie “assets”, Huashu Design met en avant l’idée de “brand assets protocol” : donner des éléments de marque (logo, palette, captures UI) permet au rendu de coller à une identité existante. Sans ces entrées, le README annonce une qualité plus moyenne, ce qui est cohérent : une bonne high-fidelity design naît souvent d’un contexte visuel déjà défini.

Il y a des limites assumées. Le projet ne promet pas une édition au niveau “calque” dans tous les formats, et ne vise pas non plus la complexité d’un Framer Motion très avancé (3D, particules, physiques). Le propos est plutôt : obtenir vite un 80/100 solide, dans des formats exportables et présentables, sans dépendre d’un produit GUI.

Côté exécution et intégration, l’architecture paraît pensée comme une boîte à outils : composants de base (frames iOS/Android, fenêtres, canvas de comparaison), documents de référence par type de tâche, et scripts d’export (vidéo, PDF, PPTX, vérification). Cela donne un modèle mental clair : un agent peut composer des briques et suivre un chemin de production, plutôt que d’improviser à chaque fois.

Enfin, un détail important avant d’adopter : la licence affichée dans le README indique un usage “Personal Use Only”. Pour un usage en équipe ou dans un contexte commercial, il faut vérifier précisément les conditions et, si nécessaire, demander une autorisation adaptée. À retenir : c’est un outil qui vise à rendre la création “shipable” depuis le terminal, mais sa pertinence dépend autant du workflow que du cadre d’usage.