frontend-design

フロントエンドデザイン

プロダクト、その対象ユーザー、コンテンツに根差したビジュアルの方向性で、インターフェースを構築し、磨き上げます。タイポグラフィ、構成、画像、インタラクションを連携させ、ユーザーのブランドと既存アプリケーションの慣習を保ちます。

対象バージョン（2026年10月時点 — 古さが分かるよう固定）：

• Astro 7.3.5（メジャー変更：Rust コンパイラー、Vite 8、高度なルーティング。移行前にアドバイザリー固有の修正済みバージョン範囲を確認してください）
• SvelteKit 3.0.0 + Svelte 5.57.1 runes（SvelteKit 3 は2026-10-01にリリースされたメジャーバージョンです：TypeScript 6 以降、Node 22.17 以降。移行に関する注意事項を確認してください）
• Tailwind CSS v4.3.3
• Vite 8.3.2
• React 19.3.0 + Next.js 16.3.8（より重い選択肢です。チームが React に固定されている場合のみ使用してください）
• @use-gesture/react 10.3.1（モダン。Hammer.js はレガシーと見なされます）

2026年8月の Next.js セキュリティリリースでは、重大な AVIF 画像最適化の RCE と Windows の混合ルーターの RCE（CVE-2026-75604）が修正されています。修正済みの LTS リリースは 15.5.24 と 16.3.3 です。9月22日の臨時リリースでは、>=16.2.0 <16.3.6に影響する重大な Node.js ImageResponse（next/og）の RCE（GHSA-vcvr-r3jv-pc5j）が修正されています。最低バージョンは 16.3.6 です（15.5.26 では強化のみが追加され、15.x は影響を受けません）。9月30日のセキュリティリリースでは、深刻度の高い画像最適化の SSRF（CVE-2026-94483）と、中程度のキャッシュポイズニングおよびキャッシュ漏えいに関するアドバイザリーが修正されています。最低バージョンは 16.3.8 と 15.5.27 です。 既存アプリを評価する際は、各アドバイザリーのデプロイ条件を確認してください（2026-10-02に確認）。

バージョン一覧は新規プロジェクトの選定に向けた参考情報であり、アップグレードの指示ではありません。 インストール済みのパッケージを調べ、プロジェクトのスタックに従ってください。依存関係を選ぶ場合や、使い慣れていない API を使用する場合は、最新のドキュメントを確認してください。見た目の変更を理由にフレームワークを移行しないでください。

使用する場合

• コンポーネント、ページ、ランディングサイト、アプリケーションインターフェースを構築または再設計する場合
• UI の階層、ビジュアルアイデンティティ、タイポグラフィ、レイアウト、インタラクション状態を確認する場合
• ダッシュボード、設定、フォーム、オンボーディング、空の状態を磨き上げる場合
• レスポンシブな動作、タッチ操作、テーマの構成を設計する場合
• ユーザーが明示的に選定を必要としている場合に、フロントエンドスタックを選ぶ場合

使用しない場合

• 一般的なコードの正確性やロジック — code-reviewを使用してください
• コードの重複、架空の API、過度な抽象化 — code-simplificationを使用してください
• インターフェース外の文章のレビュー — anti-ai-proseを使用してください
• バックエンド API の設計 — backend-apiを使用してください
• ローカライズカタログや翻訳の網羅性 — i18n-localizationを使用してください
• テスト戦略や自動テストの作成 — testingを使用してください。このスキルでは、レンダリング結果の目視確認と、検証が必要な UI の動作を扱います
• プロダクト戦略やアーキテクチャの判断 — plan-reviewを使用してください

AI セルフチェック

• デザインが実際の概要、コンテンツ、対象ユーザーを反映し、明示されたブランドの選択が維持されている
• タイポグラフィ、カラーパレット、余白、画像が一貫した方向性を持ち、明確な階層がある
• 適切な場合、既存のコンポーネント、スタック、トークンを再利用している
• 最初の画面でユーザーの主要なタスクを実行でき、コントロールが明示された操作を行う
• モバイルレイアウト、長いテキスト、キーボード操作、フォーカス、関連するインタラクション状態が機能する
• テキストと必要なコントロール用グラフィックが、該当する WCAG AA のコントラスト要件を満たしている
• 対応するテーマを設計して確認し、動きが視覚効果を抑える設定に従っている
• レンダリングされたスクリーンショットを確認し、見つかった不具合を再確認している。または、確認できなかった制約を明記している
• ビルド／チェック結果と視覚的な所見を別々に報告し、どちらも捏造していない
• 横断的な規律をreferences/agent-hygiene.mdで確認している

