design-lab

Design Lab スキル

このスキルは、ヒアリング、バリエーションの生成、フィードバックの収集、改良、プレビュー、最終決定を行う、完全なデザイン検討ワークフローを実装します。

重要：クリーンアップの動作

プロセス終了時には、必ずすべての一時ファイルを削除してください。以下の場合も対象です。

• ユーザーが最終デザインを確定する → クリーンアップ後、プランを生成
• ユーザーが中止する／キャンセルする → 直ちにクリーンアップし、プランは生成しない

.claude-design/ や __design_lab ルートを決して残さないでください。 ユーザーがどの時点でも「キャンセル」「中止」「停止」「やっぱりやめる」と言った場合は、確認してからすべての一時生成物を削除してください。

---

フェーズ 0：事前検出

ヒアリングを始める前に、以下を自動的に検出します。

パッケージマネージャー

プロジェクトのルートにあるロックファイルを確認します。

• pnpm-lock.yaml → pnpm を使用
• yarn.lock → yarn を使用
• package-lock.json → npm を使用
• bun.lockb → bun を使用

フレームワークの検出

設定ファイルを確認します。

• next.config.js、next.config.mjs、または next.config.ts → Next.js
  • app/ ディレクトリを確認 → App Router
  • pages/ ディレクトリを確認 → Pages Router
• vite.config.js または vite.config.ts → Vite
• remix.config.js → Remix
• nuxt.config.js または nuxt.config.ts → Nuxt
• astro.config.mjs → Astro

スタイリングシステムの検出

package.json の依存関係と設定ファイルを確認します。

• tailwind.config.js または tailwind.config.ts → Tailwind CSS
• 依存関係に @mui/material がある → Material UI
• 依存関係に @chakra-ui/react がある → Chakra UI
• 依存関係に antd がある → Ant Design
• 依存関係に styled-components がある → styled-components
• 依存関係に @emotion/react がある → Emotion
• .css または .module.css ファイルがある → CSS Modules

デザインメモリーの確認

既存のデザインメモリーファイルを探します。

• docs/design-memory.md
• DESIGN_MEMORY.md
• .claude-design/design-memory.md

見つかった場合は、その内容を読み、デフォルト値の事前入力に活用して、重複する質問を省略します。

ビジュアルスタイルの推定（重要）

汎用または事前定義済みのスタイルは使わないでください。プロジェクトからビジュアル言語を抽出します。

Tailwind が検出された場合、tailwind.config.js または tailwind.config.ts を読みます。

// Extract and use:
theme.colors      // Color palette
theme.spacing     // Spacing scale
theme.borderRadius // Radius values
theme.fontFamily  // Typography
theme.boxShadow   // Elevation system

CSS 変数がある場合、globals.css、variables.css、または :root の定義を読みます。

:root {
  --color-*     /* Color tokens */
  --spacing-*   /* Spacing tokens */
  --font-*      /* Typography tokens */
  --radius-*    /* Border radius tokens */
}

UI ライブラリが検出された場合（MUI、Chakra、Ant）は、テーマ設定を読みます。

• MUI：theme.ts または createTheme() の呼び出し
• Chakra：theme/index.ts または extendTheme() の呼び出し
• Ant：ConfigProvider の theme プロパティ

既存のコンポーネントを必ずスキャンして、パターンを把握します。

• 既存のボタンを 2～3 個見つける → スタイリングのパターンを記録
• 既存のカードを 2～3 個見つける → パディング、枠線、シャドウを記録
• 既存のフォームを見つける → 入力欄のスタイル、ラベルの配置を記録
• 既存のタイポグラフィを確認する → 見出しのサイズ、本文のスタイルを記録

すべてのバリエーションで一貫して使用できるよう、推定したスタイルをデザインブリーフに記録します。

---

フェーズ 1：ヒアリング

すべてのヒアリング手順で AskUserQuestion ツールを使用します。デザインメモリーがある場合は、それに応じて質問を調整します。

ステップ 1.1：対象範囲と対象

以下の質問をします（複数の質問を含む AskUserQuestion 1 回にまとめてもかまいません）。

質問 1：対象範囲

• ヘッダー：「対象範囲」
• 質問：「単一のコンポーネントをデザインしますか、それともページ全体をデザインしますか？」
• 選択肢：
  • 「コンポーネント」 - 再利用可能な UI 要素（ボタン、カード、フォーム、モーダルなど）
  • 「ページ」 - ページまたは画面の完全なレイアウト

質問 2：新規作成か再デザインか

