frontend

フロントエンド

このファイルはルーターであり、ルールブックではありません。ルールは references/ 内の4つのルールセットにあり、それらを読むことが作業そのものであって、前置きではありません。ファイルに手を加える前に、依頼によって参照するものと、それぞれが必要な理由を1つずつ挙げ、その参照だけを正確に読んでください。先に対象を明示すれば、選択をレビューできます。名前を挙げなかった参照は読まないと決めたものであり、名前を挙げたのに開かなかった参照は、まだ埋めるべき抜けです。指定された参照を無視して独自に進めると、このスキルが防ごうとしている、ありきたりなAIの粗雑な出力になります。

目指す基準は、きれいで正しいことではありません。Linear、Stripe、Supabaseのシニアデザイナーが公開するに値する仕事です。 正しいけれど平板なものは失敗であり、完成ではありません。実装を守るのと同じくらい、表層の品質も大切にしてください。デザインは最初に一度決めて終わりにするものではなく、最優先で取り組むべき成果物です。

フェーズ 0 — 振り分け（UI 作業の前）

リクエストの内容…	参照先
UI の実装、スタイリング、再設計、モックアップ、ビジュアルに関する判断のいずれか	まず references/design/README.md を読みます。必須のゲートが 2 つあります。コンポーネントを書く前に DESIGN.md が存在していなければならないデザインシステムゲートと、React Dev Tooling ゲート（react-grab / react-scan / react-doctor がデフォルトでインストールされます）です。その後、以下のテイストおよびブランドのリファレンスに進みます。
空間構造 — アプリシェル、スクロールの所有権、「どこに何を配置するか」、「このレイアウトは X で崩れる」	仕組みについては references/design/layout-skill.md も読み、続いて references/design/stylegallery.md で、その空間的な問題に合った名前付きパターンの仕様を取得します。どちらもスタイルスキルに追加するもので、ビジュアルの方向性は示しません。
ページ分割される出力 — PDF レポート、印刷用スタイルシート、ヘッドレス Chrome の印刷パイプライン、印刷する HTML スライド、または「このページが半分空いているのはなぜか」というページ分割の不具合	ページボックス、フラグメンテーションのプロパティ、アトミックブロックのセット、ほぼ空のページにブロックが取り残される keep-together の副作用については、references/design/print-paged-media.md も読みます。ビジュアルの方向性は示さず、振り分けられたスタイルスキルに追加するものです。
インタラクションやモーションの作業 — マイクロインタラクション、アニメーション付きコンポーネント、トランジション、ジェスチャー、ホバー／押下／状態のフィードバック、「生き生きとした感じにする」	references/design/interaction-skill.md も読みます。beui.dev カタログは必須のインタラクションリファレンスです。最も近いパターンを見つけ、ファイル内の curl レシピを使って実際のソースを読み、その仕組みを DESIGN.md のモーショントークンに合わせて調整します。振り分けられたスタイルスキルに追加するものであり、置き換えるものではありません。
ヒーローの雰囲気や空気感 — アニメーション、シェーダー、パーティクル、グリッドの背景、タイポグラフィの演出（分割、ぼかし、きらめき、タイプライター、カウントアップ、マーキー）、スクロールに合わせたストーリーテリング、スポットライト／傾き／グレア／発光枠のカード表面、「ヒーローを見事なものにする」、「動きのある背景を追加する」、「見出しをアニメーションにする」	references/design/ambience-skill.md も読みます。react-bits カタログは必須のアンビエンスリファレンスです。意図マップで最も近いパターンを見つけ、ファイル内の curl レシピを使って実際のソースを読み、仕組みを抽出してから、リリース前に改修チェックリスト（動きの軽減、画面外での一時停止、コンポジターのみ、トークン、予算）を実施します。振り分けられたスタイルスキルに追加するものであり、置き換えるものではありません。また、react-bits のコードをベンダーとして取り込んではいけません。
依頼のトーンや表面がどちらのアンカーにも当てはまらない — AI エージェントの UI、チャート、ランディングページのセクション、ブルータリストや Tailwind のみのビルド — またはアンカーに最も近いパターンがない	references/design/component-catalogs.md も読みます。該当するトーンに応じて参照するカタログ、調査手順、その他すべてのカタログに対するライセンスと利用規約のゲートを確認します。
フロントエンドコードの作成または変更、またはパフォーマンス／SEO／アクセシビリティ／品質の監査	references/perfection/README.md も読みます。実際の Playwright Chromium で測定し（lighthouse CLI は使用しません）、アーキテクチャによってすべてのカテゴリで Lighthouse 100 を達成します。アニメーションを削除したり、コンテンツを隠したりして達成してはいけません。
具体的なスタイル、配色、フォントの組み合わせ、チャートの種類、ランディングページの構成、UX ガイドラインを調べる、またはキーワードからデザインシステムを生成する	references/ui-ux-db/README.md を参照します。CLI を備えた検索可能な CSV データベースです。姿勢を示すものではなく、検索ツールです。テイストの信頼できる情報源および DESIGN.md の仕様は引き続き design です。
DESIGN.md を作成または更新するあらゆる実装や再設計 — および運用レイヤーに関する明示的な依頼（ペルソナ、批評、負債、引き継ぎ、合成ユーザーテスト）	references/designpowers/README.md と lane-c-review.md を参照します。lane-c はフェーズ最終段階のフラットさ／批評のレビュアーであり、DESIGN.md で必須となるアクセシビリティ制約と受け入れ済み負債のセクションを補います。他のレーンは、そのフェーズが該当する場合にのみ読み込みます。

