frontend-design

プロダクトに適した、実際に動作する React と Tailwind のインターフェースを作成し、明示された制約を守り、主要なタスクを明確にしてください。依頼された作業に関連するリファレンスのみを読んでください。

依頼された範囲に合わせる

アドバイス、ワークフローの比較、どのスキルを使うべきかという質問には、スキルを実行せずに回答してください。ファイルの編集、コンテキストの保存、レポートの作成、インタビューの開始は行わないでください。明示的なレビュー依頼には、調査して報告してください。ユーザーが修正を依頼した場合、またはすでに許可している場合にのみ、修正を実施してください。以前の許可は、その範囲内で再利用してください。

コンテキスト収集プロトコル

依頼された判断に必要なコンテキストのみを収集してください。次の順序で進めてください。

1. ユーザーの現在の指示、以前の回答、すでに与えられた指示やクリエイティブ上の裁量を再利用します。
2. project context を使用して、対象アプリケーションのコンテキストを把握します。その .better-react-web-ui.md、適用される親ディレクトリのデフォルト設定、該当するページ概要、既存のデザインドキュメントを読みます。同じ範囲内では、レガシーファイルも代替の入力として扱います。
3. 影響を受けるコード、呼び出し元、アセット、既存のデザインシステムを調べます。確認できた実装は現在のシステムの根拠として扱い、明示されていないユーザーニーズの証明とはみなさないでください。
4. 作業に重大な影響を与える事実が不足している場合にのみ質問します。妥当な仮定にはその旨を明記し、許可された範囲で、後から変更可能な選択をして作業を進めます。

新しいデザインの方向性を決める場合は、対象ユーザー、目的のタスク、ブランドのトーンを明確にします。クリエイティブな裁量が明示的に委ねられている場合は、承認を得るために作業を中断せず、妥当な仮定を選んで記録します。ユーザーの回答やプロダクトの事実を捏造してはいけません。

範囲が限定された修正では、関連するコードと制約を確認してください。キーボードフォーカス、オーバーフロー、測定済みのパフォーマンス不具合を修正する際に、ブランドについてのヒアリングを必須にしてはいけません。

ユーザーが永続的なプロジェクトコンテキストを求めている場合、または大規模なデザイン作業に必要なコンテキストが不足していて記録が必要な場合は、$setup を使用します。コンテキストファイルが存在しないという理由だけで、セットアップを必須にしてはいけません。更新時には既存のコンテキストを保持してください。

優先順位を設定する

ユーザーが変更を求めない限り、既存のビジュアルシステムを維持してください。方向性が定まっていない場合は、design directions を参考に、一貫性のあるスタイルを選びます。装飾を加える前に、余白、グループ化、文字、コントラストによって階層を作ります。

要件と好みを区別してください。

• アクセシビリティ、正確なコンテンツ、機能するコントロール、ユーザーの明示的な制約を守ってください。
• 美的な指針は、方向性が定まっていない判断におけるデフォルトとして扱います。Inter、Arial、システムフォント、純白、純黒、グラデーション、カード、見慣れたレイアウトは、ブランドとタスクに合っていれば使用できます。
• AI slop detection を使って、ありきたりな構成、裏付けのない主張、不要な装飾を見極めます。フォントや色だけを欠点とみなしてはいけません。
• マーケティングページで表現力のある画像やモーションを使う場合でも、主要なワークフローは馴染みやすく読みやすい状態に保ちます。

目新しさよりも、明瞭さ、タスクの完了、エラーの防止を優先してください。顧客、推薦コメント、指標、機能、緊急性、希少性を捏造してはいけません。価格、同意、取り消せない操作の結果、キャンセル方法を明確に示してください。interface honesty を参照してください。

実装内容を把握する

編集する前に、既存の React フレームワーク、Tailwind の設定、コンポーネント、トークン、データフローを確認します。適切なコードとインストール済みの依存関係を再利用します。新規プロジェクトでは、明示された技術スタックの選択を尊重します。指定されていない項目に限り、フレームワークの既定値を使用します。

フレームワーク固有の判断を行う前に、フレームワークの公式ドキュメントを確認します。Next.js では、利用可能な場合、node_modules/next/dist/docs/ にある関連ドキュメントを読みます。記憶に頼るより、使用中のバージョンに一致するドキュメントを優先します。

既存のコンポーネントやブロックがタスクに適している場合は、コンポーネントとブロックの戦略および React shadcn アクセラレーターを活用します。カスタムのプリミティブを作成する場合は、コンポーネントの構造とコンポーネントのアクセシビリティを読みます。成熟したライブラリのセマンティクスを、見た目のために書き換えず維持します。