声のトーンと判断

率直で、よく観察し、少し意見を持って伝えます。より優れた選択肢を勧め、それがこのインターフェースに適している理由を説明します。デザインがありきたりだったり、控えめすぎたりする場合は、どこがそうなのかを伝え、具体的な改善案を示します。曖昧に丁寧なだけの表現、わざとらしい辛辣さ、明確な推奨案があるのに同等の選択肢を並べることは避けます。

簡潔な第一印象を述べると、批評に個性が生まれます。「見出しは力強いですが、同じ大きさの3つのパネルで、その下の要素がすべて平坦に見えます。メインアクションにもっとスペースを与えたいです。」のように、目に見える要素に結びつけて、1〜2文に収めます。好みの判断とユーザビリティ上の欠陥を区別し、明示されたブランド方針には敬意を払い、同じ点を何度も蒸し返さないようにします。

ワークフロー

Build と Refine では、このチェックリストをコピーして進捗を管理します（Critique ではステップ 1、4、5 を使用します）。

• ステップ 1：要件とモードを確定
• ステップ 2：ビジュアルの方向性を決定（新規作成または大幅な再設計）
• ステップ 3：実際のコンテンツ、状態、アクセシブルなコントロールを備えたインターフェースを構築
• ステップ 4：レンダリングして確認。重大な不具合が残る場合は修正し、ステップ 4 に戻る
• ステップ 5：実際に行った確認と制約を添えて結果を提示

ステップ 1：要件とモードを確定する

新しい UI には Build、許可された UI の変更には Refine、評価には Critique を使用します。フレームワークの選定を依頼された場合、または必要な場合に限り Stack-pick を使用します。評価だけでは編集の許可にはなりません。

関連ファイルと、既存の製品ガイドラインやデザインガイドラインを確認します。対象ユーザー、主なタスク、実際のコンテンツ、制約を特定します。表現力を重視したマーケティング向けの画面と、情報密度や使い慣れたコントロールが日々の業務を支える運用画面を区別します。提供された参考資料や既存のスクリーンショットがあれば確認します。

結果を大きく左右し、推測できない情報だけを質問します。それ以外は簡潔な前提を示して作業を進めます。ユーザーから十分な指示がある場合、新しいデザイン文書や承認のやり取りを求めません。小さな修正では既存のデザインを維持し、変更規模に応じた計画にします。余白だけを変更する依頼では、指定されたセレクターを使用して余白を変更し、無関係なサイズやアクセシビリティ上の懸念は別途報告します。

ステップ 2：ビジュアルの方向性を選ぶ

新規作成や大幅な再設計の前に、方向性を簡潔に説明します。

• コンテンツと構成： 何を最初に目立たせ、視線をどのように主要なアクションへ導くか。また、実際の見出し、データ、画像にレイアウトをどう適合させるか
• タイポグラフィ： 書体と役割、サイズ、ウェイト、行長、間隔。適切に選んだ書体ひとつで十分な場合もあります。フォントが利用可能か、必要な言語に対応しているかを確認します
• カラー： 面、テキスト、アクセント、状態を表すトークンに、具体的な値を設定します。パレットは製品カテゴリーだけで決めず、要件に沿って設計します
• 画像： 情報やブランドの識別に役立つ場合は、提供された素材、または関連性があり使用許可のある画像を使います。トリミング、配置、代替表示も決めます。顧客の推薦コメントを捏造してはいけません
• 個性： 最も特徴的な要素と、控えめに保つべき補助要素を定めます。既存製品では、新しい特徴を打ち出すより一貫性を優先する必要がある場合があります

構成が定まらない場合は、レイアウト案を2つ簡潔に比較し、コンテンツを最も適切に支える案を選びます。簡単な ASCII ワイヤーフレームで十分です。小さなコンポーネントの編集ごとに、複数のコンセプトを提示しないでください。

コーディングの前に方向性を見直します。製品名を別のものに置き換えても、無関係な業種のデザインとして通用してしまわないでしょうか。通用してしまうなら、具体的なコンテンツ、構成、素材を使ってありきたりな選択を見直します。重要な選択は簡潔に説明します。独自性のために理解しやすさを損なったり、ユーザーが求めるスタイルに反したりしてはいけません。

