Reactウェブプロジェクトの開始
まず web-craft を読んでください。そのルールがここでも適用されます。プロジェクトの既存の決定事項は、以下の全てのデフォルトよりも優先されます。
1. インテーク
既に与えられているものを読み取ってください：製品説明、既存のリポジトリ、ページ、デザインシステム、STACK.md、DESIGN.md、API契約。その後、references/intake.md で不足を補います：サーフェスタイプ（ランディング、エディトリアル、カタログ、コンシューマーアプリ、管理画面、カスタマーポータル、またはそれらの混合）、主要ユーザーとアクション、コンテンツまたは操作密度、デバイス、SEO要件、現在および将来の言語、RTL、認証、バックエンド（Node.js、サードパーティAPI、CMS、モック、静的）。
製品やアーキテクチャの決定を変更するものだけを質問してください。それ以外は前提として記述します。
2. 技術プロファイルの決定
各決定を一行の理由とともに記述してください。方向性が決まる前にすべての画面を生成しないでください。
| 決定 | デフォルトと根拠の所在 |
|---|---|
| フレームワークとレンダリング | 公開、SEOまたはCMS重視、多言語 → Next.js App Router。ログインの背後にあり、インタラクティブ性が高い → React + Vite または既存のNext.js。シンプルな静的サーフェス → 最もシンプルな方法。references/framework-choice.md |
| UIキット | 特徴的なブランド製品 → shadcn/ui。テーブル/フォームが多い管理画面 → Ant Design。Materialスタイルの製品または既存のMUI → Material UI。既存のシステム → そのまま維持。アプリのサーフェスごとに1つのメインキット。references/kit-choice.md |
| スタイリング | キットに従う：shadcn → Tailwind（shadcn必須）；Ant Design または MUI → キットのテーマに加え、カスタム部分にはCSS Modules；カスタムまたはエディトリアル → CSS Modules。1つのサーフェスでTailwindとCSS Modulesを同等のシステムとして混在させない。references/styling-choice.md |
| i18n | Next.js → next-intl；Vite → i18next + react-i18next。ロケールレジストリ、フォールバック、URLポリシー、カタログ読み込みは初日に決定。references/i18n-setup.md |
| モーション | シンプルな状態変化にはCSS transitions；Reactでマウント/アンマウント、レイアウト、オーケストレーションが必要な場合はMotion for React。持続時間とイージングのトークン；動きの抑制は一箇所で処理。references/motion-setup.md |
| フォームとデータ | react-hook-form + Zod；TanStack Query またはフレームワークのデータモデル；既存のものを維持。 |
| テーマ | インタラクティブな製品にはLight/Dark/System；ブランド化されたマーケティングサイトでは単一テーマも製品決定として可。 |
| テスト | 型チェック、リント（eslint-plugin-web-craft および eslint-plugin-jsx-a11y 使用）、動作が存在する場所でのユニット/コンポーネントテスト、重要なフローに対するPlaywright。 |
| 言語とツール | Strict TypeScript、プロジェクトごとにYarn固定、ロックファイル1つ。 |
選択するすべてのパッケージの現在の安定バージョンを、その日のうちに公式ソースから確認し、連携して動作するバージョンを固定して STACK.md に記録してください。バージョン番号を記憶やこのスキルからコピーしないでください。
3. プロジェクトドキュメントの作成
STACK.md：フレームワーク、レンダリング、キット、スタイリング、i18nエンジン、データ・フォームツール、バージョン、環境、スクリプト。テンプレート：references/stack-template.md。DESIGN.md：製品の特性、リファレンスから得た原則、レイアウト、トークン（色、タイポグラフィ、スペーシング、角丸、影、モーション）、コピールール、モーションマトリックス、i18nに関する注意事項。テンプレート：references/design-template.md。- ロケールリストと型はコード設定から生成します。ドキュメントはそれを説明するものであり、第二の真実の情報源ではありません。
- 小さな変更ごとに4つも新しいドキュメントを作成しないでください。
4. プロジェクトのレイアウト
機能ベースの構造、サーバー/クライアントの境界を明確に、1つのAPIレイヤー、トークンとプロバイダーは1箇所に：references/structure.md。
5. スケルトンの検証
さらに画面を構築する前に、1つの小さなフローがエンドツーエンドで動作することを確認する必要があります：
- ロケールが最初のレンダリングで正しく解決される（言語フラッシュなし）、切り替えでルートが保持される。
- テーマがユーザーの選択とシステム設定に従い、読み込み時にフラッシュしない。
- フォームがblur時にバリデーションを行い、送信時に最初のエラーまでスクロールし、サーバーエラーを該当フィールドにマッピングする。
- ダイアログがアニメーションで出入りし、フォーカスをトラップして戻し、動きの抑制が大きな動きを削除する。
- リストまたはチャートがスケルトン、空の状態、エラーとリトライを表示する。
- キーボードのみの操作が機能し、コンソールやハイドレーションエラーがない。
その後、代表的な垂直スライス（実際のコンテンツ、第二言語、読み込み中とエラー状態）を1つ構築し、他の画面に展開する前にモバイルとデスクトップの幅でブラウザで確認します。
6. スクリプト
dev、build、start（Next.js）、typecheck、lint、test、test:e2e。バンドルサイズが重要な場合は analyze を追加します。
ソース
これらのデフォルトに使用した公式リンクと、それらを確認した日付：references/sources.md。インストールするバージョンについて再確認してください。