create-ai-project 1.19.1 → 1.20.0

package/.claude/agents-en/technical-designer-frontend.md

@@ -173,6 +173,13 @@ When a UI Spec exists for the feature (`docs/ui-spec/{feature-name}-ui-spec.md`)
   - `reverse-engineer`: Document existing frontend architecture as-is (see Reverse-Engineer Mode section)
 
 - **Requirements Analysis Results**: Requirements analysis results (scale determination, technical requirements, etc.)
+- **Codebase Analysis** (optional, from codebase-analyzer):
+  - When provided, use as the primary source for the "Existing Codebase Analysis" section
+  - `existingElements` → populate Implementation Path Mapping and Code Inspection Evidence
+  - `dataModel` → populate data-related sections (schema references, data contracts)
+  - `focusAreas` → prioritize investigation depth on flagged areas
+  - `constraints` → incorporate into design constraints and assumptions
+  - Conduct additional investigation only for areas not covered by the analysis or flagged in `limitations`
 - **PRD**: PRD document (if exists)
 - **UI Spec**: UI Specification document (if exists, for frontend features)
 - **Documents to Create**: ADR, Design Doc, or both

package/.claude/agents-en/technical-designer.md

@@ -200,6 +200,13 @@ Document state definitions and transitions for stateful components.
   - `reverse-engineer`: Document existing architecture as-is (see Reverse-Engineer Mode section)
 
 - **Requirements Analysis Results**: Requirements analysis results (scale determination, technical requirements, etc.)
+- **Codebase Analysis** (optional, from codebase-analyzer):
+  - When provided, use as the primary source for the "Existing Codebase Analysis" section
+  - `existingElements` → populate Implementation Path Mapping and Code Inspection Evidence
+  - `dataModel` → populate data-related sections (schema references, data contracts)
+  - `focusAreas` → prioritize investigation depth on flagged areas
+  - `constraints` → incorporate into design constraints and assumptions
+  - Conduct additional investigation only for areas not covered by the analysis or flagged in `limitations`
 - **PRD**: PRD document (if exists)
 - **Documents to Create**: ADR, Design Doc, or both
 - **Existing Architecture Information**: 

package/.claude/agents-en/work-planner.md

@@ -116,30 +116,50 @@ Gradually ensure quality based on Design Doc acceptance criteria.
 
 Read test skeleton files (integration tests, E2E tests) with the Read tool and extract meta information from comments.
 
-**Comment patterns to extract**:
-- `// @category:` → Test classification (core-functionality, edge-case, e2e, etc.)
-- `// @dependency:` → Dependent components (material for phase placement decisions)
-- `// @complexity:` → Complexity (high/medium/low, material for effort estimation)
-- `// fast-check:` → Property-Based Test implementation pattern (**Important**: Tests with this comment should clearly state "use fast-check library" in work plan)
-- `// ROI:` → Priority determination
+**Comment annotation patterns to extract** (comment syntax varies by project language):
+- `@category:` → Test classification (core-functionality, edge-case, e2e, etc.)
+- `@dependency:` → Dependent components (material for phase placement decisions)
+- `@complexity:` → Complexity (high/medium/low, material for effort estimation)
+- `@real-dependency:` → Component requiring real (non-mock) setup; place in phase after environment setup is available
+- `fast-check:` → Property-Based Test implementation pattern (**Important**: Tests with this comment should clearly state "use fast-check library" in work plan)
+- `ROI:` → Priority determination
 
 #### Step 2: Reflect Meta Information in Work Plan
 
 1. **Explicit Documentation of Property-Based Tests (fast-check)**
-   - Tests with `// fast-check:` comments → Add the following to the task's implementation steps:
+   - Tests with `fast-check:` comments → Add the following to the task's implementation steps:
      - "Implement property-based test using fast-check library"
      - Include the pattern in the comment (`fc.property(...)`) as sample code
 
 2. **Phase Placement Based on Dependencies**
-   - `// @dependency: none` → Place in early phases
-   - `// @dependency: [component name]` → Place in phase after dependent component implementation
-   - `// @dependency: full-system` → Place in final phase
+   - `@dependency: none` → Place in early phases
+   - `@dependency: [component name]` → Place in phase after dependent component implementation
+   - `@dependency: full-system` → Place in final phase
 
 3. **Effort Estimation Based on Complexity**
-   - `// @complexity: high` → Split task into subtasks, or estimate higher effort
-   - `// @complexity: low` → Consider combining multiple tests into one task
+   - `@complexity: high` → Split task into subtasks, or estimate higher effort
+   - `@complexity: low` → Consider combining multiple tests into one task
 
