UI Designer Skill

発火条件（適用タイミング）

• 依頼が「画面設計」「UI方針」「コンポーネント設計」「情報設計」「トーン&マナー」「デザインシステム」「画面の骨格」なら適用する。
• doc/input/design/ がある、または /design-extract / /design-skeleton の利用時に優先適用する。

このSkillの基本方針（整理軸）

• 基本方針: UIは“絵”ではなく“意思決定の補助”。ユーザーの目的達成を最短にする。
• ルール化: 反復するUIはコンポーネント化し、揺れはトークンで止める。
• 実装可能性: 仕様は状態（loading/error/empty/disabled）まで含める。

思想（判断ルール）

1. 優先度を先に決める（何を最初に見せ、何を後回しにするか）。
2. 一画面に詰めない。段階（progressive disclosure）で見せる。
3. 状態は必ず定義する（通常/ローディング/空/エラー/権限なし）。
4. 一貫性は“ルール”で担保する（コンポーネント/トークン/余白/タイポ）。
5. 実装者が迷わない仕様にする（文章で曖昧にしない）。
6. "らしさ"は規範/逸脱のペアで設計する。差別化は「ベストプラクティスをどこで意図的に外すか」から生まれる。逸脱は意図を明示し、なんとなく外さない。
7. 格（レジスタ）を揃える。フォーマル度の違う要素を無造作に混ぜるとチグハグになる。構造は精密に、遊び・有機性は"点"で効かせる。

進め方（最初に確認する問い）

• 画面の目的は？（何を完了できれば成功か）
• 主要ユーザーは誰？（ペルソナ/利用文脈）
• 重要操作は何？（primary action）
• 例外は？（空/エラー/権限/遅い通信）
• 再利用の範囲は？（ページ固有か、横断か）

出力フォーマット（必ずこの順）

1. 画面の目的/成功条件
2. 情報設計（優先度・構造）
3. コンポーネント案（責務/props/状態）
4. トークン/スタイル方針（色/余白/タイポ）
5. 例外状態の仕様（empty/error/loading）
6. 次アクション（プロトタイプ→実装）

よくある落とし穴

• 例外状態が未定義で、実装が場当たりになる
• 見た目の揺れをトークン化せず、magic numberが増える
• 画面目的が曖昧で、要素が増殖する