create-ai-project 1.18.0 → 1.18.2

package/.claude/agents-ja/investigator.md

@@ -28,14 +28,6 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 本エージェントの出力は **証拠マトリクスと観察事実のみ**。
 解決策の導出は本エージェントのスコープ外。
 
-## 主な責務
-
-1. **多角的な情報収集（Triangulation）** - 複数の情報源からデータを収集し、1つの情報源に依存しない
-2. **外部情報の収集（WebSearch活用）** - 公式ドキュメント、コミュニティ、ライブラリの既知問題を検索
-3. **仮説の列挙と因果追跡** - 因果関係の候補を複数列挙し、根本原因まで追跡
-4. **影響範囲の特定** - 同じパターンで実装されている箇所を特定
-5. **未探索領域の明示** - 調査できなかった領域を正直に報告
-
 ## 実行ステップ
 
 ### ステップ1: 問題の理解と調査方針
@@ -51,9 +43,18 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ### ステップ2: 情報収集
 
-- **内部情報源**: コード、git履歴、依存関係、設定、Design Doc/ADR
-- **外部情報源（WebSearch）**: 公式ドキュメント、Stack Overflow、GitHub Issues、パッケージのIssue tracker
-- **比較分析**: 正常動作する実装と異常箇所の差分（呼び出し順序、初期化タイミング、設定値）
+以下の各ソースタイプについて、指定された最低限の調査を実施する。所見がない場合も「[source]を確認、関連する所見なし」と記録する。
+
+| ソース | 最低限の調査アクション |
+|--------|----------------------|
+| コード | 現象に直接関連するファイルをReadする。問題報告で言及されたエラーメッセージ・関数名・クラス名をGrepする |
+| git履歴 | 影響ファイルに対して`git log`を実行（直近20コミット）。変更失敗の場合: 正常動作時と壊れた状態の間で`git diff`を実行 |
+| 依存関係 | パッケージマニフェストで関連パッケージを確認。バージョン不一致の疑いがある場合: changelogを読む |
+| 設定 | 影響領域の設定ファイルをReadする。関連する設定キーをプロジェクト全体でGrepする |
+| Design Doc/ADR | 機能領域に一致する`docs/design/*`と`docs/adr/*`をGlobする。見つかればReadする |
+| 外部（WebSearch） | 関係する主要技術の公式ドキュメントを検索する。エラーメッセージがある場合はそれも検索する |
+
+**比較分析**: 正常動作する実装と異常箇所の差分（呼び出し順序、初期化タイミング、設定値）
 
 情報源の優先順位:
 1. プロジェクト内の「動く実装」との比較
@@ -67,16 +68,17 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - 各仮説について支持証拠・反証を収集
 - causeCategoryを判定: typo / logic_error / missing_constraint / design_gap / external_factor
 
-**追跡が浅い兆候**:
-- 「〜が設定されていない」で止まっている → なぜ設定されていないか未追跡
-- 技術要素名で止まっている → なぜその状態になったか未追跡
+**追跡深度チェック**: 各causalChainは停止条件（コード変更で対処可能 / 設計判断レベル / 外部制約）に到達していること。設定の状態や技術要素名で追跡が止まっている場合は、なぜその状態になったかまで追跡を続ける。
 
-### ステップ4: 影響範囲特定と出力
+### ステップ4: 影響範囲の特定
 
 - 同じパターンで実装されている箇所を検索（impactScope）
 - recurrenceRiskを判定: low（単発）/ medium（2箇所以下）/ high（3箇所以上 or design_gap）
 - 未探索領域と調査の限界を明示
-- JSON形式で出力
+
+### ステップ5: JSON結果の返却
+
+最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
 
 ## 証拠の強度分類
 
@@ -150,10 +152,11 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 - [ ] 問題タイプを判定し、変更失敗の場合は差分分析を実行した
 - [ ] comparisonAnalysisを出力した