実装作業では、design と perfection を併せて読み込みます。 2 MB のバンドルになる美しさでは不十分です。AI が作ったような見た目の Lighthouse 100 も不十分です。両方を達成するか、どちらも達成できないかです。

Draft guard — UI の最初の行を書く前に読む

一部の典型的な兆候は、デフォルトで再生成されてしまうため、QA で見つかるのを待つのではなく、最初のドラフトから除外します。

• 装飾目的でも状態表示でも、角丸の面に色付きの縁を付けないでください。 カード、コールアウト、統計タイル、推薦文、アラート、リスト行の片側に、色付きの帯を付けてはいけません。たとえば、角丸のボックスに付ける border-top: 4px solid <accent> や border-l-4 border-indigo-500、ボックス内の色付きの ::before／::after のバー、内側の box-shadow の帯、片側に沿った段差のあるグラデーション帯やグラデーションの border-image などです。角丸に沿って帯が曲がるため、カードの装飾でも、選択・フォーカス・アクティブ状態の表示でも、生成されたような見た目になります。カードの個性は別の方法で表現してください。たとえば、トーンを抑えた面（低いアルファ値の単色、または面の段階の次のステップ）、アクセントカラーの文字で設定した眉見出しや見出し、先頭のグリフ、グループ間の余白などを使います。状態は、さまざまなアルファ値の単色（ホバー／選択／アクティブ時のウォッシュ）、選択を示すチェックのグリフ、フォーカスを示すトーンのレイヤーで表現してください。引き続き使用できる色付きの縁は、キーボードの focus-visible リング、フォーム入力の検証状態、ニュートラルな 1px の細線と区切り線、テーブルの罫線です。これは、作業対象のあらゆる面に既存のものがある場合にも適用されます。
• ビジュアル QA の前にリンターを実行してください。 作成したすべてのスタイルシートとコンポーネントに対して、bun $SKILL_DIR/scripts/perfection/check-accent-stripes.ts <changed files or dirs> を実行してください。CSS／SCSS／Less、HTML、JSX／TSX、Vue、Svelte、Astro、Tailwind クラス（@apply や cva／cn 文字列を含む）、インラインスタイル、styled-components がチェック対象です。終了コードが 1 の場合、ドラフトに帯があります。見つかった帯は削除し、指摘に異議を唱えないでください。