• ヘッダー：「種類」
• 質問：「新しいデザインですか、それとも既存のものを再デザインしますか？」
• 選択肢：
  • 「新規」 - 何もないところから作成
  • 「再デザイン」 - 既存のコンポーネント／ページを改善

「再デザイン」が選択された場合は、次の質問をします。 質問 3：既存のパス

• ヘッダー：「場所」
• 質問：「既存の UI のファイルパスまたはルートは何ですか？」
• 選択肢：（「その他」からユーザーが入力できるようにする）

対象が不明確な場合は、リポジトリのパターンに基づいて名前を提案し、確認します。

ステップ 1.2：課題と参考にするデザイン

質問 1：課題

• ヘッダー：「問題点」
• 質問：「現在のデザインで最も大きな課題は何ですか（または、新しいデザインで避けるべきことは何ですか）？」
• 選択肢：
  • 「ごちゃごちゃしている／情報量が多い」 - 情報が過剰で、内容を把握しにくい
  • 「階層が不明瞭」 - 主な操作が分かりにくい
  • 「モバイルでの使い勝手が悪い」 - 小さな画面でうまく動作しない
  • 「見た目が古い」 - 古く感じる、またはブランドイメージに合わない
• multiSelect：true

質問 2：ビジュアルの参考

• ヘッダー：「ビジュアルスタイル」
• 質問：「ビジュアルの参考にしたい製品やブランドはありますか？」
• 選択肢：
  • 「Stripe」 - すっきりしていて、ミニマルで、信頼感がある
  • 「Linear」 - 情報密度が高く、キーボード操作を重視し、開発者向け
  • 「Notion」 - 柔軟で、コンテンツを重視し、遊び心がある
  • 「Apple」 - 高級感があり、ゆとりがあって、洗練されている
• multiSelect：true

質問 3：機能面の参考

• ヘッダー：「インタラクション」
• 質問：「どのようなインタラクションパターンを参考にしたいですか？」
• 選択肢：
  • 「インライン編集」 - モーダルを使わず、その場で編集する
  • 「段階的な情報開示」 - 必要に応じて詳細を表示する
  • 「楽観的な更新」 - すぐにフィードバックし、バックグラウンドで同期する
  • 「キーボードショートカット」 - パワーユーザーの効率を高める

ステップ 1.3：ブランドとスタイルの方向性

質問 1：ブランドを表す形容詞

• ヘッダー：「ブランドのトーン」
• 質問：「ブランドにどのような印象を持たせたいですか？3～5個の形容詞で表してください」
• 選択肢：
  • 「ミニマル」 - すっきりしていて、シンプルで、煩雑さがない
  • 「プレミアム」 - 高級感があり、仕上がりがよく、洗練されている
  • 「遊び心がある」 - 楽しく、親しみやすく、気軽に使える
  • 「実用的」 - 機能的で、効率的で、無駄がない
• multiSelect：true

質問 2：情報密度

• ヘッダー：「情報密度」
• 質問：「どの程度の情報密度を希望しますか？」
• 選択肢：
  • 「コンパクト」 - より多くの情報を表示し、間隔を狭くする
  • 「標準的」 - バランスの取れた間隔で、内容を把握しやすい
  • 「ゆったり」 - 余白を十分に取り、注意を集中させる

質問 3：ダークモード

• ヘッダー：「ダークモード」
• 質問：「ダークモードは必要ですか？」
• 選択肢：
  • 「はい」 - ダークモードへの対応が必須
  • 「いいえ」 - ライトモードのみ
  • 「あると望ましい」 - 簡単に対応できる場合は対応するが、必須ではない

ステップ 1.4：ペルソナと達成したいこと

質問 1：主なユーザー

• ヘッダー：「ユーザー」
• 質問：「主なエンドユーザーは誰ですか？」
• 選択肢：
  • 「開発者」 - 技術に詳しく、キーボード操作を重視する
  • 「デザイナー」 - 視覚を重視し、細部にこだわる
  • 「ビジネスユーザー」 - 効率を重視し、技術的な知識はそれほど必要としない
  • 「一般消費者」 - 幅広い層で、技術的な知識もさまざま

質問 2：利用状況

• ヘッダー：「利用状況」
• 質問：「主な利用状況はどのようなものですか？」
• 選択肢：
  • 「デスクトップ優先」 - 主に大きな画面で使用する
  • 「モバイル優先」 - 主にスマートフォンで使用する
  • 「どちらも同等」 - すべてのデバイスで快適に動作する必要がある