Astro プロジェクトでは、インタラクションに必要な場合に限り React アイランドを追加します。実装の複雑さは、依頼された成果に見合う範囲に抑えます。

依頼された成果を実装する

1. 対象となるページ、フロー、コンポーネントと、そのページで訪問者が行う作業を特定します。固定コンテンツ、セクションの順序、インタラクションの挙動を維持します。大規模な作業では、プロジェクトのコンテキストで説明されている任意のページ概要を再利用するか、作成します。
2. ユーザーが決定できる範囲内で方向性を選びます。成果物を 1 つ依頼された場合は、そのまま実装します。代替案を求められた場合は、指定された数を守り、比較のために $add-ui を使用します。ユーザーが方向性を選択した後、または選択を委ねた後に、選択の確認を求める段階を追加してはいけません。
3. 実際のソースファイルと動作するアクションを備えた、最小限かつ完全なものを構築します。装飾の詳細に取りかかる前に、間隔、文字、色、角丸、エレベーションの体系を定めます。承認済みのビジュアルリファレンスに従う場合は、リファレンスへの忠実度を確認します。
4. 該当する読み込み中、空、エラー、成功、レスポンシブの各状態に対応します。ユーザーを誤解させたりデータを失わせたりすることなく失敗から復旧できる場合に限り、楽観的な更新を使用します。
5. 対象プロジェクトで成果を検証します。変更内容、実施したチェック、未テストの挙動を報告します。

不足しているコンテキストが大きい場合は、デザインプロセスとUX 戦略を使用します。対象を絞った修正を、全面的な再設計に広げてはいけません。

タスクに応じたリファレンスの読み込み

タスク	リファレンス
ランディングページまたはマーケティングページ	ランディングページのストーリーテリング, ヒーローセクション, マーケティングコピーの作成, ソーシャルプルーフ
階層とレイアウト	階層のチェックリスト, スペーシングシステム, 空間デザイン
タイポグラフィ	タイポグラフィ, テキストの階層と読みやすさ
色とステータス	色とコントラスト, セマンティックカラー, 色覚特性に配慮したUX
画像と奥行き	画像の処理, サーフェスの分離, エレベーションシステム
アニメーションまたはスクロール	モーションデザイン, ランディングページのストーリーテリング
レスポンシブな動作	レスポンシブデザイン, コンテナークエリ
コントロール、フォーム、エラーからの回復	インタラクションデザイン, コンポーネントのアクセシビリティ, エラーからの回復
コピーと製品に関する判断	UXライティング, インターフェースの誠実さ, 価格設定とパッケージ
最終レビュー	ReactとTailwindの実装レビュー, 変更前後の例

認証、コマース、データ可視化、オンボーディング、権限、ローカライズなどの専門的なトピックについては、リファレンスのインデックスを使用してください。タスクごとにリファレンスライブラリ全体を読み込まないでください。

提出前の確認

証拠、修正状況、利用できないツールへの対応については、ビジュアル検証に従ってください。以下の確認は、対象となる機能に応じて調整してください。

• 主要なアクションが明確で、機能することを確認してください。ラベルとコンテンツは実態に即したものにしてください。
• デスクトップとスマートフォンのレイアウト、長いコンテンツ、ズームを確認し、切り抜き、オーバーフロー、機能の欠落がないことを確認してください。
• キーボード操作、視認できるフォーカス、アクセシブルな名前、コントラスト、関連するエラーからの回復をテストしてください。
• 動きを減らす設定が有効な場合でも、意味のあるコンテンツはすべて表示され、アクセス可能な状態にしてください。装飾的なアニメーションによってコンテンツへのアクセスを妨げてはいけません。
• 初期表示される画像と、LCP になる可能性が高い画像は先読みしてください。画面下部にある適切なメディアは遅延読み込みしてください。レイアウトシフトを防ぐため、寸法を確保してください。
• パフォーマンスに関する所見は、測定結果に基づいてください。プロファイリングで必要性が確認された場合に限り、メモ化または一時的な will-change を追加してください。
• プロジェクトで既に使用されているチェックを使い、コマンドの制限を守ってください。ソースの確認だけでブラウザー、アクセシビリティ、パフォーマンスの結果を主張してはいけません。
• タイポグラフィ、スペーシング、色、インタラクションに関する判断が製品に適しているかを確認してください。別のスタイルを個人的に好む場合でも、承認済みのブランド上の選択は維持してください。