create-ai-project 1.18.1 → 1.18.2

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

@@ -44,20 +44,7 @@ UI Specが存在する場合（`docs/ui-spec/{feature-name}-ui-spec.md`）:
 
 ## ドキュメント作成の判断基準
 
-ドキュメント作成基準の詳細はdocumentation-criteriaスキルに準拠。
-
-### 概要
-- ADR: コンポーネントアーキテクチャ変更、状態管理変更、Reactパターン変更、外部ライブラリ変更
-- Design Doc: 3コンポーネント/ファイル以上の変更で必須
-- 以下の場合も規模に関わらず必須：
-  - 複雑な状態管理ロジック
-    - 判断基準: 3つ以上の状態変数を管理、または5つ以上の非同期処理（API呼び出し）の連携
-    - 例: 複雑なフォーム状態管理、複数のAPI呼び出しのオーケストレーション
-  - 新しいReactパターンやカスタムフックの導入
-    - 例: 新しいコンテキストパターン、カスタムフックライブラリ
-
-### 重要：判定の整合性
-- 判定に矛盾がある場合は、その旨を明記して出力に含める
+ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判定に矛盾がある場合は、その旨を明記して出力に含める。
 
 ## Design Doc作成前の必須プロセス
 
@@ -87,27 +74,20 @@ Design Doc作成前に必ず実施：
    - 採用した判断（既存使用/改善提案/新規実装）とその根拠を記録
 
 ### 統合ポイント分析【重要】
-新機能や既存機能の変更時に、既存コンポーネントとの統合ポイントを明確化：
-
-1. **統合ポイントの特定と記載**
-   ```yaml
-   ## 統合ポイントマップ
-   統合点1:
-     既存コンポーネント: [コンポーネント名・フック名]
-     統合方法: [Props受け渡し/Context共有/Custom Hook利用/等]
-     影響度: 高（データフロー変更）/中（Props利用）/低（読み取りのみ）
-     必要なテスト観点: [既存コンポーネントの継続性確認内容]
-   ```
-
-2. **影響度による分類**
-   - **高**: 既存のデータフローや状態管理を変更・拡張
-   - **中**: 既存コンポーネントのstate/contextを利用・更新
-   - **低**: 読み取りのみの操作、レンダリング追加等
-
-3. **Design Docへの反映**
-   - 「## 統合ポイントマップ」セクションを作成
-   - 各統合ポイントでの責務と境界を明確化
-   - エラー動作とローディング状態を設計段階で定義
+既存コンポーネントとのすべての統合ポイントを「## 統合ポイントマップ」セクションに記載する:
+
+各統合ポイントについて記録:
+- 既存コンポーネント/フック名
+- 統合方法（Props渡し/Context共有/Custom Hook/イベント）
+- 影響度: 高（データフロー変更）/ 中（状態利用）/ 低（読み取りのみ）
+- 必要なテスト観点
+
+各統合境界についてコントラクトを定義:
+- 入力（Props）: Props型と必須/オプション
+- 出力（イベント）: イベントハンドラーシグネチャ
+- エラー時: Error Boundary、エラー状態、フォールバックUI
+
+各統合ポイントで既存コンポーネントとの競合（命名規則、Propsパターン）を確認し記載する。
 
 ### 合意事項チェックリスト【最重要】
 Design Doc作成開始時に必ず実施：
@@ -170,38 +150,18 @@ Design Doc作成前に実施：
 
 共通ADRが必要な場合: 複数コンポーネントに共通する技術的決定
 
-### 統合ポイント仕様
-既存コンポーネントとの統合ポイントを文書化（場所、旧Props、新Props、切り替え方法）。
-
 ### データ契約
 コンポーネント間のProps型と状態管理契約を定義（型、事前条件、保証、エラー動作）。
 
 ### 状態遷移（該当する場合）
 ステートフルコンポーネントの状態定義と遷移を文書化（loading、error、success states）。
 
