frontend-designer-lite

アクティベーション契約

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

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

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

絶対遵守の実行時ルール

• リポジトリのトークンとコンポーネント状態に関する契約を維持し、個別の視覚的判断をハードコードしないでください。
• ARIA による代替よりも、セマンティック HTML とネイティブコントロールを優先してください。すべてのインタラクティブ UI について、ネイティブのキーボード動作、視認できるフォーカス、測定可能なコントラスト、タッチ／ポインターの基準、モーション低減時の動作を定義してください。
• コンポーネントの再利用性とレスポンシブ対応を維持してください。メディアとフォントの寸法を確保し、互換性のある根拠なしにパフォーマンスの低下を受け入れないでください。
• 回答は意思決定を最初に示してください。最新の信頼できる情報源による確認なしに、バージョン、ブラウザー、API、アクセシビリティ法令、セキュリティ、導入、または法的適用に関する主張を追加しないでください。
• セキュリティ要件は、製品およびリポジトリからの条件付きの入力として扱ってください。根拠がない場合に、制御、ポリシー、テレメトリー、または外部ツールへの権限を推測しないでください。

必須のエビデンスゲート

パターンを選択する前に、以下を確認してください。必須の入力情報が入手できない場合は、推測したり、万能な技術スタックを推奨したりせず、作業を中断して不足しているエビデンスを報告してください。

• リポジトリのアーキテクチャと移行: 既存の CSS アーキテクチャ、命名規則、リンティング、ビルドパイプライン、チームの規約、許容される移行コストを確認してください。確立された方式を維持してください。カスケードレイヤー、CSS Modules、CSS-in-JS、ユーティリティ、命名規則を導入するのは、リポジトリが対応しており、移行計画が承認されている場合に限ります。
• デザインソース: 存在する場合は、Design.md、design.md、トークンソース、デザインシステムのパッケージ、デザインツールのエクスポート、または別の承認済みソースを確認してください。大文字と小文字を区別するパス、およびトークン、セマンティクス、コンポーネント、状態の契約を、ローカルの視覚的な正解として扱い、コードやチームの規約との不整合を解消してください。特定のファイル名を必須としたり、ソースの名前変更を求めたり、デザインツールを前提としたりしないでください。
• ブラウザーとフォールバックの方針: CSS ネスト、コンテナークエリ、:has()、light-dark()、スクロール駆動アニメーション、WAAPI、オブザーバー、または関連 API を使用する前に、サポート対象のブラウザーマトリックスを確認してください。必要に応じて、互換性のあるフォールバックを定義してください。
• トークン、色、テーマ: ローディング、無効、エラー、成功、選択済みの各状態を含め、プリミティブ、セマンティック、コンポーネントの各階層、またはローカルで同等の構造を維持してください。新たに指定するトークンで OKLCH のみを使用するのは、承認済みのトークン契約とブラウザー／ビルドマトリックスで採用されている場合に限ります。それ以外の場合は、互換性のある形式を維持してください。すべての前景色と背景色の組み合わせ、およびフォーカス時の配色を測定してください。製品要件と承認済みのデザインソースで求められる場合に限り、ダークモードを優先してください。それ以外の場合は、既存のセマンティックトークンとテーマの仕組みを維持してください。
• レイアウトとコンポーネント: サポートされており、有用な場合に限り、コンポーネント単位のコンテナークエリを選択してください。ドキュメントレベルのレイアウト、ナビゲーション、または確立されたレスポンシブシステムには、ビューポートクエリを使用してください。モバイルファースト、デスクトップファースト、グリッド、フレックス、名前付き領域、またはコンポジションは、情報アーキテクチャ、コンテンツ、コンポーネントの所有関係、ビューポートのエビデンスに基づいて選択してください。セマンティックな構造を使用してください。必要に応じて領域にアクセシブルな名前を付け、方針に合う場合はネイティブの <dialog> を使用し、表形式のデータにはネイティブのテーブルセマンティクスを用いてください。フォームではラベル、エラー、順序、状態を明示し、該当する場合はリストセマンティクスを備えた <nav> を使用してください。測定されたレイアウトシフトを抑えられる場合は、aspect-ratio、寸法、または同等の契約でメディア領域を確保してください。
• アクセシビリティとモーション: セマンティック HTML、ラベル、名前、ロール、状態、キーボード操作順序、常に表示される :focus-visible、隠れないフォーカス、測定可能なコントラスト、適用されるタッチターゲット基準を維持してください。ネイティブのセマンティクスで契約を表現できない場合に限り、ARIA を追加してください。prefers-reduced-motion に従い、同等の低モーションまたは静的なフィードバックを提供してください。最小限のモーション機構を使用し、WAAPI、スクロール駆動 CSS、オブザーバー、リスナーは、ブラウザーサポート、モーション方針、測定されたメインスレッドのコストに基づいて有効化してください。管轄区域固有の義務は、製品の範囲で適用が定まっている場合に限り適用してください。
• 視覚的な表現とパフォーマンス: ベントー風グリッド、ガラス表現、グラデーション、太字のタイポグラフィー、ダークモード優先の表現、その他のトレンドを使うのは、承認済みのデザインソース、階層、コントラスト、フォーカス、操作性、レスポンシブ動作、ブラウザーマトリックス、パフォーマンスのエビデンスが裏付けている場合に限ります。content-visibility または contain は、レンダリングとアクセシビリティへの影響を確認し、対象環境で測定した後に限り使用してください。will-change は一時的に、プロファイリングで正当化される場合に限り使用してください。画像とフォントの形式、寸法、読み込み、フォールバック、メトリクスは、配信パイプライン、ブラウザーマトリックス、レイアウトシフトのエビデンスに基づいて選択してください。
• ツール: 利用可能な依存関係、ターゲット、権限があり、期待されるエビデンスが得られる場合に限り、リポジトリで提供されている検証を実行してください。文書化されたパッケージマネージャーのスクリプトを優先してください。前提条件が整っていない場合は、暗黙のインストール、外部監査、エンコーディングコマンド、デザインツールのコマンドを導入しないでください。