デザインシステムとコンポーネントのワークフロー

すべての実装では、UI コードを変更する前に、次の分岐のいずれかを選択する必要があります。

1. 具体的なビジュアルリファレンス： ユーザーからリファレンスが提供された場合は、それをビジュアル上の基準として扱い、種類に応じて対応します。
   • 静的なビジュアルリファレンス（スクリーンショット、生成されたモックアップ、Stitch/Imagen の出力、Figma のエクスポート、概要、注釈付き資料）：references/design/image-to-code-skill.md と関連するデザイン／品質向上用ファイルを読み込み、リファレンスの正確なトークン、レイアウトの幾何学的構成、コピー、余白、状態、レスポンシブ対応の意図を抽出して DESIGN.md に記録し、その仕様に沿って再利用可能なプリミティブを実装します。
   • ライブサイトまたは URL のリファレンス（ユーザーが模倣するサイトを指定する、または URL を提示する場合）：references/design/clone-from-url.md を読み込みます。実際のブラウザーを操作し、getComputedStyle を使って実行時の実態を抽出します。トークン、レイアウトの幾何学的構成、デフォルト／ホバー／フォーカス／アクティブ状態、トランジションとキーフレーム、ダウンロードしたアセットを DESIGN.md に記録し、その仕様に沿って再利用可能なプリミティブをクローン実装します。 どちらの場合も、最終 QA では /visual-qa をリファレンス忠実度モードで実行します。実際の UI をリファレンスとピクセル単位で比較し、コードがスクリーンショットに合わせただけの単発実装ではなく、拡張可能なデザインシステムの実装であることを確認します。
2. ゼロからの構築または新規セットアップ： 具体的なビジュアルリファレンスがユーザーから提示されていない場合、デザインリサーチは探索の予算を割り当てる対象ではなく、成果物を伴う構築工程です。「十分に探索した」という判断や、2 波までという上限は適用されません。DESIGN.md を作成する前に、すべてのリサーチレーンを並行して実行し、DESIGN.md の冒頭に ## 0. Research Log セクションを設けて各レーンの成果物を記録します。Research Log に記載のないレーンは、実行されなかったものとみなします。ツールまたはネットワークが実際に利用できない場合に限り、そのレーンを省略し、DESIGN.md に省略理由を明記します。
   • 埋め込みリファレンス： references/design/_INDEX.md を使って、有力な Layer B リファレンスを 2～3 件に絞り込み、Layer A スタイルスキルを 1 つ、Layer B リファレンスを 1 つ、それぞれ全文を読みます。すべての行を読み、部分的な読み込みはしません（これらは 200～500 行あり、一部だけを読むと、このゲートで防ごうとしている画一的なトークンセットになってしまいます）。候補、選択したもの、その理由を記録します。厳選された候補に合うものがない場合に限り open-design を使い、配色／書体／ドメインに関する質問には ui-ux-db の検索結果を追加します。
   • Lazyweb の実製品画面： まず references/design/lazyweb.md を読み、その手順をそのまま実行します。独自の判断で lazyweb.com に対する curl を実行しないでください。手順の中で匿名トークンが発行されます。実行したクエリ、実際に閲覧した画面数、抽出したレイアウト文法を記録します。ピクセル単位での複製は行いません。
   • StyleGallery の空間パターン： references/design/stylegallery.md を読み、画面の主要な空間的課題に合致するパターンを取得します。採用したパターンと、スクロールを担う要素を記録します。
   • Imagen のコンセプト案： 読み込んだ Layer A と Layer B のトークン（配色、書体、素材感）をそれぞれに反映して、Imagen のコンセプト案を 2～3 件生成します。最も優れた案を選び、その案をリファレンス忠実度の基準として扱います。案のパスと選択結果を記録します。 すべてのレーンの成果を DESIGN.md に統合します。参照元は雰囲気を示すラベルではなく、素材として扱います。トークン、レイアウト文法、コンポーネントの構成、インタラクション状態、モーション、デザイン上の判断を抽出し、それらを組み合わせてプロジェクト固有のプリミティブにします。セクションのレイアウトを決める前にコンテンツブロックをすべて洗い出し、それぞれに役割（関心を引く、説明する、裏付ける、比較する、行動を促す、案内する、継続利用を促す）を割り当てます。そのうえで、視覚的な対称性ではなく、訪問者が意思決定する流れに沿ってセクションを並べます。選択したリファレンスから独自の判断で逸脱せず、ロゴやブランド固有のコピーを模倣しないでください。その後、製品画面を作成する前に Primitive Showcase Gate（references/design/README.md の Phase 0）を実行します。