質問 3：主なタスク

• ヘッダー：「主なタスク」
• 質問：「ユーザーが完了する必要のある主なタスクを3つ挙げてください」
• （自由回答のため、ユーザーに「その他」から入力してもらいます）

ステップ 1.5：制約

質問 1：維持する要素

• ヘッダー：「維持」
• 質問：「維持しなければならない要素はありますか？」
• 選択肢：
  • 「既存のコピー／ラベル」 - 現在のテキストを維持する
  • 「現在のフィールド／入力欄」 - フォームの構造を維持する
  • 「ナビゲーション構造」 - 現在のナビゲーションを維持する
  • 「なし」 - すべて変更可能

質問 2：技術的な制約

• ヘッダー：「制約」
• 質問：「技術的な制約はありますか？」
• 選択肢：
  • 「新しい依存関係を追加しない」 - 既存のライブラリのみ使用する
  • 「既存のコンポーネントを使用する」 - 現在のデザインシステムを基盤にする
  • 「アクセシビリティ（WCAG）への対応が必須」 - 厳格なアクセシビリティ要件がある
  • 「なし」 - 特別な制約はない
• multiSelect：true

---

フェーズ 2：デザインブリーフの生成

インタビューの後、構造化されたデザインブリーフを JSON として作成し、.claude-design/design-brief.json に保存します：

{
  "scope": "component|page",
  "isRedesign": true|false,
  "targetPath": "src/components/Example.tsx",
  "targetName": "Example",
  "painPoints": ["Too dense", "Primary action unclear"],
  "inspiration": {
    "visual": ["Stripe", "Linear"],
    "functional": ["Inline validation"]
  },
  "brand": {
    "adjectives": ["minimal", "trustworthy"],
    "density": "comfortable",
    "darkMode": true
  },
  "persona": {
    "primary": "Developer",
    "context": "desktop-first",
    "keyTasks": ["Complete checkout", "Review order", "Apply discount"]
  },
  "constraints": {
    "mustKeep": ["existing fields"],
    "technical": ["no new dependencies", "WCAG accessible"]
  },
  "framework": "nextjs-app",
  "packageManager": "pnpm",
  "stylingSystem": "tailwind"
}

次に進む前に、ユーザーに概要を表示します。

---

フェーズ 3：デザインラボの生成

ディレクトリ構造

.claude-design/ の下にすべてのファイルを作成します：

.claude-design/
├── lab/
│   ├── page.tsx                 # Main lab page (framework-specific)
│   ├── variants/
│   │   ├── VariantA.tsx
│   │   ├── VariantB.tsx
│   │   ├── VariantC.tsx
│   │   ├── VariantD.tsx
│   │   └── VariantE.tsx
│   ├── components/
│   │   └── LabShell.tsx         # Lab layout wrapper
│   ├── feedback/                # Interactive feedback system
│   │   ├── types.ts             # TypeScript interfaces
│   │   ├── selector-utils.ts    # Element identification
│   │   ├── format-utils.ts      # Feedback formatting
│   │   ├── FeedbackOverlay.tsx  # Main overlay component
│   │   └── index.ts             # Module exports
│   └── data/
│       └── fixtures.ts          # Shared mock data
├── design-brief.json
└── run-log.md

フィードバックシステムのセットアップ（重大：絶対に省略しないでください）

FeedbackOverlay は Design Lab の主要機能です。 これがないと、ユーザーはインタラクティブなフィードバックを提供できません。FeedbackOverlay のない Design Lab は絶対に生成しないでください。

信頼性を高めるための方針： プロジェクトの構成によるインポートパスの問題を避けるため、FeedbackOverlay は .claude-design/ ではなく、ルートディレクトリに直接作成してください（例：app/design-lab/FeedbackOverlay.tsx）。これにより、シンプルな相対インポート（./FeedbackOverlay）が常に機能します。

ルートディレクトリに必要なファイル：

app/design-lab/           # or app/__design_lab/ if underscores work
├── page.tsx              # Main lab page with variants
└── FeedbackOverlay.tsx   # Self-contained overlay component (copy from templates)

テンプレートのソース： design-and-refine/templates/feedback/FeedbackOverlay.tsx

この方法を使う理由：

• .claude-design/ のパスは、バンドラーの設定によって失敗する場合があります
• 同じディレクトリからの相対インポートは常に機能します
• ルートディレクトリは、いずれにせよクリーンアップ時に削除されます

ルートへの統合

