create-ai-project 1.11.2

package/docs/rules/ai-development-guide.md

@@ -0,0 +1,260 @@
+# AI開発者ガイド - 技術的判断基準とアンチパターン集
+
+## 技術的アンチパターン（赤信号パターン）
+
+以下のパターンを検出したら即座に停止し、設計を見直すこと：
+
+### コード品質のアンチパターン
+1. **同じようなコードを3回以上書いた** - Rule of Threeに違反
+2. **単一ファイルに複数の責務が混在** - 単一責任原則（SRP）違反
+3. **同じ内容を複数ファイルで定義** - DRY原則違反
+4. **依存関係を確認せずに変更** - 予期しない影響の可能性
+5. **コメントアウトでコード無効化** - バージョン管理を活用すべき
+6. **エラーの握りつぶし** - 問題の隠蔽は技術的負債
+7. **型アサーション（as）の多用** - 型安全性の放棄
+
+### 設計のアンチパターン
+- **「一旦動くように」という思考** - 技術的負債の蓄積
+- **継ぎ足し実装** - 既存コードへの無計画な追加
+- **不確実技術の楽観的実装** - 未知要素を「たぶん動く」前提で設計
+- **対処療法的修正** - 根本原因を解決しない表面的な修正
+- **無計画な大規模変更** - 段階的アプローチの欠如
+
+## フォールバック処理に関する設計原則
+
+### 基本原則：Fail-Fast
+分散システムにおいて、フォールバック処理よりもプライマリコードの信頼性向上を優先する設計思想。
+
+### フォールバック実装の判断基準
+- **原則禁止**: エラー時の無条件フォールバックは実装しない
+- **例外的許可**: Design Docで明示的に定義された場合のみ実装
+- **レイヤー責務**:
+  - インフラ層: エラーを必ず上位に投げる（フォールバック判断なし）
+  - アプリケーション層: ビジネス要件に基づく判断を実装
+
+### フォールバック過多の検出
+- 同一機能で3つ目のcatch文を書く時点で設計見直しを必須とする
+- フォールバックを実装する前にDesign Docでの定義を確認
+- エラーは適切にログ出力し、失敗を明確にする
+
+## Rule of Three - コード重複の判断基準
+
+Martin Fowler「Refactoring」に基づく重複コードの扱い方：
+
+| 重複回数 | 対応 | 理由 |
+|---------|------|------|
+| 1回目 | インライン実装 | 将来の変化が予測できない |
+| 2回目 | 将来の統合を意識 | パターンが見え始める |
+| 3回目 | 共通化実施 | パターンが確立された |
+
+### 共通化の判断基準
+
+**共通化すべきケース**
+- ビジネスロジックの重複
+- 複雑な処理アルゴリズム
+- 一括変更が必要になる可能性が高い箇所
+- バリデーションルール
+
+**共通化を避けるべきケース**
+- 偶然の一致（たまたま同じコード）
+- 将来異なる方向に進化する可能性
+- 共通化により可読性が著しく低下
+- テストコード内の簡単なヘルパー
+
+### 実装例
+```typescript
+// ❌ 1回目の重複で即共通化
+function validateUserEmail(email: string) { /* ... */ }
+function validateContactEmail(email: string) { /* ... */ }
+
+// ✅ 3回目で共通化
+function validateEmail(email: string, context: 'user' | 'contact' | 'admin') { /* ... */ }
+```
+
+## よくある失敗パターンと回避方法
+
+### パターン1: エラー修正の連鎖
+**症状**: エラーを修正すると新しいエラーが発生
+**原因**: 根本原因を理解せずに表面的な修正
+**回避方法**: 5 Whysで根本原因を特定してから修正
+
+### パターン2: 型安全性の放棄
+**症状**: any型やasの多用
+**原因**: 型エラーを回避したい衝動
+**回避方法**: unknown型と型ガードで安全に処理
+
+### パターン3: テスト不足での実装
+**症状**: 実装後にバグ多発
+**原因**: Red-Green-Refactorプロセスの無視
+**回避方法**: 必ず失敗するテストから開始
+
+### パターン4: 技術的不確実性の無視
+**症状**: 新技術導入時の想定外エラー多発
+**原因**: 事前調査なしで「公式ドキュメント通りなら動くはず」
+**回避方法**: 
+- タスクファイル冒頭に確実性評価を記載
+  ```
+  確実性: low（理由: MCP接続の実例がない）
+  探索的実装: true
+  フォールバック: 従来APIを使用
+  ```
+- 確実性lowの場合、最初に最小限の動作確認コードを作成
+- 動作確認できたら本実装、できなければフォールバック実行
+
+### パターン5: 既存コード調査不足
+**症状**: 重複実装、アーキテクチャ不整合、結合時の障害
+**原因**: 実装前の既存コード理解不足
+**回避方法**: 
+- 実装前に類似機能の存在を必ず検索（同じドメイン、責務、設定パターンをキーワードに）
+- 類似機能を発見 → その実装を使用する（新規実装は行わない）
+- 類似機能が技術的負債 → ADRで改善提案を作成してから実装
+- 類似機能が存在しない → 既存の設計思想に沿って新規実装
+- すべての判断と根拠をDesign Docの「既存コードベース分析」セクションに記録
+
+## デバッグ手法
+
+### 1. エラー分析手順
+1. エラーメッセージ（最初の行）を正確に読む
+2. スタックトレースの最初と最後に注目
+3. 自分のコードが現れる最初の行を特定
+
+### 2. 5 Whys - 根本原因分析
+```
+症状: TypeScriptのビルドエラー
+Why1: 型定義が一致しない → Why2: インターフェースが更新された
+Why3: 依存関係の変更 → Why4: パッケージ更新の影響
+Why5: 破壊的変更を含むメジャーバージョンアップ
+根本原因: package.jsonでのバージョン指定が不適切
+```
+
+### 3. 最小再現コード
+問題を切り分けるため、最小限のコードで再現を試みる：
+- 関連のない部分を削除
+- モックで外部依存を置き換え
+- 問題が再現する最小構成を作成
+
+### 4. デバッグログ出力
+```typescript
+console.log('DEBUG:', {
+  context: 'user-creation',
+  input: { email, name },
+  state: currentState,
+  timestamp: new Date().toISOString()
+})
+```
+
+## 品質チェックコマンドリファレンス
+
+### Phase 1-3: 基本チェック
+```bash
+# Biome総合チェック（lint + format）
+npm run check
+
+# 未使用エクスポートの検出
+npm run check:unused
+
+# TypeScriptビルド
+npm run build
+```
+
+### Phase 4-6: テストと最終確認
+```bash
+# テスト実行
+npm test
+
+# カバレッジ測定（キャッシュクリア）
+npm run test:coverage:fresh
+
+# 全体統合チェック
+npm run check:all
+```
+
+### 補助コマンド
+```bash
+# カバレッジレポート確認
+open coverage/index.html
+
+# Vitestプロセスのクリーンアップ（テスト後必須）
+npm run cleanup:processes
+
+# 安全なテスト実行（自動クリーンアップ付き）
+npm run test:safe
+
+# 自動修正
+npm run format        # フォーマット修正
+npm run lint:fix      # Lint修正
+```
+
+### トラブルシューティング
+- **ポート使用中エラー**: `npm run cleanup:processes`
+- **キャッシュ問題**: `npm run test:coverage:fresh`
+- **依存関係エラー**: `npm ci`で再インストール
+
+## 技術的判断が必要な場面
+
+### 抽象化のタイミング
+- 具体的な実装を3回書いてからパターンを抽出
+- YAGNIを意識し、現在必要な機能のみ実装
+- 将来の拡張性より現在のシンプルさを優先
+
+### パフォーマンス vs 可読性
+- 明確なボトルネックがない限り可読性を優先
+- 計測してから最適化（推測するな、計測せよ）
+- 最適化する場合はコメントで理由を明記
+
+### 型定義の粒度
+- 過度に細かい型は保守性を低下させる
+- ドメインを適切に表現する型を設計
+- ユーティリティ型を活用して重複を削減
+
+## 継続的改善のマインドセット
+
+- **謙虚**: 完璧なコードは存在しない、フィードバック歓迎
+- **勇気**: 必要なリファクタリングは大胆に実行
+- **透明性**: 技術的な判断理由を明確に記録
+
+## 実装作業の完全性担保
+
+### 影響範囲調査の必須手順
+
+**完了定義**: 以下3段階すべての完了
+
+#### 1. 検索（Discovery）
+```bash
+Grep -n "TargetClass\|TargetMethod" -o content
+Grep -n "DependencyClass" -o content
+Grep -n "targetData\|SetData\|UpdateData" -o content
+```
+
+#### 2. 読解（Understanding）
+**必須**: 発見した全ファイルを読み込み、作業に必要な部分をコンテキストに含める：
+- 呼び出し元の目的と文脈
+- 依存関係の方向
+- データフロー: 生成→変更→参照
+
+#### 3. 特定（Identification）
+影響範囲の構造化報告（必須）：
+```
+## 影響範囲分析
+### 直接影響: ClassA、ClassB（理由明記）
+### 間接影響: SystemX、PrefabY（連携経路明記）
+### 処理フロー: 入力→処理1→処理2→出力
+```
+
+**重要**: 検索のみで完了とせず、3段階すべてを実行すること
+
+### 未使用コード削除ルール
+
+未使用コード検出時 → 使用予定？
+- Yes → 即実装（保留禁止）
+- No → 即削除（Git履歴に残る）
+
+対象: コード・ドキュメント・設定ファイル
+
+### 既存コード削除判断フロー
+
+```
+使用中？ No → 即削除（Git履歴に残る）
+      Yes → 動作？ No → 削除+再実装
+                  Yes → 修正
+```

