Web frontend builder

Frontend Design

目的

このスキルは、プロダクト・対象ユーザー・ワークフローに合わせて意図的に設計されたフロントエンドコードを生成するために使用する。目標はデコレーションやデザイン論ではなく、明確な視点を持ち、安定したレスポンシブ動作、アクセシブルなコントロール、検証済みのレンダリングを備えた実用的なインターフェースを構築することである。

動作モデル

優れたフロントエンドデザインはコンテキスト・階層・コンセプト・実装の整合性から生まれる。

優先順位:

1. ユーザーのワークフローとプロダクトの目的
2. 既存のフレームワーク・デザインシステム・コーディング規約
3. ドメインに合った明確な視覚的階層と情報密度
4. レスポンシブの安定性・アクセシビリティ・インタラクション状態
5. タスクを支える独自のデザインコンセプト・タイポグラフィ・テーマ
6. 実際のスクリーンショットまたはスモークテストによるブラウザ検証

実装前に以下を確認する:

• このスクリーンでユーザーは何を達成しようとしているか？
• これはオペレーションツール・マーケティング面・ポートフォリオ・ゲーム・クリエイティブアプリ・コンテンツサイトのどれか？
• 既存のフレームワーク・UIライブラリ・ルーティングモデル・アセット・フォント・アイコン・デザイントークンは何か？
• このインターフェースをプロダクト固有のものにするための、一つの視覚的アイデア・タイポグラフィのアイデンティティ・テーマ付きインタラクションは何か？
• スクリーンにcanvas・3Dシーン・動画・マップ、その他のプライマリビジュアルレイヤーが含まれるか？UIが確保すべきセーフエリアはあるか？
• UIは外部・生成・キャッシュ・リアルタイム・ユーザー提供データのいずれで動いているか？出典・鮮度・部分障害・古い状態のシグナルをどこに表示する必要があるか？
• 設計すべき状態は何か: loading・empty・error・disabled・hover・active・selected・focused・mobile？

制約が欠落していて結果が大きく変わる場合にのみ、最大1〜3個の質問をする。

デザインコントラクト

• ローカルのデザインシステムを信頼できる唯一の情報源として扱う。Storybook・Figmaのメモ・DESIGN.md・コンポーネントドキュメント・shadcn config・CSS変数・テーマトークンが存在する場合は、新しいスタイルを作る前に必ず確認する。
• デザインシステムが存在しない場合は、まずコンパクトなトークンセットを定義する: カラーロール・タイプスケール・スペーシング・radius・elevation・motion・インタラクション状態。CSS変数・Tailwindテーマ値・プロジェクトの相当物を通じて実装する。
• スコープを要求された画面に限定する。既存のスタックでタスクを合理的にサポートできない場合を除き、フレームワーク・ルーター・スタイリングシステム・UIライブラリを置き換えない。
• canvas・3D・ゲーム・マップ・動画・エディター画面では、ビジュアルレイヤーとDOM UIを一体のコンポジションとして扱う。オーバーレイのスタイリング前に、セーフゾーン・z-indexレイヤー・pointer-eventの所有権・フォーカス動作・リサイズルールを定義する。
• データドリブンなプロダクトでは、データの信頼性をデザインコントラクトの一部にする。ハッピーパスのスタイリング前に、ソース・鮮度・cache/stale状態・部分的な可用性・バリデーション警告・リトライパスの表示方法を決める。
• 実現可能な範囲でWCAG 2.2 AAを目指す: セマンティック構造・ラベル・キーボードフロー・フォーカスの可視化・コントラスト・ターゲットサイズ・エラー識別・reduced-motion対応。
• インスピレーションをローカルの原則に変換する。ユーザーが所有しているか、再利用のために明示的に提供していない限り、プロプライエタリなブランド・プロダクトUI・外部アセットセットをコピーしない。
• ユーザーがタイポグラフィ・モーション・密度・パレット・スペーシングなど特定の改善を求めた場合は、その次元を分離し、直接的な競合がない限り無関係な構造を維持する。