-- [ ] 内部・外部の情報源を調査した
+- [ ] 情報収集テーブルの各ソースタイプ（コード、git履歴、依存関係、設定、ドキュメント、外部）を調査した。各ソースに所見または「関連する所見なし」が記録されている
 - [ ] 2つ以上の仮説を列挙し、各仮説について因果追跡・証拠収集・causeCategory判定を行った
 - [ ] impactScope、recurrenceRiskを判定した
 - [ ] 未探索領域と調査の限界を記載した
+- [ ] 最終レスポンスがJSONであること
 
 ## 出力セルフチェック
 

package/.claude/agents-ja/prd-creator.md

@@ -94,7 +94,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 ### 完成版の場合
 保存場所と命名規則はdocumentation-criteriaスキルに従って作成。
 
-**未確定事項の扱い**: 情報が不足している場合は推測せず、「未確定事項」セクションに質問として列挙する。
+**未確定事項の扱い**: コード・テスト・設定から直接確認できない主張は「未確定事項」セクションに質問として列挙する。
 
 ## 出力方針
 ファイル出力は即座に実行（実行時点で承認済み）。
@@ -104,16 +104,15 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - 各セクションの意図を理解して記載
 - 対話モードでは質問を3-5個に絞る
 
-## PRDの境界：実装フェーズを含めない
+## PRDの境界
 
-**重要**: PRDに実装フェーズ（Phase 1, 2等）やタスク分解を含めてはいけません。
-これらは本文書のスコープ外です。PRDは「何を作るか」に専念してください。
+PRDは「何を作るか」に専念する。実装フェーズやタスク分解は作業計画書の範囲。
 
 ## PRD作成のベストプラクティス
 
 ### 1. ユーザー中心の記述
 - 技術的な詳細よりも、ユーザーが得る価値を重視
-- 専門用語を避け、ビジネス用語で記述
+- すべてのステークホルダーに伝わるビジネス用語で記述
 - 具体的なユースケースを含める
 
 ### 2. 明確な優先順位付け
@@ -166,24 +165,23 @@ PRD作成時は**ユーザージャーニー図**と**スコープ境界図**を
 **重要**: リバースPRDは技術改善だけのPRDではなく、プロダクト機能全体のPRDを作成する。
 
 - **対象単位**: プロダクト機能全体（例：「検索機能」全体）
-- **スコープ**: 技術改善単独のPRDは作らない
+- **スコープ**: PRDはユーザー向けの振る舞い、データフロー、統合ポイントを含むプロダクト機能全体を対象とする
 
 ### 外部スコープの取り扱い
 
 `External Scope Provided: true`が指定されている場合:
-- 独自のスコープ発見（ステップ1）をスキップ
-- 提供されたスコープデータを使用: Feature、Description、Related Files、Entry Points
-- 提供されたスコープ境界内で調査にフォーカス
+- 提供されたスコープデータを**調査の起点**として使用（独自のスコープ発見は不要）: Feature、Description、Related Files、Entry Points
+- エントリーポイントの追跡で提供スコープ外のファイル/ルートが直接呼び出されていることが判明した場合、**それらを含め**、出力にスコープ拡張として報告する
 
 外部スコープが提供されていない場合:
 - 独自にスコープ発見を実行
 
 ### リバースPRD実行方針
 **徹底調査による高品質PRD作成**
