design

/claude-db:design

新規開発プロジェクト向けのエンジン選定とスターターモデルです。これは モジュール M0（エンジン選定）：スコアではなく推奨 です。/claude-db:design は2つの監査スコアを生成せず、データベースにも書き込みません。

$ARGUMENTS = プロジェクトの平易な説明（データ、アクセスパターン、規模、制約など）です。適切に選定するには情報が足りない場合は、まず鋭い質問を2～3個してください。または、完全なガイド付きウィザードを使うために /claude-db:start に引き継いでください。

実行内容

1. M0 の判断ツリーに沿って進めます（references/engine-selection-tree.md。パラダイムの判断材料については references/detection-signals.md と data-tiers.md も参照）。アクセスパターンとデータの形状からパラダイム（リレーショナル／ドキュメント／キー・バリュー／ワイドカラム／ベクトル／時系列／グラフ）を絞り込み、具体的なエンジンを選びます。
2. エンジンを推奨します。必ず 無難なデフォルト（多くのアプリケーションのワークロードでは Postgres）と比較してください。無難なデフォルトが適している場合（通常はこちらです）は、そのことを明言し、別の選択肢を選ぶ根拠となる具体的なニーズを示します。ロックインと運用コストについても正直に説明してください。価格、レイテンシー、スループット、ベンチマークの数値を捏造してはいけません。トレードオフは定性的に説明するか、実際の数値が必要な場合は needs_api と記してください。
3. 推奨エンジン向けの スターターデータモデル を提示します。コアエンティティ、キー（適切に UUIDv7／ULID／bigint を使用し、金額には決して float を使わず、timestamptz／UTC を使用）、明らかなリレーションシップ／埋め込み、適切な初回マイグレーションに含めるべき制約／インデックスを示します。
4. node scripts/gen-diagram.mjs --file <schema> [--paradigm relational|document|key-value|wide-column|graph] を使って、パラダイムに対応した図を作成します（リレーショナルなら ERD、ドキュメントならアクセスパターンマップ、DynamoDB／KV ならキーと GSI のスケッチ、グラフならノード／エッジ）。

形式 — 初心者向けの説明を先に、技術的な詳細は展開可能に

• 初心者にもわかりやすい平易な説明から始めます。どのデータベースを選ぶかを一文で示し、最初から専門用語を使わずに理由を説明します。
• 続けて 展開可能な技術レイヤー を示します。詳しく知りたい読者向けに、DDL／コレクション仕様、インデックスの選択、キー戦略、設計ルールの根拠（各選択がどの監査モジュールの要件を満たすか。例：M2 キー、M4 型、M11 インデックス）を説明します。
• 最後に、次のように案内します。「最初のスキーマができたら、/claude-db:audit を実行して、設計と整合性、およびパフォーマンスとスケールについてスコアを付けてください。」

--emit <prisma|drizzle|sql> — 初回マイグレーションを生成する

モデルを推奨した後（上記の手順はすべて先に実行します。--emit が推奨に置き換わることはありません）、選択したターゲット向けに 可逆な初回マイグレーション を作成します。

• 推奨したスターターモデルについて、指定された形式（Prisma スキーマ、Drizzle スキーマ、または生の SQL DDL）でスキーマを生成します。
• db-migration-writer エージェント（Task 経由）にスキャフォールドを渡し、可逆なマイグレーション（アップ＋ダウン）として作成させます。ライターは fix のガードを再利用します。Git ツリーが汚れている場合は拒否し（Git リポジトリがない場合は書き込み可能として扱い、バックアップは引き続きプラグインのデータディレクトリに保存します）、デフォルトではドライランプレビューを実行し、シークレットを含めないようにします（.env／認証情報／架空の接続文字列を決して書き込みません）。
• --emit sql の場合に限り、新しいスキーマ向けに外部キーを考慮したシードデータを生成する /claude-db:seed も案内します。

ユーザーの言語（EN／ES）で回答してください。