Claude Codeのターミナルに一行打つだけで、クリックできるiOSプロトタイプやアニメーション付きスライドが手元に届く——そんな体験を提供するのが、このリポジトリです。Figmaを開く手間も、デザインツールのプラグインを探す手間もない。AIエージェントがHTMLを生成し、ブラウザが画面を描き、スクリプトがMP4に書き出すまで、すべてが会話の中に収まっています。
リポジトリの仕組みと、その裏にある設計の判断を一緒に見ていきましょう。
どんなスキルか
huashu-designは、Claude CodeをはじめとするAIエージェント向けの「デザイン特化型スキル」です。npx skills add alchaincyf/huashu-designでインストールすると、エージェントが「高保真プロトタイプを作る設計師」として振る舞うようになります。
作れるものは幅広く、交互原型（クリック可能なApp/Webモックアップ）・HTMLスライドデッキ・MP4やGIFへの書き出し付き時系列アニメーション・60種のHTMLネイティブスタイルから選ぶインフォグラフィック、そして5軸評価レビューまでカバーしています。いずれも「HTMLを書いてブラウザで見る」という一本のラインの上で動くため、Figmaや After Effectsのような別アプリは不要です。
2万3千を超えるスターを持ち、MIT ライセンスで個人・商用ともに無制限で使えます。Claude Code以外にもCursor、Codex、Hermes等のスキル対応エージェントで動作します。
設計でここが上手い
「三方向ハードゲート」という強制的な発散
どんな依頼でも、まず3つの視覚的な初稿を出してから確認を取る——このルールがSKILL.mdに「100%必走」として書かれています。ユーザーが「モダンな感じで」と風格を指定しても免除されません。
方向を出すロジックも単純ではなく、秒数ルーレット（現在の秒数をもとに60スタイル一覧から選ぶことでモデルが偏愛する「ミニマル一択」を崩す）、世界的な受賞サイトの参照移植、「予算無制限なら誰に頼むか」という設計スタジオ視点の三本が並行して走ります。文章で風格を選ばせるのではなく、三版の実物を並べて「見て選ぶ」形にしているところが実用的です。プロトタイプに迷う場面でどちらのスタイルがいいか言語で判断するのは難しく、並べて見て初めて分かることが多いので、この強制発散は手間ではなく省力化として機能します。
品牌資産プロトコル：記憶から色を拾わない
特定ブランドが絡む仕事では、5ステップの「品牌資産協議」が強制起動します。公式ページを検索してSVGをダウンロードし、ファイルの中から16進カラーコードをgrepで抽出してからbrand-spec.mdに固定する、という手順です。「Stripeの色はたしか青系」といった記憶引き出しを明示的に禁じています。
READMEにはA/Bテストの記録もあり、このプロトコルを適用したv2は適用しなかったv1と比べてアウトプットの分散が5分の1に下がったとされています。色が毎回ぶれないことは、エージェントで複数ファイルを並行生成するときに特に重要で、バラバラなブランド表現がまとめて出てくる事故を防ぎます。
「Junior Designerワークフロー」による早期確認の仕組み
HTMLの冒頭にassumptions・placeholders・reasoning commentsを書いてからユーザーに見せ、確認を取ってから本実装に進む——という順序が明文化されています。グレーのブロックが並んだ段階で方向のズレを修正するほうが、作り込んでから差し戻すより圧倒的に安く済みます。
一見地味ですが、エージェントが「一気に仕上げてから出す」という振る舞いを抑制するルールとして機能しています。実際にこのルールがあるかどうかで、長めのタスクの途中修正コストが大きく変わるはずです。
スクリプトによるローカル完結のエクスポート
render-video.js（HTML→MP4）・add-music.sh・html2pptx.js（ComputedStyleを読んでPowerPointオブジェクトに変換）など、エクスポートツール群がすべてローカルで完結します。クラウド機能はscripts/cloud/に隔離されており、使う場合も自分のAPIキーを使うかどうかを明示的に確認するフローになっています。ネットワーク接続なしで高解像度の成果物が出る設計は、企業内で使う場合の安心感にも直結します。
こういう人に向くかも
GUIのデザインツールをなるべく開かずにプロトタイプや資料を作りたいエンジニア、あるいはPMやディレクター職で「見せられる形のもの」が定期的に必要な人に合っています。
すでにClaude CodeやCursorをメイン環境にしている場合、インストールから最初の出力まで短時間で確認できます。ターミナルで作業する流れの中に、プロトタイプ作成が自然に入ってくる感覚です。
一方、Figmaファイルとして渡す必要があったり、エンジニアリングハンドオフ向けのコンポーネント仕様が必要だったりするチームには向きません。HTMLとMP4とPPTXが出力の主体で、レイヤー編集可能なFigmaへの書き出しはこのスキルの対象外です。
設計の良し悪しをどこで見るか
機能の単一性
プロトタイプ・スライド・アニメーション・評価レビューと、機能の範囲が広く、「単一機能」とは言いにくいスキルです。ただし「HTMLを出力する」という技術的な軸は一本なので、機能が増えても出力形式が散らかりにくい構造になっています。タスクルーティング表（SKILL.md冒頭の分岐一覧）がその複雑さを整理していて、読めば自分のユースケースが対象かどうか判断できます。
想定ユーザー像の解像度
READMEに「設計師ではなくターミナルで作業したいエンジニア」「GUIを開きたくない人」という像が書かれており、想定ユーザーが具体的です。Claude Designとの比較表でも「操作方法が対話（言葉を打って待つ）か、GUI（点・ドラッグ・修正）か」という差を明示していて、どちらが自分の好みかで選べます。
ドキュメントの深度
references/ディレクトリに、ブランド資産プロトコル・アニメーション落とし穴・批評ガイド・動画エクスポートなど、タスク別のサブドキュメントが揃っています。SKILL.mdが全体のルーティングを担い、詳細は各referenceに委ねる構造です。エージェントはタスクに応じて必要な部分だけ読めばよく、常に全文をコンテキストに乗せる必要がありません。トークンの無駄遣いを減らす設計として、これはかなり意識されていると感じます。
メンテナンスの継続性
スター数の推移グラフがREADMEに掲載されており、関心が継続していることは分かります。コミュニティによる翻訳版も英語・韓国語・ベトナム語の3つが揃っています。一方で、作者一人が主体の個人リポジトリである点は変わらず、長期的なメンテナンスを組織として保証するものではありません。商用プロジェクトで依存する場合は、自社でフォークして管理するコストも頭に入れておくと安心でしょう。
想定外の使われ方への備え
Limitations節に「Framer Motionレベルの複雑アニメーションは範囲外」「完全空白ブランドからのhi-fi設計は品質が60〜65点になる」と書かれています。「このスキルは80点のスキルで、100点の製品ではない」という文章も含めて、できないことを正直に書いているところは好印象です。
自分が書くなら、どこを変えるか
気になる点をいくつか挙げると、まずSKILL.mdの分量です。タスクルーティング表・核心原則・各モードの詳細が一ファイルに集まっており、エージェントが毎回全体を読む場合のコンテキスト消費は軽くありません。references/への委譲構造は意識されているので、SKILL.md本体をさらに薄くしてロジックを各referenceに分散する方向は検討の余地がありそうです。
次に、日本語でそのまま使う場合の動作確認情報がほぼありません。中文・英語でのデモは豊富ですが、日本語のUIラベルや長音符を含むテキストでPPTXやPDF書き出しがどう動くかは、自分で試してみるまで分かりません。日本語環境で本格導入する前に、フォント周りとエクスポートのテストを先に済ませておくのが現実的です。
SKILL.mdの「禁止句式」リスト（記憶に頼った断言を禁じるもの）は有効な仕組みですが、エージェントが実際にこのルールを守っているかどうかをユーザーが検証する手段がまだ薄い印象です。verify.pyがどこまで自動検証するか、もう少し詳しいドキュメントがあると信頼感が増すかもしれません。
導入を検討するときのチェック観点
- Claude Code・Cursor・Codexなど、スキル対応のエージェントをすでに使っているか
skillsCLIが1.5.19以上であることを確認しているか（旧バージョンにはサブディレクトリ同期のバグがあるため）- 成果物がHTML・MP4・GIF・PPTXで問題ないか（Figmaファイルとして渡す必要があれば別の手段が必要）
- 日本語テキストを含む出力が必要な場合、フォントとエクスポートの動作を小規模で先に確認しているか
- 特定ブランドの色やロゴを使う案件では、公式素材を手元に用意する準備ができているか
- ローカル実行に依存するエクスポートスクリプト（Playwright・ffmpegなど）の環境構築が済んでいるか
- 商用プロジェクトで長期運用する場合、自社フォークでの管理コストを見込んでいるか
「80点のスキル」が指すもの
READMEに「このスキルは80点のスキルで、100点の製品ではない。GUIを開きたくない人には、80点のスキルのほうが100点の製品より使いやすい」という一文があります。この表現は正直で、かつ使い方の基準を与えてくれます。
毎回Figmaを開いてプロトタイプを作り込むほどではないけれど、テキストエディタとスクリーンショットだけでは説明しきれない——そういうグレーゾーンのタスクが手元にあるなら、一度試してみる価値はあるはずです。品牌資産プロトコルやJunior Designerワークフローといった個々の仕組みは、このスキルを使わなくても自分のプロンプトに取り込める考え方として参考になります。