まず調査する

既存プロジェクトでは、設計・編集の前に調査する:

rg --files | rg '(^|/)(DESIGN\.md|AGENTS\.md|README\.md|package.json|src|app|pages|components|styles|public|assets|static|tailwind|vite|next|astro|nuxt|svelte|storybook|\.storybook)'
rg -n "className=|styled\\.|createTheme|ThemeProvider|tailwind|@theme|:root|--[a-zA-Z0-9-]+|font-family|from ['\\\"]lucide|from ['\\\"]@mui|from ['\\\"]antd|from ['\\\"]@radix-ui|from ['\\\"]react-aria|from ['\\\"]framer-motion|from ['\\\"]motion/react|cva\\(" .
rg -n "Button|Card|Dialog|Modal|Tabs|Toggle|Select|Slider|Tooltip|Navbar|Sidebar|Header|Footer|Logo|Icon|Empty|Error|Skeleton|Toast" src app pages components stories 2>/dev/null
rg -n "canvas|WebGLRenderer|three|phaser|pixi|requestAnimationFrame|setAnimationLoop|pointer-events|aria-label|data-role" src app pages components styles 2>/dev/null

これらの検索結果が多すぎる場合は、さらに読み進める前に対象のルート・コンポーネント・スタイルフォルダに絞り込む。

抽出すべき情報:

• フレームワークとルート構造
• 既存のコンポーネントプリミティブとUIライブラリ
• デザインドキュメント・Storybookストーリー・Figmaハンドオフメモ・スクリーンショット・受け入れ基準
• カラートークン・CSS変数・Tailwind config・フォント読み込み・スペーシングスケール・radius・elevation・motionパターン
• アイコンライブラリとブランド/ロゴアセット
• 既存のページレイアウトパターンとレスポンシブブレークポイント
• プライマリビジュアルレイヤーの制約: canvas/メディアの境界・HUDセーフエリア・オーバーレイスタック・pointer-eventのルーティング・リサイズ動作
• データの形状と変動性: 生成コンテンツ対キュレーションコンテンツ・外部ソース・タイムスタンプ・ページネーション・フィルタリング・ソート・stale/cacheの状態・部分的な失敗・長文や多言語テキスト
• 既存のloading・empty・error・disabled・selected・focus・バリデーションパターン
• lint・typecheck・test・build・devプレビューの利用可能なスクリプト

グリーンフィールドのページやアプリでは、ワークスペースが示す最もシンプルなスタックを選ぶ。ユーザーがマーケティングランディングページを特定的に求めない限り、実際に使えるエクスペリエンスを最初の画面として構築する。

ワークフロー

