create-ai-project 1.18.1 → 1.18.2

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

@@ -74,6 +74,7 @@ prompt: |
 - 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 `$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.
 
@@ -97,8 +98,9 @@ prompt: |
   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)
@@ -115,14 +117,16 @@ prompt: |
 
   doc_type: prd
   document_path: $STEP_2_OUTPUT
-  code_paths: $PRD_UNIT_COMBINED_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
@@ -206,6 +210,7 @@ Map `$STEP_1_OUTPUT` units to Design Doc generation targets, carrying forward:
 - `technicalProfile.publicInterfaces` → Public Interfaces
 - `dependencies` → Dependencies
 - `relatedFiles` → Scope boundary
+- `unitInventory` → Unit Inventory (routes, test files, public exports)
 
 **Store output as**: `$STEP_6_OUTPUT`
 
@@ -229,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`
@@ -251,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`
@@ -281,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-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

@@ -74,6 +74,7 @@ prompt: |
 - ユニットが発見されない → ユーザーにヒントを求める
 - `$STEP_1_OUTPUT.prdUnits`が存在すること
 - `prdUnits`全体の`sourceUnits`を結合・重複除去した集合が`discoveredUnits`のID集合と一致すること — 欠落や重複がないこと
+- 各discoveredUnitの`unitInventory`に少なくとも1つの非空カテゴリ（routes、testFiles、publicExports）があること。3つすべてが空のユニットは発見が不完全 — そのユニットのrelatedFilesにフォーカスしてscope-discovererを再実行する
 
 **人間レビューポイント**（有効時）: `$STEP_1_OUTPUT.prdUnits`とソースユニットのマッピングを提示する。ユーザーはグルーピングの確認、調整、またはスコープからの除外を行う。これは最も重要なレビューポイント — グルーピングの誤りはすべての下流ドキュメントに波及する。
 
@@ -97,8 +98,9 @@ prompt: |
   関連ファイル: $PRD_UNIT_COMBINED_RELATED_FILES
   エントリーポイント: $PRD_UNIT_COMBINED_ENTRY_POINTS
 
-  独自のスコープ発見をスキップ。提供されたスコープデータを使用。
-  指定スコープ内でのコード調査に基づき最終版PRDを作成。
+  提供されたスコープを調査の起点として使用。
+  エントリーポイントの追跡でスコープ外のファイルが判明した場合は含める。
+  徹底的なコード調査に基づき最終版PRDを作成。
 ```
 
 **出力を保存**: `$STEP_2_OUTPUT`（PRDパス）
@@ -115,14 +117,16 @@ prompt: |
 
   doc_type: prd
   document_path: $STEP_2_OUTPUT
-  code_paths: $PRD_UNIT_COMBINED_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: レビュー
@@ -206,6 +210,7 @@ fullstack=Yesの場合、ユニットの`relatedFiles`と`technicalProfile.prima
 - `technicalProfile.publicInterfaces` → publicインターフェース
 - `dependencies` → 依存関係
 - `relatedFiles` → スコープ境界
+- `unitInventory` → ユニットインベントリ（ルート、テストファイル、publicエクスポート）
 
 **出力を保存**: `$STEP_6_OUTPUT`
 
@@ -229,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`
@@ -251,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`
@@ -281,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/CHANGELOG.md

@@ -5,6 +5,38 @@ 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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-ai-project",
-  "version": "1.18.1",
+  "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": [