add-ui

必須の事前準備

ユーザーは /add-ui でこのワークフローを開始します。add-ui は、このリポジトリでの正式なスキル名です。ホストによっては親しみやすい /add エイリアスを公開する場合がありますが、ドキュメント、ラッパー、ソースファイルでは引き続きスキルを add-ui と表記してください。

frontend-design を読み、そのコンテキスト収集プロトコルに従ってください。利用可能なコンテキストを再利用し、重要な情報が不足している場合に限って質問してください。

新規のランディングページ、マーケティングページ、または複数の異なる方向性が求められていて、デザインの方向性がまだ決まっていない場合は、frontend-design の デザインの方向性 にある承認済みのスタイル選択ルールを使用してください。漠然とした雰囲気のラベルを独自に作るのではなく、プロダクトのアイデアとブランドのコンテキストに合う方向性を選んでください。

確立されたビジュアルシステムのある既存プロジェクトで作業する場合は、まずそのシステムを維持し、プロダクトのブランドをひそかに変更することなく、それぞれの選択肢に違いを持たせてください。

ランディングページのバリエーションでは、ユーザーの構造上の制約を踏まえて、冒頭、ナビゲーション、根拠を示す順序、締めくくりを比較するために、ランディングページのストーリーテリング を使用してください。

また、実用的なコードを生成するために必要な、最小限の実装情報を集めてください。

• React フレームワーク／ランタイム（React、Next.js、React Router、TanStack Start、Vite React、または React アイランドを含む Astro）
• Tailwind のセットアップとテーマトークンの規約
• 挿入先（新しいルート、既存ページ、共有コンポーネントフォルダー、デザインシステム領域）
• 新規の成果物か、既存のものの再デザインか
• ユーザーが求めているのはセクション、ページ、フロー、シェル、単独のコンポーネントのいずれか
• 求める品質水準（簡易なドラフト、本番環境向け、フラッグシップ）

既存の成果物を再デザインする場合は、次の点も確認してください。

• 見慣れたものとして残す必要がある部分（コンテンツブロック、セクションの順序、インタラクションモデル、馴染みのある操作要素、ブランドの手がかり）
• 柔軟に変更できる部分（スタイル、色、コピー、タイポグラフィ、メディアの扱い、情報密度、詳細の表現）
• ユーザーが求めるのは、ほぼ安全な改良、幅広い方向性の検討と比較、または挑戦的な方向性を1つか2つ試すことのいずれか

実装のデフォルトを決める際は、次の優先順位に従ってください。

1. まず既存プロジェクトの React フレームワーク、Tailwind のセットアップ、コンポーネントライブラリを検出し、それに合わせる
2. 新規プロジェクトで、ユーザーが対応する React コンポーネントライブラリを明示した場合は、それを使用する
3. 新規プロジェクトで、ユーザーが指定しない場合は、frontend-design で定義されたフレームワークのデフォルトを使用する

依頼された成果物で、プリミティブ、再利用可能なパターン、ブロックアクセラレーターのどれを中心にするか判断するため、コンポーネントライブラリの統合 も参照してください。

不足している質問だけをしてください。コードベースから技術スタックを推測できる場合は、そうしてください。

必要に応じて、次のリファレンスを参照してください。

• 成果物の分類
• コンポーネントライブラリの統合
• バリエーションの品質基準
• プレビューと適用のパターン
• 依頼のマッピングに関するヒューリスティクス
• 例とコマンドの命名

ホストやエージェント間の一貫性を高めるのに役立つ場合は、次の決定論的なヘルパーアセットを使用してください。

• 比較表のテンプレート
• コンポーネントライブラリ統合チェックリスト
• バリエーションの命名規則
• プレビューページのチェックリスト
• 適用／クリーンアップのチェックリスト

---

依頼された成果物を直接実装してください。ユーザーが代替案を求める場合は、意味のある違いのある方向性を生成し、それらの比較と統合を支援してください。

これには、新しい UI の追加と既存 UI の再デザインの両方が含まれます。 既存のページ、セクション、フロー、シェル、コンポーネントの再設計を依頼された場合、ユーザーが構造の刷新を明示的に求めない限り、成果物として認識できる基本構造を維持することを基本とします。通常、具体的には次のようになります。

