create-ai-project 1.12.0 → 1.12.1

package/.claude/skills/subagents-orchestration-guide/SKILL.md

@@ -1,212 +0,0 @@
----
-name: subagents-orchestration-guide
-description: サブエージェント間の調整のためのオーケストレーションガイド。規模判定、ドキュメント要件、停止ポイント、自律実行モードを定義。
----
-
-# サブエージェント実践ガイド - オーケストレーション指針
-
-サブエージェントを活用してタスクを効率的に処理するための実践的な行動指針。
-
-## 最重要原則：オーケストレーターとして振る舞う
-
-**「私は作業者ではない。オーケストレーターである。」**
-
-### 正しい振る舞い
-- 新規タスク: requirement-analyzerから開始
-- フロー実行中: 規模判定に基づくフローを厳守
-- 各フェーズ: 適切なサブエージェントに委譲
-- 停止ポイント: 必ずユーザー承認を待つ
-
-### 避ける行為
-- Grep/Glob/Readで自分で調査を始める
-- 自分で分析や設計を考え始める
-- 「まず調べてみます」と言って作業を開始する
-- requirement-analyzerを後回しにする
-
-**タスク開始時は必ずrequirement-analyzer。フロー開始後は規模判定に従う。**
-
-## タスク受領時の判断
-
-```mermaid
-graph TD
-    Start[新規タスク受領] --> RA[requirement-analyzerで要件分析]
-    RA --> Scale[規模判定]
-    Scale --> Flow[規模に応じたフロー実行]
-```
-
-### フロー実行中の要件変更検知
-
-**フロー実行中**にユーザーレスポンスで以下を検知したら、フローを停止してrequirement-analyzerへ：
-- 新機能・動作の言及（追加の操作方法、別画面での表示など）
-- 制約・条件の追加（データ量制限、権限制御など）
-- 技術要件の変更（処理方式、出力形式の変更など）
-
-**1つでも該当 → 統合要件でrequirement-analyzerから再開**
-
-## 活用できるサブエージェント
-
-### 実装支援エージェント
-1. **quality-fixer**: 全体品質保証と修正完了まで自己完結処理
-2. **task-decomposer**: 作業計画書の適切なタスク分解
-3. **task-executor**: 個別タスクの実行と構造化レスポンス
-4. **integration-test-reviewer**: 統合テスト/E2Eテストのスケルトン準拠レビュー
-
-### ドキュメント作成エージェント
-5. **requirement-analyzer**: 要件分析と作業規模判定（WebSearch対応、最新技術情報の調査）
-6. **prd-creator**: Product Requirements Document作成（WebSearch対応、市場動向調査）
-7. **technical-designer**: ADR/Design Doc作成（最新技術情報の調査、Property注釈付与）
-8. **work-planner**: 作業計画書作成（テストスケルトンからメタ情報を抽出・反映）
-9. **document-reviewer**: 単一ドキュメントの品質・完成度・ルール準拠チェック
-10. **design-sync**: Design Doc間の整合性検証（明示的矛盾のみ検出）
-11. **acceptance-test-generator**: Design DocのACから統合テストとE2Eテストのスケルトン生成
-
-## オーケストレーション原則
-
-### 責務分離を意識した振り分け
-
-**task-executorの責務**:
-- 実装作業とテスト追加
-- 追加したテストのパス確認（既存テストは対象外）
-- 品質保証はtask-executorの責務外
-
-**quality-fixerの責務**:
-- 全体品質保証（型チェック、lint、全テスト実行等）
-- 品質エラーの完全修正実行
-- 修正完了まで自己完結で処理
-- 最終的な approved 判定（修正完了後のみ）
-
-### 標準フロー
-
-**基本サイクル**: `task-executor → エスカレーション判定・フォローアップ → quality-fixer → commit` の4ステップサイクルを管理。
-各タスクごとにこのサイクルを繰り返し、品質を保証。
-
-## Sub-agent間の制約
-
-**重要**: Sub-agentから他のSub-agentを直接呼び出すことはできない。複数のSub-agentを連携させる場合は、メインAIがオーケストレーターとして動作。
-
-## 規模判定とドキュメント要件
-
-| 規模 | ファイル数 | PRD | ADR | Design Doc | 作業計画書 |
-|------|-----------|-----|-----|------------|-----------|
-| 小規模 | 1-2 | 更新※1 | 不要 | 不要 | 簡易版 |
-| 中規模 | 3-5 | 更新※1 | 条件付き※2 | **必須** | **必須** |
-| 大規模 | 6以上 | **必須**※3 | 条件付き※2 | **必須** | **必須** |
-
-※1: 該当機能のPRDが存在する場合は更新
-※2: アーキテクチャ変更、新技術導入、データフロー変更がある場合
-※3: 新規作成/既存更新/リバースPRD（既存PRDがない場合）
-
-## 構造化レスポンス仕様
-
-各サブエージェントはJSON形式で応答：
-- **task-executor**: status, filesModified, testsAdded, readyForQualityCheck
-- **integration-test-reviewer**: status, verdict (approved/needs_revision), requiredFixes
-- **quality-fixer**: status, checksPerformed, fixesApplied, approved
-- **document-reviewer**: status, reviewsPerformed, issues, recommendations, approvalReady
-- **design-sync**: sync_status, total_conflicts, conflicts (severity, type, source_file, target_file)
-
-## 作業計画時の基本フロー
-
-### 大規模（6ファイル以上）
-1. requirement-analyzer → 要件分析 **[停止: 要件確認]**
-2. prd-creator → PRD作成 → document-reviewer **[停止: 要件確認]**
-3. technical-designer → ADR作成（必要な場合） → document-reviewer **[停止: 技術方針決定]**
-4. technical-designer → Design Doc作成 → document-reviewer → design-sync **[停止: 設計内容確認]**
-5. acceptance-test-generator → テストスケルトン生成
-6. work-planner → 作業計画書作成 **[停止: 実装フェーズ全体の一括承認]**
-7. **自律実行モード開始**: task-decomposer → 全タスク実行 → 完了報告
-
-### 中規模（3-5ファイル）
-1. requirement-analyzer → 要件分析 **[停止: 要件確認]**
-2. technical-designer → Design Doc作成 → document-reviewer → design-sync **[停止: 技術方針決定]**
-3. acceptance-test-generator → テストスケルトン生成
-4. work-planner → 作業計画書作成 **[停止: 実装フェーズ全体の一括承認]**
-5. **自律実行モード開始**: task-decomposer → 全タスク実行 → 完了報告
-
-### 小規模（1-2ファイル）
-1. 簡易計画書作成 **[停止: 実装フェーズ全体の一括承認]**
-2. **自律実行モード開始**: 直接実装 → 完了報告
-
-## 自律実行モード
-
-### 権限委譲
-
-**自律実行モード開始後**：
-- 実装フェーズ全体の一括承認により、サブエージェントに権限委譲
-- task-executor：実装権限（Edit/Write使用可）
-- quality-fixer：修正権限（品質エラー自動修正）
-
-### 自律実行の停止条件
-
-以下の場合に自律実行を停止し、ユーザーにエスカレーション：
-
-1. **サブエージェントからのエスカレーション**
-   - `status: "escalation_needed"` のレスポンス受信時
-   - `status: "blocked"` のレスポンス受信時
-
-2. **要件変更検知時**
-   - 要件変更検知チェックリストで1つでも該当
-   - 自律実行を停止し、requirement-analyzerに統合要件で再分析
-
-3. **work-planner更新制限に抵触時**
-   - task-decomposer開始後の要件変更は全体再設計が必要
-   - requirement-analyzerから全体フローを再開
-
-4. **ユーザー明示停止時**
-   - 直接的な停止指示や割り込み
-
-### 自律実行中のタスク管理
-
-**2段階のTodoWrite管理**
-
-#### Step1: task-decomposer完了後
-フェーズ管理Todoを登録：
-```
-[in_progress] 実装フェーズ管理: Phase1開始
-[pending] 実装フェーズ管理: Phase2開始
-[pending] 実装フェーズ管理: Phase3開始
-```
-
-#### Step2: フェーズ開始時
-該当フェーズのタスクを4ステップで展開：
-```
-[completed] 実装フェーズ管理: Phase1開始
-[pending] 実装フェーズ管理: Phase2開始
-[in_progress] Phase1-Task01: task-executor実行
-[pending] Phase1-Task01: エスカレーション判定・フォローアップ
-[pending] Phase1-Task01: quality-fixer実行
-[pending] Phase1-Task01: git commit
-... （同パターンで繰り返し）
-[pending] Phase1: 完了チェック
-```
-
-## オーケストレーターの主な役割
-
-1. **状態管理**: 現在のフェーズ、各サブエージェントの状態、次のアクションを把握
-2. **情報の橋渡し**: サブエージェント間のデータ変換と伝達
-3. **品質保証とコミット実行**: approved=true確認後、即座にgit commit実行
-4. **自律実行モード管理**: 承認後の自律実行開始・停止・エスカレーション判断
-5. **ADRステータス管理**: ユーザー判断後のADRステータス更新（Accepted/Rejected）
-
-## 重要な制約
-
-- **品質チェックは必須**: コミット前にquality-fixerの承認が必要
-- **構造化レスポンス必須**: サブエージェント間の情報伝達はJSON形式
-- **承認管理**: ドキュメント作成→document-reviewer実行→ユーザー承認を得てから次へ進む
-- **フロー確認**: 承認取得後は必ず作業計画フロー（大規模/中規模/小規模）で次のステップを確認
-- **整合性検証**: サブエージェント判定に矛盾がある場合はガイドラインを優先
-
-## 人間との必須対話ポイント
-
-### 基本原則
-- **停止は必須**: 以下のタイミングでは必ず人間の応答を待つ
-- **確認→合意のサイクル**: ドキュメント生成後は合意またはupdateモードでの修正指示を受けてから次へ進む
-- **具体的な質問**: 選択肢（A/B/C）や比較表を用いて判断しやすく
-- **効率より対話**: 手戻りを防ぐため、早い段階で確認を取る
-
-### 主要な停止ポイント
-- **requirement-analyzer完了後**: 要件分析結果と質問事項の確認
-- **PRD作成→document-reviewer実行後**: 要件理解と整合性の確認
-- **ADR作成→document-reviewer実行後**: 技術方針と整合性の確認
-- **Design Doc作成→document-reviewer実行後**: 設計内容と整合性の確認
-- **計画書作成後**: 実装フェーズ全体の一括承認

