design-workflow について
プロトタイプ、デザインドキュメント、UIコードを作成する人向けのデザインスキルです。既存のデザインシステムに従い、コンポーネント単位で構築し、品質を確認します。
主な機能
- 01デザインシステムとの一貫性
- 02AI風の定型表現の回避
- 03コンポーネント単位の手順
- 04ビジュアル参考資料の活用
- 05プロトタイプ品質チェックリスト
活用シーン
- 01UIプロトタイプの作成
- 02インターフェース部品の構築
- 03レスポンシブデザインの確認
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ c0x12c/ ai-toolkit --skill design-workflowインストール後、Claude Code で/design-workflowを入力して読み込まれたか確認します。
同梱ファイルchecklists.md
詳細
デザインワークフロースキル
AI が生成したように見えない UI デザインを作成するためのガイドラインです。これらのルールは、プロトタイプ、デザインドキュメント、UI コードなど、あらゆるデザイン作業に適用されます。
このスキルでできること
- 「ありがちな AI デザイン」のパターンを避ける方法を学びます
- デザイン品質を確認するためのチェックリストを提供します
- コンポーネントごとにデザインを進める方法を案内します
- プロトタイプの品質基準を定めます
ルール 1:既存のデザインシステムを使う
新しい色、フォント、間隔を決して独自に作らないでください。 常にプロジェクトで定義されているものを使ってください。
最初に読むもの
.planning/design-config.md— プロジェクトのカラー、フォント、間隔、ブランドアイデンティティ- design-config に記載されたテーマファイル — 実際の CSS トークン
- コードベース内の既存コンポーネント — そのパターンに合わせます
要点
- プロジェクトのカラーパレットにある正確な 16 進数値を使います(
bg-blue-500のような Tailwind のデフォルト値ではなく) - プロジェクトのフォントを使います — Inter、Poppins、Space Grotesk に置き換えないでください
- プロジェクトの角丸とシャドウの値を使います
- CSS 変数またはトークンを参照します — 値を直接ハードコードしないでください
ルール 2:ありがちな AI パターンを避ける
次のパターンは「AI が作った」とすぐにわかるものです — すべて避けてください。
色
- プロジェクトのカラーパレットにない色は使わないでください
- 紫やバイオレットのランダムなグラデーションは使わないでください(AI にありがちな定番その 1 です)
- ネオンカラーやレインボーグラデーションは使わないでください
- アクセントカラーのない、グレーの上にグレーを重ねる配色は避けてください
- プロジェクトのアクセントカラーを使ってください — それがデザインの個性になります
レイアウト
- すべてを中央揃えにし、すべてのセクションに最大幅を設定するのは避けてください
- テキストの背後に巨大なグラデーションの塊を置いたヒーローセクションは避けてください
- どれも同じように見えるアイコン付きの 3 列の機能カードは避けてください
- すべてのセクションを、右に画像、左にテキストという 50 対 50 の分割にするのは避けてください
- ときにはグリッドを崩しましょう — 非対称のほうが興味深いデザインになります
タイポグラフィ
- すべてに同じフォントサイズを使わないでください
- 明確な階層を作ります:大きな見出し、中くらいの小見出し、小さな本文
- フォントの太さにコントラストをつけます
- 長いテキストブロックを中央揃えにしないでください
コンポーネント
- どれも同じ見た目の角丸長方形は避けてください
- カードに視覚的な変化をつけます — サイズを変えたり、強調表示するカードと通常のカードを使い分けたりしてください
- ボタンには、プライマリ、セカンダリ、ゴーストの明確な階層を持たせます
- すべてにアイコンを使わないでください — テキストのほうが適している場合もあります
コピー
- ありきたりなマーケティング文句(「可能性を解き放つ」「次のレベルへ進む」など)は使わないでください
- 具体的に書きます — 実際の機能名や数値を使ってください
- design-config の Design Personality に記載されたトーンに合わせます
ルール 3:コンポーネントごとにデザインする
ページ全体を一度にデザインしないでください。パーツを作ってから組み合わせます。
作業の順序
- デザイントークン — 既存のテーマファイルで色、フォント、間隔を確認します
- 基本コンポーネント — Button、Card、Badge、Input(小さく、独立した状態で作成)
- 複合コンポーネント — ナビゲーションバー、サイドバー、ヒーローセクション、機能カード
- 画面全体 — コンポーネントを組み合わせてページを作成します
- 状態 — 各コンポーネントにローディング、空、エラーの状態を追加します
- レスポンシブ対応 — モバイル、タブレット、デスクトップ向けに各画面を調整します
ルール 4:ビジュアルリファレンスを使う
リファレンスがある場合:
- 何が見た目のよさにつながっているかを調べます(レイアウト、色、タイポグラフィ、余白)
- 参考にはしますが、コピーはしません — レイアウトをそのまま再現するのではなく、品質のレベルを合わせます
- プロジェクトのデザインシステムに適用します
リファレンスがない場合:
- design-config の Reference Apps を確認します
- 余白を重視します — 余白が広いほど高級感が増します
- アクセントカラーは控えめに使います — 画面の最大 10~15% にとどめます
- 各セクションに、ひとつ大きく大胆な要素を配置します(視覚的階層)
ルール 5:プロトタイプの品質基準
必須
- プロジェクトのテーマファイルにある正確な色
- 実際のフォントが読み込まれていること
- 適切な間隔(あちこちにランダムなパディングを設定しない)
- 実際のコンテンツ(「Lorem ipsum」ではない)
- すべての状態が見えること(ローディング、空、エラー、成功)
- レスポンシブ対応:375px、768px、1440px で動作すること
禁止
- プレースホルダー画像やストックフォトの URL
- Tailwind のデフォルトカラー
- ホバー/フォーカス状態の欠落
- どのビューポートでもレイアウトが崩れること
- 読みにくいテキスト(コントラストを確認してください)
レビューとチェックリスト
セルフチェック、批評レビューのチェックリスト、設計と実装の不一致に関するトラブルシューティングについては、checklists.md をご覧ください。
コメント
Markdown 対応