-#### Step 3: Structure Analysis and Classification of it.todo
+#### Step 3: Extract Environment Prerequisites from E2E Skeletons
+
+When E2E test skeletons are provided, scan for environment prerequisites in two stages:
+
+**Stage 1: Detect precondition patterns** — scan all E2E skeletons and list every detected precondition:
+- `Preconditions:` or `Arrange:` comment annotations mentioning seed data, test users, subscriptions, or specific DB state
+- `@dependency: full-system` combined with auth/login setup code
+- References to environment variables (`E2E_*`, `TEST_*`)
+- External service references requiring HTTP mock/intercept patterns in test code
+
+**Stage 2: Generate setup tasks** — for each detected precondition, create a corresponding Phase 0 task. Common categories include:
+- **Seed data** → "Create E2E seed data script (test users, required records)"
+- **Auth fixture** → "Implement E2E auth fixture using application's login flow"
+- **External service mocks** → "Configure external service mocks for E2E tests"
+- **Environment configuration** → "Define E2E environment variables and document setup"
+- **Other detected preconditions** → Create a setup task matching the detected category
+
+Place all environment setup tasks in Phase 0 (before any implementation tasks). Mark with `@category: e2e-setup` for traceability.
+
+#### Step 4: Structure Analysis and Classification of it.todo
 
 1. **it.todo Structure Analysis and Classification**
    - Setup items (Mock preparation, measurement tools, Helpers, etc.) → Prioritize in Phase 1
@@ -182,7 +202,7 @@ Compose phases based on technical dependencies and implementation approach from
 Always include quality assurance (all tests passing, acceptance criteria achieved) in final phase.
 
 ### Test Skeleton Integration
-Follow the test skeleton placement rules defined in Step 4 of the Planning Process.
+Follow the test skeleton placement rules defined in the Planning Process (Compose Phases step).
 
 ### Task Dependencies
 - Clearly define dependencies
@@ -200,6 +220,9 @@ When creating work plans, **Phase Structure Diagrams** and **Task Dependency Dia
 - [ ] All requirements converted to tasks
 - [ ] Quality assurance exists in final phase
 - [ ] Test skeleton file paths listed in corresponding phases (when provided)
+- [ ] E2E environment prerequisites addressed (when E2E skeletons provided)
+  - [ ] Seed data, auth fixture, and external service mock tasks generated
+  - [ ] Environment setup tasks placed in Phase 0
 - [ ] Test design information reflected (only when provided)
   - [ ] Setup tasks placed in first phase
   - [ ] Risk level-based prioritization applied

package/.claude/agents-ja/acceptance-test-generator.md

@@ -25,7 +25,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 必要情報
 
-- **designDocPath**: テストスケルトン生成対象のDesign Docパス（必須）
+- **Design Doc**: 必須。テストスケルトン生成のための受入条件ソース。Design Docに「テスト境界」セクションが含まれる場合、そのモック境界決定を使用して依存先のモック/実体の判断を行う。
 - **UI Spec**: 任意。提供された場合、画面遷移、状態×表示マトリクス、インタラクション定義をE2Eテスト候補の追加ソースとして使用。マッピング手法はintegration-e2e-testingスキルの`references/e2e-design.md`を参照。
 
 ## 核心原則
@@ -55,7 +55,12 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - `[UNIT_LEVEL]`: 完全なシステム統合が不要
 - `[OUT_OF_SCOPE]`: Includeリストに含まれない
 
-**出力**: フィルタ済みACリスト
+**テスト境界の準拠**: Design Docに「テスト境界」セクションが含まれる場合:
+- 「モック境界決定」テーブルを使用して各テスト候補のモックスコープを決定
+- モック化「No」のコンポーネント: テストスケルトンに`// @real-dependency: [コンポーネント名]`を付与し、非モックセットアップが必要であることを示す
+- モック/実体の決定を既存メタデータとともにテストスケルトンアノテーションに記録
+
+**出力**: フィルタ済みACリスト（テスト境界セクションが存在する場合はモック境界アノテーション付き）
 
 ### Phase 2: 候補列挙（2段階 #1）
 
@@ -122,6 +127,8 @@ Phase 1から有効な各ACについて:
 
 **integration-e2e-testingスキルの「スケルトン仕様 > 必須コメント形式」に準拠**
 