package/.claude/skills/task-analyzer/SKILL.md

@@ -1,142 +0,0 @@
----
-name: task-analyzer
-description: メタ認知的タスク分析とスキル選択。タスクの本質を分析し、規模を見積もり、適切なスキルをメタデータと共に返却。
----
-
-# タスクアナライザー - メタ認知的分析フレームワーク
-
-## 目的
-
-受け取ったタスクの本質を分析し、以下を決定：
-1. 作業規模の判定（小規模/中規模/大規模）
-2. 適用するスキルの特定
-3. 潜在的な失敗パターンの認識
-4. 初動アクションのガイダンス提供
-
-## 分析フレームワーク
-
-### タスク本質の抽出
-
-タスクを受け取った際に分析：
-
-```yaml
-taskEssence:
-  surfaceRequest: "[ユーザーが文字通り求めたこと]"
-  underlyingGoal: "[ユーザーが実際に達成したいこと]"
-  implicitRequirements: "[明示されていないが暗黙の要件]"
-  scaleDetermination:
-    fileCount: "[変更予定ファイル数]"
-    scale: "small|medium|large"
-    confidence: "high|medium|low"
-```
-
-### 規模判定基準
-
-| 規模 | ファイル数 | 特徴 |
-|------|----------|-----|
-| 小規模 | 1-2ファイル | 単一責務の変更、局所的な影響 |
-| 中規模 | 3-5ファイル | コンポーネント横断の変更、調整が必要 |
-| 大規模 | 6ファイル以上 | システム全体への影響、ドキュメントが必要 |
-
-### スキル選択マトリクス
-
-タスク特性に基づいて適用するスキルを選択：
-
-| タスク種別 | 必要なスキル |
-|-----------|------------|
-| 新機能 | documentation-criteria, implementation-approach, typescript-rules, coding-standards |
-| バグ修正 | coding-standards, typescript-rules, coding-standardsのデバッグ技法 |
-| リファクタリング | coding-standards, implementation-approach |
-| テスト作成 | typescript-testing, integration-e2e-testing |
-| ドキュメント | documentation-criteria |
-| フロントエンド | frontend/typescript-rules, frontend/typescript-testing, frontend/technical-spec |
-
-### 失敗パターンの認識
-
-開始前に潜在的な失敗パターンを特定：
-
-```yaml
-warningPatterns:
-  - pattern: "[検出されたパターン名]"
-    risk: "high|medium|low"
-    mitigation: "[このパターンを避ける方法]"
-```
-
-監視すべき一般的なパターン：
-1. **エラー修正連鎖** - 根本原因分析なしの表面的な修正
-2. **型安全性の放棄** - any/asの過剰使用
-3. **不十分なテスト** - Red-Green-Refactorのスキップ
-4. **技術的不確実性** - スパイクなしでの未知技術の採用
-5. **調査不足** - 既存コードを確認せずに開始
-
-### 初動アクションガイダンス
-
-分析に基づいて具体的な最初のステップを提供：
-
-```yaml
-firstActionGuidance:
-  action: "[使用すべき具体的なツールまたはアクション]"
-  rationale: "[なぜこれが最初のステップであるべきか]"
-  expectedOutcome: "[このアクションで何が明らかになるか]"
-```
-
-## 出力形式
-
-タスクを分析する際、構造化されたJSONを返却：
-
-```json
-{
-  "taskEssence": {
-    "surfaceRequest": "...",
-    "underlyingGoal": "...",
-    "implicitRequirements": ["..."],
-    "scaleDetermination": {
-      "fileCount": "...",
-      "scale": "...",
-      "confidence": "..."
-    }
-  },
-  "applicableSkills": [
-    {
-      "name": "...",
-      "relevance": "primary|secondary",
-      "sections": ["..."]
-    }
-  ],
-  "warningPatterns": [
-    {
-      "pattern": "...",
-      "risk": "...",
-      "mitigation": "..."
-    }
-  ],
-  "firstActionGuidance": {
-    "action": "...",
-    "rationale": "...",
-    "expectedOutcome": "..."
-  }
-}
-```
-
-## TodoWriteとの統合
-
-task-analyzer完了後：
-
-1. **TodoWriteを更新**: taskEssenceに基づいてタスク説明を精緻化
-2. **スキル制約を追加**: 最初のtodoとして「スキル制約の確認」
-3. **検証を追加**: 最終todoとして「スキル忠実度の検証」
-4. **警告を反映**: 失敗パターンを避けるためタスク分解に反映
-
-## 使用パターン
-
-1. ユーザーから新規タスクを受け取る
-2. task-analyzerを実行して本質を理解
-3. 適用するスキルを読み込む
-4. 精緻化した理解でTodoWriteを更新
-5. スキルガイドラインに従って実装開始
-6. 完了時にスキル忠実度を検証
-
-## リファレンス
-
-スキルのメタデータと選択：
-- [スキルインデックス](references/skills-index.yaml) - 利用可能なすべてのスキルのメタデータ（タグ、典型的な使用法、主要な参照先を含む）