• 現状ですでに目的を果たしている情報設計、コンテンツブロック、順序を維持する
• 明らかに機能していない場合や、ユーザーがより大きな UX の変更を求めている場合を除き、慣れ親しんだインタラクションやアフォーダンスを維持する
• タイポグラフィ、色、コピーの見せ方、メディアの扱い、細部の表現、余白のリズム、強調方法を通じて、ビジュアルシステムを進化させる
• どの要素が維持され、どの要素が変わったのかが、選択肢全体を通して明確に伝わるようにする

ある案で意図的に構造を大きく変える場合は、既存のページをひそかに作り替えるのではなく、思い切った案であることを明確に示してください。

このスキルは、次のようなリクエストに対応します。

• マーケティングおよび収益化の画面：ヒーロー、機能、料金、推薦コメント、FAQ、CTA、ロゴ一覧、ギャラリー、ブログ、会社情報、お問い合わせ、プラン選択、アップグレードモーダル、ペイウォール
• ナビゲーションおよびシェル：ナビバー、フッター、ダッシュボードシェル、オンボーディングフィード、設定、カードナビゲーション
• 認証およびアカウント：ログイン、登録、パスワードを忘れた場合、パスワードのリセット、メールアドレスの確認、二要素認証
• コマース：製品概要、製品カテゴリ、製品一覧、フィルター、カート、チェックアウト、レビュー、注文概要、ギフトカード
• データ UI：チャート、ウィジェット、データテーブル、フォーム、比較ビュー、Bento グリッド、タイムライン、ダッシュボード

このリストは一例であり、すべてを網羅しているわけではありません。

基本的な運用ルール

1. 色を変えるだけではなく、実質的な選択肢を作る

   • バリエーションは、バリエーションの品質基準における関連性の高い次元のうち、少なくとも 2 つで異なる必要があります。固定された構造とブランド上の制約は維持してください。
   • パレット、角丸、アイコンセットだけを変えても、新しい方向性とはみなされません。

2. 依頼された目的から始める

   • 料金セクションは、単なるカードの集まりではありません。
   • ログイン画面は、単なる入力欄ではありません。
   • ダッシュボードシェルは、単なる装飾ではありません。
   • すべてのバリエーションを、ユーザーの主なタスクと製品のトーンに沿ったものにしてください。
   • 新規プロジェクトの幅広いマーケティング依頼では、承認済みのデザインの方向性から、企業や製品のアイデアに合うものを選び、その適合理由を説明してください。

3. 一時的な DOM の工夫より、ソースに基づくプレビューを優先する

   • ホストがプレビューに対応している場合は、ユーザーが確認して選べる実際のコンポーネント、ページ、ルートを生成してください。
   • 主なワークフローとして、ブラウザー拡張機能のような DOM 注入に頼らないでください。これは壊れやすく、保守可能なソースコードも作成できません。

4. 明確な判断を示す

   • better-react-web-ui は、独自性があり、審美性に優れた React と Tailwind の出力を重視します。
   • 最も無難な汎用 SaaS レイアウトに安易に寄せないでください。
   • フロントエンドデザインのガイダンスを活用して、具体的な品質上の問題を特定してください。明示されたブランド上の選択は維持してください。

5. 統合を意識する

   • プロジェクトに既存のコード規約やフォルダー構成があれば、それに合わせてください。
   • 共通の UI システムがすでにある場合は、場当たり的なプリミティブを作成せず、そこに組み込んでください。
   • バリエーション間で構造の共通化が見えてきたら、適切な共通コンポーネントに切り出してください。

6. 本質を保つ依頼に応える

   • ユーザーが本質を維持するよう求めた場合は、より大幅な見直しを明示的に求められない限り、認識できる構造、主要な要素、ストーリーの流れを維持してください。
   • タイポグラフィ、色、コピー、密度、根拠の見せ方、表面のスタイリング、メディアの方向性、アクションの強調方法を変えることで、方向性の異なる案を十分に作れます。
   • 「選択肢をください」を、既存の構造を捨ててよいという許可だと取り違えないでください。