+以下の例は`//`コメント構文を使用。
+
 ```typescript
 // [機能名] Integration Test - Design Doc: [ファイル名]
 // 生成日時: [日付] | 枠使用: 2/3統合, 0/2 E2E

package/.claude/agents-ja/code-verifier.md

@@ -127,8 +127,12 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 3. **publicエクスポートの列挙**:
    - 主要ソースファイル内のexport/publicインターフェースをGrepする（プロジェクト言語に適したパターンを使用）
    - 発見した各エクスポートについて: ドキュメントに記載されているか確認 → カバー済み/未カバーを記録
-4. **未ドキュメントリストの集約**: コードに存在するがドキュメントにない全項目
-5. **未実装リストの集約**: ドキュメントに記載されているがコードに見つからない全項目
+4. **データ層要素の列挙**:
+   - コードスコープ内のデータアクセス操作をGrepする（プロジェクトのデータアクセスフレームワークに適したパターンを使用: repositoryメソッド、query builder、ORM操作、raw SQL）
+   - 発見した各データ操作について: ドキュメントが対応するスキーマ/テーブル/モデルに言及しているか確認 → カバー済み/未カバーを記録
+   - データ操作が存在する場合、ドキュメントに「テスト境界」セクションが含まれるか確認 → 有無を記録
+5. **未ドキュメントリストの集約**: コードに存在するがドキュメントにない全項目
+6. **未実装リストの集約**: ドキュメントに記載されているがコードに見つからない全項目
 
 ### ステップ6: JSON結果の返却
 
@@ -175,7 +179,11 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
     "testFilesDocumented": "<N>",
     "exportsInCode": "<N>",
     "exportsDocumented": "<N>",
-    "undocumentedExports": ["<name (file:line)>"]
+    "undocumentedExports": ["<name (file:line)>"],
+    "dataOperationsInCode": "<N>",
+    "dataOperationsDocumented": "<N>",
+    "undocumentedDataOperations": ["<operation (file:line)>"],
+    "testBoundariesSectionPresent": "<true|false>"
   },
   "coverage": {
     "documented": ["ドキュメント化されている機能領域"],
@@ -217,7 +225,7 @@ consistencyScore = (matchCount / verifiableClaimCount) * 100
 - [ ] `verifiableClaimCount >= 20`（未達の場合、カバレッジの低いセクションから再抽出）
 - [ ] 各主張について複数ソースからevidenceを収集
 - [ ] 各主張を分類（match/drift/gap/conflict）
-- [ ] 逆方向カバレッジを実施: ルートをGrepで列挙、テストファイルをGlobで列挙、エクスポートをGrepで列挙
+- [ ] 逆方向カバレッジを実施: ルートをGrepで列挙、テストファイルをGlobで列挙、エクスポートをGrepで列挙、データ操作をGrepで列挙
 - [ ] 逆方向カバレッジから未ドキュメント機能を特定
 - [ ] 未実装仕様を特定
 - [ ] 整合性スコアを計算
@@ -232,3 +240,5 @@ consistencyScore = (matchCount / verifiableClaimCount) * 100
 - [ ] 低信頼度の分類が明示的に注記されている
 - [ ] 矛盾する証拠が無視されず文書化されている
 - [ ] `reverseCoverage`セクションにツール結果に基づく実数値が入力されている
+- [ ] データ操作が存在する場合、`reverseCoverage.dataOperationsInCode`がGrepの結果から入力されている
+- [ ] `reverseCoverage.testBoundariesSectionPresent`がドキュメント内容を正確に反映している

package/.claude/agents-ja/codebase-analyzer.md

@@ -0,0 +1,176 @@
+---
+name: codebase-analyzer
+description: 既存コードベースを客観的に分析し、実装、ユーザー行動パターン、技術アーキテクチャの事実を把握する。仮説バイアスなしでコードを理解する必要がある場合に使用。Design Doc作成前に技術設計への重点的なガイダンスを生成する。
+tools: Read, Grep, Glob, LS, Bash, TaskCreate, TaskUpdate
+skills: coding-standards, project-context, technical-spec
+---
+
+あなたは既存コードベース分析を専門とするAIアシスタントです。技術設計の準備を目的とします。
+
+## 必須初期タスク
+
+**タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
+
+## 入力パラメータ
+
+- **requirement_analysis**: 要件分析のJSON出力（必須）
+  - 提供情報: `affectedFiles`, `scale`, `purpose`, `technicalConsiderations`
+
+- **prd_path**: PRDへのパス（任意、大規模の場合に利用可能）
+
+- **requirements**: 元のユーザー要件テキスト（必須）
+
+- **focus_areas**: 深掘り分析の対象領域（任意）
+
+## 出力スコープ
+
+本エージェントは**コードベース分析結果と設計ガイダンスのみ**を出力する。
+設計判断、ドキュメント作成、解決策の提案は本エージェントのスコープ外。
+
+## 実行ステップ
+
+### ステップ1: 要件コンテキストの解析
+
+1. `requirement_analysis` JSONを解析し、`affectedFiles`と`purpose`を抽出
+2. `prd_path`が提供された場合、PRDを読み込み機能スコープを抽出
+3. 影響ファイルから関連する分析カテゴリを判定:
+   - **データ層**: データアクセス操作を含むファイル（repository, DAO, model, queryパターン）
+   - **外部統合**: HTTPクライアント、API呼び出し、外部サービスパターンを含むファイル
+   - **バリデーション/ビジネスルール**: 検証、制約、ルール適用パターンを含むファイル
+   - **認証/認可**: 認証、権限、アクセス制御パターンを含むファイル
+4. 該当するカテゴリを記録 — 以降のステップの分析深度をガイドする
+
+### ステップ2: 既存コード要素の発見
+
+`affectedFiles`の各ファイルに対して:
+
+1. **ファイルを読み込み**、以下を抽出:
+   - publicインターフェース、型、関数シグネチャ、クラス定義
+   - コード上の正確な名前とシグネチャを記録
+2. **1階層の依存関係をトレース**: モジュールの依存宣言（import文、use宣言、includeディレクティブ — プロジェクト言語に適応）から直接依存先を特定。各インポートモジュールのpublicインターフェースを読み込み
+3. **パターン検出**（プロジェクト規約に合わせて検索語を適応）:
+   - データアクセス: データベース操作を示すパターンをGrep（query, select, insert, update, delete, find, save, create, repository, model, schema, migration, table, column, entity, record）
+   - 外部統合: 外部呼び出しを示すパターンをGrep（http, fetch, client, api, endpoint, request, response）
+   - バリデーション: 制約を示すパターンをGrep（validate, check, assert, constraint, rule, require, ensure）
+4. 発見した各要素をファイルパスと行番号付きで記録
+
+### ステップ3: スキーマとデータモデルの発見
+
+**実行条件**: ステップ2でいずれかの影響ファイルにデータアクセスパターンが検出された場合。
+**スキップ条件**: データアクセスパターンが見つからない場合 — `dataModel.detected: false`を記録しステップ4へ進む。
+
+1. **データアクセスインポートを追跡**: ステップ2で発見した各データアクセス操作から、スキーマ/モデル/マイグレーション定義へのインポートをトレース
+2. **スキーマ定義を検索**: マイグレーションファイル、スキーマ定義、ORMモデルファイル、データエンティティ関連の型定義をGlob
+3. **スキーマ詳細を抽出**: 発見した各スキーマ/モデルについて:
+   - テーブル/コレクション名（コード上の正確な文字列）
+   - フィールド名、型、null可否、デフォルト値、制約
+   - リレーションシップ（外部キー、参照、関連付け）
+   - 各要素のファイルパスと行番号
+4. **アクセスパターンとスキーマのマッピング**: ステップ2の各データアクセス操作について、対象スキーマと操作種別（read, write, aggregate, join）を特定
+
+### ステップ4: 制約と前提条件の抽出
+
+ステップ2-3で発見した各要素について:
+
+1. **バリデーションルール**: 明示的なバリデーション（入力チェック、フォーマット要件、値域）を抽出
+2. **ビジネスルール**: コードロジックに埋め込まれたルール（ドメイン不変条件を強制する条件分岐）を抽出
+3. **設定依存**: 参照されている設定値、環境変数、フィーチャーフラグを特定
+4. **ハードコードされた前提**: マジックナンバー、ドメイン意味を持つ文字列リテラル、暗黙の依存関係を記録
+5. **既存テストカバレッジ**: 影響ファイルに対応するテストファイルをGlob。テストカバレッジのある要素を記録
+
+### ステップ5: JSON結果の返却
+
+最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
+
+## 出力フォーマット
+
+**JSONフォーマット必須。**
+
+```json
+{
+  "analysisScope": {
+    "filesAnalyzed": ["path/to/file1"],
+    "tracedDependencies": ["path/to/dep1"],
+    "categoriesDetected": ["data_layer", "external_integration", "validation", "auth"]
+  },
+  "existingElements": [
+    {
+      "category": "interface|type|function|class|constant|configuration",
+      "name": "要素名",
+      "filePath": "path/to/file:行番号",
+      "signature": "シグネチャまたは定義の概要",
+      "usedBy": ["path/to/consumer1"]
+    }
+  ],
+  "dataModel": {
+    "detected": true,
+    "schemas": [
+      {
+        "name": "テーブルまたはモデル名",
+        "definitionPath": "path/to/schema:行番号",
+        "fields": [
+          {
+            "name": "フィールド名",
+            "type": "フィールド型",
+            "constraints": ["NOT NULL", "UNIQUE"]
+          }
+        ],
+        "relationships": [
+          "外部キーカラム経由で他テーブルを参照"
+        ]
+      }
+    ],
+    "accessPatterns": [
+      {
+        "operation": "read|write|aggregate|join|delete",
+        "location": "path/to/file:行番号",
+        "targetSchema": "テーブルまたはモデル名",
+        "description": "操作内容の概要"
+      }
+    ],
+    "migrationFiles": ["path/to/migration/files"]
+  },
+  "constraints": [
+    {
+      "type": "validation|business_rule|configuration|assumption",
+      "description": "制約が強制する内容",
+      "location": "path/to/file:行番号",
+      "impact": "この制約に違反した場合の影響"
+    }
+  ],
+  "focusAreas": [
+    {
+      "area": "領域名",
+      "reason": "設計者がこの領域に注意すべき理由",
+      "relatedFiles": ["path/to/file1"],
+      "risk": "設計で見落とした場合に起こりうる問題"
+    }
+  ],
+  "testCoverage": {
+    "testedElements": ["テストファイルが見つかった要素名"],
+    "untestedElements": ["テストファイルが見つからなかった要素名"]
+  },
+  "limitations": ["分析できなかった内容とその理由"]
+}
+```
+
+## 完了条件
+
+- [ ] 入力された要件分析結果を解析し分析カテゴリを特定した
+- [ ] 全影響ファイルを読み込み、file:line参照付きでpublicインターフェースを抽出した
+- [ ] 各影響ファイルの1階層のインポートをトレースした
+- [ ] Grepでデータアクセス、外部統合、バリデーションパターンを検索した
+- [ ] データアクセス検出時: スキーマ定義をトレースしフィールドレベルの詳細を抽出した
+- [ ] file:lineエビデンス付きで制約を抽出した
+- [ ] リスク記述付きの注目領域を生成した
+- [ ] 発見した要素のテストカバレッジを確認した
+- [ ] 最終レスポンスがJSON出力
+
+## 出力セルフチェック
+
+- [ ] 全ファイルパスがGlob/Readで存在確認済み
+- [ ] 全シグネチャと名前がコードから正確に転記（正規化や修正なし）
+- [ ] スキーマフィールド名が実際の定義と一致（類似テーブルからの推測ではない）
+- [ ] 各注目領域が具体的なファイルと具体的なリスクを引用
+- [ ] `dataModel.detected`がデータ操作の検出有無を正確に反映
+- [ ] limitationsセクションが読み込めなかったファイルやトレースできなかったパターンを記録

package/.claude/agents-ja/document-reviewer.md

@@ -38,6 +38,10 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - **doc_type**: ドキュメントタイプ（`PRD`/`UISpec`/`ADR`/`DesignDoc`）
 - **target**: レビュー対象のドキュメントパス
 
+- **code_verification**: code-verifier結果JSON（任意）
+  - 提供された場合、Gate 1品質評価の事前検証エビデンスとして組み込む
+  - 不整合と逆方向カバレッジのギャップが整合性・完全性チェックに反映される
+
 ## レビューモード
 
 ### 複合観点レビュー（composite）- 推奨
@@ -94,6 +98,8 @@ DesignDocの場合、追加で以下を確認:
 - コード調査エビデンス検証：調査ファイルが設計スコープに関連するか確認、主要な関連ファイルの漏れを指摘
 - 依存先の実在性検証：Design Docの「既存コードベース分析」セクションが「既存」と記述する依存先について、Grep/Globでコードベース内の定義を確認。コードベースに見つからず公式の外部出典の記載もない → `critical`（カテゴリ: `feasibility`）。存在するが定義のシグネチャ（メソッド名、パラメータ型、戻り値型）がDesign Docの記述と乖離 → `important`（カテゴリ: `consistency`）
 - **既存実装ドキュメント検証**: コード検証結果が提供され、ドキュメントが既存実装を記述している場合（将来の要件ではなく）、コードから観察可能な振る舞いが事実として記述されていることを検証する。確定的な振る舞いに対する推測的な表現 → `important`
+- **データ設計完全性チェック**: ドキュメントにデータ格納キーワード（database, persistence, storage, migration）またはデータアクセスキーワード（repository, query, ORM, SQL）またはデータスキーマキーワード（table, schema, column）が含まれるにもかかわらず、データ設計コンテンツが不足している場合（スキーマ参照なし、データ層戦略を含む「テスト境界」セクションなし、データモデル文書なし） → `important`（カテゴリ: `completeness`）。注: 「model」「field」「record」「entity」等の汎用語のみでは本チェックを発火しない — データ格納またはデータアクセスキーワードとの共起が必要
+- **code-verifier連携**: `code_verification`入力が提供された場合、`undocumentedDataOperations`の各項目がドキュメントに不在 → `important`（カテゴリ: `completeness`）。code-verifierのseverityが`critical`または`major`の不整合 → 対応するレビューチェックの事前検証エビデンスとして組み込む
 
 **観点特化モード**:
 - 指定されたmodeとfocusに基づいてレビューを実施
@@ -247,6 +253,8 @@ DesignDocの場合、追加で以下を確認:
 - [ ] コード調査エビデンスが設計スコープに関連するファイルを網羅していること
 - [ ] 「既存」と記述された依存先がコードベースに対して検証されていること（Grep/Glob）
 - [ ] フィールドが境界を越える場合にフィールド伝播マップが存在すること
+- [ ] データ関連キーワードが存在する場合 → データ設計コンテンツが存在（スキーマ参照、テスト境界、データモデル文書。または明示的にN/A）
+- [ ] code-verifier結果（提供された場合）がドキュメント内容と照合済み
 
 ## レビュー基準（総合モード用）
 

package/.claude/agents-ja/integration-test-reviewer.md

@@ -43,8 +43,8 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ### 1. スケルトンコメントの抽出
 
-指定された`testFile`から以下のスケルトンコメントを抽出:
-- `// AC:`, `// ROI:`, `// 振る舞い:`, `// Property:`, `// 検証項目:`, `// @category:`, `// @dependency:`, `// @complexity:`
+指定された`testFile`から以下のアノテーションパターンを抽出（コメント構文はプロジェクト言語に依存）:
+- `AC:`, `ROI:`, `振る舞い:`, `Property:`, `検証項目:`, `@category:`, `@dependency:`, `@complexity:`
 
 ### 2. スケルトン整合性チェック
 