package/docs/rules/architecture/implementation-approach.md

@@ -0,0 +1,136 @@
+# 実装戦略選択フレームワーク（メタ認知的アプローチ）
+
+## メタ認知的戦略選択プロセス
+
+### Phase 1: 現状の包括的分析
+
+**核心質問**: 「既存の実装はどうなっているのか？」
+
+#### 分析フレームワーク
+```yaml
+アーキテクチャ分析: 責務分離、データフロー、依存関係、技術的負債
+実装品質評価: コード品質、テストカバレッジ、パフォーマンス、セキュリティ
+歴史的文脈理解: 現在の形の理由、過去判断の妥当性、制約の変化、要求の進化
+```
+
+#### メタ認知質問リスト
+- この実装の真の責務は何か？
+- どの部分がビジネス本質で、どの部分が技術的制約由来か？
+- コードから明確でない依存関係や暗黙の前提条件は何か？
+- 現在の設計がもたらしている利点と制約は？
+
+### Phase 2: 戦略探索と創造
+
+**核心質問**: 「before → after を判断する時に、参考にすべき実装パターンや戦略は何なのか？」
+
+#### 戦略発見プロセス
+```yaml
+調査・探索: 技術スタック事例（WebSearch活用）、同種プロジェクト、OSS実装、文献・ブログ
+創造的思考: 戦略組み合わせ、制約前提設計、フェーズ分け、拡張ポイント設計
+```
+
+#### 参考戦略パターン（創造的組み合わせを推奨）
+
+**レガシー対応戦略**:
+- ストラングラーパターン: 段階的置換による漸進的移行
+- ファサードパターン: 統一インターフェースによる複雑性の隠蔽
+- アダプターパターン: 既存システムとの橋渡し
+
+**新規開発戦略**:
+- 機能駆動開発: ユーザー価値重視の縦断実装
+- 基盤駆動開発: 安定性重視の基盤優先構築
+- リスク駆動開発: 最大リスク要素から優先的に対処
+
+**統合・移行戦略**:
+- プロキシパターン: 透過的な機能拡張
+- デコレーターパターン: 既存機能の段階的強化
+- ブリッジパターン: 抽象化による柔軟性確保
+
+**重要**: 最適解は各プロジェクトの文脈に応じた創造的思考により発見される。
+
+### Phase 3: リスク評価とコントロール
+
+**核心質問**: 「既存の実装にそれを当てはめた時にどういうリスクが発生し、それをどうコントロールするのが最良なのか？」
+
+#### リスク分析マトリクス
+```yaml
+技術的リスク: 既存システム影響、データ整合性、パフォーマンス劣化、統合複雑性
+運用リスク: サービス可用性、デプロイダウンタイム、運用プロセス変更、切り戻し手順
+プロジェクトリスク: スケジュール遅延、技術習得コスト、品質達成度、チーム連携
+```
+
+#### リスクコントロール戦略
+```yaml
+予防的対策: 段階的移行、並行動作検証、統合・回帰テスト追加、監視設定
+発生時対応: 切り戻し手順、ログ・メトリクス準備、連絡体制定義、サービス継続手順
+```
+
+### Phase 4: 制約適合性検証
+
+**核心質問**: 「このプロジェクトの制約は何か？」
+
+#### 制約チェックリスト
+```yaml
+技術的制約: ライブラリ互換性、リソース容量、義務要件、数値目標
+時間的制約: 期限・優先度、依存関係、マイルストーン、学習期間
+リソース制約: チーム・スキル、作業時間・体制、予算、外部契約
+ビジネス制約: 市場投入時期、顧客影響、法規制・標準
+```
+
+### Phase 5: 実装アプローチ決定
+
+基本的な実装アプローチから最適解を選択（創造的組み合わせも推奨）：
+
+#### 垂直スライス（機能駆動）
+**特徴**: 機能単位で全層を縦断実装
+**適用条件**: 機能間の依存が少ない、ユーザーが利用可能な形で出力、アーキテクチャ全層への変更が必要
+**確認方法**: 各機能完成時のエンドユーザー価値提供
+
+#### 水平スライス（基盤駆動）  
+**特徴**: アーキテクチャ層別の段階的構築
+**適用条件**: 基盤システムの安定性が重要、複数機能が共通基盤に依存、層別の段階的確認が有効
+**確認方法**: 全基盤層完成時の統合動作確認
+
+#### ハイブリッド（創造的組み合わせ）
+**特徴**: プロジェクト特性に応じた柔軟な組み合わせ
+**適用条件**: 要件が明確でない、フェーズごとにアプローチ変更が必要、プロトタイピングから本格実装への移行
+**確認方法**: 各フェーズの目標に応じてL1/L2/L3の適切なレベルで確認
+
+### Phase 6: 判断根拠の文書化
+
+**Design Docでの記載**：実装戦略の選択理由と根拠を明記する。
+
+## 確認レベル定義
+
+各タスクの完了確認における優先順位：
+
+- **L1: 機能動作確認** - エンドユーザー機能として動作（例：検索実行可能）
+- **L2: テスト動作確認** - 新規テストが追加されパス（例：型定義テスト）  
+- **L3: ビルド成功確認** - コンパイルエラーなし（例：インターフェース定義）
+
+**優先順位**: L1 > L2 > L3 の順で確認可能性を重視
+
+## 統合ポイントの定義
+
+選択した戦略に応じて統合ポイントを定義：
+- **ストラングラー系**: 各機能の新旧システム切り替え時
+- **機能駆動**: ユーザーが実際に機能を利用可能になった時
+- **基盤駆動**: 全アーキテクチャ層が揃いE2Eテストが通った時
+- **ハイブリッド**: 各フェーズで定義した個別目標達成時
+
+## アンチパターン
+
+- **パターン固執**: リスト内の戦略のみで選択し、独自の組み合わせを検討しない
+- **分析不足**: Phase 1の分析フレームワークを飛ばして戦略選択  
+- **リスク軽視**: Phase 3のリスク分析マトリクスを省略して実装着手
+- **制約無視**: Phase 4の制約チェックリストを確認せず戦略決定
+- **根拠省略**: Phase 6の文書化テンプレートを使用せず戦略選択
+
+## メタ認知的実行のための指針
+
+1. **既知パターンの活用**: 出発点として参考し、創造的組み合わせを探索
+2. **WebSearch積極活用**: 同種技術スタックの実装事例を調査  
+3. **5 Whys適用**: 根本理由を追求し本質を把握
+4. **複数観点評価**: Phase 1-4の各観点から網羅的に評価
+5. **創造的思考**: 複数戦略の順序適用やプロジェクト固有の制約を活かした設計を検討
+6. **判断根拠明示**: 設計ドキュメントでの戦略選択根拠を明示化