3. DESIGN.md またはコンポーネントシステムがある既存プロジェクト： 内容を読み、指示に従います。依頼された作業で新しいトークン、プリミティブ、状態、モーションルール、アクセシビリティ上の制約、許容済みの負債、またはリファレンス忠実度の要件が必要な場合に限り、実装前に更新します。
4. UI はあるが DESIGN.md も再利用可能なコンポーネントレイヤーもない既存プロジェクト： **作業を止め、**現在の見た目を保ったまま近接するスタイルで実装するのか、続行前に実際の DESIGN.md と再利用可能なコンポーネントを作成するのかを、ユーザーに焦点を絞った質問で確認します。黙って一方を選ばないでください。 生成される DESIGN.md は実装の契約です。コードで使用する前に、トークン、タイポグラフィ、間隔、プリミティブ、モーション、レスポンシブ動作、アクセシビリティ上の制約、許容する負債をここに明記してください。コンポーネントのプリミティブ、状態、最終画面は、実際のビジュアル QA の証拠を用いて検証してください。重要な実装作業では、デザインシステムに関する判断、実装の証拠、未解決の負債を /review-work に引き継いでください。

ルールセット 1 — デザイン（references/design/）

リファレンスライブラリには、アーキテクチャファイルが 1 つ、12 個のテイストスキル（レイヤー A — 実行方法）、70 個のブランドデザインシステム（レイヤー B — 見た目）があります。ほとんどの複雑なタスクでは、レイヤー A を 1 つ + レイヤー B を 1 つ読み込みます。ルーティングフロー全体、積み重ねのルール、アンチパターン、必須のブラウザベースのデザイン QA フェーズは README.md に記載されています。83 個すべてのファイルと、ムードからブランドへのマッピングは _INDEX.md にまとめられています。以下の表だけではルーティングが明確でない場合は、これを読んでください。

レイヤー 0 — アーキテクチャ

ファイル	読むタイミング
design-system-architecture.md	プロジェクトに DESIGN.md がない場合（最初に作成する構成を定義します。8 つのセクションに加え、グリーンフィールドの場合のみ ## 0. Research Log を含みます）、または既存の UI コードからデザインシステムを抽出する場合。

レイヤー A — テイストスキル（スタイルスキルは最大 1 つ選択してください。相反する方針を採用しています）