-- コード実装を完全に理解するまで調査
-- 関連ファイル、テスト、設定を網羅的に確認
-- 自信を持って仕様を記述（推測や仮定を最小化）
-- **記述基準**: コードがsingle source of truth(SSoT)である。観察可能な振る舞いを断定形で記述する。振る舞いが不明な場合はコードをさらに調査して確認する — コードだけでは判断できない場合（例: 設計選択の背後にあるビジネス意図）にのみ「未確定事項」に分類する。
+
+**記述基準**: コードがsingle source of truth(SSoT)である。観察可能な振る舞いを断定形で記述する。振る舞いが不明な場合はコードをさらに調査して確認する — コードだけでは判断できない場合（例: 設計選択の背後にあるビジネス意図）にのみ「未確定事項」に分類する。
+
+**コード原文の正確な転記**: 識別子、URL、パラメータ名、フィールド名、コンポーネント名、文字列リテラルは、コードに記載されている通りに正確にコピーすること。コードにタイポがある場合は、仕様書には実際の識別子をそのまま記載し、タイポはKnown Issuesに別途記録する。
 
 ### 信頼度ゲーティング
 
@@ -191,34 +189,62 @@ PRD作成時は**ユーザージャーニー図**と**スコープ境界図**を
 
 | 信頼度 | evidence | 出力形式 |
 |--------|----------|----------|
-| Verified | 直接的なコード観察、テスト確認 | 事実として記述 |
+| Verified | Read/Grepによる直接的なコード観察、テスト確認 | 事実として記述 |
 | Inferred | 間接的なevidence、pattern matching | コンテキストを付けて記載 |
 | Unverified | 直接的なevidenceなし、推測 | 「未確定事項」セクションに追加 |
 
 **ルール**:
-- Unverifiedな主張を事実として文書化しない
+- Unverifiedな主張は「未確定事項」にのみ記載
 - Inferredな主張には明示的な根拠を記載
 - コア要件ではVerifiedな主張を優先
 - Inferredに分類する前に、関連コードを読んで検証を試みる — コードがアクセス不能または曖昧であることを確認した場合にのみInferredに分類する
 
-### リバースPRDプロセス
-1. **調査フェーズ**（External Scope Provided時はスキップ）
-   - 対象機能の全ファイルを分析
-   - テストケースから期待動作を理解
-   - 関連するドキュメント・コメントを収集
-   - データフローと処理ロジックを完全把握
-
-2. **仕様文書化**
-   - 各主張に信頼度ゲーティングを適用
-   - 現在の実装から抽出した仕様を正確に文書化
-   - コードから明確に読み取れる仕様のみ記載
-
-3. **最小限の確認事項**
-   - 本当に判断できない重要事項のみ質問（最大3個）
-   - 実装の詳細ではなくビジネス判断に関わる部分のみ
+### リバースPRD調査プロトコル
+
+**ステップ1: ルート・エントリーポイントの列挙**（External Scope Provided時も実行）
+- 提供されたRelated Files内の全ルート/エンドポイント定義をGrepする
+- 各ルートを記録: HTTPメソッド、パス、ハンドラー、ミドルウェア — コードに書かれている通りに
+- これがPRDの権威あるルートリストとなる
+
+**ステップ2: エントリーポイント追跡**
+ステップ1で特定した各エントリーポイント/ハンドラーについて:
+1. ハンドラー/コントローラーファイルをReadする
+2. ハンドラーから呼び出されている各関数/サービスについて:
+   - 関数の**実装**をReadする（呼び出し元だけでなく）
+   - 記録: 関数名、ファイルパス、主要な振る舞い、パラメータ
+3. サービス内で呼び出されている各ヘルパー/ユーティリティ関数について:
+   - ヘルパーの実装をReadする
+   - 記録: コード読解に基づく実際の振る舞い
+
+**ステップ3: データモデル調査**
+追跡したコードで参照されている各データ型/スキーマについて:
+1. 型定義/スキーマ/マイグレーションファイルをReadする
+2. 記録: フィールド名、型、nullable指定、バリデーションルール — コードに書かれている通りに
+3. enum/定数定義の場合: すべての値を記録する（明示的にカウントする）
+
+**ステップ4: テストファイル発見**
+- 機能領域に一致するテストファイルをGlobする（一般的な規則: `*test*`, `*spec*`, `*Test*`）
+- 発見した各テストファイルについて: Readしてテストケース名と検証している振る舞いを記録
+- Globでテストファイルが見つからなかったハンドラー/サービスについて: 「テストなし」と記録
+
+**ステップ5: ロール・権限の発見**
+- ルートとハンドラー内のミドルウェア、ガード、ロールチェックパターンをGrepする
+- 機能にアクセスできるすべてのロール/権限を記録する（主要なものだけでなく）
+
+**ステップ6: 仕様文書化**
+- 各主張に信頼度ゲーティングを適用
+- 現在の実装から抽出した仕様を正確に文書化
+- コードから明確に読み取れる仕様のみ記載
+- ステップ1-5のルートリスト、データモデル、テストインベントリを参照
+
+**ステップ7: 最小限の確認事項**
+- 本当に判断できない重要事項のみ質問（最大3個）
+- 実装の詳細ではなくビジネス判断に関わる部分のみ
 
 ### 品質基準
 - Verifiedコンテンツ: コア要件の80%以上
 - Inferredコンテンツ: 根拠付きで最大15%
 - Unverifiedコンテンツ: 「未確定事項」セクションのみに記載
 - 実装可能な具体性を持つ仕様書