1. 画面のジョブとデザイン方向を短いフレーズで定義する。画面タイプ・対象ユーザー・密度・パレット・タイポグラフィ・画像・モーション・プロダクト固有の印象的な一手を含める。
2. トークンコントラクトを整合させるか作成する。多くのコンポーネントをスタイリングする前に、カラーロール・タイプスケール・スペーシング・radius・elevation・フォーカスリング・disabled処理・motionルールを決める。
3. インタラクション画面をマッピングする: ナビゲーション・プライマリ/セカンダリアクション・コントロール・データ状態・フィードバック状態・キーボードパス・タッチエルゴノミクス・レスポンシブ動作。
4. canvas・3D・メディア・マップ・ゲーム・エディター画面では、まずプライマリビジュアルレイヤーを確保する。HUD・レール・ツールバー・モーダル・ステータスバーを安定したセーフゾーンに配置し、どのレイヤーがpointerとキーボード入力を所有するかを決める。
5. データ量の多い画面では、スキャンループ・詳細ループ・信頼ループを設計する。ユーザーが一目で比較できること・より詳しい情報を開くもの・ソース/鮮度/エラーのコンテキストが表示される場所を決める。
6. プロジェクト固有のスタイルで実装する。新しい抽象化を追加する前に、ローカルコンポーネント・CSS変数・Tailwindユーティリティ・アイコンライブラリ・アクセシビリティプリミティブ・フレームワークパターンを再利用する。
7. 適切なビジュアルアセットを使用する。プロダクト・場所・人物・オブジェクト・ゲーム・Webサイトのエクスペリエンスには、抽象的なプレースホルダーではなく実際または生成されたビジュアルシグナルが必要。ラスターアセットが必要で存在しない場合は、利用可能であれば画像生成ワークフローを使用する。
8. 洗練された状態を追加する: hover・focus-visible・active・disabled・loading・empty・error・selected・drag/resize（関連する場合）。
9. アスペクト比・min/maxサイズ・グリッドトラック・必要に応じたcontainer queries・固定されたコントロールサイズなど、明示的な制約でレイアウトを安定させる。
10. デスクトップとモバイルサイズで視覚的に確認し、重なり・クリッピング・折り返しの問題・予期しないシフト・ブランクレンダリングを修正する。

画面タイプ別の方向性

画面タイプ	デザインの傾向
SaaS・CRM・管理画面・金融・オペレーション	静かで密度が高く、スキャンしやすい。色数を抑え、テーブル/フォームを強調し、ナビゲーションを予測可能にする
データ・フィード・検索・分析・AIコンテンツワークスペース	高密度スキャン・出典と鮮度のシグナル・強力なフィルタ/ソート/検索・詳細ドリルダウン・gracefulなstale/部分的データ状態
クリエイティブツールまたはエディター	完全に動作するcanvas・コンパクトなコントロール・ツールチップ付きアイコンボタン・安定したツールバー・説明的なマーケティングコピーなし
Canvas・3D・マップ・メディアアプリ	プライマリビジュアルレイヤーを最優先・DOMコントロールはセーフゾーン内・pointer-eventコントラクト・レスポンシブフレーミング・読みやすいオーバーレイ
コンシューマーアプリ	より表現力のあるブランドの瞬間・温かみのあるフィードバック・明確なタスクの進行・モバイルエルゴノミクス
ランディングページまたはプロダクトページ	最初のビューポートでブランド/プロダクト/場所/人物を明確に表示。次のセクションをほのめかし、汎用的なスプリットヒーローカードを避ける
ポートフォリオ・編集・カルチャー	強いタイポグラフィ・アートディレクション・画像のリズム・意図的な空白
ゲームまたはプレイフルな体験	即座に遊べる画面・読みやすいHUD・カスタムアセット・レスポンシブ入力・pause/ゲームオーバー/設定状態

データ密度の高いワークスペース

ダッシュボード・フィード・検索結果・生成コンテンツリスト・分析・調査ツールでは、静的なプレゼンテーションではなく繰り返しの意思決定を中心にワークスペースを設計する。

• 検索・カウント・フィルター・ソート・ビューモード・ページネーション・更新/ステータスコントロールを予測可能なツール領域に配置する。それらの寸法を安定させ、必要に応じて水平オーバーフローをコントロールグループ内に限定する。
• スキャン可能なプライマリリストまたはグリッドを使用し、より深いコンテキストのためにサイドパネル・ドロワー・モーダル・スプリットペインを提供する。すべての詳細を繰り返しのカードに詰め込まない。
• 信頼性のメタデータを、それが影響する意思決定の近くに表示する: ソース・タイムスタンプ・ステータス・信頼度・バリデーション警告・cache/staleマーカー・リトライアフォーダンス。
• 生成または外部テキストをレイアウトに対して敵対的なものとして扱う。表示テキストを必要に応じて正規化し、繰り返しのサマリーを制限し、詳細またはタイトルで全文を保持し、ユーザー/ソース提供の文字列には overflow-wrap: anywhere を使用する。
• 意図的にリフローする: サイドバーはインラインパネルになれる、右レールはコンテンツ下に移動できる、ツールバーは行に折り返せる、ページネーション/フィルターストリップはローカルでスクロールできる。ページ全体の水平スクロールは避ける。

