create-ai-project 1.18.0 → 1.18.2

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,15 @@ 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
+- Each discovered unit's `unitInventory` has at least one non-empty category (routes, testFiles, or publicExports). Units with all three empty indicate incomplete discovery — re-run scope-discoverer with focus on that unit's relatedFiles
 
-**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,13 +93,14 @@ 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.
+  Use provided scope as investigation starting point.
+  If tracing entry points reveals files outside this scope, include them.
+  Create final version PRD based on thorough code investigation.
 ```
 
 **Store output as**: `$STEP_2_OUTPUT` (PRD path)
@@ -113,14 +117,16 @@ prompt: |
 
   doc_type: prd
   document_path: $STEP_2_OUTPUT
-  code_paths: $UNIT_RELATED_FILES (from $STEP_1_OUTPUT)
   verbose: false
 ```
 
+Note: `code_paths` is intentionally NOT provided. The verifier independently discovers code scope from the document, ensuring independent verification not constrained by scope-discoverer's output.
+
 **Store output as**: `$STEP_3_OUTPUT`
 
 **Quality Gate**:
-- consistencyScore >= 70 → proceed to review
+- consistencyScore >= 70 AND verifiableClaimCount >= 20 → proceed to review
+- consistencyScore >= 70 BUT verifiableClaimCount < 20 → re-run verifier (investigation too shallow)
 - consistencyScore < 70 → flag for detailed review
 
 #### Step 4: Review
@@ -195,13 +201,16 @@ 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
 - `technicalProfile.publicInterfaces` → Public Interfaces
 - `dependencies` → Dependencies
 - `relatedFiles` → Scope boundary
+- `unitInventory` → Unit Inventory (routes, test files, public exports)
 
 **Store output as**: `$STEP_6_OUTPUT`
 
@@ -225,17 +234,18 @@ subagent_type: technical-designer
 prompt: |
   Create Design Doc for the following feature based on existing code.
 
-  Operation Mode: create
+  Operation Mode: reverse-engineer
 
   Feature: $UNIT_NAME (from $STEP_6_OUTPUT)
   Description: $UNIT_DESCRIPTION
   Primary Files: $UNIT_PRIMARY_MODULES
   Public Interfaces: $UNIT_PUBLIC_INTERFACES
   Dependencies: $UNIT_DEPENDENCIES
+  Unit Inventory: $UNIT_INVENTORY (routes, test files, public exports from scope discovery)
 
   Parent PRD: $APPROVED_PRD_PATH
 
-  Document current architecture. Do not propose changes.
+  Document current architecture as-is. Use Unit Inventory as a completeness baseline — all routes and exports should be accounted for in the Design Doc.
 ```
 
 **Store output as**: `$STEP_7_OUTPUT`
@@ -247,20 +257,21 @@ subagent_type: technical-designer-frontend
 prompt: |
   Create a frontend Design Doc for the following feature based on existing code.
 
-  Operation Mode: create
+  Operation Mode: reverse-engineer
 
   Feature: $UNIT_NAME (from $STEP_6_OUTPUT)
   Description: $UNIT_DESCRIPTION
   Primary Files: $UNIT_PRIMARY_MODULES
   Public Interfaces: $UNIT_PUBLIC_INTERFACES
   Dependencies: $UNIT_DEPENDENCIES
+  Unit Inventory: $UNIT_INVENTORY
 
   Parent PRD: $APPROVED_PRD_PATH
   Backend Design Doc: $STEP_7_OUTPUT
 
   Reference backend Design Doc for API contracts.
   Focus on: component hierarchy, state management, UI interactions, data fetching.
-  Document current architecture. Do not propose changes.
+  Document current architecture as-is. Use Unit Inventory as completeness baseline.
 ```
 
 **Store output as**: `$STEP_7_FRONTEND_OUTPUT`
@@ -277,10 +288,11 @@ prompt: |
 
   doc_type: design-doc
   document_path: $STEP_7_OUTPUT or $STEP_7_FRONTEND_OUTPUT