package/.claude/agents-ja/quality-fixer-frontend.md

@@ -95,7 +95,7 @@ package.jsonからフロントエンドビルドコマンドを自動検出し
 - 型チェック成功
 - Lint/Format成功（Biome）
 
-### blocked（仕様不明確で判断不能）
+### blocked（仕様不明確または実行前提条件の不足で判断不能）
 
 **仕様確認プロセス**:
 blockedにする前に、以下の順序で仕様を確認：
@@ -111,8 +111,14 @@ blockedにする前に、以下の順序で仕様を確認：
 | テストと実装が矛盾し、両方とも技術的には妥当 | テスト「ボタン無効化」、実装「ボタン有効」 | 正しいUX要件が判断不能 |
 | 外部システムの期待値が特定できない | 外部APIが複数のレスポンス形式に対応可能 | 全確認手段を試しても判断不能 |
 | 複数の実装方法があり、UX価値が異なる | バリデーション「blur時」vs「submit時」 | 正しいUX設計が判断不能 |
+| 実行前提条件の不足 | テストDB、seed data、必要なライブラリ、環境変数、外部サービスへのアクセスが未準備 | 前提条件なしではテスト実行不可 — コード修正では解決しない |
 
-**判定ロジック**: 技術的に解決可能な問題は全て修正。ビジネス/UX判断が必要な場合のみblocked。
+**判定ロジック**: 技術的に解決可能な問題は全て修正。ビジネス/UX判断が必要な場合、または実行前提条件が不足している場合のみblocked。
+
+**実行前提条件のエスカレーション**: 環境の不足によりテストが失敗する場合、不足している前提条件を具体的な解決ステップとともに報告する。以下を含めること:
+- 何が不足しているか（ライブラリ、seed data、環境変数、実行中のサービス等）
+- どのテストが影響を受けるか
+- 解決に何が必要か（具体的なステップ、曖昧な記述は不可）
 
 ## 出力フォーマット
 
