create-ai-project 1.18.0 → 1.18.1

package/.claude/agents-en/code-reviewer.md

@@ -75,11 +75,14 @@ Verify against the Design Doc architecture:
 - No unnecessary duplicate implementations (Pattern 5 from coding-standards skill)
 - Existing codebase analysis section includes similar functionality investigation results
 
-### 5. Calculate Compliance and Produce Report
+### 5. Calculate Compliance
 - Compliance rate = (fulfilled items + 0.5 × partially fulfilled items) / total AC items × 100
 - Compile all AC statuses, quality issues with specific locations
 - Determine verdict based on compliance rate
 
+### 6. Return JSON Result
+Return the JSON result as the final response. See Output Format for the schema.
+
 ## Output Format
 
 ```json
@@ -133,6 +136,13 @@ Verify against the Design Doc architecture:
    - Acknowledge good implementations
    - Present improvements as actionable items
 
+## Completion Criteria
+
+- [ ] All acceptance criteria individually evaluated
+- [ ] Compliance rate calculated
+- [ ] Verdict determined
+- [ ] Final response is the JSON output
+
 ## Escalation Criteria
 
 Recommend higher-level review when:

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

@@ -119,6 +119,10 @@ For each claim with collected evidence:
 2. **Implementation Coverage**: What percentage of specs are implemented?
 3. List undocumented features and unimplemented specs
 
+### Step 6: Return JSON Result
+
+Return the JSON result as the final response. See Output Format for the schema.
+
 ## Output Format
 
 **JSON format is mandatory.**
@@ -184,7 +188,7 @@ consistencyScore = (matchCount / verifiableClaimCount) * 100
 - [ ] Identified undocumented features in code
 - [ ] Identified unimplemented specifications
 - [ ] Calculated consistency score
-- [ ] Output in specified format
+- [ ] Final response is the JSON output
 
 ## Output Self-Check
 

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

@@ -112,13 +112,15 @@ Checklist:
 - [ ] If prior_context_count > 0: Each item has resolution status
 - [ ] If prior_context_count > 0: `prior_context_check` object prepared
 - [ ] Output is valid JSON
+- [ ] Final response is the JSON output
 
 Complete all items before proceeding to output.
 
-### Step 6: Review Result Report
-- Output results in JSON format according to perspective
+### Step 6: Return JSON Result
+- Use the JSON schema according to review mode (comprehensive or perspective-specific)
 - Clearly classify problem importance
 - Include `prior_context_check` object if prior_context_count > 0
+- Return the JSON result as the final response. See Output Format for the schema.
 
 ## Output Format
 

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

@@ -74,6 +74,9 @@ Verify the following for each test case:
 | Internal Components | Use actual | Unnecessary mocking |
 | Log Output Verification | Use vi.fn() | Mock without verification |
 
+### 4. Return JSON Result
+Return the JSON result as the final response. See Output Format for the schema.
+
 ## Output Format
 
 ### Structured Response
@@ -194,3 +197,10 @@ When needs_revision decision, output fix instructions usable in subsequent proce
 - IF `@dependency: full-system` → mock usage is FAILURE
 - Verify execution timing: AFTER all components are implemented
 - Verify critical user journey coverage is COMPLETE
+
+## Completion Criteria
+
+- [ ] All skeleton comments verified against implementation
+- [ ] Implementation quality evaluated
+- [ ] Mock boundaries verified (integration tests)
+- [ ] Final response is the JSON output

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

@@ -71,12 +71,15 @@ Information source priority:
 - Stopping at "~ is not configured" → without tracing why it's not configured
 - Stopping at technical element names → without tracing why that state occurred
 
-### Step 4: Impact Scope Identification and Output
+### Step 4: Impact Scope Identification
 
 - Search for locations implemented with the same pattern (impactScope)
 - Determine recurrenceRisk: low (isolated) / medium (2 or fewer locations) / high (3+ locations or design_gap)
 - Disclose unexplored areas and investigation limitations
-- Output in JSON format
+
+### Step 5: Return JSON Result
+
+Return the JSON result as the final response. See Output Format for the schema.
 
 ## Evidence Strength Classification
 
@@ -154,6 +157,7 @@ Information source priority:
 - [ ] Enumerated 2+ hypotheses with causal tracking, evidence collection, and causeCategory determination for each
 - [ ] Determined impactScope and recurrenceRisk
 - [ ] Documented unexplored areas and investigation limitations
+- [ ] Final response is the JSON output
 
 ## Output Self-Check
 

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

@@ -39,7 +39,13 @@ Use the appropriate run command based on the `packageManager` field in package.j
 2. Error found → Execute fix immediately
 3. After fix → Re-execute relevant phase
 4. Repeat until all phases complete
-5. Phase 4 final confirmation, approved only when all pass
+5. All pass → proceed to Step 5
+6. Cannot determine spec → proceed to Step 5 with `blocked` status
+
+**Step 5: Return JSON Result**
+Return one of the following as the final response (see Output Format for schemas):
+- `status: "approved"` — all quality checks pass
+- `status: "blocked"` — specification unclear, business judgment required
 
 ### Phase Details
 
@@ -198,11 +204,9 @@ Execute `test` script (run all tests with Vitest)
 }
 ```
 
-### User Report (Mandatory)
-
-Summarize quality check results in an understandable way for users
+## Intermediate Progress Report
 
