frontend-design-ui-ux

これは実装スキルではなく、デザイン仕様スキルです。交渉の余地のないルール： 1. このスキルで本番用の UI コードを書かないでください。仕様と固定されたデザイン言語を作成し、構築作業はエンジニアリングエージェントに委任してください。デザイン仕様を作成するのは私たちであり、エージェントが実装します。 2. 画面を仕様化する前に、独自性のある美的アイデンティティを 1 つ決め、反実仮想のデフォルトテストに合格してください。同様の依頼ならどれでも同じ見た目にするのであれば、それはデフォルトです。変更してください。 3. `references/anti-slop.md` にある名前で AI スロップを禁止してください。スロップテストは作業の合否を決めます。誰かが疑いもなく「AI が作った」と言えるなら、失敗です。 4. デザイン言語を `DESIGN.md` に固定し、すべての画面をそれに準拠させてください。変化はアイデンティティの範囲内で、アイデンティティの間では決して行いません。以降の機能やセッションでは、まず `DESIGN.md` を読み直してください。 5. ユーザーからインスピレーションとなるリンクが提示された場合は、`browse` スキルで必ずアクセスして要素を統合してください。単一のリファレンスを模倣したり、そのスロップを引き継いだりしてはいけません。 6. 引き渡し前にデザイン・プレフライトゲートを実施してください。正直にチェックを付けられない項目が 1 つでもあれば、完了ではありません。 7. 私たちを際立たせる厳密さを保ってください。状態の網羅、フローとエッジケース、アクセシビリティを省略してはいけません。

frontend-design-ui-ux

Inputs

• $request：デザイン対象の機能、ページ、コンポーネント、または UX の課題。任意でインスピレーション URL も指定できます。

Goal

独自性があり、一貫性を備え、実装可能なデザインパッケージを作成します。委任されたエンジニアリングエージェントがそのまま実装できる仕様です。すべての成果物は .ulpi/design/ 以下に作成します。

• .ulpi/design/DESIGN.md：固定されたデザイン言語（アイデンティティ、パレット、書体、スケール、シグネチャー、トーン、採用するデザインシステム）。プロジェクト全体に適用され、毎回のセッションで最初に読み直します。
• .ulpi/design/<feature>.md：機能ごとの仕様。ユーザーフローと状態、コンポーネント仕様、構築の引き渡し情報（対象エージェントと受け入れ基準）を記載します。DESIGN.md に準拠させます。

Step 0: 発見と入力情報

対象ユーザー · プロダクトの目標 · デバイスと利用状況 · 既存のデザインシステムまたはブランド上の制約 · アクセシビリティへの期待を確認します。一度だけ、次の質問をしてください。「参考にしたいサイトやデザインはありますか？ URL を 1〜4 件貼り付けてください。」

課題の情報が不足している場合は質問してください。ただし、要点を絞った質問は 2 つまでとし、長々と質問攻めにしてはいけません。成功基準：ユーザーとプロダクトの観点から課題が定義され、インスピレーションのリンクがあれば収集されていること。

Step 1: インスピレーションの取り込み（任意）

ユーザーからリンクが提示された場合は、browse スキルで各リンクに必ずアクセスし、デザインの DNA（書体、色、形、間隔、レイアウト）を抽出して、サイトごとに 1 行の DNA メモにまとめます。それらを統合し、いずれか 1 つを模倣してはいけません。 browse が利用できない場合、またはリンクにアクセスできない場合は、ユーザーに雰囲気を説明してもらい、それをもとに進めます。

references/inspiration-intake.md を読み込みます。成功基準：各リファレンスから再利用可能な DNA を抽出し、取り入れる要素と除外する要素を明確にすること。あるいは、問題なくスキップすること。

Step 2: デザインを読み解き、美的な方向性を定める

定型的な見た目を決して世に出さないデザインリードの視点で取り組みます。トークンを決める前に、デフォルトの美的感覚に頼る反射を断ち切ります。

• 1 行の Design Read（印象と狙い）を提示します。
• references/anti-slop.md の選択肢から、名前の付いた美的方向性を1 つ決め、依頼の内容（およびインスピレーションの DNA があればそれも）に基づいて理由を説明します。
• 反実仮想のデフォルトテストを実施します。この見た目は、同様の依頼なら何にでも答えとして使えますか？ そうであれば、変更してください。
• 必要に応じて、テイストの調整値（design_variance／motion_intensity／visual_density、各 1〜10）を設定し、方向性に合った複雑さにします（マキシマリストなら凝った表現、ミニマルなら抑制、精度、余白）。

方向性の選択肢、パターンの用語集、明示的に禁止する項目を確認するため、references/anti-slop.md を読み込みます。 成功基準：依頼に固有の方向性が明確に定められ、汎用的なデフォルトではないこと。

ステップ 3：デザイン言語を導き出して固定する → .ulpi/design/DESIGN.md を作成する

レジスター（ブランド向けかプロダクト向けか）を決定し、product の場合は、土台とするデザインシステムを選びます（references/design-system-routing.md を参照）。次に、アイデンティティを導き出して固定します。パレット（OKLCH、色味を帯びたニュートラルカラー、60-30-10、WCAG 準拠を確認）、コントラスト軸で組み合わせたタイポグラフィの役割、単一の余白・角丸・モーションのスケール、シグネチャー、そしてトーンを定めます。これを .ulpi/design/DESIGN.md に記述します。これは、すべての画面が準拠する一貫性の唯一の基準です。