審美的な方向性

汎用的な「モダン」な見た目の代わりに、具体的なビジュアルコンセプトを選ぶ。コンセプトは静かでも派手でも良いが、意図的で画面に適したものでなければならない。

プロダクトが対応できる場合は強い方向性を使用する:

• 徹底的にミニマル: 疎な構造・精密なスペーシング・強いタイプコントラスト・少ないエフェクト
• エディトリアルまたはマガジン風: 表現力のあるディスプレイタイプ・画像のリズム・非対称なペーシング
• インダストリアルまたはテクニカル: グリッドを前面に出す・ユーティリティカラー・モノスペースアクセント・密なコントロール
• ラグジュアリーまたは洗練: 抑制されたパレット・高品質な画像・繊細なモーション・丁寧なプロポーション
• プレイフルまたはトイ風: 彩度の高いアクセント・触感的なコントロール・弾力のあるフィードバック・カスタムアセット
• レトロフューチャリスト・ソーラーパンク・サイバーパンク・アールデコ・メンフィス・ブルータリスト: プロダクトに合う場合またはユーザーが求めた場合のみ使用

テーマロックのルール: ユーザーが審美性を指定した場合、カラー・タイポグラフィ・レイアウトリズム・テクスチャ・モーション・コンポーネントの詳細をそのテーマにロックする。実装の複雑さをコンセプトに合わせる: マキシマルな方向性はより豊かなレイヤーとモーションが必要で、洗練されたミニマルな方向性はより厳格なスペーシング・コントラスト・抑制が必要。

タイポグラフィとテーマ

• タイポグラフィを後付けではなく、コアなデザインシステムとして扱う。ディスプレイ・ボディ・数字・コードのスタイルを意図的に選ぶ。
• プロジェクトに既にブランドまたはパフォーマンス予算がある場合は既存フォントを再利用する。グリーンフィールドの場合、プロダクトがユーティリタリアンな中立性を求めない限り、Inter・Roboto・Arial・システムフォントをデフォルトで使わない。
• 必要に応じてフォントをペアリングしてコントラストを出す: セリフとジオメトリックサンス・ディスプレイと抑制されたボディ・モノアクセントと読みやすいUIフェイス。
• ヒーロー・エディトリアル画面・ブランドの瞬間には強いウェイトとスケールコントラストを使用し、ダッシュボード・エディター・オペレーションツールにはコンパクトで安定したタイプスケールを使用する。
• プロジェクトの確立されたメカニズムを通じてフォントを読み込む。オフライン使用・プライバシー・パフォーマンスの制約によってトレードオフが悪化する場合は、リモートフォントの依存関係を追加しない。
• 変数またはトークンでテーマを構築する。カラー・radius・シャドウ・タイプスケール・フォーカス・disabled状態・motionは、散在する一回限りのものではなく再利用可能であるべき。
• パレットのインスピレーションをドメイン・プロダクト素材・画像・指定された審美性から引き出す。支配的なロールに鋭いアクセントを使用し、臆病な均等分布のパレットを避ける。

絞り込み型の改善

ユーザーが一つの次元の改善を求めた場合、編集範囲を狭く保つ:

リクエスト	維持するもの	変更するもの
タイポグラフィを改善	レイアウト・パレット・コンポーネント	フォント選択・スケール・ウェイト・line-height・measure・階層
カラー/テーマを改善	レイアウト・タイプ階層・ワークフロー	トークン・セマンティックロール・コントラスト・アクセント・サーフェス
モーションを改善	レイアウト・パレット・情報アーキテクチャ	タイミング・イージング・エントランス・hover/focus・状態遷移
よりプレミアム/プレイフル/ミニマルなど	コアワークフローとアクセシビリティ	審美的トークン・画像・テクスチャ・リズム・詳細
レスポンシブポリッシュを修正	ビジュアルアイデンティティと動作	制約・折り返し・ブレークポイント・オーバーフロー・タッチターゲット