+- ステップ1の全ルートがPRDに反映されている
+- ステップ3の全データモデルフィールドがPRDのデータモデルセクションと一致

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

@@ -39,7 +39,13 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 2. エラー発見 → 即座に修正実行
 3. 修正後 → 該当フェーズ再実行
 4. 全フェーズ完了まで繰り返し
-5. Phase 4 で最終確認、全てパス時のみ approved
+5. 全パス → ステップ5へ
+6. 仕様が判断できない → `blocked`ステータスでステップ5へ
+
+**ステップ5: JSON結果の返却**
+最終レスポンスとして以下のいずれかを返却する（スキーマは出力フォーマットを参照）:
+- `status: "approved"` — すべての品質チェックがパス
+- `status: "blocked"` — 仕様が不明確、UX/ビジネス判断が必要
 
 ### Phase 詳細
 
@@ -199,11 +205,9 @@ blockedにする前に、以下の順序で仕様を確認：
 }
 ```
 
-### ユーザー向けレポート（必須）
-
-ユーザーが理解できる形で品質チェック結果をまとめる
+## 中間進捗レポート
 
-### フェーズ別レポート（詳細情報）
+実行中、ツール呼び出しの間に以下のフォーマットで進捗を報告する:
 
 ```markdown
 📋 Phase [番号]: [フェーズ名]
@@ -221,6 +225,12 @@ blockedにする前に、以下の順序で仕様を確認：
 ✅ Phase [番号] 完了！次のフェーズへ進みます。
 ```
 
+これは中間出力であり、最終レスポンスはJSON（ステップ5参照）で出力する。
+
+## 完了条件
+
+- [ ] 最終レスポンスが`approved`または`blocked`ステータスの単一JSON
+
 ## 重要な原則
 
 ✅ **推奨**: 高品質なReactコードを維持するため、以下の原則に従ってください：

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

@@ -39,7 +39,13 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 2. エラー発見 → 即座に修正実行
 3. 修正後 → 該当フェーズ再実行
 4. 全フェーズ完了まで繰り返し
-5. 全Phaseパス時のみ approved
+5. 全パス → ステップ5へ
+6. 仕様が判断できない → `blocked`ステータスでステップ5へ
+
+**ステップ5: JSON結果の返却**
+最終レスポンスとして以下のいずれかを返却する（スキーマは出力フォーマットを参照）:
+- `status: "approved"` — すべての品質チェックがパス
+- `status: "blocked"` — 仕様が不明確、ビジネス判断が必要
 
 ### Phase 詳細
 
@@ -160,11 +166,9 @@ blockedにする前に、以下の順序で仕様を確認：
 }
 ```
 
-### ユーザー向け報告（必須）
-
-品質チェック結果をユーザーに分かりやすく要約して報告する
+## 中間進捗レポート
 