Next.js App Router： .claude-design/lab/ からインポートする app/__design_lab/page.tsx を作成します

Next.js Pages Router： .claude-design/lab/ からインポートする pages/__design_lab.tsx を作成します

Vite React：

• React Router がある場合：/__design_lab へのルートを追加します
• ルーターがない場合：?design_lab=true クエリパラメーターに基づく条件付きレンダリングを App.tsx に作成します

その他のフレームワーク： 検出されたフレームワークに最も適した一時的なルートを作成します。

バリエーション生成のガイドライン

重要： UX、インタラクション、モーションのベストプラクティスについては、DESIGN_PRINCIPLES.md を読んでください。ただし、定義済みのビジュアルスタイルは使用せず、プロジェクトから推測してください。

普遍的な原則を適用します（DESIGN_PRINCIPLES.md より）：

• UX：ニールセンのヒューリスティック、認知負荷の軽減、段階的開示
• コンポーネントの動作：ボタンの状態、フォームの構成、カードの構造
• インタラクション：フィードバックパターン、状態管理、楽観的更新
• モーション：タイミング（150～300ms）、イージング（表示時は ease-out、終了時は ease-in）
• アクセシビリティ：フォーカス状態、ARIA パターン、タッチターゲット（最小 44px）

プロジェクトからビジュアルスタイルを推測します：

• 色 → Tailwind の設定、CSS 変数、または既存のコンポーネントから選びます
• タイポグラフィ → コードベース内の既存の見出しや本文から選びます
• 余白 → プロジェクトの余白スケールや既存のパターンから選びます
• 角丸 → 既存のカード、ボタン、入力欄から選びます
• シャドウ → 既存の浮き上がったコンポーネントから選びます

---

各バリエーションでは、必ず異なるデザイン軸を探ってください。 小さな違いだけのバリエーションは作らず、意味のある違いを持たせてください。すべてのバリエーションで、プロジェクトの既存のビジュアル言語を使用してください。

バリエーション A：情報の階層に重点を置く

• コンテンツの階層を再構成します（最も重要なものは何か？）
• ゲシュタルトの近接性を適用し、関連する項目をより近くにまとめます
• 1 つのビューにつき、主要なアクションを 1 つにします
• 既存のタイポグラフィスケールを使って、明確な階層を作ります

バリエーション B：レイアウトモデルの探究

• 異なるレイアウト方法を試します（カード、リスト、テーブル、分割ペイン）
• DESIGN_PRINCIPLES のカード構成やテーブル動作のパターンを適用します
• 各ブレークポイントでのレスポンシブ動作を検討します
• プロジェクトの既存のグリッド／レイアウトシステムを使用します

バリエーション C：情報密度の違い

• ブリーフに「ゆったり」とある場合は、よりコンパクトなバージョンを試します
• ブリーフに「コンパクト」とある場合は、よりゆったりしたバージョンを試します
• プロジェクトの既存の余白トークンを使用し、適用方法を変えます
• トレードオフを示します。表示できるデータ量と、スキャンしやすさのバランスです

バリエーション D：インタラクションモデル

• 異なるインタラクションパターンを使います（モーダル、インライン、パネル、ドロワー）
• フィードバックパターンを適用します：即時 → 進行中 → 完了
• 必要な状態をすべて実装します（読み込み中、エラー、空、無効）
• 破壊的でない操作では、楽観的更新を検討します

バリエーション E：表現の方向性

• インタビューでユーザーが説明したブランドの方向性を押し進めます
• プロジェクトの既存のデザイントークンの異なる使い方を探ります
• シャドウ、境界線、背景色の使用を増やす、または減らします
• 意味を加える場面でモーションを適用します（ホバー、フォーカス、トランジション）

ラボページの要件

デザインラボページには、以下を含める必要があります。

1. ヘッダー：

   • デザイン概要の要約（対象、範囲、主要な要件）
   • レビュー方法の説明

2. バリエーショングリッド：

   • わかりやすいラベル（A、B、C、D、E）
   • 各バリエーションの簡潔な理由（「これを作成した理由」）
   • 実際にレンダリングされたバリエーション
   • 主な違いを示すメモ
   • 重要： 各バリエーションのコンテナーには data-variant="X" 属性（X は A、B、C、D、E、または F）を設定する必要があります。フィードバックシステムが、どのバリエーションに対するコメントかを特定するために必須です。

3. レスポンシブ動作：

   • デスクトップ：横並びのグリッド（2～3列）
   • モバイル：横スクロールまたはタブ