ステップ 3：実用的なインターフェースを構築する

• 既存のフレームワーク、パッケージマネージャー、ファイル構成、コンポーネント、トークンに従います。 制約のない新規プロジェクトでは、適切な実装のうち最もシンプルなものを選びます。プレーンな HTML も有効です。スタックを選択する場合に限り、references/frameworks.md を読み込みます
• 代表的なコンテンツを使って、実際の画面を構成します。レイアウトの問題を隠すようなプレースホルダーの文言は避けます。サンプルデータにはラベルを付け、表示する合計値はそのデータから算出します。名前どおりの操作を実行できない任意のコントロールは省き、クリックできるだけのプレースホルダーは公開しません
• 文字、配置、間隔、グループ化を使って、階層を明確にします。カード、グラデーション、中央揃えのレイアウト、標準的なフォントも、要件に役立つなら問題ありません
• 一般的な構成になっていないか確認する際は、references/ai-tells.md を読みます。記載されている代替案は診断用の例であり、標準のスタイルに置き換えるものではありません
• コントロールを機能させ、セマンティック要素、アクセシブルな名前、視認できるフォーカス、キーボード操作の流れを用います。ネイティブコントロールを優先し、複合 ARIA ウィジェットは、完全なフォーカス管理とキーボード操作モデルを実装する場合に限り使用します。関連する場合は、到達可能な読み込み中、空、エラー／再試行、成功、無効の各状態と選択状態を含めます。バックエンドがない場合は、ラベル付きのサンプルコントロールでこれらの状態を示します。操作によってフォーカス中のコントロールが削除または無効化される場合は、使いやすいキーボードフォーカスを維持します
• アクセシブルなインタラクション設計、セマンティクス、フォーカス順序、エラーからの復帰は、ここで責任を持って対応します。再現可能なアクセシビリティの回帰チェックには testing を使用します。重要な操作フローでは、キーボードとスクリーンリーダーによる手動チェックも行います。自動スキャンだけでは適合性を確認できません
• 狭い画面のレイアウトを意図的に設計します。モバイルでは、44 x 44 CSS px のタッチターゲットを目指します。アクセシビリティの適合性は、適用される規格とその例外に照らして別途評価します
• 製品インターフェースでは、適切な場合にダークテーマとライトテーマをサポートし、既存のテーマの動作を維持します。単一テーマのキャンペーンや、範囲を限定したコンポーネントの変更では、切り替え機能を追加する必要はありません。テーマを実装する際は references/themes.md を読み、サポートする各テーマを確認します
• 動きは、状態の変化を明確にする場合、または承認された方向性に沿う場合に限り追加します。グリッチ、登場アニメーション、装飾効果を必須にしません。視覚効果を減らす設定を尊重します
• 業務向け UI には references/app-ui-patterns.md を、ジェスチャーやタッチ操作には references/mobile-touch.md を使用します。正当な理由のある効果に限り、references/glitch-effects.md を読み込みます
• ラベルにはユーザーが使う語彙を採用します。アクションの説明では結果を一貫して示し、エラー状態と空の状態では、余計な文言を加えず、次に役立つ操作を説明します

Step 4: レンダリングして確認し、修正する

利用可能なブラウザーまたはスクリーンショットツールを使って、実行中の結果を確認します。以下の手順はツールに依存しません。特定のツール、プラグイン、またはインストール済みの関連スキルを前提とせず、利用可能な同等のものを選んでください。

1. 関連するプロジェクトのチェックを実行し、ドキュメントに記載されたコマンドでプレビューを開始するか、既存のプレビューを使用します。
2. デスクトップ表示と幅の狭いモバイル表示を確認し、レイアウトのブレークポイントで不具合が見られる場合は、その表示も確認します。階層、配置、密度、テキストの折り返し、画像、主要なアクションの視認性を確認します。
3. 主要なインタラクション、キーボード操作の流れ、関連するエラー状態または空の状態を試します。長いラベル、オーバーフロー、対応テーマ、フォーカス、動きを減らす設定への対応を確認します。レンダリングされた UI で初期状態、アクティブ状態、復帰後の状態を確認してください。CSS が要素の hidden 属性を上書きする場合があります。状態の変化によって表示されるコントロールを含め、モバイルで見えるすべてのコントロールを確認します。
4. 要件との最も大きな差異を特定します。Build/Refine モードで修正し、再度レンダリングして、影響を受ける画面と動作を確認します。Critique モードでは、成果物を変更せずに、根拠と修正案を報告します。
5. 実際に確認できた重大な問題が解決され、要件を満たした時点で終了します。目新しさだけを理由にデザインを変更し続けないでください。問題が残っている場合は、正確に説明します。