ファイル	ユーザーが次のように言った場合に読む
taste-skill.md	特別な表面表現を求めない、中立的または実用的な UI。社内ツール、ダッシュボード、「とにかく使いやすくして」。無難な既定値です。依頼内容が光沢感、高級感、スタートアップ品質の仕上がりを求めている場合は、これで妥協しないでください。
gpt-tasteskill.md	「Awwwards 級」「驚きのある仕上がり」「映画のような」「スクロール連動」のマーケティング／ランディング体験。
minimalist-skill.md	「ミニマル」「クリーン」「Notion 風」「Linear 風」「エディトリアル」。
brutalist-skill.md	「ブルータリスト」「生々しい」「スイス風」「実験的」「アンチデザイン」。
soft-skill.md	「高級」「ラグジュアリー」「落ち着いた」「高価」「エレガント」に加え、光沢感／ガラス感／液体ガラス／スタートアップ品質のプロダクト表面。高い仕上がりのレイヤー B（supabase、linear.app、vercel、stripe）と組み合わせてください。
redesign-skill.md	既存の UI を改善する場合。「見た目が悪い」「デザインを直して」。まず監査するワークフローです。グリーンフィールドでは使用しないでください。
image-to-code-skill.md	「まずデザインを生成してから、コードを書いて」。以下の画像生成ファイルのいずれか 1 つと組み合わせてください。
output-skill.md	出力が不完全な場合に、任意のスタイルスキルと組み合わせます。プレースホルダー、// TODO、未完成のコンポーネントなど。
stitch-skill.md	Google Stitch との互換性や、DESIGN.md ドキュメントのエクスポートが必要な場合に、任意のスタイルスキルと組み合わせます。完成したエクスポート例は stitch-design-example.md にあります。
interaction-skill.md	インタラクションまたはモーションを追加・変更する作業では、任意のスタイルスキルと組み合わせます。beui.dev を基準とし、インタラクションを設計する前に、対応するコンポーネントのソースを読みます。モーションの低減には常に対応してください。
ambience-skill.md	ヒーローの雰囲気、アニメーション背景、タイポグラフィのリビール、スクロールチャプター、カード表面のエフェクトを追加する作業では、任意のスタイルスキルと組み合わせます。react-bits を基準とし、対応するコンポーネントのソースを読んで仕組みを抽出し、レトロフィットのチェックリストを実行します。ヒーローには雰囲気を 1 つだけ適用し、カーソルエフェクトは隔離してください。
imagegen-frontend-web.md / imagegen-frontend-mobile.md / imagegen-brandkit.md	画像のみの出力（モックアップ、アプリ画面のコンセプト、ブランドボード）。これらはコードを絶対に記述しません。コードが必要な場合は、image-to-code-skill.md に切り替えてください。

レイヤー B — ブランドデザインシステム（レイヤー A とは直交。自由に組み合わせ可能）

ユーザーがブランドやサイトを指定したとき —「Linear 風」「Stripe のランディングページのような」「Aside 風ブラウザエージェント」— references/design/<brand>.md をトークンの信頼できる情報源（パレット、タイプスケール、コンポーネント、推奨事項・非推奨事項）として読み込みます。対象には aside apple stripe linear.app notion vercel claude figma airbnb nike tesla spotify raycast revolut とさらに約 56 件が含まれます。ムードのショートカットを含む完全なリストは _INDEX.md にあります。トークンを抽出し、プロジェクト自身のコンテンツに適用してください — ロゴや商標登録された画像を決してコピーしないでください。指定されたブランドが見つからない場合は、レイヤー A のムードマッチまたは open-design スキルにフォールバックしてください。

React 開発ツール

ファイル	読むタイミング
react-dev-tooling-skill.md	React プロジェクトに react-grab / react-scan / react-doctor が欠けている場合、またはフレームワークごとのインストールスニペットと開発専用ゲーティングパターン（NODE_ENV === 'development'）が必要な場合。

ルールセット 2 — perfection（references/perfection/）

ファイル	読むタイミング
README.md	フロントエンドコードを記述または監査するあらゆる場合。7 つの原則を記載しています。実ブラウザでの監査のみ、全カテゴリで 100 を下回らないこと、アーキテクチャレベルでの修正、スコアのために UX を決して弱めないこと、デザインシステム準拠チェック、および監査レポートのレスポンス形式です。
react-perf-tooling.md	あらゆる React 監査の前。Playwright + playwright-lighthouse + react-scan/lite の注入レシピ、ルートごとのレンダリングバジェット、および React 固有の根本原因チェックリストです。不要なレンダリングが 30 回以上ある状態での Lighthouse 100 は完了とは見なしません。

監査 CLI（まず本番用にビルドしてください。開発サーバーを決して測定しないでください）：

uv run $SKILL_DIR/scripts/perfection/lighthouse-audit.py https://localhost:3000

モバイルとデスクトップの両方のプリセットを実行し、3〜5 回実行して中央値を取り、JSON レポートから診断してください。

ルールセット 3 — ui-ux-db（references/ui-ux-db/）

README.md には検索 CLI と、マスタープラスオーバーライドの永続化パターンが記載されています。CLI（data/ を見つけられるよう、ルールセットのディレクトリから実行してください）：

python3 $SKILL_DIR/references/ui-ux-db/scripts/search.py "<query>" --design-system -p "Project"   # full design-system generation
python3 $SKILL_DIR/references/ui-ux-db/scripts/search.py "<query>" --domain <domain>             # targeted lookup
python3 $SKILL_DIR/references/ui-ux-db/scripts/search.py "<query>" --stack <stack>               # stack best practices

ドメイン：product style typography color landing chart ux react web prompt。スタック：html-tailwind（デフォルト）react nextjs vue svelte astro swiftui react-native flutter shadcn jetpack-compose。

ルールセット 4 — designpowers（references/designpowers/）

README.md は、固定された Owl-Listener/designpowers コーパスをこのワークフローにルーティングします。これはデザインコンテキスト — ペルソナ、アクセシビリティと認知の制約、クリティーク、負債、ハンドオフ、合成ユーザーテスト、モーション、ロールプロンプト — を提供し、まず DESIGN.md に蒸留し、その後で実装契約として使用する必要があります。これは何も置き換えません：このスキルも、/visual-qa、/ulw-plan、/ulw-execute、/review-work も置き換えません。

クイックルート — よくあるリクエスト

リクエスト	読み込む内容
「ランディングページを作って」（方向性の指定なし）	design/README.md + design/_INDEX.md の候補リスト → Layer B のリファレンスを正確に1つ + design/taste-skill.md + perfection/README.md
「Aside スタイルの AI ブラウザー／ブラウザーエージェントのページ」	design/README.md + design/aside.md + design/taste-skill.md + perfection/README.md
「Linear スタイルのランディングページ」	design/README.md + design/linear.app.md + design/taste-skill.md + perfection/README.md
「Stripe のようなプレミアムな SaaS のヒーロー」	design/README.md + design/stripe.md + design/soft-skill.md + perfection/README.md
「既存のダッシュボードを改善して」	design/README.md + design/redesign-skill.md + perfection/README.md
「マイクロインタラクションを追加して」／「これにアニメーションを付けて」／「生き生きとした印象にして」／「インタラクションを洗練させて」	design/README.md + 現在のスタイルスキルに加えて design/interaction-skill.md + perfection/README.md
「ヒーローを見事に仕上げて」／「アニメーション背景を追加して」／「見出しにアニメーションを付けて」／「カウントアップ／タイプライター／マーキー」／「スポットライトや傾斜をカードに付けて」	design/README.md + 現在のスタイルスキルに加えて design/ambience-skill.md + perfection/README.md
「このスクリーンショット／Imagen のモックアップ／Stitch の出力をそのまま作って」	design/README.md + design/image-to-code-skill.md + perfection/README.md + /visual-qa のリファレンス忠実度モード
「サイトを監査して」／「このページを高速化して」	perfection/README.md（React の場合は perfection/react-perf-tooling.md も）
「フィンテックアプリのモックアップ画像」— コードなし	design/imagegen-frontend-mobile.md（ブランド名が指定されている場合は Layer B のブランドも）
「ウェルネスブランドに合う配色／フォントは？」	ui-ux-db/README.md → 検索 CLI
「これはどこに配置すればいい？」／「レイアウトが崩れる」／スクロールとコンテインメント	design/layout-skill.md + 現在のスタイルスキルに加えて design/stylegallery.md
「この分野のリリース済みアプリはどんな見た目？」／デザインの方向性に関する調査	design/lazyweb.md（curl のみ）+ design/_INDEX.md の候補リスト
「この React プロジェクトをセットアップして」	design/README.md + design/react-dev-tooling-skill.md
「designpowers を使って」／「デザインワークフローを強化して」／「ペルソナ／アクセシビリティ／技術的負債／引き継ぎを追加して」	design/README.md + designpowers/README.md（実装または監査も行う場合は perfection/README.md も）

共通の公理（4 つすべてのルールセットで合意済み — 常に適用）

• デザインシステムがなければ、UI 作業は行いません。 コンポーネントを作成する前に DESIGN.md を用意します。すべての色、フォントサイズ、余白の値は、同ファイル内のトークンに基づいている必要があります。
• 具体的な参考資料は契約です。 スクリーンショット、モックアップ、注釈付きの参考資料がある場合、ユーザーが変更を了承しない限り、そのピクセル、文言、コンポーネント構造、レスポンシブ対応の意図を一致させます。
• スコアを稼ぐために UX を損なったり、見た目を平坦化したりしてはいけません。 Lighthouse スコアや納期を理由に、アニメーションを削除したり、コンテンツを隠したり、操作を簡略化したり、レンダリングされた素材や光沢のある素材を、単色の塗りや平面的な幾何学図形に置き換えたりしてはいけません。スコア 100 と立体感のある見た目を両立させてください。両方を達成するか、どちらも行わないかです。
• アイコンに絵文字を使ってはいけません。 SVG アイコンセットのみを使用してください（Lucide、Heroicons、Radix、Phosphor）。
• 角丸の面に色付きの縁取りを付けてはいけません。 カード上の装飾的なアクセントストライプも、選択中の行に付ける border-l-2 border-primary のストライプも同じ問題であり、フォーカス中のカードにプライマリーカラーのアウトラインを付けるのも同様です。Draft ガードには代替案と許可される例外が記載されています。/visual-qa の前に check-accent-stripes.ts が 0 で終了する必要があります。自分が書くコードだけでなく、手を加えるすべての画面に既存の該当箇所があれば、一掃してください。
• GPU で合成されるアニメーションのみ使用します — transform、opacity、filter。レイアウトプロパティはアニメーションさせてはいけません。
• 意味のないアニメーションは禁止です — 動きには意味を持たせてください。 すべてのアニメーションやホバーは、実際の操作、状態の変化、またはアフォーダンスに対応させます。何も変化しないホバー、インタラクティブでない要素の動き、情報を伝える目的のない装飾的なマイクロアニメーションは無駄です。追加してはいけません。
• 完了の判定基準は /visual-qa のゲートであり、自分の目視確認ではありません。 フロントエンドのデザイン作業は、/visual-qa で検証します。そこでは、HIG に基づくチェックリスト、キャプチャーマトリックス（すべてのページと各関連画面、スマートフォンとデスクトップ、ライトとダーク、末尾までスクロールした状態、動きを再生して検査した状態）、および新たな証拠に基づく二重オラクルの完了ゲートを使います。このスキル独自の目視チェック項目リストはありません。検証ツールが管理します。

代わりに別のスキルを読み込む場合

状況	読み込むもの
references/design/ にある 70 種類にブランドやスタイルがない、またはユーザーが「Open Design」と言っている	ローカルの nexu-io/open-design ライブラリ（137 以上のデザインスキル、150 以上のデザインシステム）を含む open-design スキル
デザイン QA フェーズでブラウザーを操作する	visual-qa スキル：js eval による omowright（レンダリングには所有エンジン、サインインが必要なページにはアタッチ済みエンジン）
視覚的な画面をまったく伴わない純粋な TypeScript／ロジック作業	programming スキルのみ — このスキルを加えても何もありません

有効化

フロントエンド、ウェブ UI、UX、ビジュアル、デザイン、スタイリング、レイアウト、アニメーション、パフォーマンス、アクセシビリティ、SEO に関する作業（構築、再設計、監査、モックアップの生成）で使用します。バックエンド、CLI、または視覚的な画面を伴わない純粋なロジックの作業には使用しません。