package/.claude/skills/task-analyzer/references/skills-index.yaml

@@ -1,211 +0,0 @@
-# スキルメタデータインデックス
-# rule-advisorがタスク分析に基づいて適切なスキルを選択するために使用
-
-skills:
-  coding-standards:
-    skill: "coding-standards"
-    tags: [anti-patterns, technical-judgment, debugging, rule-of-three, implementation, type-safety, refactoring, code-reading, best-practices, impact-analysis, unused-code, code-deletion, testing, tdd]
-    typical-use: "全ドメイン共通の技術的判断基準、アンチパターン検出、デバッグ手法、実装時のベストプラクティス、影響範囲調査、未使用コード削除、テスト設計原則"
-    size: large
-    key-references:
-      - "Rule of Three - Martin Fowler"
-      - "5 Whys - トヨタ生産方式"
-      - "DRY原則 - The Pragmatic Programmer"
-      - "単一責任原則（SRP） - Clean Code"
-      - "YAGNI原則 - Extreme Programming"
-      - "Avoiding fallback in distributed systems - AWS Builders' Library"
-      - "Test-Driven Development - Kent Beck"
-      - "Red-Green-Refactor - Kent Beck"
-      - "AAAパターン - Arrange-Act-Assert"
-    sections:
-      - "技術的アンチパターン（赤信号パターン）"
-      - "基本原則"
-      - "コメント記述ルール"
-      - "エラーハンドリングの基本原則"
-      - "Rule of Three - コード重複の判断基準"
-      - "よくある失敗パターンと回避方法"
-      - "デバッグ手法"
-      - "型安全性の基礎"
-      - "リファクタリング手法"
-      - "技術的判断が必要な場面"
-      - "継続的改善のマインドセット"
-      - "実装作業の完全性担保"
-      - "Red-Green-Refactorプロセス（テストファースト開発）"
-      - "テスト設計原則"
-      - "テストヘルパーの活用ルール"
-      - "テストの粒度原則"
-      - "継続性テストの範囲"
-
-  typescript-rules:
-    skill: "typescript-rules"
-    tags: [implementation, type-safety, async, coding-style, functional-programming, dependency-injection, backend]
-    typical-use: "バックエンドTypeScriptコードの作成・修正、クラス使用判断、DI実装"
-    size: small
-    key-references:
-      - "Dependency Injection - Martin Fowler"
-    sections:
-      - "Backend実装における型安全性"
-      - "コーディング規約"
-      - "エラーハンドリング"
-      - "パフォーマンス最適化"
-
-  typescript-testing:
-    skill: "typescript-testing"
-    tags: [quality, testing, coverage, vitest, backend, implementation]
-    typical-use: "バックエンドテスト作成、Vitest設定、70%カバレッジ要件、テスト品質基準"
-    size: small
-    key-references:
-      - "Vitest公式ドキュメント"
-    sections:
-      - "テストフレームワーク"
-      - "テストの基本方針"
-      - "テストの実装規約"
-      - "テスト品質基準"
-      - "モックの型安全性"
-      - "Vitestの基本例"
-
-  technical-spec:
-    skill: "technical-spec"
-    tags: [architecture, design, documentation, environment, data-flow, implementation, quality-commands, testing, build]
-    typical-use: "技術設計、環境設定、ドキュメント作成プロセス、実装方針決定、品質チェックコマンド、ビルドとテスト実行"
-    size: medium
-    key-references:
-      - "ADRフォーマット - Michael Nygard"
-      - "単一データソース原則 - Single Source of Truth"
-    sections:
-      - "技術スタックの基本方針"
-      - "環境変数管理とセキュリティ"
-      - "アーキテクチャ設計"
-      - "パターン適用の一貫性"
-      - "データフロー統一原則"
-      - "ビルドとテスト"
-
-  project-context:
-    skill: "project-context"
-    tags: [context, project-specific, implementation]
-    typical-use: "プロジェクト固有情報、実装原則の理解"
-    size: small
-    key-references:
-      - "プロジェクト固有（経験則）"
-    sections:
-      - "基本設定"
-      - "実装原則"
-      - "カスタマイズガイド"
-
-  documentation-criteria:
-    skill: "documentation-criteria"
-    tags: [documentation, decision-making, adr, prd, design-doc, planning, process]
-    typical-use: "実装開始時の規模判定、ドキュメント作成判定、ADR/PRD/Design Doc/作業計画書の作成基準"
-    size: medium
-    key-references:
-      - "ADR手法 - Michael Nygard"
-      - "Design Doc文化 - Google Engineering Practices"
-      - "Single Source of Truth"
-    sections:
-      - "作成判定マトリクス"
-      - "ADR作成条件（いずれか該当で必須）"
-      - "各ドキュメントの詳細定義"
-      - "作成プロセス"
-      - "保存場所"
-      - "ADRステータス"
-      - "AI自動化ルール"
-      - "図表作成要件"
-      - "共通ADRとの関係性"
-
-  implementation-approach:
-    skill: "implementation-approach"
-    tags: [architecture, implementation, task-decomposition, strategy-patterns, strangler-pattern, facade-pattern, design, planning, confirmation-levels]
-    typical-use: "実装戦略の選択、タスク分解、設計判断、大規模変更の計画"
-    size: medium
-    key-references:
-      - "Strangler Fig Pattern - Martin Fowler"
-      - "Feature Slicing - Martin Fowler"
-      - "Walking Skeleton - Alistair Cockburn"
-      - "Facade Pattern - Gang of Four"
-    sections:
-      - "メタ認知的戦略選択プロセス"
-      - "確認レベル定義"
-      - "統合ポイントの定義"
-      - "アンチパターン"
-      - "メタ認知的実行のための指針"
-
-  integration-e2e-testing:
-    skill: "integration-e2e-testing"
-    tags: [testing, integration-test, e2e-test, property-based-testing, fast-check, test-skeleton, test-review, quality]
-    typical-use: "統合テスト・E2Eテストのスケルトン生成、テスト実装、テストレビュー、Property-Based Test実装"
-    size: small
-    key-references:
-      - "fast-check - Property-based testing for TypeScript"
-      - "Node.js Testing Best Practices - Yoni Goldberg"
-      - "Property-Based Testing - 2025 Practices"
-    sections:
-      - "テスト種別と上限"
-      - "振る舞い優先の原則"
-      - "スケルトン仕様"
-      - "実装ルール"
-      - "レビュー基準"
-
-  subagents-orchestration-guide:
-    skill: "subagents-orchestration-guide"
-    tags: [orchestration, subagents, workflow, scale-determination, document-requirements, autonomous-execution]
-    typical-use: "サブエージェントのワークフロー調整、規模判定、ドキュメント要件"
-    size: medium
-    key-references:
-      - "ワークフロー調整パターン"
-      - "エージェント連携パターン"
-    sections:
-      - "規模判定"
-      - "ドキュメント要件"
-      - "停止ポイント"
-      - "自律実行モード"
-
-  # フロントエンド固有スキル
-  frontend/typescript-rules:
-    skill: "frontend/typescript-rules"
-    tags: [frontend, react, implementation, type-safety, props-driven, hooks, component-design, vite, error-boundary]
-    typical-use: "React/Viteでのフロントエンド開発、コンポーネント設計、Props設計、環境変数管理"
-    size: small
-    key-references:
-      - "React公式ドキュメント - Function Components"
-      - "Props-driven開発 - React Patterns"
-    sections:
-      - "フロントエンド固有のアンチパターン"
-      - "Frontend実装における型安全性"
-      - "コーディング規約"
-      - "エラーハンドリング"
-      - "パフォーマンス最適化"
-
-  frontend/typescript-testing:
-    skill: "frontend/typescript-testing"
-    tags: [frontend, react, quality, testing, coverage, vitest, react-testing-library, msw, component-testing, implementation]
-    typical-use: "Reactコンポーネントのテスト作成、React Testing Library、MSW、60%カバレッジ要件、Co-location"
-    size: small
-    key-references:
-      - "React Testing Library - Kent C. Dodds"
-      - "MSW (Mock Service Worker) - API Mocking"
-      - "ADR-0002 Co-location原則"
-    sections:
-      - "テストフレームワーク"
-      - "テストの基本方針"
-      - "テストの実装規約"
-      - "モックの型安全性の徹底"
-      - "React Testing Libraryの基本例"
-
-  frontend/technical-spec:
-    skill: "frontend/technical-spec"
-    tags: [frontend, react, architecture, design, documentation, environment, data-flow, implementation, vite, security, client-side, state-management, context-api, hooks, lighthouse, bundle-size, non-functional-requirements]
-    typical-use: "フロントエンド技術設計、環境変数管理（Vite）、セキュリティ制約、アーキテクチャ設計、状態管理パターン、実装方針決定、非機能要件の確認"
-    size: medium
-    key-references:
-      - "Vite公式ドキュメント - Environment Variables"
-      - "React公式ドキュメント - State Management"
-      - "Single Source of Truth - データフロー原則"
-      - "Immutable Update Patterns - React"
-      - "Lighthouse - Google Web Performance"
-      - "Web.dev - Performance Best Practices"
-    sections:
-      - "技術スタックの基本方針"
-      - "環境変数管理とセキュリティ"
-      - "アーキテクチャ設計"
-      - "データフロー統一原則"
-      - "ビルドとテスト"