-### Phase-by-phase Report (Detailed Information)
+During execution, report progress between tool calls using this format:
 
 ```markdown
 📋 Phase [Number]: [Phase Name]
@@ -220,6 +224,12 @@ Issues requiring fixes:
 ✅ Phase [Number] Complete! Proceeding to next phase.
 ```
 
+This is intermediate output only. The final response must be the JSON result (Step 5).
+
+## Completion Criteria
+
+- [ ] Final response is a single JSON with status `approved` or `blocked`
+
 ## Important Principles
 
 ✅ **Recommended**: Follow these principles to maintain high-quality React code:

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

@@ -39,7 +39,13 @@ Use the appropriate run command based on the `packageManager` field in package.j
 2. Error found → Execute fix immediately
 3. After fix → Re-execute relevant phase
 4. Repeat until all phases complete
-5. Approved only when all Phases pass
+5. All pass → proceed to Step 5
+6. Cannot determine spec → proceed to Step 5 with `blocked` status
+
+**Step 5: Return JSON Result**
+Return one of the following as the final response (see Output Format for schemas):
+- `status: "approved"` — all quality checks pass
+- `status: "blocked"` — specification unclear, business judgment required
 
 ### Phase Details
 
@@ -159,11 +165,9 @@ Refer to the "Quality Check Requirements" section in technical-spec skill for de
 }
 ```
 
-### User Report (Mandatory)
-
-Summarize quality check results in an understandable way for users
+## Intermediate Progress Report
 
-### Phase-by-phase Report (Detailed Information)
+During execution, report progress between tool calls using this format:
 
 ```markdown
 📋 Phase [Number]: [Phase Name]
@@ -181,6 +185,12 @@ Issues requiring fixes:
 ✅ Phase [Number] Complete! Proceeding to next phase.
 ```
 
+This is intermediate output only. The final response must be the JSON result (Step 5).
+
+## Completion Criteria
+
+- [ ] Final response is a single JSON with status `approved` or `blocked`
+
 ## Important Principles
 
 ✅ **Recommended**: Follow principles defined in skills to maintain high-quality code:

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

@@ -43,6 +43,9 @@ Identify constraints, risks, and dependencies. Use WebSearch to verify current t
 ### 6. Formulate Questions
 Identify any ambiguities that affect scale determination (scopeDependencies) or require user confirmation before proceeding.
 
+### 7. Return JSON Result
+Return the JSON result as the final response. See Output Format for the schema.
+
 ## Work Scale Determination Criteria
 
 Scale determination and required document details follow documentation-criteria skill.
@@ -148,4 +151,5 @@ This agent executes each analysis independently and does not maintain previous s
 - [ ] Have I properly estimated the impact scope?
 - [ ] Have I correctly determined ADR necessity?
 - [ ] Have I not overlooked technical risks?
-- [ ] Have I listed scopeDependencies for uncertain scale?
+- [ ] Have I listed scopeDependencies for uncertain scale?
+- [ ] Final response is the JSON output

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

@@ -49,6 +49,9 @@ From each skill:
 - Prioritize concrete procedures over abstract principles
 - Include checklists and actionable items
 
+### 4. Return JSON Result
+Return the JSON result as the final response. See Output Format for the schema.
+
 ## Output Format
 
 Return structured JSON:
@@ -108,6 +111,12 @@ Return structured JSON:
 - If skill file cannot be loaded: Suggest alternative skills
 - If task content unclear: Include clarifying questions
 
+## Completion Criteria
+
+- [ ] Task analysis completed with type, scale, and tags
+- [ ] Relevant skills loaded and sections extracted
+- [ ] Final response is the JSON output
+
 ## Metacognitive Question Design
 
 Generate 3-5 questions according to task nature:

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

@@ -38,8 +38,8 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 
 ## Output Scope
 
-This agent outputs **scope discovery results and evidence only**.
-Document generation is out of scope for this agent.
+This agent outputs **scope discovery results, evidence, and PRD unit grouping**.
+Document generation (PRD content, Design Doc content) is out of scope for this agent.
 
 ## Core Responsibilities
 
@@ -104,8 +104,9 @@ Explore the codebase from both user-value and technical perspectives simultaneou
    - Identify interface contracts
 
 4. **Synthesis into Functional Units**
-   - Merge user-value groups and technical boundaries into functional units
+   - Combine user-value groups and technical boundaries into functional units
    - Each unit should represent a coherent feature with identifiable technical scope
+   - For each unit, identify its `valueProfile`: who uses it, what goal it serves, and what high-level capability it belongs to
    - Apply Granularity Criteria (see below)
 
 5. **Boundary Validation**
@@ -117,6 +118,15 @@ Explore the codebase from both user-value and technical perspectives simultaneou
    - Stop discovery when 3 consecutive source types from the Discovery Sources table yield no new units
    - Mark discovery as saturated in output
 
+7. **PRD Unit Grouping** (execute only after steps 1-6 are fully complete)
+   - Using the finalized `discoveredUnits` and their `valueProfile` metadata, group units into PRD-appropriate units
+   - Grouping logic: units with the same `valueCategory` AND the same `userGoal` AND the same `targetPersona` belong to one PRD unit. If any of the three differs, the units become separate PRD units
+   - Every discovered unit must appear in exactly one PRD unit's `sourceUnits`
+   - Output as `prdUnits` alongside `discoveredUnits` (see Output Format)
+
+8. **Return JSON Result**
+   - Return the JSON result as the final response. See Output Format for the schema.
+
 ## Granularity Criteria
 
 Each discovered unit represents a Vertical Slice (see implementation-approach skill) — a coherent functional unit that spans all relevant layers.
@@ -129,11 +139,13 @@ Each discovered unit should satisfy:
 - Multiple independent user journeys within one unit
 - Multiple distinct data domains with no shared state
 
-**Merge signals** (units may be too granular):
+**Cohesion signals** (units that may belong together):
 - Units share >50% of related files
 - One unit cannot function without the other
 - Combined scope is still under 10 files
 
+Note: These signals are informational only during steps 1-6. Keep all discovered units separate and capture accurate value metadata (see `valueProfile` in Output Format). PRD-level grouping is performed in step 7 after discovery is complete.
+
 ## Confidence Assessment
 
 | Level | Triangulation Strength | Criteria |
@@ -165,6 +177,11 @@ Each discovered unit should satisfy:
       "entryPoints": ["/path1", "/path2"],
       "relatedFiles": ["src/feature/*"],
       "dependencies": ["UNIT-002"],
+      "valueProfile": {
+        "targetPersona": "Who this feature serves (e.g., 'end user', 'admin', 'developer')",
+        "userGoal": "What the user is trying to accomplish with this feature",
+        "valueCategory": "High-level capability this belongs to (e.g., 'Authentication', 'Content Management', 'Reporting')"
+      },
       "technicalProfile": {
         "primaryModules": ["src/<feature>/module-a.ts", "src/<feature>/module-b.ts"],
         "publicInterfaces": ["ServiceA.operation()", "ModuleB.handle()"],
@@ -187,6 +204,16 @@ Each discovered unit should satisfy:
       "suggestedAction": "What to do"
     }
   ],
+  "prdUnits": [
+    {
+      "id": "PRD-001",
+      "name": "PRD unit name (user-value level)",
+      "description": "What this capability delivers to the user",
+      "sourceUnits": ["UNIT-001", "UNIT-003"],
+      "combinedRelatedFiles": ["src/feature-a/*", "src/feature-b/*"],
+      "combinedEntryPoints": ["/path1", "/path2", "/path3"]
+    }
+  ],
   "limitations": ["What could not be discovered and why"]
 }
 ```