package/docs/rules/documentation-criteria.md

@@ -0,0 +1,180 @@
+# ドキュメント作成基準
+
+## 作成判定マトリクス
+
+| 条件 | 必要ドキュメント | 作成順序 |
+|-----|--------------|---------|
+| 新機能追加 | PRD → [ADR] → Design Doc → 作業計画書 | PRD承認後 |
+| ADR条件該当（下記参照） | ADR → Design Doc → 作業計画書 | 即座に開始 |
+| 6ファイル以上 | ADR → Design Doc → 作業計画書（必須） | 即座に開始 |
+| 3-5ファイル | Design Doc → 作業計画書（推奨） | 即座に開始 |
+| 1-2ファイル | なし | 直接実装 |
+
+## ADR作成条件（いずれか該当で必須）
+
+### 1. 型システム変更
+- **3階層以上のネスト型追加**: `type A = { b: { c: { d: T } } }`
+  - 判断理由: 深いネストは複雑性が高く、影響範囲が広い
+- **3箇所以上で使用される型の変更・削除**
+  - 判断理由: 複数箇所への影響は慎重な判断が必要
+- **型の責務変更**（例: DTO→Entity）
+  - 判断理由: 概念モデルの変更は設計思想に関わる
+
+### 2. データフロー変更
+- **保存場所変更**（DB→ファイル、メモリ→キャッシュ）
+- **3ステップ以上の処理順序変更**
+  - 例: 「入力→検証→保存」から「入力→保存→非同期検証」
+- **データ受け渡し方法変更**（props→Context、直接参照→イベント）
+
+### 3. アーキテクチャ変更
+- レイヤー追加・責務変更・コンポーネント再配置
+
+### 4. 外部依存変更
+- ライブラリ・フレームワーク・外部API導入・置換
+
+### 5. 複雑な実装ロジック（規模に関わらず）
+- 3つ以上の状態を管理
+- 5つ以上の非同期処理の連携
+
+## 各ドキュメントの詳細定義
+
+### PRD（Product Requirements Document）
+
+**目的**: ビジネス要件とユーザー価値を定義
+
+**含むもの**:
+- ビジネス要件とユーザー価値
+- 成功指標とKPI（測定可能な形式）
+- ユーザーストーリーとユースケース
+- MoSCoW法による優先順位（Must/Should/Could/Won't）
+- MVPとFutureフェーズの分離
+- ユーザージャーニー図（必須）
+- スコープ境界図（必須）
+
+**含まないもの**:
+- 技術実装詳細（→Design Doc）
+- 技術選定理由（→ADR）
+- **実装フェーズ**（→作業計画書）
+- **タスク分解**（→作業計画書）
+
+### ADR（Architecture Decision Record）
+
+**目的**: 技術的決定の理由と背景を記録
+
+**含むもの**:
+- 決定事項（何を選択したか）
+- 根拠（なぜその選択をしたか）
+- 選択肢の比較（最低3案）とトレードオフ
+- アーキテクチャへの影響
+- 実装への原則的な指針（例:「依存性注入を使用」）
+
+**含まないもの**:
+- 実装スケジュール、期間（→作業計画書）
+- 実装手順の詳細（→Design Doc）
+- 具体的なコード例（→Design Doc）
+- 担当者の割り当て（→作業計画書）
+
+### Design Document
+
+**目的**: 技術的実装方法を詳細定義
+
+**含むもの**:
+- **既存コードベース分析**（必須）
+  - 実装パスマッピング（既存と新規の両方を記載）
+  - 統合点の明確化（新規実装でも既存との接続点を記載）
+- 技術的実装アプローチ（垂直/水平/ハイブリッド）
+- **技術的依存関係と実装制約**（実装の必要順序）
+- インターフェース定義と型定義
+- データフローとコンポーネント設計
+- **統合ポイントでのE2E確認手順**
+- **受入条件（測定可能な形式）**
+- 変更影響マップ（直接影響/間接影響/波及なしを明記）
+- 統合点の完全な列挙
+- データ契約の明確化
+- **合意事項チェックリスト**（関係者との合意内容）
+- **前提となるADR**（共通ADR含む）
+
+**必須構造要素**:
+```yaml
+変更影響マップ:
+  変更対象: [コンポーネント/機能]
+  直接影響: [ファイル/関数]
+  間接影響: [データ形式/処理時間]
+  波及なし: [影響を受けない機能]
+
+インターフェース変更マトリクス:
+  既存: [メソッド名]
+  新規: [メソッド名]
+  変換必要性: [あり/なし]
+  互換性確保: [方法]
+```
+
+**含まないもの**:
+- なぜその技術を選んだか（→ADR参照）
+- いつ実装するか、期間（→作業計画書）
+- 誰が実装するか（→作業計画書）
+
+### 作業計画書
+
+**目的**: 実装タスクの管理と進捗追跡
+
+**含むもの**:
+- **フェーズ構成**（Design Docの技術的依存関係を基に作成）
+- タスク分解と依存関係（最大2階層まで）
+- スケジュールと期間見積もり
+- **Design DocのE2E確認手順を各フェーズに配置**
+- **最終フェーズに品質保証を含む**（必須）
+- 進捗記録（チェックボックス形式）
+
+**含まないもの**:
+- 技術的な根拠（→ADR）
+- 設計の詳細（→Design Doc）
+- 技術的依存関係の決定（→Design Doc）
+
+**タスク完了定義の3要素**:
+1. **実装完了**: コードが動作する
+2. **品質完了**: テスト・型チェック・リントがパス
+3. **統合完了**: 他コンポーネントとの連携確認
+
+## 作成プロセス
+
+1. **問題分析**: 変更規模判定、ADR条件確認
+2. **ADR選択肢検討**（ADR時のみ）: 3案以上比較、トレードオフ明記
+3. **作成**: テンプレート使用、測定可能な条件記載
+4. **承認**: レビュー後「Accepted」で実装可
+
+## 保存場所
+
+| ドキュメント | パス | 命名規則 | テンプレート |
+|------------|-----|---------|------------|
+| PRD | `docs/prd/` | `[機能名]-prd.md` | `template-ja.md` |
+| ADR | `docs/adr/` | `ADR-[4桁]-[タイトル].md` | `template-ja.md` |
+| Design Doc | `docs/design/` | `[機能名]-design.md` | `template-ja.md` |
+| 作業計画書 | `docs/plans/` | `YYYYMMDD-{type}-{description}.md` | `template-ja.md` |
+
+※作業計画書は`.gitignore`で除外
+
+## ADRステータス
+`Proposed` → `Accepted` → `Deprecated`/`Superseded`/`Rejected`
+
+## AI自動化ルール
+- 5ファイル以上: ADR作成提案
+- 型・データフロー変更検出: ADR必須化
+- 既存ADR確認してから実装
+
+## 図表作成要件
+
+各ドキュメントで必須の図表（mermaid記法使用）：
+
+| ドキュメント | 必須図表 | 目的 |
+|------------|---------|-----|
+| PRD | ユーザージャーニー図、スコープ境界図 | ユーザー体験と範囲の明確化 |
+| ADR | 選択肢比較図（必要時） | トレードオフの視覚化 |
+| Design Doc | アーキテクチャ図、データフロー図 | 技術構造の理解 |
+| 作業計画書 | フェーズ構成図、タスク依存関係図 | 実装順序の明確化 |
+
+## 共通ADRとの関係性
+1. **作成時**: 共通技術領域（ログ、エラーハンドリング、非同期処理等）を特定し、既存共通ADRを参照
+2. **不足時**: 必要な共通ADRが存在しない場合は作成を検討
+3. **Design Doc**: 「前提となるADR」セクションで共通ADRを明記
+4. **準拠確認**: 設計が共通ADRの決定事項と整合しているかを検証

