tool-design-style-selector

デザインスタイルセレクター

プロジェクトをスキャンし、目的を特定して、最適なデザインシステムのスタイルを提案・適用します。

スタイルプリセット

このスキルでは、次のいずれかを選択できます。

1. 既存のスタイルを維持し、design-system.md に抽出する（プロジェクトがすでに「成熟した」見た目の場合に推奨）、または
2. 30 種類のプリセットスタイルのいずれかを適用し、design-system.md を生成する。

スタイルファイルは styles/ にあり、以下のファイルに一覧があります。

• styles-index.md（ID → ファイル名 → テーマ）

プリセットの簡単な例：

• 05-saas（B2B ツール、ダッシュボード）
• 08-swiss-minimalist（明快な階層構造、企業向け）
• 13-neo-brutalism（大胆、インディー／クリエイティブ）
• 19-minimal-dark（集中モード、開発ツール）

実行フロー

ステップ 1：プロジェクトをスキャンする

Scan the following files to identify project intent:
- README.md / README
- package.json / pyproject.toml / Cargo.toml
- Existing Claude.md / agent.md / AGENTS.md
- src/ or app/ directory structure
- Existing style files (tailwind.config, globals.css)
- Brand assets (logo, favicon)

ステップ 2：目的を分析する

以下の情報を抽出します。

• プロジェクトの種類：SaaS／企業サイト／EC サイト／ブログ／ツール／ゲーム／...
• 対象ユーザー：開発者／企業／消費者／子ども／専門家／...
• ブランドのトーン：プロフェッショナル／遊び心のある／高級感／ミニマル／大胆／...
• 技術スタック：React／Vue／Next.js／静的サイト／...
• 既存のデザイン制約：現在の色／フォント／コンポーネントライブラリ

ステップ 2.5：既存スタイルの判定（既存プロジェクトでは、まず「スタイルを維持」するかどうかを判断する）

目的：「すでに見栄えが良い／すでにブランドが確立している」プロジェクトにスタイルの全面変更を無理に行い、不必要な UI の作り直しや認知的コストを招くことを防ぎます。

リポジトリにすでに UI がある場合は、まず「スタイルの成熟度」を簡単に評価し、根拠を明記します（主観だけで判断しないでください）。

成熟したスタイルの兆候（複数の基準を満たせば十分です）：

• 明確なデザイントークンがある：tailwind.config.* に色／フォント／角丸／影／間隔の設定がかなり揃っている、または :root の CSS 変数がシステムを構成している
• コンポーネントライブラリ／コンポーネントのスタイルに一貫性がある（ボタン／入力欄／カードなどのセマンティックコンポーネントが広く再利用されている）
• ページ間でレイアウトと間隔に基本的な一貫性がある（ハードコードされた色の値／ピクセル値／インラインスタイルはほとんど見られない）
• ブランドアセット（ロゴ、ファビコン、ブランドカラー）が UI 全体に一貫して反映されている

未成熟／一貫性のないスタイルの兆候：

• 同じ種類のコンポーネントが複数のスタイルで使われている（ボタン／フォーム／カードに一貫性がない）
• 複数の UI ライブラリ／複数のトークンセットが混在している（例：複数の Tailwind カラースキームと複数の globals.css）
• 散在する 16 進数値／インラインスタイル／ランダムな間隔が多い

判定結果（必須）：

• 「スタイルが成熟している」と判断した場合：既存のスタイルを維持して design-system.md に抽出することをデフォルトで推奨します（プリセットへの切り替えを強制しないでください）
• 「成熟していない」と判断した場合：ステップ 3 に進み、プリセットから提案して置き換えます

ユーザーに確認する質問は、方針を選ぶための 1 つだけにします（複数選択肢）：

現在のプロジェクトのスタイルをスキャンしたところ、[かなり成熟している／あまり統一されていない] と判断しました。どの方針にしますか？

1. 既存のスタイルを維持する：現在の UI を逆抽出して design-system.md にまとめます（ドキュメント化＋軽い統一のみで、大幅なスタイル変更は行いません）
2. このリポジトリのプリセットを使う：30 種類のスタイルから 1 つを選び、統一されたスタイルに置き換えます（より大幅な UI の変更が必要です）
3. ハイブリッド：大まかな方向性は維持しつつ、デザイントークン／コンポーネント仕様を使って一貫性のない箇所を統一します（中程度の変更）

1. が選択された場合：ステップ 3 で「30 種類のスタイルを提案」する必要はありません。代わりに「抽出して design-system.md を生成」します。

ステップ 3：スタイルを提案する

分析結果に基づき、最も適合するスタイルを上位 3 件提案します。

Recommendation #1: [Style Name] ⭐ Best Match
- Match Score: 95%
- Reason: ...
- Fit Points: ...

Recommendation #2: [Style Name]
- Match Score: 85%
- Reason: ...

Recommendation #3: [Style Name]
- Match Score: 75%
- Reason: ...

ステップ 3.5（インストール済みの場合はデフォルト）：tool-ui-ux-pro-max でトークンを充実させる