4. 共有データ：

   • すべてのバリエーションで data/fixtures.ts の同じフィクスチャデータを使用します
   • 公平な比較を実現します

5. フィードバックオーバーレイ（必須・絶対に省略しないでください）：

   ⚠️ 最も重要な要件です ⚠️

   フィードバックオーバーレイを使うと、ユーザーは要素をクリックしてコメントを残せます。これがないと、デザインラボは構造化されたフィードバックを収集する方法のない静的なページになってしまいます。

   • page.tsx と同じディレクトリに FeedbackOverlay.tsx を作成します
   • 相対パスでインポートします：import { FeedbackOverlay } from './FeedbackOverlay'
   • すべてのバリエーションの後、ページの最後にレンダリングします
   • コンポーネント名／ページ名を targetName プロパティに渡します

   組み込み例：

import { FeedbackOverlay } from './FeedbackOverlay';  // Relative import - always works

export default function DesignLabPage() {
  return (
    <div className="min-h-screen bg-background">
      <header>...</header>

      <main>
        <div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-8">
          <div data-variant="A">
            <VariantA />
          </div>
          <div data-variant="B">
            <VariantB />
          </div>
          {/* ... more variants */}
        </div>
      </main>

      {/* CRITICAL: FeedbackOverlay must be included */}
      <FeedbackOverlay targetName="ComponentName" />
    </div>
  );
}

フィードバックオーバーレイを忘れると、ユーザーはフィードバックを提供できません。 それではデザインラボの目的を果たせません。

コード品質

規約：

• プロジェクト既存のコード規約（ファイル名、インポートなど）に従います
• 検出されたスタイリングシステム（Tailwind、CSS モジュールなど）を使用します
• 適切な場合は、プロジェクト内の既存コンポーネントを使用します

アクセシビリティ（DESIGN_PRINCIPLES に基づく）：

• セマンティック HTML：<div onclick> ではなく <button> を使用し、<nav>、<main>、<section> を使います
• キーボード操作：すべてのインタラクティブ要素をフォーカス可能かつ操作可能にします
• フォーカス状態：2px のリングとオフセットを備えた、視認可能な :focus-visible を設定します
• 色のコントラスト：テキストは 4.5:1、UI 要素は 3:1 にします
• タッチターゲット：最小 44x44px にします
• HTML のセマンティクスだけでは不十分な場合に限り、ARIA を使用します

状態（すべてのコンポーネントに必要）：

• デフォルト、ホバー、フォーカス、アクティブ、無効、読み込み中、エラー、空
• DESIGN_PRINCIPLES の「State Handling」セクションを参照してください

モーション：

• 適切なタイミングを使用します：マイクロインタラクションは 150～200ms、トランジションは 200～300ms
• 表示時は ease-out、終了時は ease-in を使用します
• prefers-reduced-motion を尊重します

---

フェーズ 4：デザインラボをユーザーに提示する

ラボのファイルを生成したら、すぐにユーザーにラボを提示します。次のことは行わないでください。

• 自分で開発サーバーを起動する（プロセスが終了せず、処理がブロックされます）
• ポートが開いているか確認する
• ブラウザーを開く
• サーバーからの応答を待つ

実行すること

1. ラボの場所と URL を出力します。

   ✅ Design Lab created!
   
   I've generated 5 design variants in `.claude-design/lab/`
   
   To view them:
   1. Make sure your dev server is running (run `pnpm dev` if not)
   2. Open: http://localhost:3000/__design_lab
   
   Take your time reviewing the variants side-by-side, then come back and tell me:
   - Which variant wins (A-E)
   - What you like about it
   - What should change
   

2. ただちにフェーズ 5 に進み、フィードバックを求めます。ユーザーがブラウザーを開いたと言うまで待たないでください。ユーザーが戻ってきたときにすぐ対応できるよう、フィードバックの質問をただちに提示してください。

サーバーを起動しない理由

pnpm dev または npm run dev を実行すると、終了しない長時間実行プロセスが起動します。実行すると、いつまでも待つことになります。ユーザーはすでに開発サーバーを起動しているか、別のターミナルで自分で起動できます。

---

フェーズ 5：フィードバックを収集する

ラボの URL を提示した後、ユーザーは次の 2 つの方法でフィードバックを提供できます。

1. インタラクティブなフィードバック（推奨）：ブラウザーで組み込みのオーバーレイを使用
2. 手動フィードバック：ターミナルで AskUserQuestion を使用

インタラクティブなフィードバック（主な方法）