references/design-language-lock.md（成果物と固定ルール）、references/design-tokens-template.md（導出方法）、references/design-system-routing.md（概要からシステムへのマップ）を読み込みます。成功基準：.ulpi/design/DESIGN.md が完全に作成され、内容が固定されていること。汎用的なデフォルトのアイデンティティになっていないこと。

ステップ 4：フローと状態をモデル化する

主要なユーザージャーニー、分岐や判断、状態モデル全体（読み込み中、空、部分表示、成功、エラー）に加え、エッジケース（更新、セッション期限切れ、戻る、オフライン）を文書化します。 .ulpi/design/<feature>.md に記述します。references/user-flow-template.md を使用します。成功基準：ハッピーパスだけでなく、各状態での動作が網羅されていること。

ステップ 5：コンポーネントとインタラクションのルールを仕様化する

各コンポーネントについて、目的、バリエーション、props／データ、状態、インタラクションのフィードバック、レスポンシブ動作、アクセシビリティ（ARIA、キーボード、スクリーンリーダー、フォーカス）を定義します。すべての視覚的な値を .ulpi/design/DESIGN.md に準拠させ、同じ .ulpi/design/<feature>.md に追記します。references/component-spec-template.md を使用します。成功基準：担当エンジニアが推測せずに実装でき、固定されたアイデンティティから逸脱しないこと。

ステップ 6：デザインの事前チェックを実施する

references/design-preflight.md を最初から最後まで実施します。アイデンティティの固定、粗雑さの排除、状態の網羅性、アクセシビリティ、レイアウトの完成度、認知負荷、採点式の自己批評を確認します。項目のいくつかは機械的にカウントできます。不合格の項目、または評価が 2 以下の軸があれば修正し、変更した内容と理由を 1 行で記述してから（修正して理由を説明）、再実施します。成功基準：すべての項目にチェックが入り、自己批評の軸に 2 以下がないこと。

ステップ 7：実装を引き継ぐ（実装を委任する）

.ulpi/design/<feature>.md の末尾にある委任用ブリーフを仕上げます。対象となるエンジニアリングエージェント、選定した design_system（とそのセットアップに関する注記）、受け入れ基準を記載し、次の指示を含めます。 「この仕様をそのまま実装してください。固定済みのトークンでデザインシステムをテーマ設定し、コンポーネントを再設計したり、再実装したりしないでください。」 実装はエージェントに委任します。このスキルでは UI を実装しません。

エージェントの選定

基準	対象エージェント
サーバーサイドレンダリング／SEO／App Router／Server Actions	nextjs-senior-engineer
純粋な SPA／クライアントのみ／CLI の Web UI／Electron-Tauri	react-vite-tailwind-engineer
SSR を使わない静的サイト	どちらでも可（ユーザーに確認）
不明	ユーザーに確認

成功基準：委任されたエージェントが .ulpi/design/DESIGN.md と .ulpi/design/<feature>.md を参照し、再設計せずにそのまま実装できること。

ガードレール

• このスキルから本番用 UI コードを実装しないでください。仕様を作成し、引き継いでください。
• 汎用的なデフォルトのアイデンティティを提供しないでください。ブリーフに応じてパレットとタイポグラフィを導き出し、粗雑さのテストで成果物を評価します。
• 画面が DESIGN.md から逸脱しないようにしてください。アイデンティティの範囲内で変化させ、画面間で変化させないでください。
• インスピレーションの参考資料をそのまま複製せず、そこにある粗雑さを引き継がないでください。
• アクセシビリティ、状態の網羅性、レスポンシブ動作を省略しないでください。これらは私たちの強みです。
• 具体的な成果物が必要な場合に、曖昧なデザイン説明を作成しないでください。
• browse や画像ツールが使えなくても作業を止めないでください。適切に対応し、ブリーフに基づいて続行してください。

リファレンスを読み込むタイミング

• references/inspiration-intake.md — browse でリファレンスリンクを確認し、エッセンスを抽出します（ステップ 1）。
• references/anti-slop.md — 方向性メニュー、名前付きの AI スロップ禁止事項、スロップテスト（ステップ 2、3、6）。
• references/design-language-lock.md — DESIGN.md アーティファクトと一貫性を保つためのロックルール（ステップ 3）。
• references/design-system-routing.md — ブリーフからデザインシステムへのマップと誠実さのルール（ステップ 3、プロダクトの表現）。
• references/design-tokens-template.md — ブリーフごとの色・タイポグラフィの導出方法とニュートラルスケール（ステップ 3）。
• references/user-flow-template.md — ユーザージャーニーと受け入れフロー（ステップ 4）。
• references/component-spec-template.md — コンポーネントのブリーフとインターフェース契約（ステップ 5）。
• references/design-preflight.md — 引き継ぎ前の品質・一貫性チェック（ステップ 6）。

出力要件

.ulpi/design/ 配下に作成し、次の内容を報告します。

1. デザインの読み取り内容と確定した美的方向性（あればインスピレーションのエッセンスも）
2. .ulpi/design/DESIGN.md — ロックされたデザイン言語（表現、デザインシステム、パレット、タイポグラフィ、スケール、特徴、トーン）
3. .ulpi/design/<feature>.md — フローと状態
4. — コンポーネント仕様（同じファイル内）
5. プレフライト結果（すべての項目にチェックが入り、批評軸がすべて 2 を超えていること）
6. ビルドの引き継ぎ — 対象エージェント、デザインシステム、受け入れ基準（「これを正確に実装し、再設計しないこと」）