@@ -207,11 +234,14 @@ Includes additional fields:
 - [ ] Mapped public interfaces
 - [ ] Analyzed dependency graph
 - [ ] Applied granularity criteria (split/merge as needed)
+- [ ] Identified value profile (persona, goal, category) for each unit
 - [ ] Mapped discovered units to evidence sources
 - [ ] Assessed triangulation strength for each unit
 - [ ] Documented relationships between units
 - [ ] Reached saturation or documented why not
 - [ ] Listed uncertain areas and limitations
+- [ ] Grouped discovered units into PRD units (step 7, after all discovery steps complete)
+- [ ] Final response is the JSON output
 
 ## Constraints
 

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

@@ -83,6 +83,9 @@ Each finding must include a `rationale` field whose content depends on the categ
 | **hardening** | Why the current state is acceptable, and what improvement would add |
 | **policy** | Why this is not a technical vulnerability (what mitigates the technical risk) |
 
+### 6. Return JSON Result
+Return the JSON result as the final response. See Output Format for the schema.
+
 ## Output Format
 
 ```json
@@ -137,3 +140,4 @@ Each finding must include a `rationale` field whose content depends on the categ
 - [ ] Each finding classified into confirmed_risk / defense_gap / hardening / policy
 - [ ] False positives excluded considering runtime environment and existing mitigations
 - [ ] Committed secrets checked (blocked status if found)
+- [ ] Final response is the JSON output

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

@@ -93,12 +93,15 @@ Recommendation strategy based on confidence:
 - medium: Staged approach, verify with low-impact fixes before full implementation
 - low: Start with conservative mitigation, prioritize solutions that address multiple possible causes
 
-### Step 5: Implementation Steps Creation and Output
+### Step 5: Implementation Steps Creation
 - Each step independently verifiable
 - Explicitly state dependencies between steps
 - Define completion conditions for each step
 - Include rollback procedures
-- Output structured report in JSON format
+
+### Step 6: Return JSON Result
+
+Return the JSON result as the final response. See Output Format for the schema.
 
 ## Output Format
 
@@ -167,6 +170,7 @@ Recommendation strategy based on confidence:
 - [ ] Documented residual risks
 - [ ] Verified solutions align with project rules or best practices
 - [ ] Verified input consistency with user report
+- [ ] Final response is the JSON output
 
 ## Output Self-Check
 

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

@@ -146,6 +146,11 @@ Select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have u
 Task complete when all checkbox items completed and operation verification complete.
 For research tasks, includes creating deliverable files specified in metadata "Provides" section.
 
+### 5. Return JSON Result
+Return one of the following as the final response (see Structured Response Specification for schemas):
+- `status: "completed"` — task fully implemented
+- `status: "escalation_needed"` — design deviation or similar component discovered
+
 ## Research Task Deliverables
 
 Research/analysis tasks create deliverable files specified in metadata "Provides".
@@ -247,6 +252,10 @@ When discovering similar components/hooks during existing code investigation, es
 }
 ```
 
+## Completion Criteria
+
+- [ ] Final response is a single JSON with status `completed` or `escalation_needed`
+
 ## Execution Principles
 
 **Execute**:

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

@@ -146,6 +146,11 @@ Select and execute files with pattern `docs/plans/tasks/*-task-*.md` that have u
 Task complete when all checkbox items completed and operation verification complete.
 For research tasks, includes creating deliverable files specified in metadata "Provides" section.
 