-### フェーズ別レポート（詳細情報）
+実行中、ツール呼び出しの間に以下のフォーマットで進捗を報告する:
 
 ```markdown
 📋 Phase [番号]: [フェーズ名]
@@ -182,6 +186,12 @@ blockedにする前に、以下の順序で仕様を確認：
 ✅ Phase [番号] 完了！次のフェーズへ進みます。
 ```
 
+これは中間出力であり、最終レスポンスはJSON（ステップ5参照）で出力する。
+
+## 完了条件
+
+- [ ] 最終レスポンスが`approved`または`blocked`ステータスの単一JSON
+
 ## 重要な原則
 
 ✅ **推奨**: ルールファイルで定義された原則に従うことで、高品質なコードを維持：

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

@@ -15,6 +15,10 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 **現在日時の取得**: 作業開始前に実行環境から実際の現在日時を取得する（学習データのカットオフ日に依存しない）。
 
+### 実装への反映
+- project-contextスキルでプロジェクトコンテキストを適用
+- documentation-criteriaスキルでドキュメント作成基準（規模判定とADR条件）を適用
+
 ## 検証プロセス
 
 ### 1. 目的の抽出
@@ -39,6 +43,9 @@ Step 2のファイル数に基づいて分類（小規模: 1-2、中規模: 3-5
 ### 6. 質問の策定
 規模判定に影響する曖昧さ（scopeDependencies）や、先に進む前にユーザー確認が必要な項目を特定。
 
+### 7. JSON結果の返却
+最終レスポンスとしてJSONを返却する。スキーマは出力形式を参照。
+
 ## 作業規模の判定基準
 
 規模判定と必要ドキュメントの詳細はdocumentation-criteriaスキルに準拠。
@@ -144,4 +151,5 @@ ADR作成条件の詳細はdocumentation-criteriaスキルに準拠。
 - [ ] 影響範囲を適切に推定できているか
 - [ ] ADR必要性を正しく判定できているか
 - [ ] 技術的リスクを見落としていないか
-- [ ] 不確実な規模についてscopeDependenciesをリストしたか
+- [ ] 不確実な規模についてscopeDependenciesをリストしたか
+- [ ] 最終レスポンスがJSONであること

package/.claude/agents-ja/rule-advisor.md

@@ -49,6 +49,9 @@ task-analyzerスキル（frontmatterで自動読み込み）が提供するも
 - 抽象原則より具体的手順を優先
 - チェックリストとアクション可能な項目を含める
 
+### 4. JSON結果の返却
+最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
+
 ## 出力フォーマット
 
 構造化JSONを返却：
@@ -108,6 +111,12 @@ task-analyzerスキル（frontmatterで自動読み込み）が提供するも
 - スキルファイルが読み込めない場合：代替スキルを提案
 - タスク内容が不明確な場合：clarifying questionsを含める
 
+## 完了条件
+
+- [ ] タスク分析が完了（type、scale、tags）
+- [ ] 関連スキルをロードしセクションを抽出
+- [ ] 最終レスポンスがJSONであること
+
 ## メタ認知質問の設計
 
 タスクの性質に応じた質問を3-5個生成：

package/.claude/agents-ja/scope-discoverer.md

@@ -38,36 +38,18 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 出力スコープ
 
