ux-design-from-scratch

Design From Scratch (UX Creation Orchestrator) スキル

このスキルの動作 (最初にお読みください)

これはゼロから新しいデザインを構築するためのフロントドアであり、 ux-design-review の生成側の双子です。design-review が検証の方向 (生成 → 監査) をオーケストレーションするのに対し、このスキルは構成の方向 (生成 → 生成) をオーケストレーションします。つまり、スコープのはしご — 基盤 → コンポーネント → 画面 → フロー — を順序づけ、作業に応じて各下位スコープの スキルを引き込み、その結果を検証のために design-review に引き渡します。

これは docs/orchestration-policy.md の構成オーケストレーションセクションの 実行可能な形です。その役割は、2つの失敗を避けることに尽きます。土台となるシステムを 持たずに単一の画面を構築してしまうこと、そして製品が少ししか必要としていないのに すべて (すべての基盤、すべての12個のコンポーネント) を過剰に構築してしまうことです。

このスキルを使うべきでない場合: ユーザーが特定の成果物を1つだけ求めた場合 (「料金ページをデザインして」「日付ピッカーを構築して」)、そのスキルを直接 トリガーさせてください。このオーケストレーターは、複数の成果物をゼロから構築する 場合のためのものです。明示的なスコープがオーケストレーションより優先されます。

---

Step 0 — コンテキストプロファイルを確立する (一度だけ)

ここで最も重要なフィールドは、レビューのケースの逆です:

• 使用中のデザインシステムはあるか? 真にゼロからの構築の場合、答えは通常 いいえです → 基盤スキルがスコープに入り、最初に来ます。ユーザーが すでにトークンやスタイルガイドを持っている場合は、基盤をスキップし、 コンポーネント/画面から始めて、そのシステムを継承します (抑制マトリクスを 作成に適用したもの)。
• 何を構築するのか — そのシステムを伴う単一の画面か、小さなフローか、 それとも製品サーフェス全体か? これにより、はしごをどこまで下るか、そして いくつの画面/コンポーネントを構成するかが決まります。
• プラットフォーム — モバイルか Web か (レイアウト、タッチターゲット、 ナビゲーションパターンが変わります)。
• ブランド / オーディエンス / 業界 — 基盤および画面スキル内のゲートされた 決定 (色の感情、トーン、セキュリティ態勢) を左右します。

進める前提を述べたうえで、順番に構築していきます。

---

Step 1 — はしごを構成し、各段でゲートする

はしごを上から下へたどります。各段で、子スキルを core / offer / skip に 分類します (ポリシーの構成モデルを参照) — ある段のすべてのスキルを デフォルトで適用しないでください。

子スキルは、インストール可能なスキルの name で名前が付けられています。 インストールされているものだけを構成してください。名前付きのスキルが存在しない 場合は、その段の意図を一般的なベストプラクティスでインラインに適用し、 構築をブロックするのではなく、そのギャップを記録してください。

Rung 1 — 基盤 (デザインシステムがない場合のみ)

まずシステムを確立し、その上のすべてが一貫するようにします:

• Core: ux-color、ux-typography、 ux-layout-spacing-grids — 画面が意味を持つ前に、製品にはパレット、タイプスケール、 スペーシングシステムが必要です。
• Offer: ux-iconography (製品がアイコンを多用する場合)。
• 完全にスキップ デザインシステムがすでに存在する場合は — そのトークンを 継承します。

各基盤スキルは、依然として自身のコンテキスト依存の決定をゲートします (ダークモード、ブランドの彩度などを自動で選ばないでください)。

Rung 2 — コンポーネント (画面が必要とするもののみ)

コンポーネントスキルをオンデマンドで、構築中の画面に駆動されて引き込みます — すべてを引き込むのではありません:

• フォームを含む画面 → ux-inputs-and-forms、ux-buttons、 ux-selection-controls。
• データ画面 → ux-tables、ux-search。
• オーバーレイ/フィードバック → ux-modals-and-dialogs、 ux-notifications-and-toasts、ux-loaders-and-progress。
• ナビゲーション → ux-navigation、ux-menus。

「念のため」にすべてのコンポーネントスキルを構築することは、バンドワゴンの失敗です — 要求された画面が実際に含むものだけを構成してください。

ラング 3 — 画面 (ユーザーが求めた成果物)

該当するスキル (ux-login-signup、 ux-pricing、ux-dashboard、ux-settings、ux-empty-states、 ux-landing-page、ux-activity-feed、ux-contact-support) を使って、要求された画面を構築します。各 画面スキルは、自身の文脈依存のレバーをゲートし、上記の基盤/コンポーネントを再決定するのではなく 再利用します。

ラング 4 — フロー (ビルドがジャーニーとして複数の画面にまたがる場合)

製品にジャーニーが必要な場合は、フロースキル (ux-onboarding、 ux-checkout-payment、ux-error-recovery、ux-offboarding) を組み合わせます。これにより、 画面が一貫したパスに順序付けられます。

一貫性のルール: 下位のラングで行われた決定は上位へ伝播します。基盤で一度行われた色/間隔の決定 は、すべてのコンポーネントと画面で再利用されます — 画面ごとに再議論しないでください。 これがボトムアップで構築する意味そのものです。

---

ステップ 2 — design-review による検証

成果物が存在する場合は、それらを ux-design-review (インストールされている場合) に渡します。これは 監査ポリシーを適用します (ティア A は自動実行、ティア B は提案、そして基盤をたった今 構築 したばかりなので、 ビジュアル基盤の監査は ここでは抑制されず対象となります — デザインシステムは真新しいもので 確認する価値があります)。検出された問題は、主要タスクに向けて解決してください。ux-design-review がインストールされていない場合は、存在する監査レンズを直接実行するか、ポリシーに照らして 自己レビューしてください。

---

よくある do/don't パターン

❌ しない	✅ する
色/タイポグラフィ/間隔のシステムなしで画面に直行する	まず基盤を確立する (既存のデザインシステムがない場合)
「念のため」12 個のコンポーネントスキルをすべて構築する	要求された画面に含まれるコンポーネントのみを組み合わせる
すべての画面内で色/間隔を再決定する	基盤で一度決定し、上位へ再利用する
単一の名前付き画面/コンポーネントに対してこのオーケストレーターを実行する	そのスキルを直接トリガーさせる (明示的なスコープが優先)
「画面は問題なく見える」という理由で基盤をスキップする	土台となるシステムのない画面はデザインではない — モックアップです
生成後に完了と宣言する	検証のために design-review に渡す

---

ポリシーとの関係

このスキルは、docs/orchestration-policy.md の構成オーケストレーションセクションを 実行可能な形にしたものです。両者が乖離した場合は、ポリシーが優先されます。このスキルをポリシーに合わせて更新してください。その検証の相方は ux-design-review です。

ソースレッスン (Uxcel)

これはオーケストレーターです — その実質は、組み合わせるスキルの中にあります。ルーティング先の 各基盤、コンポーネント、画面、フロースキル (例: ux-color、ux-inputs-and-forms、ux-pricing、 ux-onboarding) のソースレッスンを参照してください。