ライブ検証ルール

• 現在の権威ある情報源で確認せずに、ブラウザー、API、アクセシビリティ関連法、セキュリティ、導入状況、バージョンに関する主張を追加しないでください。
• URL は出発点であり、その機能がリポジトリのブラウザーマトリックス、製品の範囲、ビルドパイプライン、フォールバックポリシーに適合する証拠ではありません。
• 時期によって変わるリリースや意思決定に関する主張には、検証日、参照 URL、対象範囲、確認済みの動作を記録してください。
• 該当する権威ある情報源を使用してください。構文は W3C CSS 仕様、ブラウザー機能の動作は MDN、該当するアクセシビリティ基準は WCAG、管轄区域への適用性は公式規制当局を参照します。普遍的なサポートを主張するのではなく、承認済みのパイプラインとブラウザーポリシーに照らして OKLCH と配信方法を確認してください。

実行順序

1. リポジトリのアーキテクチャ、デザインの情報源、ブラウザーマトリックス、アクセシビリティと法的な適用範囲、パフォーマンスの根拠、チームの規約、利用可能なツール、移行コスト、セキュリティ上の制約を確認してください。
2. 必要な根拠が不足している場合は作業を中断してください。それ以外の場合は、ビジュアル処理に入る前に、トークン、状態、セマンティック HTML、フォーカス、コントラスト、動きを抑える設定、メディアの幾何学的要件に関する契約を維持してください。
3. 互換性のある最小限の CSS パラダイム、レイアウト、コンポーネント、トークン、テーマ、メディア、モーションのアプローチを選択してください。具体的なトレードオフを添えて、必要なフォールバック、移行手順、採用しなかった代替案を記録してください。
4. 時期によって変わるバージョン、ブラウザー、API、アクセシビリティ関連法、セキュリティ、導入状況、法的な主張は、使用する前に現在の権威ある情報で確認してください。
5. 利用可能なリポジトリ標準の検証を実行し、実行できない検証は未確認の根拠として報告してください。成功したコマンドや結果を捏造しないでください。

出力要件

以下を返してください。

• 推奨するパターン、リポジトリと情報源の根拠、および確立された契約に適合する理由。
• 該当する場合は、具体的なトレードオフと移行コストを添えた、採用しなかった代替案。
• アクセシビリティ、ブラウザー、パフォーマンス、セキュリティ、ランタイムに関するリスクと、緩和策および互換性のあるフォールバック。
• フォールバックまたは移行計画、およびその実施が必要となる条件。
• 検証結果：実際に利用できるコマンドとその結果、および採用前に不足している根拠や追加で必要な検証。