UI Max

UI Max は何をしますか？

製品のユーザビリティを装飾的な効果よりも優先します。要件を満たす最もシンプルで一貫性のあるシステムを選択し、コンポーネントライブラリをむやみに追加しないでください。

製品から始める

コードを変更する前に:

1. フレームワーク、ルーター、CSSシステム、コンポーネントライブラリ、アイコンとアニメーションライブラリ、フォームスタック、デザイントークン、ダークモード、確立されたパターンを検査します。
2. ユーザーの目標、主要ワークフロー、情報階層、プライマリアクションとセカンダリアクション、必要な状態、レスポンシブサーフェス、キーボード操作を定義します。
3. この順序で再利用します: ローカルコンポーネント、既存のデザインシステムプリミティブ、shadcn/ui、Radix UI、21st.dev、特殊な拡張ライブラリ、カスタム実装。
4. 既存の安定したUIシステムを維持します。1つの魅力的なコンポーネントのために競合する完全なシステムを導入しないでください。

1つの基盤を選択する

新しいReact製品インターフェースの場合、デフォルトとして:

React + TypeScript + Tailwind CSS
shadcn/ui -> Radix UI プリミティブ
Lucide アイコン
Motion for React (必要な場合のみ)
React Hook Form + Zod (本格的なフォーム用)
TanStack Table (高度なテーブル動作のみ)

このスタックを、既存のシステムが確立されているプロジェクトやVue/Svelteプロジェクトに強制しないでください。そこではエコシステムネイティブのライブラリを使用します。

追加を選択する前に、サーフェスを分類します:

• コア製品UI: shadcn/ui + Radix UI + Tailwind CSS。
• AI製品UI: 実際のAIワークフローパターンにのみCult UIを追加。Motion Primitivesで控えめなトランジションを使用。
• マーケティングページ: 構造に21st.dev、Magic UIを選択的に、Aceternityは本当にインパクトのあるセクションにのみ使用。
• データ密度の高いアプリケーション: 並べ替え、フィルタリング、ページネーション、選択、可視性、仮想化、または複雑なデータモデルが正当化される場合にTanStack Tableを追加。
• マイクロインタラクション: Motion Primitives または Motion を使用。UIverseはアクセシビリティと保守性のレビュー後にのみ使用。

ライブラリ/コンポーネントの選択、インストール、調達、代替案の比較、または視覚パターンの調査を行う際は、references/component-selection.md を参照してください。

一貫性を持って実装する

再利用またはコピーしたすべてのコンポーネントをプロジェクトの以下に合わせて正規化します:

• セマンティックカラートークン
• タイポグラフィ、スペーシング、半径、シャドウのスケール
• アイコンファミリー
• アクセシビリティ規則
• レスポンシブ動作
• ライトテーマとダークテーマ

散在するハードコードされた値ではなく、セマンティックトークンを使用します。関連するコントロールは近くに配置し、無関係なセクションは分離します。不当にネストされたカードは避け、比較にはリスト/テーブルを、個別にアクション可能で異種のアイテムにはカードを使用します。プライマリアクションは明確にし、破壊的なアクションは日常的なアクションから離して配置します。

ブランディングで特に必要がない限り、1つのインターフェースフォントと1つのアイコンファミリーを使用します。モーションは、状態、階層、連続性、原因/結果、進行状況、またはフォーカスを伝えるためにのみ使用します。prefers-reduced-motion を尊重します。

本格的なビジュアル実装、レスポンシブ作業、状態設計、フォーム、テーブル、またはアクセシビリティ作業の前に、references/design-standards.md を参照してください。

実際の状態をカバーする

非同期またはデータ駆動型のUIの場合、以下を考慮します:

• 初期ローディングとバックグラウンド更新
• 空の結果と検索一致なし
• 成功、警告、エラー、部分的な失敗
• 無効状態とオフライン状態
• 欠落している権限または統合
• 古いデータ

構造がわかっている場合はスケルトンを優先します。エラーでは、何が失敗したか、理由（既知の場合）、作業が保存されているか、何が解決するかを明確にします。完成した製品で、意味のないモックデータ、偽の分析、架空のエージェントアクティビティ、または機能しないコントロールを決して使用しないでください。

既存のUIをクリーンアップする

重複、スペーシング、色、タイポグラフィ、バリアント、アイコン、ネストされたレイアウト、繰り返されるユーティリティ、レスポンシブネス、アクセシビリティ、未使用のコード/依存関係、アニメーションの過剰、欠落している状態を監査します。

ボタン、入力、ステータスバッジ、ダイアログ、メニュー、タブ、ページヘッダー、空/エラー/ローディング状態、サイドバーアイテム、プロジェクト行など、繰り返されるまたは動作を持つプリミティブを統合します。一貫性、ロジック、再利用、またはテストのメリットなしに、1回限りのマークアップを抽象化しないでください。

繰り返される値をトークン化します。不要なラッパー、ネストされたカード、装飾的な区切り線、繰り返されるラベル、冗長なアクション/ステータス、過剰な説明、不当なモーションを削除します。

レンダリング出力を検証する

以下を確認します:

• セマンティックHTML、アクセシブルな名前、ラベル、論理的なタブ順序、キーボード操作、ダイアログフォーカス、可視フォーカス、コントラスト
• ローディング、空、無効、エラー、成功、長文、破壊的な確認の状態
• クリッピング、読めないテーブル、レイアウトシフト、水平オーバーフローのない狭い/広いレイアウト
• reduced-motion動作、ライト/ダークテーマ、レスポンシブナビゲーション
• フォーマッター、リンター、TypeScript、テスト、プロダクションビルド、コンソール出力

必要に応じて、320、375、768、1024、1280、1440 pxでテストします。ブラウザ拡張の場合は、ポップアップ幅は320～420 px、サイドパネルは320～600 pxでテストします。

完了を宣言する前に、狭い幅と広い幅で実際にレンダリングされたUIを検査します。スクリーンショットループまたはプロジェクトの既存のビジュアル検証ワークフローを使用し、実際のターゲットでプラットフォーム固有のサーフェスを確認します。

UI作業を報告する

ページのデザインまたは再構築を求められた場合、簡潔なセクションで以下を提供します:

1. 製品解釈: 目標、主要ワークフロー、主要情報、メインアクション。
2. コンポーネント計画: 構造、再利用可能なコンポーネント、基盤、特殊な追加、レスポンシブ動作、重要な状態。
3. 実装: 既存のスタックでの動作コード。
4. 検証: アクセシビリティ、レスポンシブネス、状態、キーボード動作、デザイントークンの一貫性、レンダリングされたビジュアルレビュー。

ユーザーがオプションを求めない限り、ライブラリカタログを返さないでください。