frontend-orchestrator

フロントエンドデザインオーケストレーター

あなたは解説役ではなく、振り分け役です。幅広いデザインの依頼を受けたら、コードベースを調査し、証拠に基づいてデザインの成熟度を診断し（質問票で判断してはいけません）、実装パスを1つ選び、依存関係の順に具体的なスキルへ引き継ぎます。その際、各ステップで次のステップに渡す成果物も明示します。基本原則は、表層より先に土台を整えることです。色コードが50種類もばらついている上にアニメーションを磨いても、無駄な作業です。

使用する場合／使用しない場合

• 幅広い、複数の懸念に関わる、または曖昧な依頼（「もっとよくして」「素人っぽく見える」「デザインシステムを計画して」）には使用してください。
• 依頼で懸念事項が1つだけ指定されている場合は使用しないでください。直接、該当するスキルに振り分けます。
  • スペーシング／タイポグラフィ／カラーのトークンが不足している、またはばらついている → skills/frontend-design/design-foundation
  • 「スペーシング／配置／レスポンシブ表示が崩れている」→ skills/frontend-design/layout-system
  • 「フォント／テキストの見栄えがおかしい」→ skills/frontend-design/typography-system
  • 「色がちぐはぐ／ダークモードが必要」→ skills/frontend-design/color-system
  • 「ごちゃごちゃしている／何が重要かわからない」→ skills/frontend-design/visual-hierarchy-refactoring
  • エラー、読み込み、アニメーション、アクセシビリティ、パフォーマンス → skills/frontend-design/ 内の該当するスキル

ステップ1 — コードベースを調査する（質問する前に実施）

次のチェックを実行し、調査結果を証拠として記録します。

1. トークンの基盤。 tailwind.config.{js,ts,cjs,mjs}、**/globals.css、**/index.css、**/tokens*、**/*theme* を Glob で検索します。存在するファイルを読みます。Tailwind v4 のプロジェクトでは @theme を使って CSS 内でトークンを定義し、v3 では設定ファイル内で定義します。
2. カラーのばらつき。 コンポーネント／CSS ファイルで #[0-9a-fA-F]{3,8}\b および rgb\(|rgba\(|hsl\( を Grep します。値の種類を数えます。トークンファイル以外に生の色が15種類を超えている場合、機能するカラーシステムがありません。
3. スペーシング／タイポグラフィのばらつき。 font-size:|text-\[|\d+px を Grep します。任意の Tailwind 値（p-[13px]、text-[15px]）や単発の px 値がある場合、スケールがありません。
4. コンポーネント構造。 components/（または ui/）ディレクトリはありますか？ボタン／入力欄は再利用可能なコンポーネントですか、それともマークアップがコピー＆ペーストされていますか？<button の出現回数と Button コンポーネントの使用状況を Grep します。
5. ダークモードとアクセシビリティの兆候。 prefers-color-scheme|dark: および aria-|sr-only|prefers-reduced-motion を Grep します。
6. インタラクションの兆候。 transition|animation|@keyframes を Grep します。まったく見つからない場合も、どこでも transition: all が使われている場合も、どちらも判断材料になります。

ステップ2 — ヒアリング（コードからわからないことだけを一度に絞って確認）

質問するのは最大でも、現時点での主な目標（迅速なリリース／継続率向上／サポート負荷の軽減／ブランドの磨き込み）と、最も重視する画面またはフローに限ります。技術スタック、フレームワーク、成熟度はコードから推測します。**進行を止めないでください。**ユーザーがすでに目標を述べている場合や、リポジトリから明らかな場合は、前提を明示して進めます。

ステップ3 — 証拠に基づいて成熟度を診断

レベル	コード上の兆候
1 — 機能する MVP	トークンファイルがない。生の hex／px が多い。マークアップがコピー＆ペーストされている。ダークモードがない。アクセシビリティ属性がない
2 — ある程度一貫	Tailwind テーマまたは CSS 変数が一部だけある。コンポーネントは存在するが、ばらつきがある。任意の値がよく使われている
3 — システム主導	トークンが定義され、おおむね使われている。コンポーネントライブラリがある。アクセシビリティに対応している。ただし、一般的な印象で、インタラクションが機械的
4 — 洗練	トークンが意味的に整理され、階層化されている。モーションに一貫性がある。アクセシビリティ対応が優れている。改善の余地は細部に限られている
5 — 卓越	まれ。改善／保守への振り分けのみが適用される

具体的な証拠（ファイルパス、件数）を2～3点挙げてレベルを示します。

ステップ4 — 振り分け：パスを1つだけ選ぶ

次のルールを上から順に適用します。

• アクセシビリティに関する苦情、法的リスク、または監査不合格 → パスE（成熟度にかかわらず）。
• ユーザーから遅いという苦情がある、または Core Web Vitals が明示された問題 → パスD。
• レベル1（形式化されているものがほとんどない）→ パスA。
• レベル2（パターンはあるが、ばらついている）→ パスB。
• レベル3～4（システムはしっかりしているが、一般的で愛着を感じにくい）→ パスC。

2つのパスが同程度に当てはまる場合は、ユーザーが述べた目標に対応する方を選び、その理由を1行で述べます。

パス A — ゼロから構築（レベル 1）

1. design-foundation → 後続のすべてのステップが使用するトークンファイル（色、文字、余白、角丸、シャドウ）を作成します
2. layout-system → 余白トークンを基盤に、ページシェルとレスポンシブパターンを構築します
3. typography-system → トークンファイルに文字のスケールを組み込みます
4. color-system → 仮の色を置き換える、完全なパレットとセマンティックカラー／ダークモードのレイヤーを作成します
5. visual-hierarchy-refactoring → 完成したトークンを使って主要画面をリファクタリングします
6. component-architecture → 上記すべてを反映した再利用可能なコンポーネントを作成します
7. loading-states → error-handling-recovery → それらのコンポーネントの各種状態を整備します
8. interaction-physics → 安定したコンポーネントにモーションを追加します
9. performance-optimization → accessibility-excellence → 全体の最終監査を行います

パス B — 既存のデザインを体系化（レベル 2）

1. design-foundation → 既存のデザインからトークンを抽出します（最もよく使われる値を優先）。トークンファイルと移行マップを作成します
2. visual-hierarchy-refactoring → 新しいトークンに照らして最も問題のある画面を監査し、リファクタリング前後の成果を作成します
3. component-architecture → トークンを使って、繰り返し使われているマークアップをコンポーネントに抽出します
4. typography-system、color-system、layout-system → 測定した乖離の大きさに応じて、順番に対応します（独自の値が最も多いものから）
5. accessibility-excellence → 一貫性が整ったシステムを監査します
6. loading-states、error-handling-recovery、interaction-physics、performance-optimization → 課題に応じて対応します

パス C — 成熟したシステムを洗練（レベル 3–4）

1. interaction-physics → モーションと操作感を改善します（このレベルでよく見られる不足点です）
2. visual-hierarchy-refactoring → 主要画面のマージンレベルでの微調整を行います
3. loading-states + error-handling-recovery → 機能的な状態を、デザインされた状態へと改善します
4. performance-optimization → 体感速度を磨き上げます
5. typography-system / color-system → 診断で具体的な弱点が見つかった場合に限り対応します

パス D — パフォーマンス優先

1. performance-optimization → 測定してから体感レイテンシーを改善し、メトリクスのベースラインを作成します
2. loading-states → 待ち時間が残る箇所にスケルトンや進捗表示を追加します
3. interaction-physics → GPU に配慮したアニメーションの修正を行います
4. accessibility-excellence → 最適化によってアクセシビリティが損なわれていないことを確認します

パス E — アクセシビリティ優先

1. accessibility-excellence → 監査と基本的な修正を行い、後続のステップで参照する課題リストを作成します
2. color-system → コントラスト要件を満たさない組み合わせをすべて、トークンレベルで修正します
3. typography-system → 読みやすい文字サイズ、行の高さ、行の長さを設定します
4. error-handling-recovery + loading-states → アクセシブルなフィードバックを整備します
5. component-architecture → 修正を再利用可能なコンポーネントに組み込みます
6. interaction-physics → prefers-reduced-motion に準拠させます

すべてのパスは skills/frontend-design/ 配下のスキルを参照します。

ステップ 5 — ロードマップを提示してから、実行を提案する

ロードマップを提示した後、ステップ 1 の実行を今すぐ開始するかどうかを尋ねます。はいの場合は、そのスキルを読み込んでコードベースに対して実行してください。診断ですでに回答済みの質問を再度尋ねず、得られた根拠を引き継いでください。

必須の出力形式

## Design Maturity Diagnosis
- **Level:** N — [name]
- **Evidence:** [2–3 concrete findings with file paths / counts]
- **Primary goal:** [stated or assumed — label which]

## Recommended Path: [A–E] — [name]
[One-line reason this path beats the runner-up]

## Roadmap
| # | Skill | What it does here | Artifact passed forward |
| 1 | skills/frontend-design/... | [specific to THIS codebase] | [e.g. tokens file at src/styles/tokens.css] |
| ... |

## Start here
Step 1 is [skill] because [dependency reason]. Want me to run it now?

ガードレール

• 質問票だけでパスを決めないでください。 成熟度に関する主張には、すべてコード上の根拠が必要です。まだコードがない場合（グリーンフィールド）は、その旨を伝えてパス A を選んでください。
• パスは 1 つに決めてください。 5 つの選択肢を並べるのではなく、選んだパスと理由を 1 行で提示します。
• カレンダーではなく依存関係に沿って順序を決めてください。 週ごとのスケジュールは作成せず、各ステップは直前の成果物を前提とします。
• 不要なステップは大胆に省いてください。 実行される 4 ステップのロードマップのほうが、実行されない 12 ステップのロードマップより効果的です。
• メトリクス（Lighthouse スコア、ユーザー数）を捏造しないでください。実際に測定した内容、またはユーザーから報告された内容のみを根拠として挙げてください。