-  code_paths: $UNIT_PRIMARY_MODULES
   verbose: false
 ```
 
+Note: `code_paths` is intentionally NOT provided. The verifier independently discovers code scope from the document.
+
 **Store output as**: `$STEP_8_OUTPUT`
 
 #### Step 9: Review

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/diagnose.md

@@ -81,7 +81,18 @@ rule-advisorの出力から以下を確認：
 Agentツールでinvestigatorを呼び出す:
 - `subagent_type`: "investigator"
 - `description`: "問題情報の収集"
-- `prompt`: "以下の現象について、関連する情報を網羅的に収集してください。現象: [ユーザーが報告した問題]"
+- `prompt`: |
+    以下の現象について、関連する情報を網羅的に収集してください。
+
+    現象: [ユーザーが報告した問題]
+
+    問題の本質: [ステップ0.3のtaskEssence]
+    調査観点: [ステップ0.4のinvestigationFocus]
+
+    [変更失敗の場合、追加で以下を含める:]
+    変更内容: [何を変更したか]
+    影響箇所: [何が壊れたか]
+    共通コンポーネント: [原因変更と影響箇所の共通点]
 
 **期待される出力**: 証拠マトリクス、比較分析結果、因果追跡結果、未探索領域のリスト、調査の限界
 
@@ -90,12 +101,20 @@ Agentツールでinvestigatorを呼び出す:
 調査出力を確認：
 
 **品質チェック**（出力JSONに以下が含まれているか）:
-- [ ] comparisonAnalysis
-- [ ] 各仮説にcausalChain（停止条件に到達）
-- [ ] 各仮説にcauseCategory
-- [ ] investigationFocusに対応する調査が含まれているか（渡された場合）
-
-**品質不足の場合**: 不足項目を指定してinvestigatorを再実行
+- [ ] `comparisonAnalysis`が存在し、`normalImplementation`がnullでない（比較対象が見つかった）、または「正常動作する実装が見つからなかった」と明示的に記録されている
+- [ ] 各仮説の`causalChain`が停止条件に到達（コード変更で対処可能 / 設計判断レベル / 外部制約）
+- [ ] 各仮説の`causeCategory`が以下のいずれか: typo / logic_error / missing_constraint / design_gap / external_factor
+- [ ] `investigationSources`が少なくとも3つの異なるソースタイプ（code, history, dependency, config, document, external）をカバー
+- [ ] ステップ0.4で提供した`investigationFocus`の項目が調査に含まれている
+- [ ] 各仮説の`supportingEvidence`に具体的なファイルや場所を引用した`source`フィールドを持つエントリが最低1つある
+
+**品質不足の場合**: 不足項目を明示してinvestigatorを再実行:
+- `prompt`: |
+    以下の不足点に焦点を当てて再調査してください:
+    - 不足: [品質チェックから具体的な不足項目を列挙]
+
+    前回の調査結果（コンテキスト用、調査済み領域の再調査は不要）:
+    [前回の調査JSON]
 
 **design_gap検出時のエスカレーション**:
 

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,15 @@ prompt: |
 **品質ゲート**:
 - 1つ以上のユニットが発見された → 続行
 - ユニットが発見されない → ユーザーにヒントを求める
+- `$STEP_1_OUTPUT.prdUnits`が存在すること
+- `prdUnits`全体の`sourceUnits`を結合・重複除去した集合が`discoveredUnits`のID集合と一致すること — 欠落や重複がないこと
+- 各discoveredUnitの`unitInventory`に少なくとも1つの非空カテゴリ（routes、testFiles、publicExports）があること。3つすべてが空のユニットは発見が不完全 — そのユニットのrelatedFilesにフォーカスしてscope-discovererを再実行する
 
-**人間レビューポイント**（有効時）: 発見されたユニットを確認用に提示。
+**人間レビューポイント**（有効時）: `$STEP_1_OUTPUT.prdUnits`とソースユニットのマッピングを提示する。ユーザーはグルーピングの確認、調整、またはスコープからの除外を行う。これは最も重要なレビューポイント — グルーピングの誤りはすべての下流ドキュメントに波及する。
 
 ### ステップ2-5: ユニット毎の処理
 
-**FOR** `$STEP_1_OUTPUT.discoveredUnits`の各ユニット **（逐次実行、1ユニットずつ）**:
+**FOR** `$STEP_1_OUTPUT.prdUnits`の各ユニット **（逐次実行、1ユニットずつ）**:
 
 #### ステップ2: PRD生成
 
@@ -90,13 +93,14 @@ 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を作成。
+  提供されたスコープを調査の起点として使用。
+  エントリーポイントの追跡でスコープ外のファイルが判明した場合は含める。
+  徹底的なコード調査に基づき最終版PRDを作成。
 ```
 
 **出力を保存**: `$STEP_2_OUTPUT`（PRDパス）
@@ -113,14 +117,16 @@ prompt: |
 
   doc_type: prd
   document_path: $STEP_2_OUTPUT
-  code_paths: $UNIT_RELATED_FILES ($STEP_1_OUTPUTより)
   verbose: false
 ```
 
+注: `code_paths`は意図的に未指定。検証エージェントがドキュメントからコードスコープを独自に発見することで、scope-discovererの出力に制約されない独立した検証を実現する。
+
 **出力を保存**: `$STEP_3_OUTPUT`
 
 **品質ゲート**:
-- consistencyScore >= 70 → レビューへ進む
+- consistencyScore >= 70 かつ verifiableClaimCount >= 20 → レビューへ進む
+- consistencyScore >= 70 だが verifiableClaimCount < 20 → 検証が浅い、code-verifierを再実行
 - consistencyScore < 70 → 詳細レビュー用にフラグ
 
 #### ステップ4: レビュー
@@ -195,13 +201,16 @@ 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` → 主要ファイル
 - `technicalProfile.publicInterfaces` → publicインターフェース
 - `dependencies` → 依存関係
 - `relatedFiles` → スコープ境界
+- `unitInventory` → ユニットインベントリ（ルート、テストファイル、publicエクスポート）
 
 **出力を保存**: `$STEP_6_OUTPUT`
 