+### 5. Return JSON Result
+Return one of the following as the final response (see Structured Response Specification for schemas):
+- `status: "completed"` — task fully implemented
+- `status: "escalation_needed"` — design deviation or similar function discovered
+
 ## Research Task Deliverables
 
 Research/analysis tasks create deliverable files specified in metadata "Provides".
@@ -247,6 +252,10 @@ When discovering similar functions during existing code investigation, escalate
 }
 ```
 
+## Completion Criteria
+
+- [ ] Final response is a single JSON with status `completed` or `escalation_needed`
+
 ## Execution Principles
 
 **Execute**:

package/.claude/agents-en/verifier.md

@@ -97,7 +97,11 @@ Classify each hypothesis by the following levels:
 - Example: "The implementation is wrong" → Was design_gap considered?
 - If inconsistent, explicitly note "Investigation focus may be misaligned with user report"
 
-**Conclusion**: Adopt unrefuted hypotheses as causes. When multiple causes exist, determine their relationship (independent/dependent/exclusive) and output in JSON format
+**Conclusion**: Adopt unrefuted hypotheses as causes. When multiple causes exist, determine their relationship (independent/dependent/exclusive)
+
+### Step 7: Return JSON Result
+
+Return the JSON result as the final response. See Output Format for the schema.
 
 ## Confidence Determination Criteria
 
@@ -186,6 +190,7 @@ Classify each hypothesis by the following levels:
 - [ ] Verified consistency with user report
 - [ ] Determined verification level for each hypothesis
 - [ ] Adopted unrefuted hypotheses as causes and determined relationship when multiple
+- [ ] Final response is the JSON output
 
 ## Output Self-Check
 

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

@@ -13,6 +13,12 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
 
+### 実装への反映
+- integration-e2e-testingスキルで統合/E2Eテストの原則と仕様を適用（最重要）
+- typescript-testingスキルでテスト設計基準（品質要件、テスト構造、命名規則）を適用
+- documentation-criteriaスキルでドキュメント基準（Design Doc/PRD構造、AC形式）を適用
+- project-contextスキルでプロジェクトコンテキスト（技術スタック、実装方針、制約）を適用
+
 ### 実装方針への準拠
 - **テストコード生成**: Design Docの実装パターン（関数 vs クラス選択）に厳密準拠必須
 - **型安全性**: typescript-testingスキルのモック作成・型定義ルールを例外なく強制

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

@@ -13,6 +13,12 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
 
+### 実装への反映
+- coding-standardsスキルで汎用的なコーディング規約、実装前の既存コード調査プロセスを適用
+- technical-specスキルで技術仕様を適用
+- typescript-rulesスキルでTypeScript開発ルールを適用
+- project-contextスキルでプロジェクトコンテキストを適用
+
 ## 主な責務
 
 1. **Design Doc準拠の検証**
@@ -69,11 +75,14 @@ Design Docのアーキテクチャに対して検証:
 - 不必要な重複実装がない（coding-standardsスキルのパターン5）
 - 既存コードベース分析セクションに類似機能調査結果が記載されている
 
-### 5. 準拠率の算出とレポート作成
+### 5. 準拠率の算出
 - 準拠率 = (fulfilled項目 + 0.5 × partially fulfilled項目) / 全AC項目 × 100
 - 全ACのステータス、具体的な場所を含む品質問題をまとめる
 - 準拠率に基づいてverdictを判定
 
+### 6. JSON結果の返却
+最終レスポンスとしてJSONを返却する。スキーマは出力形式を参照。
+
 ## 出力形式
 
 ```json
@@ -127,6 +136,13 @@ Design Docのアーキテクチャに対して検証:
    - 良い実装は積極的に評価
    - 改善点は具体的かつ実装可能な形で提示
 
+## 完了条件
+
+- [ ] すべてのACを個別に評価
+- [ ] 準拠率を算出
+- [ ] verdictを判定
+- [ ] 最終レスポンスがJSONであること
+
 ## エスカレーション基準
 
 以下の場合、上位レビューを推奨：

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

@@ -119,6 +119,10 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 2. **実装カバレッジ**: 仕様の何%が実装されているか？
 3. 未ドキュメント機能と未実装仕様を列挙
 
+### ステップ6: JSON結果の返却
+
+最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
+
 ## 出力フォーマット
 
 **JSONフォーマット必須**
@@ -184,7 +188,7 @@ consistencyScore = (matchCount / verifiableClaimCount) * 100
 - [ ] コード内の未ドキュメント機能を特定
 - [ ] 未実装仕様を特定
 - [ ] 整合性スコアを計算
-- [ ] 指定フォーマットで出力
+- [ ] 最終レスポンスがJSONであること
 
 ## 出力セルフチェック
 

package/.claude/agents-ja/design-sync.md

@@ -13,6 +13,11 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
 
+### 実装への反映
+- documentation-criteriaスキルでドキュメント基準（Design Docの構造と必須要素を理解するため）を適用
+- project-contextスキルでプロジェクトコンテキスト（用語と概念を理解するため）を適用
+- typescript-rulesスキルで型定義の整合性チェックを適用
+
 ## 検出基準（唯一の判定ルール）
 
 **検出対象**: 基準ファイルに明示的記載がある項目で、他ファイルと値が異なる場合

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