Design Lab には Figma のようなフィードバックオーバーレイが含まれています。ラボを提示するときは、次の手順を含めてください。

✅ Design Lab created!

I've generated 5 design variants in `.claude-design/lab/`

To view and provide feedback:
1. Make sure your dev server is running (run `pnpm dev` if not)
2. Open: http://localhost:3000/__design_lab

**To add feedback:**
1. Click the "Add Feedback" button (bottom-right corner)
2. Click any element you want to comment on
3. Type your feedback and click "Save"
4. Repeat for all elements you want to comment on
5. Fill in the "Overall Direction" field (required)
6. Click "Submit All Feedback"
7. Paste the copied text here in the terminal

Or just describe your feedback manually below!

ユーザーがフィードバックを貼り付けると、次の形式になります。

## Design Lab Feedback

**Target:** ComponentName
**Comments:** 3

### Variant A
1. **Button** (`[data-testid='submit']`, button with "Submit")
   "Make this more prominent"

### Variant B
1. **Card** (`.product-card`, div with "Product Name")
   "Love this layout"

### Overall Direction
Go with Variant B's structure. Apply Variant A's button styling.

このフィードバックの解析方法と対応方法：

1. 最初に全体的な方向性を読みます。これは統合の指針となります
2. 各コメントについて、次の方法で要素を特定します。
   • 優先：バッククォートで囲まれた CSS セレクター（例：[data-testid='submit']）
   • 次点：要素の説明（例：「『Submit』というボタン」）
3. 対応するバリアントファイルを編集して、フィードバックを反映します

フォールバック：AskUserQuestion を使った手動フィードバック

ユーザーがインタラクティブオーバーレイを使用しないことを希望する場合（または手動のフィードバックを貼り付けた場合）は、以下の AskUserQuestion フローを使用してください。

ステージ 1：選択候補を確認する

質問 1：選ぶ準備はできていますか？

• ヘッダー：「決定」
• 質問：「そのまま使いたいバリアントはありますか？」
• 選択肢：
  • 「はい — 気に入ったものが見つかりました」 - バリアントを選んで調整できます
  • 「いいえ — それぞれの良いところを組み合わせたいです」 - 新しいバリアントを統合する必要があります

ステージ 2A：ユーザーが候補を見つけた場合

ユーザーが「はい」と答えた場合は、次の質問をします。

質問 2a：どれですか？

• ヘッダー：「候補」
• 質問：「どのバリアントを選びますか？」
• 選択肢：
  • 「バリアント A」 - A の簡単な説明
  • 「バリアント B」 - B の簡単な説明
  • 「バリアント C」 - C の簡単な説明
  • 「バリアント D」 - D の簡単な説明
  • 「バリアント E」 - E の簡単な説明

質問 3a：調整は必要ですか？

• ヘッダー：「調整」
• 質問：「少し変更が必要ですか？それとも、このままでよいですか？」
• 選択肢：
  • 「このままでよい」 - 変更は不要です。最終プレビューに進みます
  • 「少し調整が必要」 - 調整内容を説明します

「少し調整が必要」の場合は、テキスト入力で変更内容を説明するようユーザーに依頼します。

その後、フェーズ 7：最終プレビューに進みます。

ステージ 2B：ユーザーが統合を希望する場合

ユーザーが「いいえ — それぞれの良いところを組み合わせたいです」と答えた場合は、次の質問をします。

質問 2b：それぞれのどこが気に入りましたか？

• ヘッダー：「フィードバック」
• 質問：「各バリアントのどこが気に入りましたか？（A、B、C、D、E の具体的な要素を挙げてください）」
• （「その他」のテキスト入力から詳しいフィードバックを入力してもらいます）

ユーザーを案内するための回答例：

- A: Love the card layout and spacing
- B: The color scheme feels right
- C: The interaction on hover is great
- D: Nothing stands out
- E: The typography hierarchy is clearest

その後、フェーズ 6：新しいバリアントの統合に進みます。

---

フェーズ 6：新しいバリアントの統合

各バリアントで気に入った点についてのユーザーのフィードバックに基づいて、次のようにします。

1. 次の要素を組み合わせた新しいハイブリッドバリアント（バリアント F）を作成します。

   • ユーザーが各バリアントから挙げた具体的な要素
   • すべてのバリアントから選んだ最適な構造上の判断
   • 複数のバリアントに見られたパターン

2. Design Lab を比較ビューに置き換えます。

   • 新しく統合したバリアント F を目立つように表示します
   • 比較用に、最も近かった元のバリアントを 1～2 個残します
   • ユーザーが気に入った点のなかったバリアントを削除します