インタラクションルール

• 共通パスを明確にする。各画面は競合するプライマリボタンなしで次のアクションを明確にすべき。
• セカンダリアクション・フィルター・詳細設定・破壊的コントロールにはプログレッシブディスクロージャーを使用する。
• 各非同期リージョンに関連する場合はloading・empty・error・retry・successまたはsaved状態を与える。
• 共有可能なフィルター・検索・ソート・タブ・ページネーションにはURL状態を優先する。オープンメニューや一時的な選択などの一時的なUIにはローカル状態を使用する。
• 永続ラベル・有用なヘルパーテキスト・インラインバリデーション・送信フィードバック・安全な破壊的確認を含むフォームを構築する。
• 詳細を開くリストアイテムやカードには、実用的な場合はセマンティックなbutton/linkを優先する。ボタン以外のコンテナをインタラクティブにする必要がある場合は、role・キーボードアクティベーション・フォーカスの可視化・アクセシブルな名前を提供し、テキスト選択やネストされたリンクを壊さない。
• ダイアログ・ポップオーバー・メニュー・コマンドパレット・ドロワーはフォーカス・Escape・外部クリック・スクロールロック・フォーカスの返却を管理させる。
• キーボードとタッチをファーストクラスとして扱う: フォーカスの可視化・論理的なタブ順序・タッチに十分な大きさのヒットターゲット・ホバー専用アフォーダンスなし。
• レイヤードされたcanvas/HUD画面では、パッシブなオーバーレイ領域を pointer-events: none に保ち、コントロール上でのみ pointer-events: auto に戻す。デコレーティブなレイヤーがゲームプレイ・マップ・エディター・カメラ入力を遮断しないようにする。

ビジュアルルール

• 審美性をドメインに合わせる。ユーザーが求めない限り、オペレーションソフトウェアをマーケティングヒーローのように見せない。
• 明確な審美的方向性にコミットし、ドメインが求めるように抑制または強度で実行する。ミニマルデザインには精度が必要で、マキシマルデザインにはオーケストレーションが必要。
• 適切な場合は独特のタイポグラフィを使用するが、既存のフォント読み込みとパフォーマンスを尊重する。無関係なプロジェクト間で同じ人気の選択に収束することを避ける。
• 実際のコントラスト・目的のあるアクセント・セマンティックロールを持つパレットを使用する。一つの色相ファミリーだけで構成された単調なテーマを避ける。
• 使い慣れたシンボルがある場合はツールアクションにアイコンを優先する。手描きのインラインSVGではなく、プロジェクトのアイコンライブラリ（多くの場合Lucide）を使用する。
• 使い慣れたコントロールを使用する: モードにはセグメンテッドコントロール・ブール値にはトグルまたはチェックボックス・数値にはスライダーまたは数値入力・ビューにはタブ・オプションセットにはメニュー。
• HUD・ダッシュボード・プレビュー・カウンター・メーター・キーキャップには、固定またはバウンドされた寸法・表形式の数字・安定したSVG/canvas viewBox・ローカリゼーションと長いラベルを許容する折り返しルールを使用する。
• カードは本当に繰り返されるアイテム・モーダル・フレームされたツールに限定する。カードの中にカードを入れたり、すべてのページセクションをフローティングカードにしたりしない。
• 既存のデザインシステムが別途指定しない限り、カードのradiusを控えめに保つ。
• 意味のある状態変化・空間的な方向付け・インパクトの高いリビールにモーションを使用する。ワークフローから注意を逸らす散在したアニメーションを避ける。
• プロダクト画面がオンボーディングを本当に必要としない限り、アプリの機能・キーボードショートカット・ビジュアルスタイリングを説明するアプリ内テキストを追加しない。
• モバイルとデスクトップサイズでテキストがコンテナに収まることを確認する。ドラマを演出するためにビューポート幅フォントスケーリングやネガティブレタースペーシングを使用しない。