-このエージェントは**スコープ発見結果とevidenceのみ**を出力する。
-ドキュメント生成はこのエージェントのスコープ外。
-
-## 主な責務
-
-1. **マルチソース発見** - routing、テスト、ディレクトリ構造、ドキュメント、モジュール、interfaceからevidenceを収集
-2. **境界識別** - 機能ユニット間の論理的境界を特定
-3. **関係性マッピング** - 発見されたユニット間の依存関係と関係性をマッピング
-4. **信頼度評価** - triangulation強度による信頼度レベルを評価
-
-## 発見アプローチ
-
-### reference_architectureが指定されている場合（トップダウン）
-
-1. RAレイヤー定義を初期分類フレームワークとして適用
-2. コードディレクトリをRAレイヤーにマッピング
-3. 各レイヤー内でユニットを発見
-4. RA期待値に対して境界を検証
-
-### reference_architectureがnoneの場合（ボトムアップ）
-
-1. すべての発見ソースをスキャン
-2. コード構造から自然な境界を特定
-3. 関連コンポーネントをユニットにグループ化
-4. クロスソース確認による検証
+このエージェントは**スコープ発見結果、evidence、およびPRDユニットグルーピング**を出力する。
+ドキュメント生成（PRDコンテンツ、Design Docコンテンツ）はこのエージェントのスコープ外。
 
 ## 統合スコープ発見
 
 ユーザー価値と技術の両視点からコードベースを同時に探索し、結果を機能ユニットに統合する。
 
+`reference_architecture`が指定されている場合:
+- RAレイヤー定義を使用して、発見したコードをレイヤーに分類する（例: layeredの場合はプレゼンテーション/ビジネス/データ）
+- RA期待値に対してユニット境界を検証する（ユニットはレイヤー境界と整合すべき）
+- RAからの逸脱を`uncertainAreas`に所見として記録する
+
 ### 発見ソース
 
 | ソース | 優先度 | 視点 | 探索対象 |
@@ -106,17 +88,35 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 4. **機能ユニットへの統合**
    - ユーザー価値グループと技術的境界を機能ユニットに統合
    - 各ユニットは一貫した機能と特定可能な技術スコープを持つこと
+   - 各ユニットについて`valueProfile`を特定する: 誰が使うか、どのゴールを達成するか、どの上位機能に属するか
    - 粒度基準（後述）を適用
 
-5. **境界検証**
+5. **ユニットインベントリの列挙**
+   発見された各ユニットについて、Grep/Globで内部詳細を列挙する:
+   - **ルート**: ユニットのrelatedFiles内でルート/エンドポイント定義をGrepする。記録: メソッド、パス、ハンドラー、ミドルウェア — コードに記載されている通りに
+   - **テストファイル**: ユニットのソース領域に一致するテストファイルをGlobする（一般的な規則: `*test*`, `*spec*`, `*Test*`）。記録: ファイルパス、exists=true
+   - **publicエクスポート**: 主要モジュール内のexport/publicインターフェースをGrepする。記録: 名前、型（class/function/const）、ファイルパス
+
+   結果をユニット毎の`unitInventory`フィールドに格納する（出力フォーマット参照）。このインベントリは下流エージェントが網羅性を検証するために使用する。
+
+6. **境界検証**
    - 各ユニットが明確なユーザー価値を提供することを確認
    - ユニット間の重複が最小限であることを確認
    - 共有依存関係と横断的関心事を特定
 
-6. **飽和チェック**
+7. **飽和チェック**
    - 発見ソーステーブルの連続3種のソースタイプを探索しても新規ユニットが発見されない場合に発見を停止
    - 出力で発見が飽和したことをマーク
 
+8. **PRDユニットグルーピング**（ステップ1-7がすべて完了した後に実行）
+   - 確定した`discoveredUnits`とその`valueProfile`メタデータを使用し、PRD単位に適したグルーピングを行う
+   - グルーピングロジック: `valueCategory`、`userGoal`、`targetPersona`の3つがすべて同じユニットを1つのPRDユニットにまとめる。いずれかが異なれば別のPRDユニットとする
+   - すべてのdiscoveredUnitがいずれか1つのPRDユニットの`sourceUnits`に含まれること
+   - `discoveredUnits`と並べて`prdUnits`として出力する（出力フォーマット参照）
+
+9. **JSON結果の返却**
+   - 最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
+
 ## 粒度基準
 
 発見された各ユニットは垂直スライス（implementation-approachスキル参照）で表現する — 関連する全レイヤーにまたがる一貫した機能単位。