package/docs/rules/project-context.md

@@ -0,0 +1,38 @@
+# プロジェクトコンテキスト
+
+## 基本設定
+
+### プロジェクトの性質
+- **プロジェクト形態**: Claude Code専用TypeScriptプロジェクトテンプレート
+- **利用範囲**: プロジェクトの要件に応じて設定可能
+- **実装方針**: LLM主導実装、品質重視、YAGNI原則徹底
+
+### 技術スタック
+- **基盤技術**: TypeScript、Node.js
+- **テストフレームワーク**: Vitest
+- **品質管理**: Biome、TypeScript strict mode
+
+## 実装原則
+
+### 実装方針の特徴
+- **LLM主導実装**: Claude Codeが主要な実装者として機能
+- **品質重視**: 速度より品質を優先する文化
+- **YAGNI原則**: 必要になるまで実装しない
+- **体系的な設計**: ADR/Design Doc/作業計画書による設計プロセス
+
+## カスタマイズガイド
+
+新しいプロジェクトでこのテンプレートを使用する場合：
+
+1. **プロジェクト固有情報の追加**
+   - ターゲットユーザー特性
+   - ビジネス要件と制約
+   - 技術的制約事項
+
+2. **アーキテクチャの選択**
+   - `docs/rules/architecture/` から適切なパターンを選択
+   - `docs/rules/architecture/` にプロジェクト固有の設計を配置
+
+3. **環境設定**
+   - プロジェクトに適した環境変数管理方法の実装
+   - プロジェクト固有の設定ファイル追加