@@ -112,13 +112,15 @@ DesignDocの場合、追加で以下を確認:
 - [ ] prior_context_count > 0の場合: 各項目に解決ステータスあり
 - [ ] prior_context_count > 0の場合: `prior_context_check`オブジェクト準備済み
 - [ ] 出力が有効なJSON
+- [ ] 最終レスポンスがJSONであること
 
 全項目を完了してから出力へ進む。
 
-### ステップ6: レビュー結果の報告
-- 観点に応じたJSON形式で結果を出力
+### ステップ6: JSON結果の返却
+- レビューモード（総合的または観点別）に応じたJSONスキーマを使用
 - 問題の重要度を明確に分類
 - prior_context_count > 0の場合は`prior_context_check`オブジェクトを含める
+- 最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
 
 ## 出力フォーマット
 

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

@@ -13,6 +13,10 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
 
+### 実装への反映
+- integration-e2e-testingスキルで統合/E2Eテストのレビュー基準を適用（最重要）
+- typescript-testingスキルでテスト品質基準、AAA構造、モック規約を適用
+
 ## 必要情報
 
 - **testFile**: レビュー対象のテストファイルパス（必須）
@@ -70,6 +74,9 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 | 内部コンポーネント | 実物使用 | 不要なモック化 |
 | ログ出力検証 | vi.fn()使用 | 検証なしのモック |
 
+### 4. JSON結果の返却
+最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
+
 ## 出力フォーマット
 
 ### 構造化レスポンス
@@ -190,3 +197,10 @@ needs_revision判定時、後続処理で使用できる修正指示を出力:
 - `@dependency: full-system`の場合、モック使用は不合格
 - 全コンポーネント実装完了後に実行されているか確認
 - クリティカルユーザージャーニーの網羅性を検証
+
+## 完了条件
+
+- [ ] すべてのスケルトンコメントを実装と照合
+- [ ] 実装品質を評価
+- [ ] Mock境界を検証（統合テスト）
+- [ ] 最終レスポンスがJSONであること

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

@@ -71,12 +71,15 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - 「〜が設定されていない」で止まっている → なぜ設定されていないか未追跡
 - 技術要素名で止まっている → なぜその状態になったか未追跡
 
-### ステップ4: 影響範囲特定と出力
+### ステップ4: 影響範囲の特定
 
 - 同じパターンで実装されている箇所を検索（impactScope）
 - recurrenceRiskを判定: low（単発）/ medium（2箇所以下）/ high（3箇所以上 or design_gap）
 - 未探索領域と調査の限界を明示
-- JSON形式で出力
+
+### ステップ5: JSON結果の返却
+
+最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
 
 ## 証拠の強度分類
 
@@ -154,6 +157,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - [ ] 2つ以上の仮説を列挙し、各仮説について因果追跡・証拠収集・causeCategory判定を行った
 - [ ] impactScope、recurrenceRiskを判定した
 - [ ] 未探索領域と調査の限界を記載した
+- [ ] 最終レスポンスがJSONであること
 
 ## 出力セルフチェック
 

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,8 +38,8 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 出力スコープ
 
-このエージェントは**スコープ発見結果とevidenceのみ**を出力する。
-ドキュメント生成はこのエージェントのスコープ外。
+このエージェントは**スコープ発見結果、evidence、およびPRDユニットグルーピング**を出力する。
+ドキュメント生成（PRDコンテンツ、Design Docコンテンツ）はこのエージェントのスコープ外。
 
 ## 主な責務
 
@@ -106,6 +106,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 4. **機能ユニットへの統合**
    - ユーザー価値グループと技術的境界を機能ユニットに統合
    - 各ユニットは一貫した機能と特定可能な技術スコープを持つこと
+   - 各ユニットについて`valueProfile`を特定する: 誰が使うか、どのゴールを達成するか、どの上位機能に属するか
    - 粒度基準（後述）を適用
 
 5. **境界検証**
@@ -117,6 +118,15 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
    - 発見ソーステーブルの連続3種のソースタイプを探索しても新規ユニットが発見されない場合に発見を停止
    - 出力で発見が飽和したことをマーク
 
+7. **PRDユニットグルーピング**（ステップ1-6がすべて完了した後に実行）
+   - 確定した`discoveredUnits`とその`valueProfile`メタデータを使用し、PRD単位に適したグルーピングを行う
+   - グルーピングロジック: `valueCategory`、`userGoal`、`targetPersona`の3つがすべて同じユニットを1つのPRDユニットにまとめる。いずれかが異なれば別のPRDユニットとする
+   - すべてのdiscoveredUnitがいずれか1つのPRDユニットの`sourceUnits`に含まれること
+   - `discoveredUnits`と並べて`prdUnits`として出力する（出力フォーマット参照）
+
+8. **JSON結果の返却**
+   - 最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
+
 ## 粒度基準
 
 発見された各ユニットは垂直スライス（implementation-approachスキル参照）で表現する — 関連する全レイヤーにまたがる一貫した機能単位。
@@ -129,11 +139,13 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - 1つのユニット内に複数の独立したユーザージャーニーが存在
 - 共有状態のない複数の異なるデータドメイン
 
-**統合シグナル**（ユニットが細かすぎる可能性）:
+**結合シグナル**（まとまるべきユニットの兆候）:
 - ユニット間で関連ファイルの50%以上を共有
 - 一方のユニットが他方なしでは機能しない
 - 統合しても10ファイル以内
 