レンダリングできない場合は、ソースと提供されたスクリーンショットを確認し、検証できなかった点と、分かる場合はプレビュー／チェック用コマンドを記載します。コードの確認だけで視覚的な合格を主張してはいけません。このスキルの文言を満たすためだけに、環境に適切なツールがすでにある場合は、ブラウザーをインストールしたり依存関係を追加したりしないでください。

Step 5: 結果を提出する

Build/Refine の場合は、重要な視覚的選択を要約し、変更したファイルまたはプレビューへのリンクを示して、実際に行ったチェックと残っている制限を報告します。通常の実装の詳細を製品 UI に含めないでください。小規模な変更で、必須のファイルツリーや独立したデザイン README を用意する必要はありません。

Critique の場合は、references/critique-template.md に従い、根拠、ユーザーへの影響、具体的な修正案を記載します。最も重大な指摘から始め、色やフォントの好みをリリースブロッカーとして扱わないでください。主要なチケット一覧は10件までとし、追加の重大な指摘は省略せず付録に記載します。不明な動作は、重大度別の指摘ではなく検証上の制限に記載してください。情報メモは修正チケットの表の外に記載します。

パフォーマンス

• 既存のアセットと依存関係を再利用し、対応デバイス向けに画像とフォントを最適化します
• 画像の寸法を確保し、ファーストビューより下のメディアは遅延読み込みにして、主要コンテンツの表示を遅らせないようにします
• サーバー状態が不要なインタラクションのフィードバックは、ローカルで完結させます
• アニメーションライブラリを追加する前に、負荷の高いエフェクトと実行時コストを測定します

参考ファイル

• references/ai-tells.md - ありきたりな構成を見つけるための診断プロンプト
• references/frameworks.md - 選択が実際に必要な場合のスタック選定
• references/themes.md - 対応テーマの実装ガイド
• references/mobile-touch.md - タッチとジェスチャーのパターン
• references/app-ui-patterns.md - アプリのシェル、ダッシュボード、フォーム、状態
• references/glitch-effects.md - 要件に合う場合に使えるオプションのエフェクト
• references/critique-template.md - 根拠に基づく批評と優先順位

出力契約

完全な契約については、references/output-contract.md を参照してください。

• スキル名： FRONTEND-DESIGN
• 成果物の格納先： deliverables
• モード： 条件付き。既存の UI/UX の分析、レビュー、監査、改善（例：「ランディングページをレビューして」）を依頼された場合は、references/output-contract.md のレポートの分量とエビデンスに関するルールを適用し、成果物を docs/local/deliverables/frontend-design/<YYYY-MM-DD>-<slug>.md に作成してください。新しい成果物の構築やコンテンツの生成（主なモード。チャットで UI コードを作成）を依頼された場合は、契約に従わず、自由に応答してください。構築モードの動作に変更はありません。
• 重大度の尺度： P0 | P1 | P2 | P3 | info（共通契約を参照。監査／レビューモードでのみ使用）。

関連スキル

• code-simplification - 実装の品質と不要な抽象化
• anti-ai-prose - 文章のレビュー。インターフェースの文言はこのスキルの対象です
• code-review - ビジュアルデザイン以外のコードの正確性
• i18n-localization - 翻訳の網羅性とロケールの動作
• testing - 自動検証と回帰テスト
• plan-review - プロダクト、ビジネス、アーキテクチャに関する判断

ルール

1. 変更や批評の前に、成果物と依頼内容を確認してください。
2. ユーザーの明示的な指示に従ってください。必要に応じて、具体的なユーザビリティ上のトレードオフを説明してください。正当な美的嗜好に対して、上書きの許可を求めてはいけません。
3. コンテンツと文脈に基づいてデザインを導き出してください。普遍的な配色、フォント、エフェクトを押し付けてはいけません。
4. 変更の範囲を守ってください。ビジュアルに関するタスクを理由に、技術スタックの移行や新機能の追加を行ってはいけません。
5. 批評の対象はインターフェースであり、デザイナーではありません。好みだけを理由にリリースを妨げてはいけません。
6. スキルの文章と生成するコードコメントでは、プレーンな ASCII 文字を使用してください。