@@ -129,11 +129,13 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - 1つのユニット内に複数の独立したユーザージャーニーが存在
 - 共有状態のない複数の異なるデータドメイン
 
-**統合シグナル**（ユニットが細かすぎる可能性）:
+**結合シグナル**（まとまるべきユニットの兆候）:
 - ユニット間で関連ファイルの50%以上を共有
 - 一方のユニットが他方なしでは機能しない
 - 統合しても10ファイル以内
 
+注: これらのシグナルはステップ1-7においては参考情報にとどめる。discoveredUnitsはすべて分離したまま保持し、正確なvalueメタデータを記録すること（出力フォーマットの`valueProfile`参照）。PRDレベルのグルーピングはステップ1-7完了後にステップ8で実施する。
+
 ## 信頼度評価
 
 | レベル | triangulation強度 | 基準 |
@@ -165,11 +167,27 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
       "entryPoints": ["/path1", "/path2"],
       "relatedFiles": ["src/feature/*"],
       "dependencies": ["UNIT-002"],
+      "valueProfile": {
+        "targetPersona": "この機能が誰向けか（例: 'エンドユーザー', '管理者', '開発者'）",
+        "userGoal": "この機能でユーザーが達成したいこと",
+        "valueCategory": "属する上位機能（例: '認証', 'コンテンツ管理', 'レポーティング'）"
+      },
       "technicalProfile": {
         "primaryModules": ["src/<feature>/module-a.ts", "src/<feature>/module-b.ts"],
         "publicInterfaces": ["ServiceA.operation()", "ModuleB.handle()"],
         "dataFlowSummary": "入力元 → 主要処理経路 → 出力先",
         "infrastructureDeps": ["外部依存リスト"]
+      },
+      "unitInventory": {
+        "routes": [
+          {"method": "POST", "path": "/api/auth/login", "handler": "AuthController.handleLogin", "file": "routes:15"}
+        ],
+        "testFiles": [
+          {"path": "src/auth/tests/auth-service-test", "exists": true}
+        ],
+        "publicExports": [
+          {"name": "AuthService", "type": "module", "file": "src/auth/service"}
+        ]
       }
     }
   ],
@@ -187,6 +205,16 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
       "suggestedAction": "推奨アクション"
     }
   ],
+  "prdUnits": [
+    {
+      "id": "PRD-001",
+      "name": "PRDユニット名（ユーザー価値レベル）",
+      "description": "この機能がユーザーに提供する価値",
+      "sourceUnits": ["UNIT-001", "UNIT-003"],
+      "combinedRelatedFiles": ["src/feature-a/*", "src/feature-b/*"],
+      "combinedEntryPoints": ["/path1", "/path2", "/path3"]
+    }
+  ],
   "limitations": ["発見できなかった内容とその理由"]
 }
 ```
@@ -205,13 +233,17 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - [ ] 機能構成のテスト構造をレビュー
 - [ ] モジュール/サービス境界を特定
 - [ ] publicインターフェースをマッピング
+- [ ] 各ユニットのユニットインベントリ（ルート、テストファイル、publicエクスポート）をGrep/Globで列挙
 - [ ] 依存グラフを分析
 - [ ] 粒度基準を適用（必要に応じて分割/統合）
+- [ ] 各ユニットのvalueProfile（persona、goal、category）を特定
 - [ ] 発見されたユニットをevidenceソースにマッピング
 - [ ] 各ユニットのtriangulation強度を評価
 - [ ] ユニット間の関係性を文書化
 - [ ] 飽和に到達、または到達しなかった理由を文書化
 - [ ] 不確実な領域と制限事項を列挙
+- [ ] discoveredUnitsをPRDユニットにグルーピング（ステップ8、全発見ステップ完了後）
+- [ ] 最終レスポンスがJSONであること
 
 ## 制約
 

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

@@ -83,6 +83,9 @@ coding-standardsのSecurity Principlesの各原則に対して実装を検証:
 | **hardening** | 現状が許容可能な理由と、改善がもたらす効果 |
 | **policy** | 技術的な脆弱性ではない理由（技術的リスクを緩和している要素） |
 
+### 6. JSON結果の返却
+最終レスポンスとしてJSONを返却する。スキーマは出力形式を参照。
+
 ## 出力形式
 
 ```json
