imagile-dev/design

デザイン

生成されたものではなく、選ばれたものとして読ませるインターフェースを作る。すべてのデフォルトは誰かがスキップした決断である。このスキルは、それぞれの決断を意図的に行う。最初にブリーフ、次に品質下限までのビルド、そして実際のスクリーンショットの批評という流れだ。

2つの失敗モードがあり、最初のものがより深刻である：

1. ジェネリック。そのページは、そのカテゴリのどの製品にも属しうる。現在のAIデフォルトをまとっているか、誰も覚えていないほどプレーンであるかのどちらかだ。
2. ノイズが多い。すべての要素が主張する。モーション、グラデーション、装飾が競合し、何が最初に読まれるべきかがわからない。

両方の治療法は、1つの強力なアイデアを、1つの場所で、規律あるシステムの中で表現することだ。抑制が目標ではない。意図が目標である。

1. モードを選ぶ

モード	使用する場面	手順
ビルド	新しいページ、画面、コンポーネント、デッキ、画像セット	セクション2から5
リファイン	「もっと大胆に、静かに、シンプルに、カラフルに、生き生きと」	セクション6
批評	「これをレビューして」「これは正しく見えますか？」スコア	references/critique.md
磨き込み	視覚的なものを出荷する前に	セクション7

リファインは決してリデザインしない。アイデンティティ、コピー、リクエスト以外のすべてを維持する。リクエストがリデザインを必要とするなら、そう伝えて停止する。両者の間の妥協点を取ろうとしてはならない。

2. 最初にコンテキストを読み込む

1. リポジトリルートのDESIGN.md、リポジトリのCLAUDE.md、既存のトークン（global.css、tailwind.config.*、テーマファイル）、および.claude/image-generation/style.mdを読む。
2. ブリーフが優先される。 DESIGN.mdまたはユーザーが特定のルックを指定した場合、それが「ダメな見た目（tells）」リストに載っていても、完全にそれに従う。以下のルールは、まだ誰も選択していないものにのみ適用される。
3. DESIGN.mdがない場合は、リポジトリを調査し、その後、耐久性のある事実について最大3つの質問をする：誰が使うのか、何を達成しなければならないのか、どんな証拠があるのか。抽象的に美観を選ばせてはならない。代わりに2つか3つの選択肢を示す。
4. 学んだことをreferences/design-md.mdからDESIGN.mdに書き込む。次のセッションで再度尋ねる必要があってはならない。
5. 修正は継続的なルールとなる。 ユーザーが視覚的な選択を修正した場合、同じターンでDESIGN.mdの「Standing rules」に1行追加する。
6. 手元にある証拠のみを使用する。 決して推薦文、顧客ロゴ、ユーザー数、指標、引用を捏造してはならない。プレースホルダーデータをマークし、ユーザーが確認できるようにリストする。

3. ブリーフを書く（ビルドモード）

コードを書く前に、チャットで短いブリーフを投稿する。これには1分かかり、ジェネリックな結果を防ぐ。

1. デザインリード。 一行：「これを[対象者]向けの[サーフェス]として、[モード]モードで、[方向]寄りで読む。」

2. サーフェスモード。 製品ごとではなくサーフェスごとに1つ選ぶ。開発者ツールのランディングページでも「説得」モードである。

   モード	サーフェス	表現	バリアンス / モーション / 密度
   説得	ランディング、価格、ローンチ、ポートフォリオトップ	1つの大きなアイデア、本物の画像、カラーフィールド	7 / 6 / 3
   操作	アプリ、ダッシュボード、設定、管理	システム自体がデザイン。見せかけはなし	3 / 2 / 7
   読む	ドキュメント、記事、レッスン	タイプがページを支える	3 / 2 / 5
   体験	ゲーム、遊び心のある学習、子供向け、イベント	キャラクター、アンビエントモーション、ユーモア	8 / 8 / 4

   3つのダイヤルは1から10で動作する。バリアンスは対称性から大胆な非対称性へ。モーションは静的から映画的へ。密度はギャラリーからコックピットへ。そこに雰囲気を示す言葉を読み込む：「ミニマル」はバリアンスと密度を下げ、「派手」「活気のある」はモーションを上げ、「密度が高い」「プロフェッショナル」は密度を上げる。ダイヤルをDESIGN.mdに記録する。

3. シーンセンテンス。 誰が、どこで、どんな光の下で使うのか。「薄暗い休憩室でスマートフォンでスケジュールを確認する夜勤の看護師」は、ダーク/ライトを決定する。「dev toolはダーク」のようなカテゴリラベルでは決めない。

4. アイデアセンテンス。 「[この被写体だけが持つ何か]が[視覚的装置]になる。」 次に競合他社テストを実行する：競合他社の名前を入れ替えてみる。それでもセンテンスが成立するなら、アイデアはジェネリックである。書き直す。

5. トークン。 4～6の名前付きカラーとカラー戦略（references/color.md）。タイプファミリーとその役割（references/typography.md）。レイアウトコンセプトを1文とASCIIワイヤーフレームで。モーションレベル。

6. 主張（説得のみ）。 セクションごとに1つの主張と、それぞれの証拠。主張のないセクションは削除する。ヒーロー、ロゴストリップ、3つの特徴、CTAをデフォルトにしてはならない。

7. 「ダメな見た目（tells）」に対してチェックする。 ブリーフが自由にしているすべての軸について、references/tells.mdを読む。テーマがカテゴリだけから推測できるか、次にルックがカテゴリと「ありきたりでないルック」から推測できるかを問う。どちらかの答えが「はい」の場合、その部分を修正し、何が変わったかを言う。

4. 品質下限までビルドする

大胆さは1つの場所に使う。1つの要素を記憶に残るものにし、その周りは静かに保ち、アイデアに貢献しない装飾は削る。「ダメな見た目」を取り除くときは、そのスペースを何か本物で埋める：スケール、画像、コンテンツ、カラーフィールド。単に取り除くだけでは、薄っぺらで空虚なページになる。

品質下限は、宣言されることなくすべてのサーフェスで保持される：

• トークン、リテラルではない。 色、タイプ、スペース、半径、モーションは:rootのトークンとして存在する。ライトとダークはprefers-color-schemeから取得し、data-themeで上書き可能とする。トグルがある場合はそれが優先される。
• コントラスト。 テキストは4.5:1、大きなテキスト、アイコン、コントロール、フォーカスリングは3:1。色付きの背景にグレーのテキストは絶対に避ける。
• タイプ。 最大2ファミリー。5サイズ以下。本文は16px以上で、1行あたり45～75文字。見出しはすべての幅で2行に収まる。
• モバイルファースト。 320pxから、16pxのガターで、横スクロールなしで動作する。タップターゲットは44px。入力は16px（iOSでズームされないように）。ズームを無効にしてはならない。
• 状態。 すべてのコントロールに、デフォルト、ホバー、focus-visible、アクティブ、無効、ローディング、エラー、成功の状態がある。すべての非同期領域に、ローディング、空、エラーの状態がある。
• 安定性。 レイアウトシフトがない。アニメーション付きまたは非同期パネルは固定高を維持する。グリッド内のカードはフッターを固定して同じ高さを共有する。
• クリック可能なものを傾けてはならない。 傾きは装飾的なスタンプやステッカーのみに使用する。
• モーション。 目的があり、中断可能で、transformとopacityのみを使用し、prefers-reduced-motionの下ではより控えめにする。コンテンツはJavaScriptなしでも表示可能であること。
• 画像。 一貫性のあるスタイルの、本物または生成されたアート。キャラクターと装飾アートは透明な切り抜きとして出荷し、暗いボックスにしてはならない。画像にテキストを埋め込まない。
• コピー。 短く、具体的で、ユーザー側から書く。ビジュアルは段落よりも優れる。

詳細はリファレンスにある。タスクに必要なものだけを読む：

ファイル	カバー内容
references/typography.md	フェイスの選択、スケール、メジャー、ディスプレイタイプ、ローディング
references/color.md	カラー戦略、OKLCHトークン、ダークモード、コントラスト
references/layout.md	スペース、フレーム、グリッド、階層、レスポンシブとタッチ
references/motion.md	アニメーションの有無、イージング、持続時間、パフォーマンス、動きの抑制
references/interaction.md	状態、フォーム、最悪ケースのデータ、知覚速度
references/copy.md	UXライティング、エラー、空の状態、正直なコンテンツ
references/imagery.md	アートディレクション、生成アート、写真、アイコン
references/decks.md	スライドデッキとトーク
references/tells.md	生成デザインのデフォルトの時代遅れリスト

5. 見てみる

コードレビューはデザインレビューではない。レンダリングして見る。

1. ページを実行し、375pxと1440pxでスクリーンショットを撮る。また、そこでレイアウトが変わる場合は768pxでも撮る。ライトとダークの両方が存在する場合は、両方を撮る。playwright-cli、ブラウザペイン、またはセッションで使用可能なブラウザツールを使用する。
2. 各スクリーンショットを目を細めて見る。プライマリ要素、セカンダリ要素、グループがその順序で読み取れるはずである。
3. 衝突を探す：重なり、クリップされたバナー、不意に折り返すテキスト、位置のずれたアイコン、不均一なグリッド、2x2であるべきところが3+1行になっている箇所など。
4. references/critique.mdで批評し、その修正順序で修正し、再度キャプチャする。3ラウンド後に停止し、残っているものを報告する。
5. ゲームやインタラクティブな作品の場合は、実際にプレイする。サブエージェントがモバイル幅でプレイテストすると、コードを読むだけでは決して見つからないものが見つかる。
6. 開発サーバーを起動したままにして、ユーザーにURLを教える。最終的なスクリーンショットをPRに入れる：モバイルとデスクトップ、ライトとダークの両方。

方向性が未定の場合（フォント、ロゴ、パレットなど）、2つか3つの小さなモックアップを並べて作成し、ユーザーに選んでもらう。その後、選ばれたものをビルドする。

6. リファイン

すべてのリファインは1つの方法に従う：現在の状態を評価し、1文のテーゼを書き、既存のシステムの語彙で適用し、スクリーンショットを撮り、磨き込む。

リクエスト	何をするか
もっと大胆に	ターゲットの自信レベルを隣接要素と同等に上げる：スケール、ウェイト、色へのコミットメント、画像。その後、その周りを静かにする
もっと静かに	アクセサリーを1つずつ取り除く。モーションダイヤルを下げる。色をより少ない役割に統合する
もっとシンプルに	主張のないセクションを削除する。言葉を半分に削る。段落を1つのビジュアルにする
もっとカラフルに	カラー戦略のはしごを一段上がる。最初に2つ目のアクセント色を追加してはならない
タイポグラフィ	references/typography.mdからスケールと組み合わせを再構築する
レイアウト	references/layout.mdからフレーム、左端、リズムを修正する
アニメーション	最初にreferences/motion.mdの頻度ゲートを通過する。次に、1つのオーケストレーションされた瞬間を追加する
より明確なコピー	references/copy.mdを適用する
レスポンシブ	最初に375px用に再構成する：シングルカラム、本物のタップターゲット、クリップされたものなし
堅牢化	最悪ケースのデータを入力し、references/interaction.mdから欠落している状態を追加する

7. 出荷チェックリスト

視覚的な作業が完了したと呼ぶ前に、これを実行する：

• DESIGN.mdが、行われた決定と与えられた修正を反映している
• 375pxとデスクトップ、ライトとダークのスクリーンショットに、衝突やクリッピングがない
• ブリーフで指定されていない限り、references/tells.mdのものは何も表示されていない
• すべてのコントロールに状態があり、すべての非同期領域にローディング、空、エラーの状態がある
• 最悪ケースのデータがレンダリングされる：長い名前、0件と1件のアイテム、巨大な数値
• キーボードですべてに到達でき、フォーカスが可視であり、動きの抑制が尊重されている
• accessibilityスキルが、主要なテーマで深刻な違反を0件と報告している
• 画像は一貫性があり、必要な場所で切り抜かれており、web-optimizeで最適化されている
• コピーはユーザーが必要とするものに削減され、捏造された証拠がない
• 開発サーバーが実行中で、PRにスクリーンショットがある

関連スキル

• accessibility は、axe-coreを使用してWCAG 2.2 AAをさまざまな幅、スキーム、テーマにわたって監査する。
• image-generation は、パレット固定のstyle.mdからアートを生成する。background-removalが切り抜く。web-optimizeが出荷する。
• architecture は、そのwebリファレンスにサイトのスタックデフォルトを保持する。

クレジット

このスキルは、Anthropicのfrontend-designスキル（Apache-2.0）、Paul BakausのImpeccable（Apache-2.0）、Emil Kowalskiのdesign engineeringスキル（MIT）、Leonxlnxのtaste-skill（MIT）からのアイデアを言い換え、組み合わせたものである。テキストはコピーされていない。各リファレンスファイルは、そのルールのソースを明記している。