@@ -225,17 +234,18 @@ subagent_type: technical-designer
 prompt: |
   既存コードに基づき以下の機能のDesign Docを作成する。
 
-  動作モード: create
+  動作モード: reverse-engineer
 
   機能: $UNIT_NAME ($STEP_6_OUTPUTより)
   説明: $UNIT_DESCRIPTION
   主要ファイル: $UNIT_PRIMARY_MODULES
   publicインターフェース: $UNIT_PUBLIC_INTERFACES
   依存関係: $UNIT_DEPENDENCIES
+  ユニットインベントリ: $UNIT_INVENTORY（スコープ発見で得たルート、テストファイル、publicエクスポート）
 
   親PRD: $APPROVED_PRD_PATH
 
-  現在のアーキテクチャをドキュメント化する。変更提案は行わない。
+  現在のアーキテクチャを現状のままドキュメント化する。ユニットインベントリを網羅性の検証基準として使用する — すべてのルートとエクスポートがDesign Docに反映されていること。
 ```
 
 **出力を保存**: `$STEP_7_OUTPUT`
@@ -247,20 +257,21 @@ subagent_type: technical-designer-frontend
 prompt: |
   既存コードに基づき以下の機能のフロントエンドDesign Docを作成する。
 
-  動作モード: create
+  動作モード: reverse-engineer
 
   機能: $UNIT_NAME ($STEP_6_OUTPUTより)
   説明: $UNIT_DESCRIPTION
   主要ファイル: $UNIT_PRIMARY_MODULES
   publicインターフェース: $UNIT_PUBLIC_INTERFACES
   依存関係: $UNIT_DEPENDENCIES
+  ユニットインベントリ: $UNIT_INVENTORY
 
   親PRD: $APPROVED_PRD_PATH
   バックエンドDesign Doc: $STEP_7_OUTPUT
 
   バックエンドDesign DocのAPIコントラクトを参照。
   対象: コンポーネント階層、状態管理、UI操作、データ取得。
-  現在のアーキテクチャをドキュメント化する。変更提案は行わない。
+  現在のアーキテクチャを現状のままドキュメント化する。ユニットインベントリを網羅性の検証基準として使用する。
 ```
 
 **出力を保存**: `$STEP_7_FRONTEND_OUTPUT`
@@ -277,10 +288,11 @@ prompt: |
 
   doc_type: design-doc
   document_path: $STEP_7_OUTPUT または $STEP_7_FRONTEND_OUTPUT
-  code_paths: $UNIT_PRIMARY_MODULES
   verbose: false
 ```
 
+注: `code_paths`は意図的に未指定。検証エージェントがドキュメントからコードスコープを独自に発見する。
+
 **出力を保存**: `$STEP_8_OUTPUT`
 
 #### ステップ9: レビュー

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,66 @@ 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.2] - 2026-03-26
+
+### Changed
+
+#### Investigation Depth Consistency
+- `code-verifier`: Section-by-section claim extraction with minimum 20 claims threshold and score stability constraint
+- `code-verifier`: Tool-backed evidence rules requiring Glob/Grep confirmation for existence, behavioral, and identifier claims
+- `code-verifier`: Reverse coverage assessment (code-to-document direction) enumerating routes, test files, and public exports
+- `investigator`: Structured source table with minimum investigation actions per source type, replacing vague bullet list
+- `investigator`: Tracking depth check replacing "shallow tracking signs" with explicit stop condition requirement
+- `verifier`: Structured triangulation supplementation with source type gap analysis
+
+#### Reverse-Engineer Workflow Accuracy
+- `prd-creator`: 7-step reverse investigation protocol (route enumeration → entry point tracing → data model → tests → roles → spec → confirmation)
+- `prd-creator`: Exact code transcription requirement for identifiers, URLs, and parameter names
+- `prd-creator`: Scope expansion from entry points when external scope is provided
+- `scope-discoverer`: Unit inventory enumeration (routes, test files, public exports) per discovered unit, propagated to downstream agents
+- `scope-discoverer`: Step renumbering (4.5 → 5, subsequent steps shifted to 6-9)
+- `technical-designer` / `technical-designer-frontend`: Reverse-engineer operation mode with mode-separated checklists
+- `reverse-engineer`: Independent verifier scope discovery (code_paths intentionally omitted)
+- `reverse-engineer`: verifiableClaimCount ≥ 20 quality gate
+- `reverse-engineer`: unitInventory propagation to Design Doc generation
+
+#### Diagnostic Workflow
+- `diagnose`: Structured investigator prompts passing taskEssence and investigationFocus
+- `diagnose`: Expanded quality checks with 6 specific criteria and re-run prompt template
+
+#### Agent Structure
+- Removed redundant "Core Responsibilities" sections from 5 agents (code-verifier, investigator, scope-discoverer, verifier) — content preserved in execution steps
+- `technical-designer` / `technical-designer-frontend`: Consolidated integration point contracts, removed ADR template duplication
+- `technical-designer` / `technical-designer-frontend`: Research guidelines condensed with reverse-engineer mode skip rule
+
+## [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.2",
   "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": [