-### 統合境界契約【必須】
-コンポーネント境界でのProps型、イベントハンドラ、エラーハンドリングを定義。
-
-```yaml
-境界名: [コンポーネント統合ポイント]
-  入力(Props): [Props型定義]
-  出力(Events): [イベントハンドラシグネチャ]
-  エラー時: [エラーハンドリング方法（Error Boundary、error state等）]
-```
-
-**統合境界:**
-- React → DOM: コンポーネントのブラウザDOMへのレンダリング
-- ビルドツール → Browser: ビルド出力の静的ファイルをブラウザが提供
-- API → Frontend: 外部APIレスポンスをフロントエンドで処理
-- Context → Component: Context値をコンポーネントで消費
-
-既存コンポーネントとの競合（命名規約、Propsパターン等）を確認し、統合不整合を防止するため文書化。
-
 ## 必要情報
 
 - **動作モード**:
   - `create`: 新規作成（デフォルト）
   - `update`: 既存ドキュメントの更新
+  - `reverse-engineer`: 既存フロントエンドアーキテクチャの現状ドキュメント化（reverse-engineerモードセクション参照）
 
 - **要件分析結果**: 要件分析の結果（規模判定、技術要件等）
 - **PRD**: PRDドキュメント（存在する場合）
@@ -223,42 +183,10 @@ Design Doc作成前に実施：
 
 ## ドキュメント出力形式
 
-### ADR作成（複数案比較モード）
-
-**基本構造**:
-```markdown
-# ADR-XXXX: [タイトル]
-Status: Proposed
-
-## 背景
-[フロントエンドの技術的課題と制約を1-2文で]
-
-## 選択肢
-### 選択肢A: [アプローチ名]
-- 概要: [一文で説明]
-- メリット: [2-3項目]
-- デメリット: [2-3項目]
-- 工数: X日
-
-### 選択肢B/C: [同様に文書化]
-
-## 比較
-| 評価軸 | 選択肢A | 選択肢B | 選択肢C |
-|--------|---------|---------|---------|
-| 実装工数 | 3日 | 5日 | 2日 |
-| 保守性 | 高 | 中 | 低 |
-| パフォーマンス影響 | 低 | 高 | 中 |
-
-## 決定
-選択肢[X]を選択。理由: [トレードオフを含めて2-3文で]
-```
-
-詳細は `docs/adr/template-en.md` を参照。
-
-### 通常ドキュメント作成
+### ドキュメント作成
 - **ADR**: `docs/adr/ADR-[4桁番号]-[タイトル].md` （例: ADR-0001）
 - **Design Doc**: `docs/design/[機能名]-design.md`
-- それぞれのテンプレート（`template-en.md`）に従う
+- それぞれのテンプレート（`template-ja.md`）に従う
 - ADRの場合、既存番号を確認してmax+1を使用、初期ステータスは「Proposed」
 
 ## ADR責任範囲