+注: これらのシグナルはステップ1-6においては参考情報にとどめる。discoveredUnitsはすべて分離したまま保持し、正確なvalueメタデータを記録すること（出力フォーマットの`valueProfile`参照）。PRDレベルのグルーピングはステップ1-6完了後にステップ7で実施する。
+
 ## 信頼度評価
 
 | レベル | triangulation強度 | 基準 |
@@ -165,6 +177,11 @@ 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()"],
@@ -187,6 +204,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": ["発見できなかった内容とその理由"]
 }
 ```
@@ -207,11 +234,14 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - [ ] publicインターフェースをマッピング
 - [ ] 依存グラフを分析
 - [ ] 粒度基準を適用（必要に応じて分割/統合）
+- [ ] 各ユニットのvalueProfile（persona、goal、category）を特定
 - [ ] 発見されたユニットをevidenceソースにマッピング
 - [ ] 各ユニットのtriangulation強度を評価
 - [ ] ユニット間の関係性を文書化
 - [ ] 飽和に到達、または到達しなかった理由を文書化
 - [ ] 不確実な領域と制限事項を列挙
+- [ ] discoveredUnitsをPRDユニットにグルーピング（ステップ7、全発見ステップ完了後）
+- [ ] 最終レスポンスが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
+
 ## 実行原則
 
 **実行**:

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

@@ -97,7 +97,11 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - 例:「実装がおかしい」→ design_gapを検討したか
 - 整合しない場合、「調査の焦点がユーザー報告とずれている可能性」を明示
 
-**結論**: 反証されなかった仮説を原因として採用し、複数の原因が存在する場合はその関係性（independent/dependent/exclusive）を判定してJSON形式で出力
+**結論**: 反証されなかった仮説を原因として採用し、複数の原因が存在する場合はその関係性（independent/dependent/exclusive）を判定
+
+### ステップ7: JSON結果の返却
+
+最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
 
 ## 信頼度の判定基準
 
@@ -186,6 +190,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - [ ] ユーザー報告との整合性を検証した
 - [ ] 各仮説の検証レベルを判定した
 - [ ] 反証されなかった仮説を原因として採用し、複数の場合は関係性を判定した
+- [ ] 最終レスポンスがJSONであること
 
 ## 出力セルフチェック
 

package/.claude/commands-en/reverse-engineer.md

@@ -39,7 +39,7 @@ Use AskUserQuestion to confirm:
 
 ```
 Phase 1: PRD Generation
-  Step 1: Scope Discovery (unified, single pass)
+  Step 1: Scope Discovery (unified, single pass → group into PRD units → human review)
   Step 2-5: Per-unit loop (Generation → Verification → Review → Revision)
 
 Phase 2: Design Doc Generation (if requested)
@@ -72,12 +72,14 @@ prompt: |
 **Quality Gate**:
 - At least one unit discovered → proceed
 - No units discovered → ask user for hints
+- `$STEP_1_OUTPUT.prdUnits` exists
+- All `sourceUnits` across `prdUnits` (flattened, deduplicated) match the set of `discoveredUnits` IDs — no unit missing, no unit duplicated
 
-**Human Review Point** (if enabled): Present discovered units for confirmation.
+**Human Review Point** (if enabled): Present `$STEP_1_OUTPUT.prdUnits` with their source unit mapping. The user confirms, adjusts grouping, or excludes units from scope. This is the most important review point — incorrect grouping cascades into all downstream documents.
 
 ### Step 2-5: Per-Unit Processing
 
-**FOR** each unit in `$STEP_1_OUTPUT.discoveredUnits` **(sequential, one unit at a time):**
+**FOR** each unit in `$STEP_1_OUTPUT.prdUnits` **(sequential, one unit at a time):**
 
 #### Step 2: PRD Generation
 
@@ -90,10 +92,10 @@ prompt: |
   Operation Mode: reverse-engineer
   External Scope Provided: true
 
-  Feature: $UNIT_NAME (from $STEP_1_OUTPUT)
-  Description: $UNIT_DESCRIPTION
-  Related Files: $UNIT_RELATED_FILES
-  Entry Points: $UNIT_ENTRY_POINTS
+  Feature: $PRD_UNIT_NAME (from $STEP_1_OUTPUT)
+  Description: $PRD_UNIT_DESCRIPTION
+  Related Files: $PRD_UNIT_COMBINED_RELATED_FILES
+  Entry Points: $PRD_UNIT_COMBINED_ENTRY_POINTS
 
   Skip independent scope discovery. Use provided scope data.
   Create final version PRD based on code investigation within specified scope.
@@ -113,7 +115,7 @@ prompt: |
 
   doc_type: prd
   document_path: $STEP_2_OUTPUT
-  code_paths: $UNIT_RELATED_FILES (from $STEP_1_OUTPUT)
+  code_paths: $PRD_UNIT_COMBINED_RELATED_FILES (from $STEP_1_OUTPUT)
   verbose: false
 ```
 
@@ -195,7 +197,9 @@ prompt: |
 
 ### Step 6: Design Doc Scope Mapping
 
-Use `$STEP_1_OUTPUT` (scope discovery results) directly. When fullstack=Yes, determine per unit whether backend / frontend / both Design Docs are needed based on path patterns in the unit's `relatedFiles` and `technicalProfile.primaryModules` (refer to project structure defined in technical-spec skill).
+**No additional discovery required.** Use `$STEP_1_OUTPUT.discoveredUnits` (implementation-granularity units) for technical profiles. Use `$STEP_1_OUTPUT.prdUnits[].sourceUnits` to trace which discovered units belong to each PRD unit.
+
+When fullstack=Yes, determine per unit whether backend / frontend / both Design Docs are needed based on path patterns in the unit's `relatedFiles` and `technicalProfile.primaryModules` (refer to project structure defined in technical-spec skill).
 
 Map `$STEP_1_OUTPUT` units to Design Doc generation targets, carrying forward:
 - `technicalProfile.primaryModules` → Primary Files

package/.claude/commands-en/update-doc.md

@@ -24,7 +24,7 @@ description: Update existing design documents (Design Doc / PRD / ADR) with revi
 ```
 Target document → [Stop: Confirm changes]
                         ↓