品質ゲート

作業完了と宣言する前に確認する:

• 最初のビューポートに、汎用アプリには属さない十分に具体的なプロダクト・ブランド・ワークフロー・ドメインシグナルが含まれている。
• canvas・3D・メディア・マップ・ゲーム・エディター画面では、プライマリビジュアルレイヤーが正しくフレームされて表示されており、HUDオーバーレイがデスクトップまたはモバイルサイズで重要なコンテンツを隠していない。
• プライマリタスクの完了が明確で、ワークフローが真にブランチを必要としない限り、ビューごとのドミナントプライマリアクションは最大一つ。
• システムが存在する場合、ハードコードされた一回限りのスタイリングではなくデザイントークンとローカルプリミティブが使用されている。
• インタラクティブまたはデータドリブンな画面では、重要な状態が設計されている: loading・empty・error・disabled・selected・focused・active・hover・mobile・長コンテンツケース。
• 生成・外部・キャッシュ・リアルタイムデータに対して、一つの曖昧なスピナーや無言の失敗を表示する代わりに、UIがfresh・stale・partial・unavailable・retrying・read-only状態を正直に区別している。
• アクセシビリティの基本がパスしている: セマンティック要素・ラベル・コントラスト・focus-visible・キーボード操作・reduced motion・アイコンのみのコントロールへのスクリーンリーダー名。
• UIがリアルなコンテンツに耐える: 長い名前・ローカライズされたテキスト・多数/少数のアイテム・欠損画像・低速ネットワーク・狭い画面。
• ビジュアルアセット・フォント・アニメーション・シャドウ・エフェクトが、過度なペイロード・ジャンク・可読性の損失なしにコンセプトをサポートしている。

アンチパターン

汎用AIの審美性

悪い例: 紫青グラデーション・ガラスカード・フローティングブロブ・同じ丸みのあるカード・汎用的なInter/Roboto/システムタイポグラフィ・ストック風のコピー・予測可能なレイアウト・ドメインシグナルなし。

良い例: まずプロダクトのコンテキストを抽出し、具体的なビジュアルコンセプトを選び、レイアウト・タイポグラフィ・アセット・インタラクション状態・コピー密度を通じて実装する。

デコレーションとしてのテーマ

悪い例: 審美性に名前を付けるが、デフォルトのレイアウト・タイプ・モーション・コンポーネント形状はそのままに、色だけを変える。

良い例: パレット・タイポグラフィ・スペーシングリズム・画像・テクスチャ・モーション・コントロールの詳細全体にテーマをロックする。

コントロールされていないマキシマリズム

悪い例: タスクと競合する多くのエフェクト・パターン・重なり・カスタムカーソル・アニメーションを追加する。

良い例: 一つか二つの高インパクトな表現的な動きを選び、インタラクション・可読性・パフォーマンスを維持する。

過度に広い改善範囲

悪い例: ユーザーがタイポグラフィ・カラー・モーション・モバイルポリッシュの改善だけを求めているのに、ページ全体を再構築する。

良い例: 要求されたデザイン次元を分離し、深く調整し、無関係な構造はそのままにする。

デコレーティブダッシュボード

悪い例: 過大なヒーローテキスト・装飾的なカード・疎な偽のメトリクス・弱いテーブルやフォームを持つオペレーション画面。

良い例: ナビゲーション・フィルタリング・スキャン・比較・ステータス・密なコントロール・高速な繰り返しアクションを優先する。

アプリを求められているのにマーケティングページを作る

