shadcnコンポーネントビジュアルアダプター

# shadcn Component Visual Adapter ## 目的 `${component_file_path}` にある既存の`${component_name}`コンポーネントを、以下の参照コンポーネントのビジュアルデザイン、構造、動作に合わせてリファクタリングします： > ${install_command:bunx --bun shadcn@latest add accordion} ${reference_url:} ← 任意、ドキュメントページが存在しない場合は空白 ビジネスロジック、既存のpropsインターフェース、データ取得パターンは置き換えないでください。それらは保持します。 ビジュアルレイヤー（マークアップ構造、クラス名、アニメーション、アクセシビリティ属性）のみを適応させます。 ## ステップ1 - 既存コンポーネントの分析 コードを書く前に： 1. `${component_file_path}` の完全なソースを読む。 2. 以下をマッピングする： - すべてのpropsとその型（TypeScriptインターフェースまたはPropTypes）。 - 内部状態変数（`useState`、`useReducer`、Zustandスライスなど）。 - 使用されているContextプロバイダーまたはカスタムフック。 - レンダリングされる子コンポーネントとその配置場所。 - 親に公開されるイベントハンドラーとコールバック。 3. すべてのインポートをリストアップし、shadcnプリミティブと競合するもの、または置き換え可能なものをフラグ付けする。 コードに触れる前に、簡単な監査テーブルを出力する： | 項目 | 現在の値 | アクション | |------|--------------|--------| | Props | ... | 保持 / リネーム / 削除 | | 状態 | ... | 保持 / 移行 | | Context/フック | ... | 保持 / 置き換え | | サブコンポーネント | ... | 保持 / 置き換え | | 依存関係 | ... | 保持 / インストール / 削除 | ## ステップ2 - 依存関係の解決 インストールコマンドを直接実行する： ${install_command} コマンド完了後、生成されたファイルは ${components_dir:components/ui}/ に表示されます。ステップ3に進み、それらのファイルを使用します。 ## ステップ3 - 参照コンポーネントのレビュー ${reference_url} が提供されている場合 → それを取得し、以前と同様にビジュアル仕様を抽出する。 ${reference_url} が空白の場合 → ステップ2でCLIコマンドがダウンロードしたファイルを読み、ソースコードから直接同じ情報を抽出する： - cvaバリアントスキーマ - data-state / data-disabled属性 - アニメーション/トランジションクラス - ARIAロールとprops - cn() の使用パターン ## ステップ4 - コンポーネントのリファクタリング ステップ3のビジュアル構造を、ステップ1の既存コンポーネントに適用する。 ### ルール： - ✅ 直接的なshadcn相当が存在しない限り、すべての既存のprop名と型を保持する。 - ✅ すべてのデータ取得、ビジネスロジック、コールバックを保持する。 - ✅ Radixプリミティブを `forwardRef` でラップし、柔軟性を保つために `...props` をスプレッドする。 - ✅ すべてのclassNameマージに `cn()` を使用する - 文字列連結は絶対にしない。 - ✅ 参照コンポーネントが複合サブコンポーネントを使用している場合、名前付きでエクスポートする（例：`Accordion`、`AccordionItem`、`AccordionTrigger`、`AccordionContent`）。 - ❌ 生成されたshadcnファイルをインポートして再エクスポートしない - ロジックを同じ場所に保つため、リファクタリングされたファイルにプリミティブをインラインで構築する。 - ❌ 明示的な指示なしに、参照コンポーネントに存在しないTailwindクラスを追加しない。 ### レスポンシブ動作（`${responsive_breakpoints:sm md lg}`）： モバイルファーストのレスポンシブクラスを適用する。現在のブレークポイントが `tailwind.config.ts` でプロジェクトの規約と一致していることを確認する。参照がコンテナクエリを使用している場合、`@tailwindcss/container-queries` をインストールする。 ## ステップ5 - Contextプロバイダーとフック 参照コンポーネントがContextプロバイダーを必要とする場合（例：`ToastProvider`、`TooltipProvider`）： 1. それが既に `${provider_file:app/layout.tsx}` または `${provider_file:app/providers.tsx}` にマウントされているか確認する。 2. されていない場合、適切なレイアウトファイルに追加する。正確なdiffを提供する。 3. カスタムフックが必要な場合（例：`useToast`、`useDialog`）、それを `${hooks_dir:hooks/}` に配置し、そこからインポートする。 ## ステップ6 - 明確化の質問（不明な場合は生成前に質問） 以下が既存のコードから判断できない場合、書く前に質問する： 1. **データ/props**：渡されるデータの形状は？（可能ならサンプルオブジェクトを提供） 2. **状態管理**：コンポーネントの状態はローカルか、外部管理か（Zustand、Redux、React Query）？ 3. **アセット**：lucide-reactでカバーされない必要な画像、ロゴ、カスタムアイコンはあるか？ 4. **レスポンシブ**：`${responsive_breakpoints:sm md lg}` ブレークポイントでの期待されるレイアウトは？ 5. **配置**：このコンポーネントはアプリのルーティング/レイアウトツリーのどこに配置されるか？（Contextプロバイダーの配置に重要） ## ステップ7 - 出力形式 結果を以下として提供する： 1. **`${component_file_path}`** - 完全にリファクタリングされたコンポーネントファイル。 2. **`${components_dir:components/ui}/${shadcn_component_slug}.tsx`** - shadcnプリミティブ（必要な場合のみ、CLIで生成されない場合）。 3. **`lib/utils.ts`** - 作成または更新が必要な場合のみ。 4. **レイアウト/プロバイダーのdiff** - プロバイダーを追加する必要がある場合のみ。 5. 短い**移行ノート**セクション： - 削除された依存関係 - リネームされたprops（ある場合） - 必要な手動ステップ（例：`globals.css` へのCSS変数の追加） ## Tailwind CSS変数（shadcnデザイントークン） `globals.css` に必要なCSSカスタムプロパティが含まれていることを確認する。参照コンポーネントが `--radius`、`--background`、`--foreground`、`--primary`、`--ring` などのトークンを使用する場合、不足している変数を追加する。プロジェクトがすでにカスタムテーマを定義していない限り、`${color_theme:zinc}` のshadcnデフォルトトークンセットを使用する。 ## 制約 - フレームワーク：**${framework:Next.js 14+ App Router}** - スタイリング：**Tailwind CSS ${tailwind_version:3}** のみ - インラインスタイル、CSSモジュール、styled-componentsは使用しない。 - TypeScript：**strictモード**。すべての新しいコードは完全に型付けされる必要がある。 - 直接のピア競合がない限り、既存の依存関係のバージョンをアップグレードまたはダウングレードしない。