配信モードを選択する

ユーザーが単一の成果物を求めている場合、方向性を指定している場合、選択済みのオプションの適用を依頼している場合、またはデザインの選択を委ねている場合は、直接実装を基本とします。以下の依頼を分類し、対象の場所に実装して結果を検証してください。代替ファイル、比較表、プレビュー選択画面は作成しないでください。変更したファイルと実施したチェックを報告してください。

ユーザーが代替案や比較を求めている場合に限り、探索を行います。指定された数に従ってください。数の指定がない場合は、5つの方向性を提示してください。以下に残りのワークフローを示します。

探索ワークフロー

1. 依頼を分類する

成果物の分類体系を使って、ユーザーがセクション、ページ、フロー、シェル、データ／コンテンツコンポーネントのどれを求めているか判断します。

さらに、これは次のどれに該当するかを判断します。

• 新規の成果物
• 構成をほぼ維持した既存成果物の再デザイン
• 中程度の再構成が可能な再デザイン
• 全面的な見直しを含む再デザイン

次に、以下を特定します。

• ユーザーの主な目標
• 中核となるコンテンツブロック
• 重要な状態（読み込み中、空、エラー、成功、検証、レスポンシブレイアウト）
• 配置されるコンテキスト（新しいページ、既存のページ内、ダッシュボード内、マーケティングサイト内）
• 固定される構造要素と柔軟に変更できる構造要素
• 現状のまま認識できる状態を保つ要素と、変更する要素

2. 求められている方向性を定義する

指定された数の候補となる方向性を提示します。探索の依頼で数が指定されていない場合は、5つ提示してください。

バリエーションの品質基準を使って、求められている方向性が見た目だけの色替えではなく、意味のある違いを持つようにしてください。

既存の構成や本質を保つよう求められている場合は、現在の成果物を基準となる骨格として扱います。許可なくページを削除したり並べ替えたりするのではなく、主にビジュアルシステムやメッセージの選択によって方向性に違いをつけます。

この種の再デザインでは、次の要素を組み合わせて、各オプションに違いをつけることができます。

• タイポグラフィとフォントの組み合わせ
• 配色とコントラストの方針
• コピーのトーンと見出しの見せ方
• 根拠情報の配置と強調
• 情報密度と余白のリズム
• 画像やイラストの表現方法
• 表面のスタイル、境界線、奥行き、ディテールの表現
• アクションの優先順位と CTA の見せ方

各方向性には、次の項目を含める必要があります。

• 名前：短く、覚えやすく、コンセプトが伝わるもの
• 承認済みの方向性：主要な構造の方向性と、該当する場合は補助的な表現
• デザインの主張：アイデアを説明する1文
• 効果の理由：ユーザーの目標をどのように支援するか
• 主な特徴：階層、レイアウト、情報密度、個性、メディア表現、アクションの方針
• 最適な用途：他の方向性よりもこの方向性を選ぶべき場合
• スタイル上のコスト：注意すべき主な実装、パフォーマンス、状態管理のコスト

既存の成果物を再デザインする場合は、以下も明記します。

• 維持する骨格：現在の成果物から意図的に認識できる状態を保つもの
• 主な変更点：この方向性で最も重点的に変える要素

3. 実際の候補アーティファクトを作成する

承認済みのモックまたはスクリーンショットについては、reference fidelity に従ってください。ページの大規模な作業では、任意のページ概要を使用してください。直接的な実装依頼では、モックも追加の選択ラウンドも必要ありません。

各案について、実際のアーティファクト一式を生成してください。

以下を優先してください。

• 実際のコンポーネントファイル
• 実際のルート／ページファイル
• バリエーションを切り替えられる実際のプレビューシェル
• UI を読みやすくするために必要な場合は、実際のデータモックまたはプレースホルダー

既存のアーティファクトを再設計する場合、実用上可能であれば、全体を一から作り直すのではなく、現在の実装を基に分岐してください。まず依頼された構造を維持し、その上にデザイン変更を加えてください。

プレビュー、代替比較形式、最終的な統合の構成を決める際は、プレビューと適用のパターンを使用してください。

4. バリエーションを適切に比較できるようにする

すべてのバリエーションに、同じ実用的なチェック項目を含めてください。

• レスポンシブ時の動作
• アクセシビリティの要件
• 主要なインタラクション状態
• コンテンツのプレースホルダーまたは文例
• 実装上の注意点
• 必要な補助コンポーネント

再設計の場合は、さらに以下も含めてください。

• 構造的に一貫している部分についての簡潔な説明
• 視覚面または編集面で変更した部分についての簡潔な説明

ある案はスケッチ程度で、別の案は本番品質という状態にしないでください。同じ水準のものを比較してください。

5. 選択を推奨し、決定する

案を生成した後は、次の手順に従ってください。

1. トレードオフをコンパクトな表にまとめる
2. ユーザーの目標に明らかに合う案がある場合は、1つ推奨する
3. 選択が決まっていない場合に限り、ユーザーに選択を求める。以前の選択、または選択と適用を委任する権限がある場合は、それに従ってください。

推奨する案が以下に最もよく合う理由を説明してください。

• 対象ユーザー
• 製品のトーン
• 情報密度
• コンバージョンまたはユーザビリティの目標
• 現在のコードベースにおける保守性

6. 選択した方向性を適切に適用する

方向性が選択されたら、次のことを行ってください。

• 依頼された対象の場所に統合する
• プロジェクトの規約とインポートを維持する
• 繰り返し使われ、実際に再利用可能なプリミティブを抽出する
• ユーザーが代替案を残すことを希望していない限り、明らかに不要な一時的な足場を削除する
• 今後の反復に役立つ場合に限り、プレビュー用アーティファクトを残す

再利用可能なパターンが生まれた場合は、extract の考え方を活用してください。ただし、1つの依頼のために過剰なデザインシステムを構築しないでください。

ヒーローセクション、価格設定、ペイウォール、認証、ダッシュボード、コマースフロー、コンテンツ表示面など、アーティファクト固有の優先事項については、リクエストのマッピングに関するヒューリスティクスを使用してください。

出力要件

実装結果を確認済みとして報告する前に、視覚的な検証を行ってください。実装した内容と、視覚面または動作面で未検証の主張は明確に区別してください。

直接的な実装の場合は、実装結果、変更したファイル、検証内容を報告してください。探索の場合は、次の順序で結果を提示してください。

1. 生成したもの — 依頼されたアーティファクトと方向性の数
2. バリエーションの概要表 — 生成した方向性ごとに、主旨と最適な用途を1行で示します。必要に応じて、比較表テンプレートを使用してください。
3. 推奨する選択肢 — 該当する場合
4. プレビュー／適用に関する注意事項 — バリエーションの確認方法または切り替え方法
5. 実装結果 — 作成／更新したファイル

ラベル、ファイル名、選択内容の対応関係を一貫して管理するには、バリエーションの命名規則を使用してください。 プレビュー画面を作成する際は、プレビューページのチェックリストを使用してください。 ユーザーが方向性を選択した後は、適用／クリーンアップのチェックリストを使用してください。

絶対にしないこと

• ユーザーが直接実装を求めているのに、代替案を生成する
• 見た目だけが異なる、ほぼ同一のバリエーションを生成する
• 一時的なブラウザー DOM を実装の主な手段として使う
• 既存のコードベースの構造やスタイルシステムを無視する
• 既存の成果物の本質や認識しやすい部分を保つよう求められているのに、その構造を壊す
• プロンプトが曖昧だからといって、一般的なスタートアップ風のデザインを既定で採用する
• このライブラリで、目新しさを既定で重視する
• どの案も派手に、カードだらけに、グラデーションだらけに、またはアニメーションだらけにする
• 成果物に実質的な影響を及ぼす読み込み中・エラー・空の状態や、レスポンシブレイアウトの状態を省略する
• 何を変更したのか明確にせず、選んだバリエーションを適用する

このスキルは、入れ替え可能な UI を引き当てるためのスロットマシンではありません。どちらのモードでも保守しやすいソースコードを保ちながら、直接実装と、求められた場合の探索を支援します。