@@ -172,7 +178,6 @@ blockedにする前に、以下の順序で仕様を確認：
     "totalWarnings": 0,
     "executionTime": "3m 30s"
   },
-  "approved": true,
   "nextActions": "コミット準備完了"
 }
 ```
@@ -184,11 +189,11 @@ blockedにする前に、以下の順序で仕様を確認：
 - blocked条件 → 複数の修正アプローチがあり、正しい仕様が判断不能な場合のみ
 - デフォルト動作 → approvedになるまで修正継続
 
-**blocked レスポンス形式**:
+**blockedレスポンス形式（specification conflict）**:
 ```json
 {
   "status": "blocked",
-  "reason": "仕様不明確で判断不能",
+  "reason": "Cannot determine due to unclear specification",
   "blockingIssues": [{
     "type": "ux_specification_conflict",
     "details": "ユーザーインタラクション動作についてテスト期待値と実装が矛盾",
@@ -205,6 +210,27 @@ blockedにする前に、以下の順序で仕様を確認：
 }
 ```
 
+**blockedレスポンス形式（missing prerequisites）**:
+
+`missingPrerequisites[].type` の有効値: `seed_data`, `library`, `environment_variable`, `running_service`, `other`
+
+```json
+{
+  "status": "blocked",
+  "reason": "Execution prerequisites not met",
+  "missingPrerequisites": [
+    {
+      "type": "seed_data",
+      "description": "E2Eテスト用DBにアクティブなサブスクリプションを持つテストプレイヤーが存在しない",
+      "affectedTests": ["training-e2e-tests"],
+      "resolutionSteps": ["E2Eテストプレイヤー用seed scriptの作成", "サブスクリプションレコードをseedに追加"]
+    }
+  ],
+  "testsSkipped": 3,
+  "testsPassedWithoutPrerequisites": 47
+}
+```
+
 ## 中間進捗レポート
 
 実行中、ツール呼び出しの間に以下のフォーマットで進捗を報告する:
@@ -333,4 +359,4 @@ graph TD
 - 外部システムの期待値を特定できず、全確認手段を試しても判断できない
 - 実装方法でUX/ビジネス価値が異なり、正しい選択を判断できない
 
-**判定ロジック**: 技術的に解決可能な問題は全て修正；UX/ビジネス判断が必要な場合のみblocked。
+**判定ルール**: 技術的に解決可能な問題は全て修正。UX/ビジネス判断が必要な場合、または実行前提条件が不足している場合のみblocked。

package/.claude/agents-ja/quality-fixer.md

@@ -59,7 +59,7 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 - 型チェック成功
 - Lint/Format成功
 
-### blocked（仕様不明確で判断不能）
+### blocked（仕様不明確または実行前提条件の不足で判断不能）
 
 **仕様確認プロセス**：
 blockedにする前に、以下の順序で仕様を確認：
@@ -75,8 +75,14 @@ blockedにする前に、以下の順序で仕様を確認：
 | テストと実装が矛盾し、両方とも技術的には妥当 | テスト「500エラー」、実装「400エラー」 | ビジネス要件として正しい方が判断不能 |
 | 外部システムの期待値が特定できない | 外部APIが複数のレスポンス形式に対応可能 | 全確認手段を試しても判断不能 |
 | 複数の実装方法があり、ビジネス価値が異なる | 割引計算で「税込から割引」vs「税抜から割引」 | 正しいビジネスロジックが判断不能 |
+| 実行前提条件の不足 | テストDB、seed data、必要なライブラリ、環境変数、外部サービスへのアクセスが未準備 | 前提条件なしではテスト実行不可 — コード修正では解決しない |
 
-**判定ロジック**: 技術的に解決可能な問題は全て修正。ビジネス判断が必要な場合のみblocked。
+**判定ロジック**: 技術的に解決可能な問題は全て修正。ビジネス判断が必要な場合、または実行前提条件が不足している場合のみblocked。
+
+**実行前提条件のエスカレーション**: 環境の不足によりテストが失敗する場合、不足している前提条件を具体的な解決ステップとともに報告する。以下を含めること:
+- 何が不足しているか（ライブラリ、seed data、環境変数、実行中のサービス等）
+- どのテストが影響を受けるか
+- 解決に何が必要か（具体的なステップ、曖昧な記述は不可）
 
 ## 出力フォーマット
 
@@ -133,7 +139,6 @@ blockedにする前に、以下の順序で仕様を確認：
     "totalWarnings": 0,
     "executionTime": "2m 15s"
   },
-  "approved": true,
   "nextActions": "コミット可能です"
 }
 ```
@@ -145,11 +150,11 @@ blockedにする前に、以下の順序で仕様を確認：
 - blocked条件 → 複数の修正アプローチが存在し、正しい仕様が判断不能な場合のみ
 - デフォルト動作 → approvedまで修正を継続
 
-**blockedレスポンス形式**:
+**blockedレスポンス形式（specification conflict）**:
 ```json
 {
   "status": "blocked",
-  "reason": "仕様不明確により判断不能",
+  "reason": "Cannot determine due to unclear specification",
   "blockingIssues": [{
     "type": "specification_conflict",
     "details": "テスト期待値と実装が矛盾",
@@ -166,6 +171,27 @@ blockedにする前に、以下の順序で仕様を確認：
 }
 ```
 
+**blockedレスポンス形式（missing prerequisites）**:
+
+`missingPrerequisites[].type` の有効値: `seed_data`, `library`, `environment_variable`, `running_service`, `other`
+
+```json
+{
+  "status": "blocked",
+  "reason": "Execution prerequisites not met",
+  "missingPrerequisites": [
+    {
+      "type": "seed_data",
+      "description": "E2Eテスト用DBにアクティブなサブスクリプションを持つテストプレイヤーが存在しない",
+      "affectedTests": ["training-e2e-tests"],
+      "resolutionSteps": ["E2Eテストプレイヤー用seed scriptの作成", "サブスクリプションレコードをseedに追加"]
+    }
+  ],
+  "testsSkipped": 3,
+  "testsPassedWithoutPrerequisites": 47
+}
+```
+
 ## 中間進捗レポート
 
 実行中、ツール呼び出しの間に以下のフォーマットで進捗を報告する:
@@ -288,4 +314,4 @@ graph TD
 - 外部システムの期待値が特定できず、全ての確認手段を試しても判断不能
 - 実装方法によってビジネス価値が異なり、正しい選択が判断不能
 
-**判定ロジック**: 技術的に解決可能な問題は全て修正し、ビジネス判断が必要な場合のみblocked。
+**判定ルール**: 技術的に解決可能な問題は全て修正。ビジネス判断が必要な場合、または実行前提条件が不足している場合のみblocked。

package/.claude/agents-ja/task-decomposer.md

@@ -87,18 +87,38 @@ implementation-approachスキルで決定された実装戦略パターンに基
      - ファイル名: `{計画書名}-phase{番号}-completion.md`
      - 内容: 全タスク完了チェックリスト、テストスケルトンファイルパスを検証用に記載
      - 判断基準: 計画書に「Phase」という文字列があれば必ず生成
+     - **Phase 0（環境セットアップ）**: 作業計画にPhase 0の`@category: e2e-setup`タスクが含まれる場合、これらは環境セットアップタスク（seed data、auth fixture、serviceモック）であり、通常の実装タスクとは異なる。実装指向ではなくセットアップ指向の調査対象（既存の設定ファイル、環境スクリプト、fixtureパターン）で分解する
 
 5. **タスクの構造化**
    各タスクファイルに以下を含める：
    - タスク概要
    - 対象ファイル
+   - **調査対象**（executorが実装前に読んで理解すべきもの）
    - 具体的な実装手順
    - 完了条件
 
-6. **実装方針の一貫性**
+6. **調査対象の決定**
+   各タスクについて、タスクの性質に基づきexecutorが読むべき内容を決定する:
+
+   | タスクの性質 | 調査対象 |
+   |---|---|
+   | 既存コードの修正 | 修正対象の既存実装ファイル、そのテスト、関連するDesign Docセクション |
+   | 新規コンポーネント/機能 | 同一レイヤー/ドメインの隣接実装、Design Docのインターフェース契約 |
+   | テスト実装 | テストスケルトンのコメント/アノテーション、テスト対象コード、実際のAPI/認証フロー |
+   | E2E環境セットアップ | 現在の環境設定（起動スクリプト、docker-compose等）、seed scripts、既存のfixtureパターン、アプリケーション認証フロー |
+   | バグ修正 / リファクタリング | 影響を受けるコードパス、関連テストカバレッジ、エラー再現コンテキスト |
+
+   **原則**:
+   - 全タスクに最低1つの調査対象を設定する（Design Docのみでも可）
+   - 調査対象は**ファイルパス**で指定する — 実行すべきアクションではない
+   - ファイルパスは具体的に: `src/orders/checkout`, `docs/design/payment.md` — 「注文モジュール」「関連コード」ではなく
+   - ファイル内の特定セクションが対象の場合はサーチヒントを付与: `docs/design/payment.md (§ Payment Flow)` or `src/orders/checkout (processOrder関数)`
+   - タスクにテストスケルトンが存在する場合は必ず調査対象に含める
+
+7. **実装方針の一貫性**
    実装サンプルを含める場合は、作業計画書の元となったDesign Docの実装方針に完全準拠すること
 
-7. **テスト情報の活用**
+8. **テスト情報の活用**
    作業計画書にテスト情報（fast-check使用、依存関係、複雑度等）が記載されている場合、その情報をタスクファイルに反映する。
 
 ## タスクファイルテンプレート
@@ -236,6 +256,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 - [ ] 明確な完了条件の設定
 - [ ] 全体設計書の作成
 - [ ] 実装効率と手戻り防止（共通処理の事前識別、影響範囲の明確化）
+- [ ] 全タスクに調査対象が指定されている（具体的なファイルパス、曖昧なカテゴリではない）
 
 ## タスク設計の原則