-              technical-designer / prd-creator (update mode)
+              technical-designer / technical-designer-frontend / prd-creator (update mode)
                         ↓
               document-reviewer → [Stop: Review approval]
                         ↓ (Design Doc only)
@@ -66,15 +66,20 @@ ls docs/design/*.md docs/prd/*.md docs/adr/*.md 2>/dev/null | grep -v template
 | Multiple candidates found | Present options with AskUserQuestion |
 | No documents found | Report and end (suggest /design instead) |
 
-### Step 2: Document Type Determination
+### Step 2: Document Type and Layer Determination
 
-Determine type from document path:
+Determine type from document path, then determine the layer to select the correct update agent:
 
 | Path Pattern | Type | Update Agent | Notes |
 |-------------|------|--------------|-------|
-| `docs/design/*.md` | Design Doc | technical-designer | - |
+| `docs/design/*.md` | Design Doc | technical-designer or technical-designer-frontend | See layer detection below |
 | `docs/prd/*.md` | PRD | prd-creator | - |
-| `docs/adr/*.md` | ADR | technical-designer | Minor changes: update existing file; Major changes: create new ADR file |
+| `docs/adr/*.md` | ADR | technical-designer or technical-designer-frontend | See layer detection below |
+
+**Layer detection** (for Design Doc and ADR):
+Read the document and determine its layer from content signals:
+- **Frontend** (→ technical-designer-frontend): Document title/scope mentions React, components, UI, frontend; or file contains component hierarchy, state management, UI interactions
+- **Backend** (→ technical-designer): All other cases (API, data layer, business logic, infrastructure)
 
 **ADR Update Guidance**:
 - **Minor changes** (clarification, typo fix, small scope adjustment): Update the existing ADR file

package/.claude/commands-ja/reverse-engineer.md

@@ -39,7 +39,7 @@ AskUserQuestionで以下を確認:
 
 ```
 フェーズ1: PRD生成
-  ステップ1: スコープ発見（統合、シングルパス）
+  ステップ1: スコープ発見（統合、シングルパス → PRDユニットグルーピング → 人間レビュー）
   ステップ2-5: ユニット毎ループ（生成 → 検証 → レビュー → 修正）
 
 フェーズ2: Design Doc生成（要求された場合）
@@ -72,12 +72,14 @@ prompt: |
 **品質ゲート**:
 - 1つ以上のユニットが発見された → 続行
 - ユニットが発見されない → ユーザーにヒントを求める
+- `$STEP_1_OUTPUT.prdUnits`が存在すること
+- `prdUnits`全体の`sourceUnits`を結合・重複除去した集合が`discoveredUnits`のID集合と一致すること — 欠落や重複がないこと
 
-**人間レビューポイント**（有効時）: 発見されたユニットを確認用に提示。
+**人間レビューポイント**（有効時）: `$STEP_1_OUTPUT.prdUnits`とソースユニットのマッピングを提示する。ユーザーはグルーピングの確認、調整、またはスコープからの除外を行う。これは最も重要なレビューポイント — グルーピングの誤りはすべての下流ドキュメントに波及する。
 
 ### ステップ2-5: ユニット毎の処理
 
-**FOR** `$STEP_1_OUTPUT.discoveredUnits`の各ユニット **（逐次実行、1ユニットずつ）**:
+**FOR** `$STEP_1_OUTPUT.prdUnits`の各ユニット **（逐次実行、1ユニットずつ）**:
 
 #### ステップ2: PRD生成
 
@@ -90,10 +92,10 @@ prompt: |
   動作モード: reverse-engineer
   External Scope Provided: true
 
-  機能: $UNIT_NAME ($STEP_1_OUTPUTより)
-  説明: $UNIT_DESCRIPTION
-  関連ファイル: $UNIT_RELATED_FILES
-  エントリーポイント: $UNIT_ENTRY_POINTS
+  機能: $PRD_UNIT_NAME ($STEP_1_OUTPUTより)
+  説明: $PRD_UNIT_DESCRIPTION
+  関連ファイル: $PRD_UNIT_COMBINED_RELATED_FILES
+  エントリーポイント: $PRD_UNIT_COMBINED_ENTRY_POINTS
 
   独自のスコープ発見をスキップ。提供されたスコープデータを使用。
   指定スコープ内でのコード調査に基づき最終版PRDを作成。
@@ -113,7 +115,7 @@ prompt: |
 
   doc_type: prd
   document_path: $STEP_2_OUTPUT
-  code_paths: $UNIT_RELATED_FILES ($STEP_1_OUTPUTより)
+  code_paths: $PRD_UNIT_COMBINED_RELATED_FILES ($STEP_1_OUTPUTより)
   verbose: false
 ```
 
@@ -195,7 +197,9 @@ prompt: |
 
 ### ステップ6: Design Docスコープマッピング
 
-`$STEP_1_OUTPUT`（スコープ発見結果）をそのまま使用する。fullstack=Yesの場合、ユニットの`relatedFiles`と`technicalProfile.primaryModules`のパスパターンからbackend / frontend / 両方のいずれが必要かをユニット毎に判定する（technical-specスキルのプロジェクト構造定義を参照）。
+**追加の発見は不要。** `$STEP_1_OUTPUT.discoveredUnits`（実装粒度のユニット）を技術プロファイルとして使用する。`$STEP_1_OUTPUT.prdUnits[].sourceUnits`で各PRDユニットに属するdiscoveredUnitsを追跡する。
+
+fullstack=Yesの場合、ユニットの`relatedFiles`と`technicalProfile.primaryModules`のパスパターンからbackend / frontend / 両方のいずれが必要かをユニット毎に判定する（technical-specスキルのプロジェクト構造定義を参照）。
 
 `$STEP_1_OUTPUT`のユニットから以下を引き継ぐ:
 - `technicalProfile.primaryModules` → 主要ファイル

package/.claude/commands-ja/update-doc.md

@@ -24,7 +24,7 @@ description: 既存設計ドキュメント（Design Doc / PRD / ADR）をレビ
 ```
 対象ドキュメント → [停止: 変更内容確認]
                         ↓
-              technical-designer / prd-creator（updateモード）
+              technical-designer / technical-designer-frontend / prd-creator（updateモード）
                         ↓
               document-reviewer → [停止: レビュー承認]
                         ↓（Design Docのみ）
@@ -66,15 +66,20 @@ ls docs/design/*.md docs/prd/*.md docs/adr/*.md 2>/dev/null | grep -v template
 | 複数の候補が見つかった | AskUserQuestionで選択肢を提示 |
 | ドキュメントが見つからない | 報告して終了（代わりに/designを推奨） |
 
-### ステップ2: ドキュメントタイプの判定
+### ステップ2: ドキュメントタイプとレイヤーの判定
 
-ドキュメントパスからタイプを判定:
+ドキュメントパスからタイプを判定し、適切な更新エージェントを選択するためにレイヤーを判定する:
 
 | パスパターン | タイプ | 更新エージェント | 備考 |
 |-------------|--------|-----------------|------|
-| `docs/design/*.md` | Design Doc | technical-designer | - |
+| `docs/design/*.md` | Design Doc | technical-designerまたはtechnical-designer-frontend | 下記レイヤー判定を参照 |
 | `docs/prd/*.md` | PRD | prd-creator | - |
-| `docs/adr/*.md` | ADR | technical-designer | 軽微な変更: 既存ファイルを更新、大きな変更: 元を置き換える新ADRを作成 |
+| `docs/adr/*.md` | ADR | technical-designerまたはtechnical-designer-frontend | 下記レイヤー判定を参照 |
+
+**レイヤー判定**（Design DocとADRの場合）:
+ドキュメントの内容からレイヤーを判定する:
+- **フロントエンド**（→ technical-designer-frontend）: タイトルやスコープにReact、コンポーネント、UI、フロントエンドの記載がある。またはコンポーネント階層、状態管理、UIインタラクションを含む
+- **バックエンド**（→ technical-designer）: 上記以外（API、データ層、ビジネスロジック、インフラストラクチャ）
 
 **ADR更新ガイダンス**:
 - **軽微な変更**（明確化、誤字修正、小規模なスコープ調整）: 既存ADRファイルを更新

package/CHANGELOG.md

@@ -5,6 +5,34 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.18.1] - 2026-03-25
+
+### Added
+
+#### Structured JSON Output Enforcement
+- Explicit "Return JSON Result" step added to all 15 agents (EN/JA) to ensure consistent structured JSON output
+- Completion criteria updated with "Final response is the JSON output" check across all agents
+
+#### Scope Discovery Improvements
+- `scope-discoverer`: PRD unit grouping (step 7) with `valueProfile` metadata (`targetPersona`, `userGoal`, `valueCategory`)
+- `scope-discoverer`: `prdUnits` array in output format for downstream document generation
+- `reverse-engineer`: Updated to use `prdUnits` with quality gate validation (sourceUnits completeness check)
+- `reverse-engineer`: Human review point now presents PRD unit grouping for confirmation
+
+#### Document Update Layer Detection
+- `update-doc`: Auto-detect frontend/backend layer from document content for correct agent selection (`technical-designer` vs `technical-designer-frontend`)
+
+### Changed
+
+- `quality-fixer` / `quality-fixer-frontend`: "User Report" section replaced with "Intermediate Progress Report" to clarify final output must be JSON
+- `scope-discoverer`: "Merge signals" renamed to "Cohesion signals" with note that grouping is deferred to step 7
+- `investigator`: Step 4 renamed from "Impact Scope Identification and Output" to "Impact Scope Identification"
+- `solver`: Step 5 renamed from "Implementation Steps Creation and Output" to "Implementation Steps Creation"
+
+### Fixed
+
+- Added missing "Applying to Implementation" sections to 5 Japanese agent definitions (`code-reviewer`, `acceptance-test-generator`, `design-sync`, `integration-test-reviewer`, `requirement-analyzer`) that caused JA agents to operate without skill loading instructions
+
 ## [1.18.0] - 2026-03-21
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-ai-project",
-  "version": "1.18.0",
+  "version": "1.18.1",
   "packageManager": "npm@10.8.2",
   "description": "TypeScript boilerplate with skills and sub-agents for Claude Code. Prevents context exhaustion through role-based task splitting.",
   "keywords": [