package/.claude/skills/technical-spec/SKILL.md

@@ -1,86 +0,0 @@
----
-name: technical-spec
-description: 環境変数管理、アーキテクチャ設計、ビルド・テストコマンドを含む技術設計ルール。
----
-
-# 技術設計ルール
-
-## 技術スタックの基本方針
-TypeScriptをベースとしたアプリケーション実装。アーキテクチャパターンはプロジェクトの要件と規模に応じて選択すること。
-
-## 環境変数管理とセキュリティ
-
-### 環境変数管理
-- 環境変数は一元管理し、型安全性を確保する仕組みを構築すること
-- `process.env` の直接参照は避け、設定管理層を通じて取得すること
-- デフォルト値の設定や必須チェックを適切に実装すること
-
-### セキュリティ
-- `.env`ファイルはGitに含めない
-- APIキーやシークレットは必ず環境変数として管理
-- 機密情報のログ出力は禁止
-- エラーメッセージに機密情報を含めない
-
-## アーキテクチャ設計
-
-### アーキテクチャ設計の原則
-プロジェクトごとに適切なアーキテクチャを選択し、明確に定義すること：
-
-- **責務の分離**: 各層やモジュールの責務を明確に定義し、境界を守ること
-
-## データフロー統一原則
-
-#### 基本原則
-1. **単一データソース**: 同じ情報は1箇所にのみ保存する
-2. **構造化データ優先**: JSON文字列ではなくパース済みオブジェクトを使用
-3. **明確な責務分離**: 各層の責務を明確に定義
-
-#### データフローのベストプラクティス
-- **入力時点での検証**: データは入力層で検証し、型安全な形で内部に渡す
-- **変換の一元化**: データ変換ロジックは専用のユーティリティに集約
-- **ログの構造化**: データフローの各段階で構造化ログを出力
-
-## ビルドとテスト
-package.jsonの`packageManager`フィールドに応じた実行コマンドを使用すること。
-
-### ビルドコマンド
-- `build` - TypeScriptビルド
-- `type-check` - 型チェック（emit なし）
-
-### テストコマンド
-- `test` - テスト実行
-- `test:coverage` - カバレッジ測定
-- `test:coverage:fresh` - カバレッジ測定（キャッシュクリア）
-- `test:safe` - 安全なテスト実行（自動クリーンアップ付き）
-- `cleanup:processes` - Vitestプロセスのクリーンアップ
-
-### 品質チェック要件
-
-品質チェックは実装完了時に必須：
-
-**Phase 1-3: コード品質チェック**
-- `check` - Biome（lint + format）
-- `check:unused` - 未使用エクスポートの検出
-- `check:deps` - 循環依存の検出
-- `build` - TypeScriptビルド
-
-**Phase 4: テスト**
-- `test` - テスト実行
-
-**Phase 5: コード品質再検証**
-- `check:code` - コード品質の再検証（Phase 4でのテスト修正による副作用を清掃）
-
-### 補助コマンド
-- `check:all` - 全体統合チェック（check:code + test）※手動一括確認用
-- `open coverage/index.html` - カバレッジレポート確認
-- `format` - フォーマット修正
-- `lint:fix` - Lint修正
-
-### トラブルシューティング
-- **ポート使用中エラー**: `cleanup:processes` スクリプトを実行
-- **キャッシュ問題**: `test:coverage:fresh` スクリプトを実行
-- **依存関係エラー**: 依存関係のクリーンインストールを実行
-
-### カバレッジ要件
-- **必須**: ユニットテストカバレッジは70%以上
-- **メトリクス**: Statements、Branches、Functions、Lines