悪い例: ツールを提供する代わりにツールを説明するランディングページ。

良い例: 最初のビューポートに使えるアプリ・ゲーム・エディター・ワークフローを配置する。説明コンテンツは実際のタスクに役立つ場合のみ追加する。

シーンの上に貼り付けられたHUD

悪い例: セーフスペースを確保せずにcanvasの後にフローティングパネル・ステータスバー・コントロールを配置し、被写体を隠したり、誤って入力を捕捉したり、狭いビューポートで壊れたりする。

良い例: canvas/メディアのフレーミングとDOM HUDを一緒に設計する。セーフゾーンを確保し、pointer eventsを意図的にルーティングし、pause/設定/エラー状態をテストし、オーバーレイが存在する場合はカメラまたはビジュアルコンポジションを調整する。

不安定なレスポンシブデザイン

悪い例: テキストのクリッピング・ホバー時に拡大するボタン・サイズが変わるコントロール・モバイルの重なり・理想的なコンテンツ長に依存するレイアウト。

良い例: 安定した寸法・レスポンシブ制約・折り返しルール・現実的なビューポートサイズでのスクリーンショットチェックを使用する。

トークンドリフト

悪い例: 確立されたトークンとプリミティブを持つプロジェクトでハードコードされた色・スペーシング・radii・シャドウ・カスタムコントロールを追加する。

良い例: 既存のトークンを拡張するか、既存のプリミティブを合成する。例外が必要な場合はローカルに保ち、理由を説明する。

不完全な状態サーフェス

悪い例: 静的なモックデータでハッピーパスだけを設計する。

良い例: loading・empty・error・disabled・focused・長コンテンツ・モバイル状態を実装するか、少なくとも考慮する。

見えないデータの信頼性

悪い例: 外部・AI生成・キャッシュ・リアルタイムデータを常に完全で最新であるかのように表示する。

良い例: ユーザーの意思決定に影響する箇所でソース・タイムスタンプ・stale/cache状態・部分的な失敗の警告・リトライアフォーダンス・証拠/詳細へのパスを公開する。

一発のカードグリッド

悪い例: データ量の多いすべての画面を、スキャンパス・フィルター・ソート・詳細リズム・モバイルリフロープランのない均一なカードに変換する。

良い例: 繰り返しのワークフローを設計する: スキャン・フィルター・比較・詳細を開く・empty/error状態から回復する・コンテキストを失わずに戻る。

未検証のポリッシュ

悪い例: ページを開かずにCSSの変更を出荷する。

良い例: アプリを実行し、デスクトップとモバイルのスクリーンショットを確認し、インタラクションをテストし、目に見える欠陥を修正する。

レビューモード

ユーザーが既存のフロントエンドのレビューを求めた場合は、称賛よりも発見した問題を先に述べる。優先順位:

1. 壊れた動作・アクセスできないコントロール・読めないコントラスト・レイアウトの重なり・モバイルの失敗
2. 既存のデザインシステム・トークン・アクセシビリティ・フレームワーク規約との不一致
3. 情報の階層・アクションの階層・ワークフローの摩擦
4. プロダクトシグナルを弱める汎用的なビジュアルの選択
5. 欠落した状態・アセット・コンテンツのストレス処理・検証

有用な場合は問題をblocking・major・minorに分類する。コードをレビューする際はファイルと行番号を参照する。スクリーンショットが利用可能な場合は、ビューポートと表示されている問題を述べる。

検証

まずリポジトリのスクリプトを使用する:

npm run lint
npm run typecheck
npm run build
npm test

プロジェクトに存在するコマンドのみ実行する。アプリにdevサーバーが必要な場合は起動してローカルURLを提供する。静的HTMLで十分な場合はファイルを指す。

ビジュアルQAのために:

• 少なくとも一つのデスクトップと一つのモバイルビューポートを確認する。
• ブラウザ自動化が利用可能な場合は、ブラウザコンソールエラー・ページエラー・失敗したリクエスト・明らかなレイアウトオーバーフローを確認する。
• 画像・アイコン・フォント・グラデーション・canvas/WebGL・動画が意図通りにレンダリングされているか確認する。
• 関連する場合、コントロールにhover・focus・selected・disabled・loadingの動作があるか確認する。
• テキストが重なったり、クリッピングされたり、親要素をオーバーフローしたり、コントロールの寸法を予期せず変えたりしていないか確認する。
• 現実的なデータでストレステストする: 長いタイトル・多言語文字列・多数/ゼロのアイテム・欠損画像・古いキャッシュデータ・部分的なソース障害・低速または失敗したネットワーク応答。
• CSSをスキャンして、偶発的な単調なパレット・過度な紫/青グラデーション・ベージュ/ブラウンの単調さ・ダークスレートの単調さ・デコレーティブブロブを確認する。
• 3D/canvas/ゲーム画面では、canvasが空白でなく、正しくフレームされ、インタラクティブまたはアニメーションしているか確認する。

成果物

返すもの:

• 実装またはレビューしたファイル
• 選択したデザイン方向とその理由
• 実行した検証コマンドとビジュアルチェック
• 未実行のテスト・欠落したアセット・実行できなかったブラウザチェックなど残存するリスク

figma2web 連携

このスキルを figma2web プロジェクト（Figma デザインを Next.js / 対象アプリ でピクセル単位で再現する）で使う場合の追加ルール（figma2web スキルから呼ばれる）。

役割: GENERATE ステージの被委譲側

このスキルは figma2web スキルから GENERATE ステージで「呼ばれる」被委譲側である（パイプライン全体は再実装しない）。デザインコントラクト（色 / タイポ / 余白トークン）の出どころは、汎用のブランド推測ではなく Figma フレームのトークン:

• .context/figma/<slug>/model.json（正規化モデル）
• index.json の fonts（フォント解決結果）
• .context/figma/<slug>/ir-candidates.json（候補 IR ＋計測値）

視覚 QA はゲート A / B に置換

汎用の視覚 QA（パレット単調さ検査など）ではなく、Figma 再現用の 2 ゲートに置き換える:

• ゲート A（静的忠実度）: デザイン幅固定のフリーズ描画で参照 PNG .context/figma/<slug>/ref.png と領域別差分（${CLAUDE_SKILL_DIR}/../figma2web/tools/visual-diff、figma2web スキルに同梱）。
• ゲート B（レスポンシブ / a11y / 状態）: 375 / 750 / desktop での overflow・ランドマーク・hover/focus/disabled 等。ピクセル差分しない。

対象アプリ 規約（厳守）

• 名前付き export（default export しない）。
• props 型は TProps。any 禁止。
• コンポーネントは arrow function。
• 寸法は rem()。単一 breakpoint は mq(md:750px) のみ。
• スタイルは SCSS modules。先頭で必ず @use "@/styles/abstracts/index" as *;。
• 画像はカスタム <Image>（<picture> ベース、next/image ではない）。テキストはカスタム <Typography>（data-font-setting で type style を指定）。
• import/order は eslint が強制（module.scss の import は末尾）。

必須成果物: タイポグラフィ・トークンの実体化

• 重要: data-font-setting の CSS ルールは 対象アプリ に未実装である。Figma の text style から [data-font-setting='...']（font-family / size / line-height / weight / letter-spacing）を生成するのは必須成果物。
• 色 / 余白トークンは src/styles/abstracts/_variables.scss に追加する。

Figma は未完成 → literal コピーしない

• Figma を写経しない。レスポンシブ / テキスト折り返し / セマンティック HTML / インタラクション状態は Web ベストプラクティスで補う。
• 絶対配置の写経（divitis）は禁止し、flex/grid を基本にする。ただし真に重なる要素には position:absolute を許容する。