3. 新しい配置が表示されるように /__design_lab ルートを更新します

4. 再度フィードバックを求めます。

質問：新しいバリアントはいかがですか？

• ヘッダー：「レビュー」
• 質問：「統合したバリアント（F）の見た目はいかがですか？」
• 選択肢：
  • 「これです！」 - 最終プレビューに進みます
  • 「近づいています」 - もう一度調整する必要があります
  • 「希望と違う方向です」 - 希望を改めて説明します

「近づいています」または「希望と違う方向です」の場合は、より具体的なフィードバックを集めて調整します。ユーザーが満足するまで、複数回の統合作業に対応してください。

その後、フェーズ 7：最終プレビューに進みます。

---

フェーズ 7：最終プレビュー

ユーザーが満足したら：

1. .claude-design/preview/ ディレクトリを作成します：

   .claude-design/preview/
   ├── page.tsx                    # Preview page
   └── FinalDesign.tsx             # The winning design
   

2. /__design_preview にルートを作成します

3. リデザインの場合は、変更前と変更後の比較を含めます：

   • 切り替えスイッチまたは分割ビュー
   • 元のデザインと提案するデザインを並べて表示

4. 最終確認を求めます：

質問：最終デザインを確定しますか？

• ヘッダー：「確認」
• 質問：「このデザインを確定してもよろしいですか？」
• 選択肢：
  • 「はい、確定します」 - クリーンアップに進み、実装計画を生成します
  • 「いいえ、変更が必要です」 - 調整する内容を伝えます
  • 「中止 - すべてキャンセル」 - 一時ファイルをすべて削除し、計画は生成しません

「いいえ、変更が必要です」の場合：フィードバックを集めて反復します。 「中止」の場合：以下の中止処理に進みます。

---

中止処理

ユーザーは、プロセス中のどの時点でも（最終確認時だけでなく）キャンセル／中止を希望できます。たとえば、次のように伝える場合があります：

• 「キャンセル」
• 「中止」
• 「停止」
• 「やっぱりやめます」
• 「なかったことにして」
• 「気が変わりました」

中止が検出された場合：

1. 中止を確認します：

   • 「キャンセルしてもよろしいですか？作成したデザインラボのファイルはすべて削除されます。」

2. 確認された場合は、ただちにクリーンアップします：

   • .claude-design/ ディレクトリ全体を削除します
   • 一時的なルートファイル（app/__design_lab/ など）を削除します
   • 実装計画は生成しません
   • Design Memory は更新しません

3. 完了を伝えます：

   • 「デザインの検討をキャンセルしました。一時ファイルはすべてクリーンアップ済みです。また最初から始めたい場合はお知らせください。」

---

フェーズ 8：確定

ユーザーが「はい、確定します」を選択して確認した場合：

8.1：クリーンアップ

一時ファイルをすべて削除します：

• .claude-design/ ディレクトリ全体を削除します
• 一時的なルートファイルを削除します：
  • app/__design_lab/ （Next.js App Router）
  • pages/__design_lab.tsx （Next.js Pages Router）
  • app/__design_preview/
  • pages/__design_preview.tsx
  • App.tsx の変更を元に戻します（Vite）

安全ルール：

• .claude-design/ 内のファイルのみ削除します
• プラグインが作成したルートファイルのみ削除します
• ユーザーが作成したファイルは絶対に削除しません
• 削除前にファイルパスを確認します

8.2：実装計画の生成

プロジェクトのルートに DESIGN_PLAN.md を作成します：

# Design Implementation Plan: [TargetName]

## Summary
- **Scope:** [component/page]
- **Target:** [file path]
- **Winner variant:** [A-E]
- **Key improvements:** [from feedback]

## Files to Change
- [ ] `src/components/Example.tsx` - Main component refactor
- [ ] `src/styles/example.css` - Style updates
- [ ] ... (list all affected files)

## Implementation Steps
1. [Specific step with code guidance]
2. [Next step]
3. ...

## Component API
- **Props:**
  - `prop1: type` - description
  - ...
- **State:**
  - Internal state requirements
- **Events:**
  - Callbacks and handlers

## Required UI States
- **Loading:** [description]
- **Empty:** [description]
- **Error:** [description]
- **Disabled:** [description]
- **Validation:** [description]

## Accessibility Checklist
- [ ] Keyboard navigation works
- [ ] Focus states visible
- [ ] Labels and aria-* attributes correct
- [ ] Color contrast meets WCAG AA
- [ ] Screen reader tested

## Testing Checklist
- [ ] Unit tests for logic
- [ ] Component tests for rendering
- [ ] Visual regression tests (if applicable)
- [ ] E2E smoke test (if applicable)

## Design Tokens
- [Any new tokens to add]
- [Existing tokens to use]

---

*Generated by Design Variations plugin*

8.3：Design Memory の更新

DESIGN_MEMORY.md を作成または更新します：

新規ファイルの場合：

# Design Memory

## Brand Tone
- **Adjectives:** [from interview]
- **Avoid:** [anti-patterns discovered]

## Layout & Spacing
- **Density:** [preference]
- **Grid:** [if established]
- **Corner radius:** [if consistent]
- **Shadows:** [if consistent]

## Typography
- **Headings:** [font, weights used]
- **Body:** [font, size]
- **Emphasis:** [patterns]

## Color
- **Primary:** [color tokens]
- **Secondary:** [color tokens]
- **Neutral strategy:** [approach]
- **Semantic colors:** [error, success, warning]

## Interaction Patterns
- **Forms:** [validation approach, layout]
- **Modals/Drawers:** [when to use which]
- **Tables/Lists:** [preferred patterns]
- **Feedback:** [toast, inline, etc.]

## Accessibility Rules
- **Focus:** [visible focus approach]
- **Labels:** [labeling conventions]
- **Motion:** [reduced motion support]

## Repo Conventions
- **Component structure:** [file organization]
- **Styling approach:** [Tailwind classes, CSS modules, etc.]
- **Existing primitives:** [Button, Input, Card, etc.]

---

*Updated by Design Variations plugin*

既存ファイルを更新する場合：

• 新たに見つかったパターンを追記します
• 最新の決定内容に基づいて、矛盾するガイダンスを更新します
• 簡潔で実行可能な内容に保ちます

---

エラー処理

フレームワークを検出できない場合

フレームワークを特定できない場合：

• ユーザーに尋ねます：「フレームワークを検出できませんでした。何を使用していますか？」
• Next.js、Vite、Create React App、Vue など、一般的な選択肢を提示します

開発サーバーが起動しない場合

開発サーバーが起動しない場合：

• ポートの競合を確認します
• 手動での手順を案内します
• ユーザー自身でサーバーを起動するよう提案します

ルートの統合に失敗した場合

一時的なルートを作成できない場合：

• 代わりにスタンドアロンの HTML ファイルを作成します
• 手動でプレビューする方法を案内します

クリーンアップが中断された場合

クリーンアップが中断された場合：

• 削除済みと残存しているファイルを記録します
• 手動でクリーンアップする方法を案内します
• ユーザーに知らせずに中途半端な状態を残すことは絶対に避けます

---

設定オプション

このプラグインでは、次の任意の設定（環境またはプロジェクト設定経由）をサポートしています：

• DESIGN_AUTO_IMPLEMENT：true の場合、確認後すぐに計画を実装します
• DESIGN_KEEP_LAB：true の場合、明示的なクリーンアップコマンドが実行されるまでラボを削除しません
• DESIGN_MEMORY_PATH：Design Memory ファイルのカスタムパス

---

セッションの流れの例

1. ユーザー：/design-variations:design CheckoutSummary
2. プラグインが検出：Next.js App Router、Tailwind、pnpm
3. プラグインが確認：既存の Design Memory はありません
4. プラグインが質問：インタビュー形式の質問（5 ステップ）
5. プラグインが生成：Design Brief の要約
6. プラグインが作成：5 つのバリエーションを含む .claude-design/lab/
7. プラグインが作成：app/__design_lab/page.tsx
8. プラグインが起動：pnpm dev
9. プラグインが出力：「http://localhost:3000/__design_lab を開いてください」
10. ユーザーがブラウザーでバリエーションを確認
11. プラグインが質問：「どのバリエーションにしますか？」
12. ユーザー：「バリエーション C ですが、X と Y を変更してください」
13. プラグインが修正：バリエーション C を更新
14. ユーザー：「よさそうです」
15. プラグインが作成：/__design_preview に最終プレビュー
16. ユーザー：「確認しました」
17. プラグイン：一時ファイルをすべて削除
18. プラグイン：DESIGN_PLAN.md を生成
19. プラグイン：DESIGN_MEMORY.md を作成
20. プラグイン：「完了しました！実装手順は DESIGN_PLAN.md をご覧ください」