tool-ui-ux-pro-max がインストールされている場合は、単一のプリセット説明文に頼るのではなく、デフォルトで実行して design-system.md の具体性を高めます（カラーパレット＋タイポグラフィ＋UX 制約）。仕様を最小限にするようユーザーから明示的に求められた場合のみ省略し、その理由を記録してください。

推奨する検索項目（カテゴリごとに 1～3 件を選び、結果をまとめて design-system.md に反映します）。

# Typography pairing (heading + body + CSS import)
python3 ~/.claude/skills/tool-ui-ux-pro-max/scripts/search.py "<brand tone keywords>" --domain typography

# Color palette (primary/secondary/CTA/background/text/border)
python3 ~/.claude/skills/tool-ui-ux-pro-max/scripts/search.py "<product type keywords>" --domain color

# UX / accessibility guardrails (avoid common “looks good but feels broken” issues)
python3 ~/.claude/skills/tool-ui-ux-pro-max/scripts/search.py "accessibility" --domain ux
python3 ~/.claude/skills/tool-ui-ux-pro-max/scripts/search.py "animation" --domain ux

# Stack-specific implementation constraints (pick the actual project stack)
python3 ~/.claude/skills/tool-ui-ux-pro-max/scripts/search.py "layout responsive" --stack nextjs

ステップ 4：ユーザーによる確認

• 推奨する理由を提示します
• ユーザーが選択するか、追加の候補を求められるようにします
• 確認後、デプロイに進みます

ステップ 5：デザインシステムをデプロイする

1. Copy selected style file to project
2. Rename to design-system.md
3. Placement location:
   - Primary: Project root directory
   - Alternative: docs/ or .cursor/ or .claude/
4. If Claude.md / agent.md exists:
   - Add reference at the top of that file
   - Explain that design-system.md is the unified design constraint

ステップ 2.5 で「既存のスタイルを維持する」を選択した場合、ここでの「デプロイ」とはプリセットをコピーすることではなく、コードやスタイルから抽出したトークン、タイポグラフィのルール、コンポーネントのスタイル制約を design-system.md に書き込むことです（ルートにも配置します）。

ステップ 6：design-system.md に従って UI/UX を実装する（デフォルトで実行）

このステップの目標は、ドキュメントを生成して終わりにするのではなく、design-system.md を実際に「UI に反映」させることです。

実行要件：

• まず、実行可能な UI/UX 変換計画を作成します（対象となるページ／コンポーネント、変更範囲、受け入れ基準、ロールバック方法を明確に指定します）。
• 次に、計画に従って実装します（大規模なビジュアル／レイアウト／操作の変更を伴う場合は、確認ポイントを設ける必要があります）。

推奨される実装順序（スタイルを最も適切に統一できる箇所から開始します）：

1. デザイントークン／グローバルスタイルのエントリーポイント：フォント、色、間隔、角丸、シャドウ、基本的なタイポグラフィ（優先的に一か所に集約し、分散を避けます）。
2. コンポーネントレイヤー：ボタン、入力欄、カード、ダイアログなどの基本コンポーネントのスタイルを統一します（後ですべてのページで再利用できるようにします）。
3. ページレイヤー：全体の一貫性を確保するため、「第一印象を左右するページ」と「主要なフローページ」を優先して変更します。

注：

• ユーザーが「UI は変更せず、ドキュメントだけを作成したい」と明示した場合は、このステップをスキップし、その理由を記録します（例：実行の notes/summary に記載します）。

出力形式

スキャンレポート

📁 Project Scan Complete

Project Name: [name]
Project Type: [type]
Tech Stack: [stack]
Target Users: [audience]
Brand Tone: [tone]

Existing Design Assets:
- ✅ tailwind.config.js (has color config)
- ❌ No design system documentation
- ⚠️ Claude.md exists (needs integration)

デプロイの確認

✅ Design System Deployed

File: /design-system.md
Style: [selected style]

Completed:
1. Created design-system.md
2. Added reference in Claude.md

Next Steps (execute by default):
- Generate UI/UX transformation plan based on design-system.md (clarify page/component scope and acceptance criteria)
- After user confirmation, redo UI/UX according to plan to implement design specs (avoid "document exists but UI unchanged")

統合ルール

Claude.md / agent.md が存在する場合

ファイルの先頭に追加します：

## Design System

This project uses a unified design system, see [design-system.md](./design-system.md).

All UI development must follow the design-system.md for:
- Color specifications
- Typography rules
- Component styles
- Spacing system

既存の設定ファイルがない場合

ルートディレクトリに design-system.md を直接作成します。

スタイルファイルの場所

スタイルプロンプトファイルはすべて styles/ にあります。

ファイル名の形式：[id]-[name].md（例：01-monochrome.md）

注意事項

1. 既存のファイルを上書きしない：design-system.md がすでに存在する場合は、置き換えるかどうかを確認します
2. ユーザーの選択を尊重する：推奨は必須ではありません。ユーザーは任意のスタイルを選択できます
3. 統合方法を説明する：デプロイ後の使い方を明確に説明します
4. 技術スタックに合わせる：プロジェクトの技術スタックに応じて、具体的な実装提案を調整します