@@ -368,21 +296,32 @@ class Button extends React.Component {
 - [ ] 比較マトリックスの完全性（パフォーマンス影響含む）
 
 ### Design Docチェックリスト
-- [ ] **合意事項チェックリスト完了**（最重要）
-- [ ] **前提となる共通ADR参照**（必須）
-- [ ] **変更影響マップ作成**（必須）
-- [ ] **統合境界契約定義**（必須）
-- [ ] **統合ポイントの完全列挙**（必須）
-- [ ] **Props型契約の明確化**（必須）
+
+**全モード共通**:
+- [ ] **基準特定ゲート完了**（必須）
+- [ ] **コード調査エビデンス記録済み**（必須）
+- [ ] **統合ポイントをコントラクト付きで列挙**（必須）
+- [ ] **Props型コントラクトの明確化**（必須）
+- [ ] コンポーネント階層とデータフローが図で明確に表現されているか
+
+**create/updateモード限定**（reverse-engineerモードではスキップ）:
+- [ ] **合意事項チェックリストの完了**（最重要）
+- [ ] **前提となる共通ADRの参照**（必須）
+- [ ] **変更影響マップの作成**（必須）
 - [ ] **各フェーズのコンポーネント検証手順**（必須）
-- [ ] 要件への応答と設計の妥当性
-- [ ] テスト戦略（React Testing Library）とエラーハンドリング（Error Boundary）
-- [ ] コンポーネント階層とデータフローが図で明確に表現
-- [ ] Props変更マトリックスの完全性
-- [ ] 実装アプローチ選択理由（vertical/horizontal/hybrid）
-- [ ] 最新Reactベストプラクティス調査済み、参考文献引用
+- [ ] 要件への対応と設計の妥当性
+- [ ] テスト戦略とエラーハンドリング
+- [ ] Props変更マトリクスの完成度
+- [ ] 実装アプローチ（垂直/水平/ハイブリッド）の選択根拠
+- [ ] 最新のベストプラクティスの調査と参考資料の記載
 - [ ] **複雑性評価**: complexity_levelを設定。medium/highの場合、complexity_rationaleに(1)要件/AC、(2)制約/リスクを明記
 
+**reverse-engineerモード限定**:
+- [ ] すべてのアーキテクチャ主張がfile:lineをevidenceとして引用
+- [ ] 識別子はコードからそのまま転記
+- [ ] テストの存在はGlobで確認済み
+- [ ] ユニットインベントリ（提供時）の全項目を反映
+
 ## 受入条件作成ガイドライン
 
 **原則**: ブラウザ環境で検証可能な具体的条件を設定。曖昧な表現を避け、React Testing Libraryテストケースに変換可能な形式で文書化。
@@ -411,46 +350,40 @@ class Button extends React.Component {
 
 **原則**: AC = 隔離されたCI環境でブラウザ上で検証可能なユーザー観察可能動作
 
-## 最新情報調査ガイドライン
+## 最新情報のリサーチ
 
-### 調査タイミング
-1. **必須調査**:
-   - 新しいReactライブラリ・UIフレームワーク導入を検討する場合
-   - パフォーマンス最適化を設計する場合（コード分割、遅延読み込み）
-   - アクセシビリティ実装を設計する場合（WCAG準拠）
-   - Reactメジャーバージョンアップ時（例: React 18 → 19）
+**対象**（create/updateモード）: 新規ライブラリ/フレームワーク導入、パフォーマンス最適化、アクセシビリティ設計、大幅バージョンアップ時。
 
-2. **推奨調査**:
-   - 複雑なカスタムフック実装前
-   - 既存コンポーネントパターンの改善を検討する場合
+`date +%Y`で現在年を確認し、検索クエリに含める:
+- `[ライブラリ] best practices {現在年}`
+- `[lib A] vs [lib B] comparison {現在年}`
+- `[フレームワーク] breaking changes migration guide`
+- `[フレームワーク] accessibility best practices`
 
-### 調査方法
+出典はADR/Design Doc末尾の「## 参考資料」セクションにURLを記載。
 
-**必須調査タイミング**: 新ライブラリ導入、パフォーマンス最適化、アクセシビリティ設計、Reactバージョンアップ
+**reverse-engineerモード**: スキップ。リサーチは新規設計判断用。
 
-**具体的検索パターン例**:
-- `React new features best practices`（新機能調査）
-- `Zustand vs Redux Toolkit comparison 2025`（状態管理選定）
-- `React Server Components patterns`（設計パターン）
-- `React breaking changes migration guide`（バージョンアップ）
-- `Tailwind CSS accessibility best practices`（アクセシビリティ調査）
-- `[ライブラリ名] official documentation`（公式情報）
+## updateモード動作
+- **ADR**: 軽微な変更は既存ファイル更新、大幅な変更は新規ファイル作成
+- **Design Doc**: 改訂版セクションを追加し変更履歴を記録
 
-**引用**: ADR/Design Doc末尾に「## References」セクションを追加してURLと説明を記載
+## reverse-engineerモード（現状フロントエンドドキュメント化）
 
-### 引用形式
+既存フロントエンドアーキテクチャを現状のままドキュメント化するモード。リバースエンジニアリングワークフローで既存実装からDesign Docを作成する際に使用。
 
-ADR/Design Doc末尾に以下の形式で追加:
+### reverse-engineerモードでスキップする項目
+- ADR作成、選択肢の比較、変更影響分析、最新情報のリサーチ、実装アプローチの決定
 
-```markdown
-## References
+### reverse-engineerモード実行ステップ
 
-- [タイトル](URL) - 参照内容の簡潔な説明
-- [React公式ドキュメント](URL) - 関連する設計原則や機能
-- [フロントエンドブログ記事](URL) - 実装パターンとベストプラクティス
-- [パフォーマンス最適化ガイド](URL) - レンダリング最適化手法
-```
+1. **読み込みとインベントリ**: すべての主要ファイルをReadする。コンポーネント階層、エクスポートされたコンポーネント、フック、ユーティリティを記録する。ユニットインベントリが提供されている場合は、網羅性の検証基準として使用する — リストされたすべてのルート、エクスポート、テストファイルがDesign Docに反映されていること
+2. **コンポーネントツリーの追跡**: 各ページ/画面について、実装と子コンポーネントをReadする。記録: Props、状態管理、データ取得、条件付きレンダリング — 実装通りに
+3. **データフローの文書化**: 各データ取得呼び出しについて: エンドポイント、パラメータ、レスポンス構造を記録。状態管理について: 状態の構造、更新メカニズム、利用コンポーネントを記録
+4. **コントラクトの記録**: 各コンポーネントのインターフェースについて、Props名、型、必須/オプションを記録 — コードに書かれている通りに。ソースの正確な識別子を使用する
+5. **テストカバレッジの確認**: テストファイルをGlobする。どのコンポーネントにテストがあるかを記録。テストの存在は報告前にGlobで確認する
 
-## updateモード動作
-- **ADR**: 軽微な変更は既存ファイル更新、大きな変更は新規ファイル作成
-- **Design Doc**: リビジョンセクションを追加し変更履歴を記録
+### reverse-engineerモード品質基準
+- すべての主張がfile:lineをevidenceとして引用
+- 識別子はコードからそのまま転記
+- テストの存在はGlobで確認済み（推測ではない）

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

@@ -34,20 +34,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## ドキュメント作成の判断基準
 
-ドキュメント作成基準の詳細はdocumentation-criteriaスキルに準拠。
-
-### 概要
-- ADR: 型システム変更、データフロー変更、アーキテクチャ変更、外部依存変更
-- Design Doc: 3ファイル以上の変更で必須
-- 以下の場合も規模に関わらず必須：
-  - 複雑な実装ロジック
-    - 判断基準: 3つ以上の状態を管理、または5つ以上の非同期処理の連携
-    - 例: Reduxの複雑な状態管理、Promiseチェーンが5つ以上連結
-  - 新しいアルゴリズムやパターンの導入
-    - 例: 新しいキャッシュ戦略、カスタムルーティング実装
-
-### 重要：判定の整合性
-- 判定に矛盾がある場合は、その旨を明記して出力に含める
+ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判定に矛盾がある場合は、その旨を明記して出力に含める。
 
 ## Design Doc作成前の必須プロセス
 
@@ -82,7 +69,7 @@ Design Doc作成前に必ず実施：
    - 実装予定の機能に関連するキーワードで既存コードを検索
    - 同じドメイン、同じ責務、同じ設定パターンの実装を探索
    - 判断と行動:
-     - 類似機能を発見 → その実装を使用する（新規実装は行わない）
+     - 類似機能を発見 → 既存の実装を使用する
      - 類似機能が技術的負債 → ADRで改善提案を作成してから実装
      - 類似機能なし → 新規実装を進める
 
@@ -108,28 +95,21 @@ Design Doc作成前に必ず実施：
    - 3基準以上不適合 → 新規構造を正当化
    - 判断と根拠をDesign Docに記録
 
-### 統合ポイント分析【重要】
-新機能や既存機能の変更時に、既存システムとの統合ポイントを明確化：
-
-1. **統合ポイントの特定と記載**
-   ```yaml
-   ## 統合ポイントマップ
-   統合点1:
-     既存コンポーネント: [サービス名・メソッド名]
-     統合方法: [フック追加/呼び出し追加/データ参照等]
-     影響度: 高（処理フロー変更）/中（データ利用）/低（読み取りのみ）
-     必要なテスト観点: [既存機能の継続性確認内容]
-   ```
-
-2. **影響度による分類**
-   - **高**: 既存処理フローを変更・拡張する場合
-   - **中**: 既存データを利用・更新する場合
-   - **低**: 読み取りのみ・ログ追加等の場合
-
-3. **Design Docへの反映**
-   - 「## 統合ポイントマップ」セクションを作成
-   - 各統合点での責務と境界を明確化
-   - エラー時の振る舞いを設計段階で決定
+### 統合ポイント【重要】
+既存システムとのすべての統合ポイントを「## 統合ポイントマップ」セクションに記載する:
+
+各統合ポイントについて記録:
+- 既存コンポーネントとメソッド
+- 統合方法（フック/呼び出し/データ参照）
+- 影響度: 高（処理フロー変更）/ 中（データ利用）/ 低（読み取りのみ）
+- 必要なテスト観点
+
+各統合境界についてコントラクトを定義:
+- 入力: 何を受け取るか
+- 出力: 何を返すか（同期/非同期を明記）
+- エラー時: この境界でのエラー処理方法
+
+各統合ポイントで既存システムとの競合（優先度、命名規則）を確認し記載する。
 
 ### 合意事項チェックリスト【最重要】
 Design Doc作成の最初に必ず実施：
@@ -198,32 +178,18 @@ Design Doc作成前に実施：
 
 共通ADRが必要な場合：複数コンポーネントで共通する技術的決定
 
-### 統合点の明示
-既存システムとの統合ポイント（場所、旧実装、新実装、切り替え方法）を記載。
-
 ### データ契約
 コンポーネント間の入出力（型、前提条件、保証、エラー時動作）を定義。
 
 ### 状態遷移（該当時のみ）
 状態を持つコンポーネントの状態定義と遷移を記載。
 
-### 統合境界の約束【必須】
-コンポーネント間の境界で、入出力・同期/非同期・エラー処理を言語非依存で定義。
-
-```yaml
-境界名: [接続点]
-  入力: [何を受け取るか]
-  出力: [何を返すか（同期/非同期明記）]
-  エラー時: [どう処理するか]
-```
-
-既存システムとの競合（優先度、命名規則等）を確認し記載。これにより統合時の不整合を防止。
-
 ## 必要情報
 
 - **動作モード**:
   - `create`: 新規作成（デフォルト）
   - `update`: 既存ドキュメントの更新
+  - `reverse-engineer`: 既存アーキテクチャの現状ドキュメント化（reverse-engineerモードセクション参照）
 
 - **要件分析結果**: 要件分析の結果（規模判定、技術要件等）
 - **PRD**: PRDドキュメント（存在する場合）
@@ -244,38 +210,7 @@ Design Doc作成前に実施：
 
 ## ドキュメント出力形式
 
-### ADR作成時（複数案比較モード）
-
-**基本構造**:
-```markdown
-# ADR-XXXX: [タイトル]
-Status: Proposed
-
-## 背景
-[技術的課題と制約条件を1-2文で記載]
-
-## 選択肢
-### 案A: [アプローチ名]
-- 概要: [1文で説明]
-- 利点: [2-3項目]
-- 欠点: [2-3項目]
-- 工数: X日
-
-### 案B/C: [同様に記載]
-
-## 比較
-| 評価軸 | 案A | 案B | 案C |
-|--------|-----|-----|-----|
-| 実装工数 | 3日 | 5日 | 2日 |
-| 保守性 | 高 | 中 | 低 |
-
-## 決定
-案[X]を選択。理由: [トレードオフ含め2-3文]
-```
-
-詳細は `docs/adr/template-ja.md` 参照。
-
-### 通常のドキュメント作成時
+### ドキュメント作成
 - **ADR**: `docs/adr/ADR-[4桁番号]-[タイトル].md` (例: ADR-0001)
 - **Design Doc**: `docs/design/[機能名]-design.md`
 - 各々のテンプレート（`template-ja.md`）に従って作成
@@ -285,7 +220,7 @@ Status: Proposed
 ADRに含む：決定事項、根拠、原則的な指針
 ADRに含まない：スケジュール、実装手順、具体的コード
 
-実装ガイドラインには原則のみ記載（例：「依存性注入を使用」○、「Phase 1で実装」×）
+実装ガイドラインには原則のみ記載（例：「依存性注入を使用」）。スケジュールや手順は含めない。
 
 ## 出力方針
 ファイル出力は即座に実行（実行時点で承認済み）。
@@ -321,32 +256,41 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 ### ADRチェックリスト
 - [ ] 問題の背景と複数の選択肢の評価（最低3案）
 - [ ] トレードオフと決定理由の明確化
-- [ ] 実装への原則的な指針（具体的な手順は含まない）
+- [ ] 実装への原則的な指針
 - [ ] 既存アーキテクチャとの整合性
 - [ ] 最新技術情報の調査実施と参考資料の記載
 - [ ] **共通ADRとの関連性の明記**（該当する場合）
 - [ ] 比較マトリクスの完成度
 
 ### Design Docチェックリスト
+
+**全モード共通**:
+- [ ] **基準特定ゲート完了**（必須）
+- [ ] **コード調査エビデンス記録済み**（必須）
+- [ ] **統合ポイントをコントラクト付きで列挙**（必須）
+- [ ] **データ契約の明確化**（必須）
+- [ ] アーキテクチャとデータフローが図で明確に表現されているか
+
+**create/updateモード限定**（reverse-engineerモードではスキップ）:
 - [ ] **合意事項チェックリストの完了**（最重要）
 - [ ] **前提となる共通ADRの参照**（必須）
 - [ ] **変更影響マップの作成**（必須）
-- [ ] **統合境界の約束の定義**（必須）
-- [ ] **統合点の完全な列挙**（必須）
-- [ ] **データ契約の明確化**（必須）
 - [ ] **各フェーズのE2E確認手順**（必須）
 - [ ] 要件への対応と設計の妥当性
 - [ ] テスト戦略とエラーハンドリング
-- [ ] アーキテクチャとデータフローが図で明確に表現されているか
 - [ ] インターフェース変更マトリクスの完成度
 - [ ] 実装アプローチ（垂直/水平/ハイブリッド）の選択根拠
 - [ ] 最新のベストプラクティスの調査と参考資料の記載
 - [ ] **複雑性評価**: complexity_levelを設定。medium/highの場合、complexity_rationaleに(1)要件/AC、(2)制約/リスクを明記
-- [ ] **基準特定ゲート完了**（必須）
-- [ ] **コード調査エビデンス記録済み**（必須）
 - [ ] **データ構造の採用判断の文書化**（新規構造導入時）
 - [ ] **フィールド伝播マップの記載**（フィールドが境界を越える場合）
 
+**reverse-engineerモード限定**:
+- [ ] すべてのアーキテクチャ主張がfile:lineをevidenceとして引用
+- [ ] 識別子はコードからそのまま転記
+- [ ] テストの存在はGlobで確認済み
+- [ ] ユニットインベントリ（提供時）の全項目を反映
+
 
 ## 受入条件の作成ガイドライン
 
@@ -385,27 +329,44 @@ ACの出力に以下のいずれかが含まれる場合、Property注釈を付
 
 記法はtemplateを参照。
 
-## 最新情報調査のガイドライン
+## 最新情報のリサーチ
 
-**必須調査タイミング**: 新技術導入、パフォーマンス最適化、セキュリティ設計、大幅バージョンアップ時
-**推奨調査**: 複雑なアルゴリズム実装前、既存パターン改善時
+**対象**（create/updateモード）: 新技術/ライブラリ導入、パフォーマンス最適化、セキュリティ設計、大幅バージョンアップ時。
 
-**検索パターン例**:
-最新情報を取得するため、検索前に必ず現在年を確認：
-```bash
-date +%Y  # 例: 2025
-```
-この年を検索クエリに含める：
-- `React Server Components best practices {現在年}` （新機能調査）
-- `PostgreSQL vs MongoDB performance comparison {現在年}` （技術選定）
-- `[フレームワーク名] official documentation` （公式情報は年不要）
-
-**出典記載**: ADR/Design Doc末尾に「## 参考資料」セクションを追加
-```markdown
-## 参考資料
-- [タイトル](URL) - 参照内容の簡単な説明
-```
+`date +%Y`で現在年を確認し、検索クエリに含める:
+- `[技術] [機能] best practices {現在年}`
+- `[技術A] vs [技術B] comparison {現在年}`
+- `[フレームワーク] breaking changes migration guide`
+
+出典はADR/Design Doc末尾の「## 参考資料」セクションにURLを記載。
+
+**reverse-engineerモード**: スキップ。リサーチは新規設計判断用。
 
 ## updateモード動作
 - **ADR**: 軽微な変更は既存ファイル更新、大幅な変更は新規ファイル作成
-- **Design Doc**: 改訂版セクションを追加し変更履歴を記録
+- **Design Doc**: 改訂版セクションを追加し変更履歴を記録
+
+## reverse-engineerモード（現状ドキュメント化）
+
+既存アーキテクチャを現状のままドキュメント化するモード。リバースエンジニアリングワークフローで既存実装からDesign Docを作成する際に使用。
+
+### reverse-engineerモードでスキップする項目
+- ADR作成（決定は既に行われている — 記録すべき新規決定はない）
+- 選択肢の比較（評価すべき代替案がない）
+- 変更影響マップ（変更を提案していない）
+- フィールド伝播マップ（新規フィールドを導入していない）
+- 実装アプローチの決定（実装戦略を選択する必要がない）
+- 最新情報のリサーチ（存在するものを記録しており、新規設計ではない）
+
+### reverse-engineerモード実行ステップ
+
+1. **読み込みとインベントリ**: すべての主要ファイルをReadする。ファイル毎のpublicインターフェースを記録する。ユニットインベントリが提供されている場合は、網羅性の検証基準として使用する — リストされたすべてのルート、エクスポート、テストファイルがDesign Docに反映されていること
+2. **データフローの追跡**: 各エントリーポイントについて、サービス/ヘルパー/データ層を通じた呼び出しを追跡する。各々をReadする。実際のフローとエラー処理を実装通りに記録する
+3. **コントラクトの記録**: 各public API/ハンドラーについて記録: パラメータ、レスポンス構造、ステータスコード、ミドルウェア/ガード — コードに書かれている通りに。外部依存については: 何を呼び出し何が返されるかを記録。ソースの正確な識別子を使用する
+4. **データモデルの文書化**: スキーマ/型定義をReadする。記録: フィールド名、型、nullable指定、デフォルト値。enumの場合: すべての値を列挙
+5. **テストカバレッジの確認**: テストファイルをGlobする。どのインターフェースにテストがあるかを記録。テストの存在は報告前にGlobで確認する
+
+### reverse-engineerモード品質基準
+- すべての主張がfile:lineをevidenceとして引用
+- 識別子はコードからそのまま転記
+- テストの存在はGlobで確認済み（推測ではない）

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

@@ -27,13 +27,6 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 本エージェントの出力は **調査結果の検証と結論導出のみ**。
 解決策の導出は本エージェントのスコープ外。
 
-## 主な責務
-
-1. **Triangulation補完** - 調査で触れられていない情報源を探索し、調査結果を補完
-2. **ACH（競合仮説分析）** - 調査で挙げられた仮説以外の代替仮説を生成し、証拠との整合性を評価
-3. **Devil's Advocate** - 「調査結果が誤りである」と仮定し、反証を積極的に探す
-4. **結論の導出** - 「最も反証されなかった仮説」として結論を導出
-
 ## 実行ステップ
 
 ### ステップ1: 調査結果の検証準備
@@ -52,11 +45,13 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - impactAnalysisの論理的妥当性を確認（追加検索は行わない）
 
 ### ステップ2: Triangulation補完
-調査で確認されていない情報源を探索：
-- 別のコード領域
-- 異なる設定ファイル
-- 関連する外部ドキュメント
-- git履歴の別の観点
+調査の`investigationSources`でカバーされていないソースタイプを特定し、少なくとも1つを調査する:
+
+1. 入力の`investigationSources`を確認 — カバー済みのソースタイプ（code, history, dependency, config, document, external）を列挙
+2. 未カバーの各ソースタイプについて: 仮説に関連する対象を絞った調査を実施
+3. すべてのソースタイプがカバー済みの場合: 元の調査で言及されていない**別のコード領域**または**別の設定**を調査する
+
+各補完的な発見について、既存仮説への影響を記録する。
 
 ### ステップ3: 外部情報で補強（WebSearch）
 - 調査で見つかった仮説に関する公式情報

package/.claude/commands-en/diagnose.md

@@ -81,7 +81,18 @@ Register the following with TaskCreate and execute:
 Invoke investigator using Agent tool:
 - `subagent_type`: "investigator"
 - `description`: "Collect problem information"
-- `prompt`: "Comprehensively collect information related to the following phenomenon. Phenomenon: [Problem reported by user]"
+- `prompt`: |
+    Comprehensively collect information related to the following phenomenon.
+
+    Phenomenon: [Problem reported by user]
+
+    Problem essence: [taskEssence from Step 0.3]
+    Investigation focus: [investigationFocus from Step 0.4]
+
+    [For change failures, additionally include:]
+    Change details: [What was changed]
+    Affected area: [What broke]
+    Shared components: [Commonalities between cause and effect]
 
 **Expected output**: Evidence matrix, comparison analysis results, causal tracking results, list of unexplored areas, investigation limitations
 
@@ -90,12 +101,20 @@ Invoke investigator using Agent tool:
 Review investigation output:
 
 **Quality Check** (verify JSON output contains the following):
-- [ ] comparisonAnalysis
-- [ ] causalChain for each hypothesis (reaching stop condition)
-- [ ] causeCategory for each hypothesis
-- [ ] Investigation covering investigationFocus items (when provided)
-
-**If quality insufficient**: Re-run investigator specifying missing items
+- [ ] `comparisonAnalysis` is present and `normalImplementation` is not null (comparison target found) OR explicitly recorded as "no working implementation found"
+- [ ] `causalChain` for each hypothesis reaches a stop condition (code change / design decision / external constraint)
+- [ ] `causeCategory` for each hypothesis is one of: typo / logic_error / missing_constraint / design_gap / external_factor
+- [ ] `investigationSources` covers at least 3 distinct source types (code, history, dependency, config, document, external)
+- [ ] Investigation covers `investigationFocus` items (when provided in Step 0.4)
+- [ ] Each hypothesis has at least 1 entry in `supportingEvidence` with a `source` field citing a specific file or location
+
+**If quality insufficient**: Re-run investigator specifying missing items explicitly:
+- `prompt`: |
+    Re-investigate with focus on the following gaps:
+    - Missing: [list specific missing items from quality check]
+
+    Previous investigation results (for context, do not re-investigate covered areas):
+    [Previous investigation JSON]
 
 **design_gap Escalation**: