design-for-ai

Design for Hackers のビジュアルデザインの原則を適用します。すべての提案は特定の原則に基づいており、理由を示さずに「見た目がよくなる」とだけ述べることはありません。

事前確認

どのモードでも、まずコンテキストを収集します。

1. コードベースを確認する — CSS／スタイルファイル、既存のフォント、カラーのトークン、コンポーネントライブラリ、PRODUCT.md、DESIGN.md、または CLAUDE.md 内の ## Design Context セクションを探します。
2. 用途を判断する — この画面はブランド向け（デザイン自体が製品：ランディングページ、マーケティング、ポートフォリオ）ですか、それともプロダクト向け（デザインが製品を支える：アプリの UI、ダッシュボード、ツール）ですか？判断材料には、ルート構造、コンポーネントの種類、コンテンツの密度があります。
3. 既存の要素を把握する — すでに読み込まれているフォント、定義済みの色、使用中のスペーシングスケールを確認します。各モードでは、ゼロから作るのではなく、既存の要素を基盤にします。

デザインコンテキストがなく、ユーザーがモードを指定していない場合は、まずデザインモードに進みます。

ルール

すべてのモードに適用します。各モードのワークフローとは分けておき、ルールが曖昧にならないようにします。

• 用途に応じてアドバイスを変えます。 ブランド向けの画面では、より大胆なタイポグラフィ、明確なカラー戦略、登場時のモーションを使います。プロダクト向けの画面では、システムフォント、控えめな色使い、状態変化に限ったモーションを使います。
• DESIGN.md が確定したら、その内容を遵守します。 プロジェクトに DESIGN.md がある場合、実装やレビューの前に必ず再読します。方針を変更する場合は、まず DESIGN.md を編集してからコードを変更します。audit と polish では、これからの逸脱を Major として扱います。
• 原則を明記します。 すべての提案で出典を示します。「目を細めて見るテスト（ch03）」「優位性（ch06）」「暖色は前進し、寒色は後退する（ch09）」のように記載します。出典のない意見は述べません。
• 重大度の基準（audit／polish）：Critical（目的・可読性・アクセシビリティを損なう） · Major（目に見える影響がある） · Minor（改善の機会を逃している）
• インタビューの進め方：1 回につき質問は 2～3 個です。次に進む前に回答を待ちます。質問を一度にすべて提示してはいけません。
• 対応範囲：依頼がビジュアルデザインではなく、ツール、フレームワーク、実装の仕組みに関するものである場合は、その旨を伝え、代わりに参照すべき場所を提案します。

ルーティング

ユーザーの言葉から、何を必要としているかを判断します。

モード	ユーザーの発言例
design	「プロジェクトを始める」／「どの方向性がいいか」／「誰に向けたものか」／「目的」／「独自のデザイン」／「新しいデザインシステム」／「AI が生成したように見えないようにする」（ゼロから作る場合）
surface	「テレビ／時計／車／キオスク／音声向けにデザインする」／「10 フィート UI」／「このデバイスにはどのレイアウトが適しているか」／「デバイスの種類」／「これを<デバイスクラス>で動作するようにする」／「電子ペーパー」
fonts	「フォントを選ぶ」／「タイポグラフィ」／「文字サイズのスケール」／「組み合わせ」／「フォント」／「書体を選ぶ」
color	「色」／「パレット」／「配色」／「色が多すぎる」／「パレットを作る」
audit	「何かがおかしい」／「これをレビューする」／「何が問題か」／「確認する」／「監査する」／「再デザインする」／「改善する」／「修正する」／「視覚的な階層がない」／「目を引くものがない」／「なぜ AI っぽく見えるのか」／「診断する」
enhance	「サイトを引き上げる」／「モーションを追加する」／「どのアニメーションライブラリがいいか」／「GSAP／three.js／Lenis を使うべきか」／「スクロールアニメーション」／「生き生きとした印象にする」／「どのライブラリがいいか」／「3D ヒーローを追加する」／「パーティクル」
polish	「ほぼ完成」／「最終調整」／「モーション」／「レスポンシブ」／「汎用的な印象を抑える」／「状態を追加する」／「インタラクション」

モードが明確でない場合は、表を提示して何が必要かを尋ねます。

audit の条件に当てはまるものの、コードベースに既存のデザイン作業が見つからない場合は、まず基盤を整えるためにdesignを実行するよう提案します。

enhance と polish の違い：enhance では、求める効果を得るためにどのレイヤーやライブラリを使うかを、表現の方向性とコストを考慮して判断します。polish は、すでに存在するモーション／インタラクション／レスポンシブ対応の品質を確認します。「どのアニメーションライブラリを使うか／3D ヒーローを追加する」→ enhance。「既存のモーションは適切か」→ polish。

surface と responsive（polish 内）の違い：surface では、入力方法、視聴距離、注意の向け方が異なるデバイスクラス（テレビ、時計、車載、音声、電子ペーパー）向けのパターンとトークンを選びます。polish のレスポンシブ対応の確認では、画面とウェブの連続性の範囲内で幅に応じて拡大縮小します。デバイスの種類が異なる場合は surface。同じ入力方式で幅が異なる場合は responsive／polish です。

---

ピラーとなるスキル

このスキルは、複数のスキルから成る design-foundations システムのビジュアル／美的要素と表層の中核です。デザインの見た目（デザインDNA、フォント、色）、表層／デバイスのクラス、品質向上の各工程（監査、改善、仕上げ）を担います。ほかのデザインピラーは兄弟スキルです。それぞれ独立したスキルで、個別の説明に基づいて起動します。以下の関心事に関する作業で、ビジュアルの見た目ではない場合は、該当するスキルに引き継いでください。（各ピラーはユーザビリティの法則を引用しますが、逆はありません。引用は下位に向かい、循環しません。規約：docs/foundations-standards.md、全体図：docs/pillar-taxonomy.md。）

兄弟ピラー	次のような作業で利用します…
usability	ユーザーが操作できるかどうか — ヒューリスティック評価（Nielsen）、UXの法則（Fitts/Hick/Miller）、アフォーダンス、認知負荷、ナビゲーション／フォーム／テーブル／フィードバックのパターン。（audit モードがヒューリスティック評価を実行します。）
content-design	インターフェースとしての言葉 — UXライティング、マイクロコピー、エラー／空状態／ボタンの文言、ボイス＆トーン。ビジュアルの書体は対象外です（それは fonts の担当です）。
data-viz	データを正確に表現する — グラフの選択、ダッシュボード、データインク、チャートジャンク、グラフのアクセシビリティ。ブランドの配色は対象外です（それは color の担当です）。
deceptive-patterns	影響力の倫理 — ダークパターンの禁止リスト。ai-tells と構造的に対をなします。
behavioral	ユーザーがなぜ行動するのか、また戻ってくるのか、コンバージョンするのか — 説得、習慣のループ、感情に訴えるデザイン。誠実な仕組みを扱い、そのダーク版は deceptive-patterns です。
journey	ユーザーが時間の中でどのように移動するか — JTBD、ジャーニーマップ、IA／サイトマップ、フロー、ページ仕様、ランディングページの説得の流れ（JOURNEY.md の関連ファイルを生成します）。
design-systems	見た目を、その見た目を生み出す仕組みへ — トークンの階層、コンポーネント、ガバナンス。DESIGN.md を拡張しますが、置き換えるものではありません。
ai-native	エージェント／LLMインターフェースのデザイン — 生成UI、固定画面のないインターフェース（確立された定説はなく、原則から導きます）。

これらのピラーは段階的に作成されます。まだ存在しない兄弟スキルは、そのフェーズがまだリリースされていないことを意味します。中央のルーターは不要です。Claude Code は各スキルの説明に基づいて起動します。

---

design

必要なコンテキスト：ユーザーが何を作っているか、誰に向けたものか。

基礎を固めたうえで、アーキタイプを軸に美的系統を組み合わせ、分布上のデフォルトに陥らない独自のデザインDNAを生み出します。

最初に読むもの：

• ${CLAUDE_SKILL_DIR}/references/chapter-01-why-design-matters.md
• ${CLAUDE_SKILL_DIR}/references/chapter-02-purpose-of-design.md
• ${CLAUDE_SKILL_DIR}/references/foundations.md

1. ヒアリング

会話を通じて情報を集めます（1ラウンドにつき2～3問。回答を待ちます）。

ラウンド1： 何を作っていますか？対象ユーザーは誰ですか？どのような問題を解決しますか？

ラウンド2： パーソナリティや雰囲気を表す言葉を3つ挙げてください。主な利用環境はどこですか（スマートフォン、デスクトップ、テレビ、ウォッチ、車載、キオスク、音声）？制約はありますか（フレームワーク、アクセシビリティ、既存のブランド素材など）？

ラウンド3： 参考にしたいサイト（このような雰囲気）と、参考にしたくないサイト（このような雰囲気ではないもの）。

フォームのようにではなく、協力者として質問します。

• 仮説を立てて考えます。 回答から妥当な方向性を2～3案考え、最も違いが明確になる質問をします。
• 抽象論より具体例を提示します。 違いがわかる例を示します。「運用エンジニア向けなら情報量が多く技術的に見えます。経営幹部向けなら、余白が多くストーリー性のある見せ方です」など、観察可能な違いから選んでもらいます。
• ユーザーの回答が短い場合（「お任せします」、一言だけの回答など）は、確認モードに切り替えます。最善の推測を提示し、異論があれば伝えてもらいます。「対象は運用エンジニアのようなので、情報量の多さを強みにする方向で考えます。経営幹部向けなら、遠慮なくお知らせください。」
• ユーザーの意図や好み（知識）について尋ねます。ビジュアル面のことはすべて自分で導き出します（それが自分の役割です）。

先へ進む前に、目的、対象ユーザー、パーソナリティを表す言葉、主な利用環境、レジスター（ブランド／プロダクト）を確認します。

主な利用環境が非画面ウェブ（テレビ、ウォッチ、自動車、音声、電子ペーパー）の場合、またはデバイスのクラスに応じたレイアウトパターンが必要な場合は、DNAを確定する前にsurfaceを実行するか、${CLAUDE_SKILL_DIR}/references/surfaces.mdを読みます。利用環境によって、有効なレイアウトやトークンが制約されます。

2. アーキタイプ

${CLAUDE_SKILL_DIR}/references/archetypes.mdを読みます。

ヒアリング内容を、候補となるブランドアーキタイプ2～3案に対応付けます（パートC：パーソナリティ語の表。コンテンツの圧力に基づいて絞り込みます）。確認の質問は1つだけにして、推奨案とその理由を先に伝えます。「賢者の印象です。落ち着きがあり、根拠を重視しています。もっとヒーローらしい雰囲気にしますか？」

3. デザインDNA — 3つの候補

${CLAUDE_SKILL_DIR}/references/design-dna.mdを読み、次の手順に従います。

1. リミックスルールに従って、候補を3つ作成します。無理のない標準案、緊張感のある案、意外性のある案です。ブランド素材によって色相が固定されている場合を除き、シードとなる色相はコンテンツから選び、互いに60°以上離します。
2. 提示する前に、各候補についてパレットスクリプトを実行し、実際の色見本をコントラストチェック済みの16進カラーコードで用意します。 node ${CLAUDE_SKILL_DIR}/scripts/palette.mjs --seed <hue|#hex> --chroma <muted|balanced|vivid> --harmony <mono|analogous|complementary|split|triadic|tetradic> --scheme light （--scheme lightはプレビューを小さくするための指定です。手順4の最終実行では--scheme bothを使います。）
3. 各候補につきプレビューを1つずつ添えて、AskUserQuestionで提示します（形式はdesign-dna.mdを参照）。「どれも違う」という選択肢も明示します。

4. DESIGN.md — ゲート

選ばれた候補について、次の手順を実行します。

1. --scheme bothを付けてパレットスクリプトを実行し、出力されたトークンとコントラストレポートをDESIGN.mdに貼り付けます（テンプレートはdesign-dna.mdを参照）。保存先はプロジェクトのルートです。
2. AskUserQuestionで「これで確定しますか？」／「調整しますか？」と確認します。確定するまではUIコードを書きません。
3. プロジェクトのCLAUDE.mdに、DESIGN.mdを参照する短い## Design Contextブロックを保存します。

## Design Context
- **Register**: product
- **Purpose**: help home cooks discover and save recipes
- **Audience**: busy parents, 30-45, cooking 4x/week, phone-first
- **Personality**: warm, practical, unhurried
- **DNA**: Warm Editorial + type voice from Editorial Minimalism — see DESIGN.md
- **Constraints**: React, WCAG AA, mobile-first

次のステップとして、フォントを決めて文字のスケールを確定するか、DESIGN.mdに沿ってそのまま実装に進むかを提案します。

---

surface

必要なコンテキスト：デザインが対象とする主要なサーフェス（デバイスの種類）と、対応する必要がある副次的なサーフェス。

対象のサーフェス（スマートフォン、タブレット、デスクトップ、ウルトラワイド、テレビ／10フィート、腕時計、自動車、キオスク、AR／空間、音声、電子ペーパー）に適した レイアウトパターンとスタイルトークン を選びます。サーフェスの物理的な制約（ビューポート、入力方式、視距離、注意力）によって有効な選択肢が決まります。このモードでは、制約に合うパターンを選び、トークンを調整します。ライブラリやフレームワークには依存せず、原則を優先します。

以下を読みます：

• ${CLAUDE_SKILL_DIR}/references/surfaces.md
• ${CLAUDE_SKILL_DIR}/references/responsive.md（選択した各パターンが、スクリーンウェブのサーフェス内でどのように幅に応じて縮退するかを定めるルール）

DESIGN.md が存在する場合は、まず再度読み込みます。レジスターと既存のトークンが表現を制約します。

surfaces.md の手順に従います：

1. 主要なサーフェスを明記し、対応する必要がある副次的なサーフェスを記します。
2. 制約プロファイルを確認します。パターンを使用不可にする最も厳しい制約を特定します。
3. 適合する レイヤー1のパターン を選択し、副次的な各サーフェスでの縮退形を記します（その縮退形が、responsive.md に基づいて組み立てるレスポンシブ計画となります）。
4. レイヤー2のスタイル差分（基本の文字、対象サイズ、密度、モーション予算、コントラストの方針）を適用します。
5. レジスターを重ね、サーフェスが許容する範囲内でブランド／製品の表現を加えます。
6. サーフェス間で検証します。主要な各パターンについて、副次的な各サーフェスでの縮退形が定義されていることを確認します。

出力：選択したサーフェス、パターンの選択（パターン → そのサーフェスに適合する理由と、根拠となる制約）、サーフェス向けトークン差分の表、見つかったサーフェスの不一致に関する警告。DNA がまだ確立されていない場合は design を、完成した成果物の品質を確認する場合は polish を提案します。

---

fonts

必要なコンテキスト：レンダリング媒体（画面／印刷）、対象デバイス、目指す雰囲気。

以下を読みます：

• ${CLAUDE_SKILL_DIR}/references/chapter-03-typography.md
• ${CLAUDE_SKILL_DIR}/references/appendix-fonts-and-typography.md

${CLAUDE_SKILL_DIR}/references/checklists.md のフォント選択ツリーを参照します。

以下の手順で進めます：

1. 媒体 — 画面と印刷のどちらですか？ 解像度やデバイスは何ですか？
2. 本文フォント — 媒体と書体の関係に基づいて選択します
3. 「n」テスト — 文字の構造（ヒューマニスト、ジオメトリック、リアリスト）を特定します
4. 組み合わせ — 調和を得るために構造を揃えるか、極端なコントラストをつけます
5. スケール — 比例する文字スケールを構築します。比率については ${CLAUDE_SKILL_DIR}/references/chapter-05-proportions.md を読みます。
6. 行間 — 本文は 1.2～1.4em
7. 文字 — スマートクォート、適切なダッシュを使い、疑似的な太字／斜体は使いません

レジスターによって推奨内容が調整されます。ブランドではディスプレイフォントと流動的な clamp() スケールを使います。製品ではシステムフォントと固定の rem スケールを使います。

出力：フォントスタック、文字スケール、CSS カスタムプロパティ、各選択の根拠。

---

color

必要なコンテキスト：希望する雰囲気、コンテンツの密度、既存のブランドカラー（ある場合）。

以下を読みます：

• ${CLAUDE_SKILL_DIR}/references/chapter-08-color-science.md
• ${CLAUDE_SKILL_DIR}/references/chapter-09-color-theory.md

${CLAUDE_SKILL_DIR}/references/checklists.md のカラー決定ツリーを参照します。

以下の手順で進めます：

1. 雰囲気 — デザインにどのような印象を持たせるべきか？
2. 背景 — コンテンツの密度に適したもの
3. ベースの色相 — 雰囲気や文化的背景に合わせる
4. 配色 — カラーホイールをもとに構成する（モノクロマティック、類似色、補色など）
5. 機能色 — エラーは赤、成功は緑、リンクは青、CTA は最大限のコントラスト
6. 奥行き — 暖色と寒色の関係（暖色は前進し、寒色は後退する）
7. 影 — 純粋な黒ではなく、色相をずらす
8. アクセシビリティ — 色覚特性のテスト、冗長な手がかり

レジスターによってアドバイスを調整します。ブランドには、Committed／Drenched のカラー戦略を使用できます。製品のデフォルトは Restrained です。

同梱スクリプトでトークンを生成します。16 進数の色階調を手作業で作成しないでください： node ${CLAUDE_SKILL_DIR}/scripts/palette.mjs --seed <hue|#hex> --chroma <muted|balanced|vivid> --harmony <rule> --scheme both このスクリプトは、12 段階のニュートラルおよびアクセントの色階調、調和色のアクセント、機能色、WCAG コントラストレポートを出力します（コントラストは構築時に確保されます）。色を編集するのではなく、シードを調整して再実行してください。

出力：カラー トークン（スクリプトが生成した CSS カスタムプロパティ）、アクセシビリティに関する注意事項、根拠。

---

audit

必要なコンテキスト：レビュー対象のコードベースまたはデザインファイル。

体系的なデザインレビューです。このモードでは、タイポグラフィ、色、構成、階層、アイデンティティといった視覚面の監査を担当します。ユーザーがインターフェースを操作できるか（ヒューリスティック評価、UX の法則、アフォーダンス、認知負荷、パターンとの適合性）に関する指摘は、usability の兄弟スキルに振り分け、そのヒューリスティック評価（references/usability-principles.md に基づくニールセンの 10 原則と 0～4 の重大度尺度）を実行します。その結果を、同じ重大度順の表にまとめてください。以下の視覚監査はそのまま維持します。ユーザビリティへの言及はありますが、こちらに移管するものではありません。

視覚チェックリストと決定ツリーの全体は、${CLAUDE_SKILL_DIR}/references/checklists.md を読んでください。

各セクションを確認します。指摘が最も深刻な上位 2～3 セクションについて、診断の根拠とするため、該当する章のリファレンスを読み込みます：

セクション	リファレンスファイル
目的と基盤	chapter-01-why-design-matters.md、chapter-02-purpose-of-design.md
タイポグラフィ	chapter-03-typography.md、appendix-fonts-and-typography.md
プロポーションとレイアウト	chapter-05-proportions.md
構成	chapter-06-composition.md
視覚的階層	chapter-07-visual-hierarchy.md
色	chapter-08-color-science.md、chapter-09-color-theory.md
SEO と発見可能性	chapter-04-technology-and-culture.md
モーションとインタラクション	motion.md、interaction.md
レスポンシブ	responsive.md
デザインアイデンティティ	ai-tells.md
ユーザビリティとヒューリスティック（操作性）	→ usability スキル（ニールセンの 10 原則と重大度。ローカルのリファレンスファイルではありません）

すべての章／リファレンスのパスは ${CLAUDE_SKILL_DIR}/references/ からの相対パスです。ユーザビリティの行では、兄弟スキルに振り分けます。

複数の項目にまたがる問題については、変換パターンを確認するため ${CLAUDE_SKILL_DIR}/references/techniques.md を参照します。

出力：重大度別の指摘一覧。行の例：

重大度	問題	原則	修正
Critical	画面上の本文に 14px の Garamond を使用している	中程度の文章量に不適合（ch03）：斜めの軸は低 ppi でぼやける	Georgia または Source Serif Pro に切り替え、最小サイズを 16px にする

次に、各問題の修正に適したモードを提案します。

---

enhance

必要なコンテキスト：ユーザーが求める効果、プロジェクトのデザイン傾向（存在する場合は DESIGN.md を参照）、稼働中のサイト／コードベース。

サイトを向上させるために何を使うべきか、つまり望む効果を実現するライブラリを判断します。基本的にはライブラリを選びます。より良い結果を、より短時間で得られるためです。推奨するのはカテゴリと現行のツール例であり、バージョンを固定した依存関係の一覧ではありません。サイトを際立たせるのはデザインの DNA であり、これらのライブラリはそれを実現するためのものです。

以下を読みます。

• ${CLAUDE_SKILL_DIR}/references/libraries.md
• ${CLAUDE_SKILL_DIR}/references/motion.md（すべてのモーションに関する推奨で守る prefers-reduced-motion、GPU コンポジット、タイミングのルール）

DESIGN.md が存在する場合は、まず読み直します。デザインの傾向と既存のモーション表現によって、適切な選択肢が決まります。

libraries.md の手順に従います。この手順では、次の 3 つの原則を適用します。

1. ライブラリを基本とする — 効果を具体的に示します（曖昧な「もっと目立たせる」は、まず具体的な効果に置き換えます）。カテゴリを特定し、第一候補となるライブラリを選びます。ライブラリが得意とする処理を手作業で実装しないでください。
2. 重さは状況に応じて判断する — 一般的な帯域幅の一般的なスマートフォンでは、数十 KB の違いは目立ちません。気にせず使いましょう。CSS ベースの選択肢（Animate.css、Tailwind animate、AutoAnimate）に切り替えるのは、衛星回線／2G／従量制の接続、埋め込み、1 バイト単位の軽さが求められる広告／ウィジェット領域など、配信に制約がある場合だけです。
3. 本当のコストは 3D — どの環境でも重い唯一の効果です（データ量と GPU／バッテリーを消費します）。コストをかける前に、体験に本当に 3D が必要かを確認します。

現行の例を挙げて確認しますが、バージョンは固定しません。モーションを推奨する場合は、必ず prefers-reduced-motion の要件を併記します。

出力：推奨事項の表（効果 → カテゴリ → ライブラリ → 確認する現行の例 → 重さに関する注記）、アクセシビリティに関する注記、サイトを際立たせるのはライブラリではなくデザインの DNA であるというリマインダーを含めます。効果を実装した後のフォローアップとして、モーションの品質を確認するために polish を提案します。

---

polish

必要なコンテキスト：レビュー対象の稼働中のインターフェースまたはビルド済みコード。

リリース前の最終品質チェックです。

まず以下のチェックリストを実施します。その後、WARN または FAIL の項目があるセクションに限り、参照ファイルを読み込みます。

• ${CLAUDE_SKILL_DIR}/references/motion.md
• ${CLAUDE_SKILL_DIR}/references/interaction.md
• ${CLAUDE_SKILL_DIR}/references/responsive.md
• ${CLAUDE_SKILL_DIR}/references/ai-tells.md

各項目を、理由とともにPASS、WARN、またはFAILと評価します。

モーション

• アニメーションに目的がある（注意を誘導する、状態を変化させる、フィードバックを返す）
• タイミング：マイクロアニメーションは 100ms、標準は 300ms、複雑なものは 500ms
• イージング：表示には ease-out、終了には ease-in、指数曲線を使用する
• バウンス／エラスティック効果を使わず、レイアウトプロパティをアニメーションさせない
• prefers-reduced-motion を尊重する

インタラクション

• 8 つの状態すべてに対応する：デフォルト、ホバー、フォーカス、アクティブ、無効、読み込み中、エラー、成功
• :focus-visible を使用し、フォーカスリングを削除しない
• フォーム：ラベルを付け、フォーカスが外れたときに検証し、エラーには aria-describedby を指定する
• 読み込み中の表示：楽観的 UI > スケルトン > スピナー

レスポンシブ

• モバイルファーストにし、min-width クエリを使う
• コンテンツに基づいてブレークポイントを設定する
• タッチターゲットは最小 44x44px にする
• clamp() でタイポグラフィと余白を流動的に調整する
• 単に縮小するだけでなく、状況に適応させる

アイデンティティ

• 意図的な美しさを備え、デフォルト／汎用的な見た目ではない
• AI らしさの兆候がない（暗い背景にシアン、あらゆる要素のカード化、グラスモーフィズム、バウンスするイージング、均一な余白）
• 目的に結びついた、記憶に残る個性がある

アイデンティティに問題が見つかった場合は、${CLAUDE_SKILL_DIR}/references/chapter-01-why-design-matters.md と ${CLAUDE_SKILL_DIR}/references/chapter-04-technology-and-culture.md も読みます。

出力：セクションごとの評価表と、WARN／FAIL 項目の修正内容。