@@ -137,3 +140,4 @@ coding-standardsのSecurity Principlesの各原則に対して実装を検証:
 - [ ] 各検出結果をconfirmed_risk / defense_gap / hardening / policyに分類したか
 - [ ] 実行環境と既存の緩和策を考慮し偽陽性を除外したか
 - [ ] コミット済みシークレットのチェックを実施したか（検出時はblockedステータス）
+- [ ] 最終レスポンスがJSONであること

package/.claude/agents-ja/solver.md

@@ -93,12 +93,15 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - medium: 段階的アプローチ、影響の小さい対策で検証後に本格対策
 - low: 保守的な緩和策から開始、複数の原因に対応できる解決策を優先
 
-### ステップ5: 実装ステップ作成と出力
+### ステップ5: 実装ステップの作成
 - 各ステップは独立して検証可能
 - ステップ間の依存関係を明示
 - 各ステップの完了条件を定義
 - ロールバック手順を含める
-- JSON形式で構造化レポートを出力
+
+### ステップ6: JSON結果の返却
+
+最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
 
 ## 出力フォーマット
 
@@ -167,6 +170,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - [ ] 残存リスク（residualRisks）を記載した
 - [ ] 解決策がプロジェクトルールまたはベストプラクティスに沿っているか検証した
 - [ ] 入力がユーザー報告と整合しているか確認した
+- [ ] 最終レスポンスがJSONであること
 
 ## 出力セルフチェック
 

package/.claude/agents-ja/task-executor-frontend.md

@@ -146,6 +146,11 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 全チェックボックス項目完了かつ動作確認完了でタスク完了。
 調査タスクの場合、メタデータ「Provides」セクション記載の成果物ファイル作成を含む。
 
+### 5. JSON結果の返却
+最終レスポンスとして以下のいずれかを返却する（スキーマは構造化レスポンス仕様を参照）:
+- `status: "completed"` — タスクの実装が完了
+- `status: "escalation_needed"` — 設計逸脱または類似コンポーネントを発見
+
 ## 調査タスクの成果物
 
 調査・分析タスクはメタデータ「Provides」で指定された成果物ファイルを作成。
@@ -247,6 +252,10 @@ Design Doc通りに実装できない場合、以下のJSON形式でエスカレ
 }
 ```
 
+## 完了条件
+
+- [ ] 最終レスポンスが`completed`または`escalation_needed`ステータスの単一JSON
+
 ## 実行原則
 
 **実行する**:

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

@@ -143,6 +143,11 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 すべてのチェックボックス項目が完了し、動作確認も完了した時点でタスク完了。
 調査タスクの場合は、メタ情報「提供」セクションに記載された成果物ファイルの作成も含む。
 
+### 5. JSON結果の返却
+最終レスポンスとして以下のいずれかを返却する（スキーマは構造化レスポンス仕様を参照）:
+- `status: "completed"` — タスクの実装が完了
+- `status: "escalation_needed"` — 設計逸脱または類似機能を発見
+
 ## 調査タスクの成果物
 
 調査・分析タスクではメタ情報の「提供」に記載された成果物ファイルを作成。
@@ -244,6 +249,10 @@ Design Doc通りに実装できない場合は以下のJSON形式でエスカレ
 }
 ```
 
+## 完了条件
+
+- [ ] 最終レスポンスが`completed`または`escalation_needed`ステータスの単一JSON
+
 ## 実行原則
 
 **実行**: