UIデザイン
画面を依頼されたエージェントは画面を書きます。このスキルはその両側のギャップを埋めます。まず、画面の目的と見た目を決めること。次に、構築したものが役割を果たしているかを確認すること。
以下のすべてを2つのルールが支配します。最初のファイルの前に、顧客が達成する成果を名付けよ。動く製品を動かしてから、それが機能すると言え。
まず深さを選ぶ
| 変更内容 | ステージ |
|---|---|
| コピー、色、1つのプロパティ | 1、7、その後結果を確認 |
| 1つのコンポーネント、1つの状態 | 1、4、6、7、9 |
| 1画面、1フォーム、1フロー | 0～10を簡潔に |
| 新しい画面、または「これをモダンに」 | 0～10を完全に、ステージ3をステージ7の前に承認 |
| 「これを監査して」 | ui-reviewを使用。編集を開始しない |
| 「…のコンポーネントを探して」 | ui-findを使用 |
開始前に、選択した深さを1行で述べよ。ステージをスキップできるのは、変更がそのステージが保護するものに到達できない場合のみである。
0. 事前確認：質問する前にプロジェクトを読む
以下の順序で読み、質問を解決できる最初のもので止まれ：
- プロジェクトルートの
DESIGN.md。既存のデザインシステムは、このスキルのすべてのデフォルトとあなた自身の好みに優先する。 それに従え。作業にファイルがカバーしていないものが必要な場合は、スタイルシートで発明するのではなく、ファイルに追加せよ。 PRODUCT.md、README.md、.claude/、既存のブリーフ。- 使用されているスタック、スタイリングシステム、コンポーネントライブラリ。
- 最も近い既存の画面、およびそれをカバーするテスト。
製品自身のシステムと矛盾する画面は、発見事項であって、第三のシステムを開始する許可ではない。
1. デザインシステム
references/design-system.mdにフォーマットと、そこへの2つのルートが記載されている。
| プロジェクトの状態 | 実行すること |
|---|---|
DESIGN.md がある | それを読み、従い、その旨を1行で述べる |
| コード内に実際のデザインシステムがある：トークン、テーマファイル、Tailwind設定 | コードから値を読み取ってDESIGN.mdに体系化する（決して推測しない） |
| 文書化されたシステムのないライブ製品またはブランド | 実際のものから体系化する：レンダリングし、計算された値を読み取り、記録する |
| 何もない | ステージ3で、ユーザーが選んだ方向性から一つ書く |
製品が使用していない値を述べるDESIGN.mdを決して書くな。体系化されたシステムは、そこにあるものの記録である。新しいシステムは提案であり、ユーザーが選ぶまでそのようにマークされる。
それに対して構築する前にファイルをゲートせよ：
pnpm dlx @google/design.md lint DESIGN.md
これは実際に公開されているパッケージである。壊れたトークン参照、primaryの欠落、定義されていないタイポグラフィ、4.5:1のコントラスト基準を下回るコンポーネントカラーペアを検出する。ステージ7の前に報告されたものを修正せよ。
2. 顧客の成果
references/product-thinking.mdに手法が記載されている。ビジネス成果、顧客とそのジョブ、そして最小限の有用なバージョン。それぞれ2行。
成果を観察可能なものとして書け：
40件のオープンランを持つディスパッチャーは、リストを離れることなく、どのランが遅れているかを確認し、それを再割り当てできる。
次に、それぞれブラウザで確認できる受け入れ基準。「見た目が良い」は基準ではない。「375pxで、各ランのステータスとその再割り当てコントロールが水平スクロールなしで操作可能である」が基準である。
証拠がない場合は、前提を書き、ラベルを付けよ。誰も作成していないペルソナ、引用、コンバージョン数値を決して書くな。
3. 方向性とユーザーの選択
references/directions.mdに手法と語彙が記載されている。
3つの方向性を示せ。1つではない。単一の提案は、モデルのデフォルトの美学に理屈をつけたものに過ぎない。各方向性には、名前、アンカーヒュー、タイプの組み合わせ、密度、そして覚えやすい点の1つを、4行で示せ。
その後、止まって対話型質問ツールでユーザーに提示せよ。これは承認ゲートである：前提でこれを超えて構築してはならない。ユーザーが「あなたが選んで」と言った場合は、1つ選び、どれとその理由を1行で述べ、続行せよ。
「はい」の場合は、選ばれた方向性の実際の値でDESIGN.mdを書くか更新し、lint せよ。
4. ジャーニーとその状態
references/journey-and-states.md。
この画面が実際に持つ状態をリストアップせよ：空、1アイテム、多数、最も密度の高い実際のケース、ローディング、部分的な失敗、エラー、権限なし。1つのフィクスチャで構築された画面は他のすべての状態を隠す、そしてこれが、完成した画面が顧客との接触で失敗する最も一般的な理由である。
5. コンポーネントを書く前に探す
ui-find、またはそのスクリプトを直接実行せよ：
node .claude/skills/ui-design/scripts/find-components.js <用語> --limit 15
最初にプロジェクト自身のコンポーネントを検索せよ。製品がすでに持っているコンポーネントの2回目の実装は欠陥である。読み込んだ候補と、それぞれが不適切だった理由を述べてから、スクラッチでコンポーネントを書け。
6. モック、または実際の製品
ユーザーがすでに言っていない限り、1行でどちらかを尋ねよ。両方のルートは実際のHTMLとCSSを構築する；違いはファイルの配置場所と、何に配線されるかである。
| ルート | いつ | どこへ |
|---|---|---|
| モック | 新しい画面、リデザイン、説得すべきステークホルダー、またはユーザーが依頼した場合 | mock/下のスタンドアロンページ。実際のデザイントークンと、サンプルであることが一目でわかるサンプルデータを使用 |
| 直接 | ライブ製品内の変更、またはユーザーが構築を依頼した場合 | 製品自身のファイル |
モックは承認され、その後製品のコンポーネントで再構築される。構築前にその旨を述べ、モックファイルが出荷されることを誰も期待しないようにせよ。
7. 構築
ハッピーパスだけでなく、ステージ4の状態を構築せよ。製品自身のトークンとコンポーネントを使用せよ。
最初のUI編集の直前に、毎回、小さな編集も含めて、references/gates.mdとreferences/craft.mdを読め。
gates.mdは最低基準である：すべてのモデルが陥るデフォルトと、代わりにすべきこと。craft.mdはその上の層である。境界線ではなく影としての深さ。同心円の半径。300ms未満のイーズアウト。一度だけ発火し、繰り返しのインタラクションでは決して発火しないエントランス。表形式の数字。画面の2つの部分が接続され、顧客がそれらが1つのものであると認識できるようにする。
最も重要な画面、またはヒーローを、単独で最初に構築せよ。残りを構築する前に、新鮮な目でレビューせよ：判断の記憶を持たないサブエージェントが、あなたには見えないものを発見する。その後、残りを構築せよ。
8. 実行して見る
ソースレビューではない。アプリケーションを起動し、ブラウザで開き、顧客がそうするように実際のエントリポイントから使用せよ。
references/playwright.mdに、メカニズムと、アプリケーションがここで起動しない場合の対処法が記載されている。
スクリーンショットを見よ。ファイルリストを読むことは見ることではない。
9. レビューと修正
構築したものに対してui-reviewを実行せよ。ライブレンダリングを測定し、ジャーニーをたどり、結果をDESIGN.mdと照合し、害の順に発見事項を分類する。
深刻度順に修正せよ。ステージ2の成果に対して正当化できない変更は、誰も依頼していないスコープである。手を付けなかったものとその理由を述べよ。
次にreferences/regression.md：コードに触れる前から機能していたジャーニーを特定し、あなたの変更によって引き起こされた障害と、もともとあった障害を分離せよ。
10. 報告
- 顧客の成果、およびそれが満たされているかどうか。
- 選択された方向性、および誰によって。
- 構築または変更されたもの（ファイルごと）。
- 検証されたもの、その手段、どの幅で、どの状態で。
- 検証されなかったもの、およびその理由。
- 修正された発見事項、および残された発見事項とその理由。
- 依然として前提である前提。
誠実さ：これは上記すべてのステージに優先する
- 測定していない測定値やレンダリングしていない画面を決して報告するな。
- すべての代用物に名前を付けよ。ライブデータの代わりのフィクスチャ、アプリケーションの代わりの静的ページ、ブランドフォントの代わりのローカルフォント。
- アプリケーションを起動または到達できない場合は、その旨を述べ、すべてのジャーニーの主張を未検証とマークせよ。ソースが実行されているのを見たかのように説明するな。
- 指標、推薦の言葉、ロゴウォール、顧客数を決して発明するな。実際の数字がない場合は、ラベル付きのスロットを残し、空であると述べよ。
- 背後に何もないフォームは、そのことを表面に示せ。「送信」と表示するだけで送信しないページは、プレースホルダーではなく欠陥である。
- 自分でジャーニーをたどることは摩擦を見つける。それは顧客が何をするかを測定するものではない。
このスキルが借用するものとその出典
NOTICEに記録されている。コンポーネントのソースとそのライセンスはsources.jsonにあり、scripts/check-sources.jsがそのファイルを検証し、tests/run.shがスクリプトをテストする。