huashu-design

Sur mon radar

huashu-design est un Claude Code skill open-source (`alchaincyf/huashu-design`, MIT, 14k★ au moment de l'écriture). Une commande npx pour l'installer, une phrase à ton agent (Claude Code, Cursor, Codex...), et en 3 à 30 minutes tu récupères un livrable : prototype iOS cliquable, deck de slides éditable, animation MP4, ou infographie qualité print.

Pourquoi c'est sur mon radar

• Output HTML direct plutôt qu'un brief texte. Dans mon article Claude Design je notais que les 212 lignes de brief demandaient ensuite ~30 minutes de transcription manuelle des valeurs HEX en tokens Tailwind. huashu-design court-circuite cette étape : tu reçois directement du HTML interactif que tu peux ouvrir dans un browser.
• Agent-agnostic. Le skill est conçu pour fonctionner avec n'importe quel agent qui parse les markdown-skills : Claude Code, Cursor, Codex, Trae, Hermes, OpenClaw. Pas de verrouillage sur claude.ai.
• Junior Designer Workflow par défaut. Le skill ne tente pas un one-shot « voilà ton design final » : il commence par poser les questions, écrit des assumptions + placeholders + gray blocks dans le HTML, montre tôt, itère. Cohérent avec la discipline Superpowers (un commit après chaque étape vérifiée).
• Install en une commande : `npx skills add alchaincyf/huashu-design`. Pas d'interface, pas de panneau Figma — c'est l'agent qui pilote.

Ce que ça produit concrètement

D'après la documentation, le skill couvre 7 types de livrables, chacun avec un temps de production typique annoncé : prototype interactif HTML single-file vérifié Playwright en 10-15 min, deck HTML pour browser + PPTX éditable avec text frames préservés en 15-25 min, motion design MP4 25/60 fps avec interpolation et BGM en 8-12 min, variations side-by-side avec paramètres live en 10 min, infographie typo print-grade avec exports PDF/PNG/SVG en 10 min, advisor de direction sur 5 écoles × 20 philosophies avec démos parallèles en 5 min, et critique experte 5 dimensions avec radar et punch list en 3 min.

Tous les exemples du README sont eux-mêmes générés par huashu-design — le repo ne montre pas des mockups Figma de ce que l'outil pourrait faire, il montre ce qu'il a effectivement fait. C'est un signal fort, à confirmer en usage réel.

Le delta avec Claude Design

Là où Claude Design produit un brief — un document Markdown qui décrit la palette, la typo, les composants, les règles d'usage, à toi de transcrire dans ta codebase — huashu-design produit le livrable fini directement. Brief-first vs artifact-first : deux philosophies du design AI qui ciblent des phases différentes.

Claude Design est mieux quand tu veux un système — palette, typo, composants documentés — que tu vas réutiliser dans ta vraie codebase pendant des mois. huashu-design est mieux quand tu veux un livrable — un mockup pour valider une idée avec un stakeholder demain, un deck client pour vendredi, une animation pour un launch — utilisable tel quel.

Sur le projet Vite Fait, Bien Fait que je décris dans l'article Claude Design, j'avais besoin du système : 4 PRs phasées d'implémentation derrière. Pour le prochain projet, si je dois pitcher visuellement avant de coder, je vais probablement essayer huashu-design d'abord pour générer le mockup, puis revenir à Claude Design pour le design system une fois la direction validée.

Mécaniques internes notables

Quatre mécaniques attirent mon attention dans la doc, parce qu'elles répondent à des problèmes que j'ai rencontrés ailleurs.

• Core Asset Protocol — un process en 5 étapes pour collecter les assets d'une marque (logo, photos produit, screenshots UI, palette, fonts) : demander à l'utilisateur, chercher sur les canaux officiels (brand.com/brand, press kits, launch videos), télécharger avec 3 chemins de fallback par type d'asset, vérifier l'authenticité, figer dans un `brand-spec.md`. L'auteur revendique un A/B test v1 vs v2 qui a réduit la variance de qualité ×5. La règle « Never guess from memory » me parle directement : sur Vite Fait, Bien Fait, l'étape la plus risquée du rename de tokens était justement les hex couleurs devinés sans vérification.
• Design Direction Advisor (mode Fallback) — quand le brief est trop vague pour exécuter, le skill ne devine pas, il bascule en mode fallback : 3 directions différenciées tirées de 5 écoles × 20 philosophies (chacune d'une école différente), avec œuvres flagship, mots-clés gestalt, designer représentatif, et démos générées en parallèle pour comparaison side-by-side.
• Junior Designer Workflow — la mécanique par défaut : envoyer le batch complet de questions en une fois, attendre toutes les réponses, écrire des assumptions + placeholders + reasoning directement dans le HTML, montrer tôt même avec gray blocks, itérer. Pas d'attempt one-shot héroïque. C'est exactement la discipline que Superpowers applique au code, transposée au design.
• 5-Dimension Expert Critique — un mode de review qui score un design sur cinq axes : cohérence philosophique, hiérarchie visuelle, qualité d'exécution, fonctionnalité, innovation. Output : radar chart + punch list Keep / Fix / Quick Wins. Le genre de retour que tu attends d'un design review en équipe.

Comment l'essayer

Installation en une ligne :

npx skills add alchaincyf/huashu-design

Une fois installé, on parle à l'agent (Claude Code, Cursor, Codex...) normalement, en langage naturel :

"Make a keynote for AI psychology. Give me 3 style directions to pick from."
"Build an iOS prototype for a Pomodoro app — 4 screens, actually clickable."
"Turn this logic into a 60-second animation. Export MP4 and GIF."
"Run a 5-dimension expert review on this design."

Pas de plugin Figma, pas de panneau, juste du texte. Le skill apporte ses propres références culturelles (5 écoles, 20 philosophies) et sa discipline (asset protocol, junior designer workflow) que l'agent intègre dans sa boucle.

Ce que je vais tester sur le prochain projet

La promesse marketing du README est forte (animations 25fps, prototypes Playwright-vérifiés, PPTX avec text frames préservés). Avant de m'enthousiasmer, voici les checks que je veux faire sur un projet réel.

• Qualité output réel vs marketing-grade des démos du README. Les animations dans le README sont elles-mêmes générées par le skill, mais sélectionnées par l'auteur. Sur un brief moyen avec des contraintes réelles, qu'est-ce que ça donne vraiment ?
• `brand-spec.md` fonctionnel sur une marque où je connais les vraies couleurs et le vrai logo. Est-ce que le skill respecte ce qu'il a téléchargé, ou est-ce qu'il « améliore » silencieusement ?
• Junior Designer Workflow tient ses promesses : est-ce qu'il montre vraiment des gray blocks tôt, ou est-ce qu'il dérive vers un one-shot après le premier batch de questions ?
• Side-by-side avec Claude Design sur le même brief. Je vais re-soumettre le brief Vite Fait, Bien Fait aux deux outils et comparer ce qu'ils sortent. Pas pour départager — pour comprendre où chacun excelle.
• Mesure du temps réel pour un livrable utilisable, pas une démo. Le README annonce 3-30 minutes ; ça inclut le temps d'itération nécessaire pour passer le seuil « utilisable » ?

Le retour d'expérience de ce test sera son propre article — ce que l'outil vaut vraiment en production, pas juste en démo.

Sources & crédits

huashu-design est conçu et maintenu par 花叔 / @AlchainHust / `alchaincyf` sur GitHub. Tout le crédit du skill revient à l'auteur. Cet article est une présentation à chaud avant essai — quand je l'aurai testé, je publierai un retour d'expérience séparé.

Le skill tourne sur les agents de coding qui supportent les markdown-skills compatibles skills.sh : Claude Code (par Anthropic), Cursor, Codex, et d'autres. C'est cette portabilité agent-agnostic qui en fait un complément intéressant aux outils mono-plateforme.