frontend-designer

Activation Contract

エージェントが本番環境向けの技術方針を選択、レビュー、または文書化する必要がある場合に、フロントエンドのデザインシステムに関する判断でこのスキルを使用します。

• UI システム、コンポーネントの構造、トークン、レイアウト、または視覚的なインタラクションを設計またはレビューする場合。
• CSS アーキテクチャ、レスポンシブ動作、アクセシビリティの制約、またはモーションのルールを選択する場合。
• リポジトリのビジュアル方針を、実装可能なフロントエンドのガイダンスに変換する場合。

一般的な説明、コピー編集、またはアーキテクチャや再利用可能な実装パターンに影響しない単発のコード変更には、このスキルを使用しないでください。

Hard Rules

• リポジトリのトークンおよびコンポーネント状態の契約を維持し、個別の視覚的判断をハードコードしないでください。
• ARIA による代替よりも、セマンティック HTML とネイティブコントロールを優先してください。インタラクティブな UI では、キーボード操作、視認可能なフォーカス、測定可能なコントラスト、モーション低減時の動作を定義してください。
• レスポンシブコンポーネントは再利用可能にし、メディアとフォントのためのレイアウト領域を確保してください。また、トレードオフが許容できる根拠がない限り、パフォーマンスの低下を避けてください。
• 主な回答は判断を先に示し、詳細な根拠は長い本文に含めず、関連する参照資料に移してください。
• バージョン、ブラウザー、API、法務、または採用状況に関する新たな主張を変更履歴や判断ガイダンスに追加する前に、検証してください。

Decision Gates

確認する根拠	判断
リポジトリ固有の CSS アーキテクチャ、命名規則、リンティング、ビルドパイプライン、チーム規約	確立された方式を維持してください。レイヤー、CSS Modules、CSS-in-JS、ユーティリティ、または命名規則を導入するのは、リポジトリがそれをサポートし、移行コストが許容される場合に限ります。
既存の Design.md、design.md、デザイントークンのソース、または承認済みのデザインツール	存在する場合は、ビジュアルの正として扱ってください。特定のファイル名を必須にしたり、引き継ぎ用ファイルを生成したり、外部のデザインツールを前提にしたりしないでください。
サポート対象のブラウザーマトリックスとフォールバックポリシー	コンテナークエリ、ネスト、:has()、light-dark()、スクロール駆動アニメーション、その他のプラットフォーム機能の利用は、このマトリックスに基づいて判断してください。必要に応じてフォールバックを定義してください。
承認済みのトークン契約とブラウザー／ビルドのサポート	契約で OKLCH が選択されている場合、新たに指定するトークンは OKLCH のみにしてください。承認済みのコストと互換性計画なしに、レガシーな色形式の移行を強制しないでください。
プロダクトのテーマ要件とデザインソース	プロダクトとソースが求める場合に限り、ダークモード優先を使用してください。それ以外の場合は、既存のテーマ戦略とセマンティックトークンの動作を維持してください。
コンポーネントの再利用、ページ構成、コンテンツ、ビューポート要件	サポートされている場合、再利用可能なコンポーネントにはコンテナークエリを優先してください。ビューポートメディアクエリ、モバイルファースト、デスクトップファースト、またはコンポジションは、リポジトリとプロダクトに適した方式を使用してください。
アクセシビリティの対象範囲と測定可能な受け入れ基準	セマンティック HTML、キーボード操作、フォーカスの視認性、コントラストの測定、タッチターゲットの要件、モーション低減時の動作を維持してください。法域固有の要件は、プロダクトの対象範囲で定められている場合に限り適用してください。
パフォーマンスの根拠、予算、配信経路	containment、content-visibility、画像形式、フォント読み込み、アニメーション手法は、ブラウザーマトリックスと互換性があり、測定済みまたは明示されたパフォーマンス目標に裏付けられている場合に限り使用してください。
リポジトリにインストール済みのツールと承認済みの実行環境	利用可能な場合は、リポジトリ標準の検証コマンドを実行してください。依存関係、対象、権限、または根拠が確認できない場合は、npx、ブラウザー監査、エンコーディング、またはデザインツールのコマンドを指示しないでください。

実行手順

1. リポジトリのアーキテクチャ、デザインのソース、ブラウザー対応表、アクセシビリティの適用範囲、パフォーマンスの根拠、チームの規約、利用可能なツール、移行コストを特定します。
2. ビジュアル面の新しさを選ぶ前に、トークン、状態、セマンティック HTML、フォーカス、コントラスト、動きを抑える設定に関する要件を定義するか、維持します。
3. 必要なフォールバックと却下した代替案を記録したうえで、互換性のある最小限の CSS、レイアウト、コンポーネント、テーマ、モーションのアプローチを選択します。
4. 詳細な判断マトリックス、例、保護策、コマンドの前提条件が必要な場合に限り、references/technical-reference.md を読みます。
5. 選択したパターン、その根拠、ランタイムのリスク、フォールバックまたは移行計画、検証方法を明記します。変更履歴への記載は、確認済みの内容に限ります。

出力要件

以下を提示してください。

• 推奨する判断、リポジトリ内の根拠、その判断が適合する理由。
• 具体的なトレードオフを含む、却下した代替案。該当する場合は移行コストも含めます。
• アクセシビリティ、ブラウザー、パフォーマンス、ランタイムに関するリスクと、それらを軽減する対策またはフォールバック。
• リポジトリで実施可能な検証手順、または採用前に必要な追加の根拠。

参照資料

• references/technical-reference.md — v3.0.1 向けに厳選した技術的根拠と、条件に応じた判断指針。
• references/source-index.md — ソースへのポインターと、バージョンに左右される主張の検証ルール。