create-ai-project 1.19.0 → 1.20.0

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

@@ -9,6 +9,15 @@ skills: frontend-typescript-rules, frontend-typescript-testing, coding-standards
 
 CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
 
+## フェーズ開始ゲート [BLOCKING — 未チェック項目があればHALT]
+
+☐ [確認済] frontmatterの全必須スキルがロード済み
+☐ [確認済] タスクファイルが存在し未完了項目がある
+☐ [確認済] タスクファイルから対象ファイルリストを抽出済み
+☐ [確認済] 調査対象を読み込み主要な所見を記録済み（タスクファイルに記載がある場合）
+
+**強制**: いずれかが未チェックの場合はHALTし、`status: "escalation_needed"`を返却。
+
 ## 必須ルール
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -105,7 +114,13 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 `docs/plans/tasks/*-task-*.md` パターンのファイルで、未完了チェックボックス `[ ]` が残っているものを選択して実行
 
 ### 2. タスク背景理解
-**依存成果物の活用**:
+#### 調査対象（タスクファイルに記載がある場合は必須）
+1. タスクファイル「調査対象」セクションからファイルパスを抽出
+2. **実装前に**各ファイルをReadツールで読み込む。サーチヒントが付与されている場合（例: `(§ Auth Flow)` や `(authenticateUser関数)`）、そのセクションを特定して重点的に確認
+3. 各調査対象で観察した主要なインターフェース・関数シグネチャ、制御/データフロー、状態遷移、副作用を記録する — これらの所見が実装をガイドする
+4. 調査対象のファイルが存在しない、またはパスが古い場合は `reason: "investigation_target_not_found"` でエスカレーション（エスカレーションレスポンス2-3参照）
+
+#### 依存成果物
 1. タスクファイル「Dependencies」セクションからパスを抽出
 2. 各成果物をReadツールで読み込み
 3. **具体的な活用方法**:
@@ -252,9 +267,39 @@ Design Doc通りに実装できない場合、以下のJSON形式でエスカレ
 }
 ```
 
-## 完了条件
+#### 2-3. 調査対象未発見エスカレーション
+調査対象のファイルが存在しない、またはパスが古い場合、以下のJSON形式でエスカレーション:
+
+```json
+{
+  "status": "escalation_needed",
+  "reason": "Investigation target not found",
+  "taskName": "[実行中のタスク名]",
+  "escalation_type": "investigation_target_not_found",
+  "missingTargets": [
+    {
+      "path": "[タスクファイルで指定されたパス]",
+      "searchHint": "[セクション/関数ヒントがある場合はそれ、なければnull]",
+      "searchAttempts": ["パスを直接確認", "同一ディレクトリ内で類似ファイル名を検索"]
+    }
+  ],
+  "user_decision_required": true,
+  "suggested_options": [
+    "正しいファイルパスを提供",
+    "この調査対象を除外して続行",
+    "タスクファイルを現在のパスで更新"
+  ]
+}
+```
+
+## 完了ゲート [BLOCKING]
+
+☐ 全タスクチェックボックスがエビデンス付きで完了
+☐ 調査対象を読み込み、実装前に所見を記録した（タスクファイルに記載がある場合）
+☐ 実装が調査対象から記録した所見と整合している
+☐ 最終レスポンスが`completed`または`escalation_needed`ステータスの単一JSON
 
-- [ ] 最終レスポンスが`completed`または`escalation_needed`ステータスの単一JSON
+**強制**: いずれかが未チェックの場合はHALT。`status: "escalation_needed"`を返却。
 
 ## 実行原則
 

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

@@ -9,6 +9,15 @@ skills: typescript-rules, typescript-testing, coding-standards, project-context,
 
 CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
 
+## フェーズ開始ゲート [BLOCKING — 未チェック項目があればHALT]
+
+☐ [確認済] frontmatterの全必須スキルがロード済み
+☐ [確認済] タスクファイルが存在し未完了項目がある
+☐ [確認済] タスクファイルから対象ファイルリストを抽出済み
+☐ [確認済] 調査対象を読み込み主要な所見を記録済み（タスクファイルに記載がある場合）
+
+**強制**: いずれかが未チェックの場合はHALTし、`status: "escalation_needed"`を返却。
+
 ## 必須ルール
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -102,7 +111,13 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 `docs/plans/tasks/*-task-*.md` パターンのファイルから、未完了のチェックボックス `[ ]` が残っているものを選択して実行
 
 ### 2. タスク背景理解
-**依存成果物の活用**：
+#### 調査対象（タスクファイルに記載がある場合は必須）
+1. タスクファイル「調査対象」セクションからファイルパスを抽出
+2. **実装前に**各ファイルをReadツールで読み込む。サーチヒントが付与されている場合（例: `(§ Auth Flow)` や `(authenticateUser関数)`）、そのセクションを特定して重点的に確認
+3. 各調査対象で観察した主要なインターフェース・関数シグネチャ、制御/データフロー、状態遷移、副作用を記録する — これらの所見が実装をガイドする
+4. 調査対象のファイルが存在しない、またはパスが古い場合は `reason: "investigation_target_not_found"` でエスカレーション（エスカレーションレスポンス2-3参照）
+
+#### 依存成果物
 1. タスクファイルの「依存」セクションからパスを取得
 2. 各成果物をReadツールで読み込み
 3. **具体的活用**：
@@ -249,9 +264,39 @@ Design Doc通りに実装できない場合は以下のJSON形式でエスカレ
 }
 ```
 
-## 完了条件
+#### 2-3. 調査対象未発見エスカレーション
+調査対象のファイルが存在しない、またはパスが古い場合、以下のJSON形式でエスカレーション:
+
+```json
+{
+  "status": "escalation_needed",
+  "reason": "Investigation target not found",
+  "taskName": "[実行中のタスク名]",
+  "escalation_type": "investigation_target_not_found",
+  "missingTargets": [
+    {
+      "path": "[タスクファイルで指定されたパス]",
+      "searchHint": "[セクション/関数ヒントがある場合はそれ、なければnull]",
+      "searchAttempts": ["パスを直接確認", "同一ディレクトリ内で類似ファイル名を検索"]
+    }
+  ],
+  "user_decision_required": true,
+  "suggested_options": [
+    "正しいファイルパスを提供",
+    "この調査対象を除外して続行",
+    "タスクファイルを現在のパスで更新"
+  ]
+}
+```
+
+## 完了ゲート [BLOCKING]
+
+☐ 全タスクチェックボックスがエビデンス付きで完了
+☐ 調査対象を読み込み、実装前に所見を記録した（タスクファイルに記載がある場合）
+☐ 実装が調査対象から記録した所見と整合している
+☐ 最終レスポンスが`completed`または`escalation_needed`ステータスの単一JSON
 
-- [ ] 最終レスポンスが`completed`または`escalation_needed`ステータスの単一JSON
+**強制**: いずれかが未チェックの場合はHALT。`status: "escalation_needed"`を返却。
 
 ## 実行原則
 

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

@@ -173,6 +173,13 @@ Design Doc作成前に実施：
   - `reverse-engineer`: 既存フロントエンドアーキテクチャの現状ドキュメント化（reverse-engineerモードセクション参照）
 
 - **要件分析結果**: 要件分析の結果（規模判定、技術要件等）
+- **コードベース分析**（任意、コードベース分析エージェントから提供）:
+  - 提供された場合、「既存コードベース分析」セクションの主要ソースとして使用
+  - `existingElements` → Implementation Path MappingとCode Inspection Evidenceに反映
+  - `dataModel` → データ関連セクション（スキーマ参照、データ契約）に反映
+  - `focusAreas` → フラグされた領域の調査深度を優先
+  - `constraints` → 設計上の制約と前提条件に組み込む
+  - 分析でカバーされていない領域、または`limitations`でフラグされた領域についてのみ追加調査を実施
 - **PRD**: PRDドキュメント（存在する場合）
 - **UI Spec**: UI Specパス（存在する場合、コンポーネント構造と状態設計を継承）
 - **作成対象ドキュメント**: ADR、Design Doc、または両方

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

@@ -200,6 +200,13 @@ Design Doc作成前に実施：
   - `reverse-engineer`: 既存アーキテクチャの現状ドキュメント化（reverse-engineerモードセクション参照）
 
 - **要件分析結果**: 要件分析の結果（規模判定、技術要件等）
+- **コードベース分析**（任意、コードベース分析エージェントから提供）:
+  - 提供された場合、「既存コードベース分析」セクションの主要ソースとして使用
+  - `existingElements` → Implementation Path MappingとCode Inspection Evidenceに反映
+  - `dataModel` → データ関連セクション（スキーマ参照、データ契約）に反映
+  - `focusAreas` → フラグされた領域の調査深度を優先
+  - `constraints` → 設計上の制約と前提条件に組み込む
+  - 分析でカバーされていない領域、または`limitations`でフラグされた領域についてのみ追加調査を実施
 - **PRD**: PRDドキュメント（存在する場合）
 - **作成するドキュメント**: ADR、Design Doc、または両方
 - **既存アーキテクチャ情報**: 

package/.claude/agents-ja/work-planner.md

@@ -115,30 +115,50 @@ Design Docの受入条件を基に、段階的に品質を確保。
 
 テストスケルトンファイル（統合テスト、E2Eテスト）をReadツールで読み込み、コメントからメタ情報を抽出する。
 
-**抽出対象のコメントパターン**:
-- `// @category:` → テスト分類（core-functionality, edge-case, e2e等）
-- `// @dependency:` → 依存コンポーネント（フェーズ配置の判断材料）
-- `// @complexity:` → 複雑度（high/medium/low、工数見積もりの判断材料）
-- `// fast-check:` → Property-Based Test実装パターン（**重要**: このコメントがあるテストは「fast-checkライブラリ使用」と作業計画に明記）
-- `// ROI:` → 優先度判断
+**抽出対象のアノテーションパターン**（コメント構文はプロジェクト言語に依存）:
+- `@category:` → テスト分類（core-functionality, edge-case, e2e等）
+- `@dependency:` → 依存コンポーネント（フェーズ配置の判断材料）
+- `@complexity:` → 複雑度（high/medium/low、工数見積もりの判断材料）
+- `@real-dependency:` → 非モックセットアップが必要なコンポーネント。環境セットアップ完了後のフェーズに配置
+- `fast-check:` → Property-Based Test実装パターン（**重要**: このコメントがあるテストは「fast-checkライブラリ使用」と作業計画に明記）
+- `ROI:` → 優先度判断
 
 #### Step 2: メタ情報の作業計画への反映
 
 1. **Property-Based Test（fast-check）の明記**
-   - `// fast-check:` コメントがあるテスト → 該当タスクの実装手順に以下を追加:
+   - `fast-check:` コメントがあるテスト → 該当タスクの実装手順に以下を追加:
      - 「fast-checkライブラリを使用したproperty-based testを実装」
      - コメント内のパターン（`fc.property(...)`）をサンプルコードとして記載
 
 2. **依存関係に基づくフェーズ配置**
-   - `// @dependency: none` → 早いフェーズに配置
-   - `// @dependency: [コンポーネント名]` → 依存コンポーネント実装後のフェーズに配置
-   - `// @dependency: full-system` → 最終フェーズに配置
+   - `@dependency: none` → 早いフェーズに配置
+   - `@dependency: [コンポーネント名]` → 依存コンポーネント実装後のフェーズに配置
+   - `@dependency: full-system` → 最終フェーズに配置
 
 3. **複雑度に基づく工数見積もり**
-   - `// @complexity: high` → タスクを細分化、または工数を多めに見積もる
-   - `// @complexity: low` → 複数テストを1タスクにまとめることを検討
+   - `@complexity: high` → タスクを細分化、または工数を多めに見積もる
+   - `@complexity: low` → 複数テストを1タスクにまとめることを検討
 
-#### Step 3: it.todoの構造分析と分類
+#### Step 3: E2EスケルトンからのEnvironment Prerequisites抽出
+
+E2Eテストスケルトンが提供された場合、2段階で環境前提条件をスキャンする:
+
+**Stage 1: 前提条件パターンの検出** — 全E2Eスケルトンをスキャンし、検出した全前提条件を列挙:
+- seed data、テストユーザー、サブスクリプション、特定のDB状態に言及する`Preconditions:`または`Arrange:`コメントアノテーション
+- auth/loginセットアップコードと組み合わされた`@dependency: full-system`
+- 環境変数への参照（`E2E_*`, `TEST_*`）
+- テストコード内のHTTP mock/interceptパターンを必要とする外部サービス参照
+
+**Stage 2: セットアップタスクの生成** — 検出した各前提条件に対応するPhase 0タスクを作成。一般的なカテゴリ:
+- **Seed data** → 「E2E seed data scriptの作成（テストユーザー、必要なレコード）」
+- **Auth fixture** → 「アプリケーションのログインフローを使用したE2E auth fixtureの実装」
+- **外部サービスモック** → 「E2Eテスト用の外部サービスモック設定」
+- **環境設定** → 「E2E環境変数の定義とセットアップ手順の文書化」
+- **その他の検出された前提条件** → 検出カテゴリに合わせたセットアップタスクを作成
+
+全環境セットアップタスクをPhase 0（実装タスクより前）に配置する。トレーサビリティのため`@category: e2e-setup`を付与。
+
+#### Step 4: it.todoの構造分析と分類
 
 1. **it.todoの構造分析と分類**
    - セットアップ系（Mock準備、測定ツール、Helper等）→ Phase 1に最優先配置
@@ -181,7 +201,7 @@ Design Docの技術的依存関係と実装アプローチに基づいてフェ
 最終フェーズには必ず品質保証（全テスト通過、受入条件達成）を含める。
 
 ### テストスケルトンの統合
-計画プロセスのステップ4で定義したテストスケルトン配置ルールに従う。
+計画プロセス（フェーズ構成ステップ）で定義したテストスケルトン配置ルールに従う。
 
 ### タスクの依存関係
 - 依存関係を明確に定義
@@ -199,6 +219,9 @@ Design Docの技術的依存関係と実装アプローチに基づいてフェ
 - [ ] 全要件のタスク化
 - [ ] 最終フェーズに品質保証の存在
 - [ ] テストスケルトンファイルパスを対応するフェーズに記載（提供時）
+- [ ] E2E環境前提条件に対応済み（E2Eスケルトンが提供された場合）
+  - [ ] seed data、auth fixture、外部サービスモックのタスクを生成
+  - [ ] 環境セットアップタスクをPhase 0に配置
 - [ ] テスト設計情報の反映（提供された場合のみ）
   - [ ] セットアップタスクが最初のフェーズに配置されている
   - [ ] リスクレベルに基づく優先順位付けが適用されている

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

@@ -11,7 +11,8 @@ description: Execute from requirement analysis to design document creation
 **Execution Protocol**:
 1. **Delegate all work through Agent tool** — invoke sub-agents, pass data between them, and report results (permitted tools: see subagents-orchestration-guide "Orchestrator's Permitted Tools")
 2. **Follow subagents-orchestration-guide skill design flow exactly**:
-   - Execute: requirement-analyzer → technical-designer → document-reviewer → design-sync
+   - Execute: requirement-analyzer → codebase-analyzer → technical-designer → code-verifier → document-reviewer → design-sync
+   - **ADR-only**: Skip codebase-analyzer and code-verifier (these apply to Design Doc only)
    - **Stop at every `[Stop: ...]` marker** → Wait for user approval before proceeding
 3. **Scope**: Complete when design documents receive approval
 
@@ -22,7 +23,9 @@ description: Execute from requirement analysis to design document creation
 ```
 Requirements → requirement-analyzer → [Stop: Scale determination]
                                            ↓
-                                   technical-designer → document-reviewer
+                                   codebase-analyzer → technical-designer
+                                           ↓
+                                   code-verifier → document-reviewer
                                            ↓
                                       design-sync → [Stop: Design approval]
 ```
@@ -38,12 +41,16 @@ Once requirements are moderately clarified, analyze with requirement-analyzer an
 
 Clearly present design alternatives and trade-offs.
 
+Execute the process below within design scope. Follow subagents-orchestration-guide Call Examples for codebase-analyzer and code-verifier invocations.
+
 ## Scope Boundaries
 
 **Included in this command**:
 - Requirement analysis with requirement-analyzer
+- Codebase analysis with codebase-analyzer (before technical design)
 - ADR creation (if architecture changes, new technology, or data flow changes)
 - Design Doc creation with technical-designer
+- Design Doc verification with code-verifier (before document review)
 - Document review with document-reviewer
 - Design Doc consistency verification with design-sync
 
@@ -52,17 +59,21 @@ Clearly present design alternatives and trade-offs.
 ## Execution Flow
 
 1. requirement-analyzer → Requirement analysis
-2. technical-designer → Design Doc creation
-3. document-reviewer → Single document quality check
-4. User approval (WAIT for approval)
-5. design-sync → Design Doc consistency verification
+2. codebase-analyzer → Codebase analysis (pass requirement-analyzer output)
+3. technical-designer → Design Doc creation (pass codebase-analyzer output)
+4. code-verifier → Verify Design Doc against existing code
+5. document-reviewer → Single document quality check (pass code-verifier results)
+6. User approval (WAIT for approval)
+7. design-sync → Design Doc consistency verification
    - IF conflicts found → Report to user → Wait for fix instructions → Fix with technical-designer(update)
    - IF no conflicts → End
 
 ## Completion Criteria
 
 - [ ] Executed requirement-analyzer and determined scale
+- [ ] Executed codebase-analyzer and passed results to technical-designer
 - [ ] Created appropriate design document (ADR or Design Doc) with technical-designer
+- [ ] Executed code-verifier on Design Doc and passed results to document-reviewer (skip for ADR-only)
 - [ ] Executed document-reviewer and addressed feedback
 - [ ] Executed design-sync for consistency verification
 - [ ] Obtained user approval for design document

package/.claude/commands-en/front-design.md

@@ -20,9 +20,11 @@ Orchestrator invokes sub-agents and passes structured JSON between them.
 
 **Included in this command**:
 - Requirement analysis with requirement-analyzer
+- Codebase analysis with codebase-analyzer (before Design Doc creation)
 - UI Specification creation with ui-spec-designer (prototype code inquiry included)
 - ADR creation (if architecture changes, new technology, or data flow changes)
 - Design Doc creation with technical-designer-frontend
+- Design Doc verification with code-verifier (before document review)
 - Document review with document-reviewer
 
 **Responsibility Boundary**: This command completes with frontend design document (UI Spec/ADR/Design Doc) approval. Work planning and beyond are outside scope.
@@ -63,12 +65,18 @@ Then create the UI Specification:
 - **[STOP]**: Present UI Spec for user approval
 
 ### Step 3: Design Document Creation Phase
+First, analyze the existing codebase:
+- Invoke **codebase-analyzer** using Agent tool
+  - `subagent_type: "codebase-analyzer"`, `description: "Codebase analysis"`, `prompt: "requirement_analysis: [JSON from Step 1]. requirements: [user requirements]. Analyze existing codebase for frontend design guidance."`
+
 Create appropriate design documents according to scale determination:
 - Invoke **technical-designer-frontend** using Agent tool
   - For ADR: `subagent_type: "technical-designer-frontend"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]"`
-  - For Design Doc: `subagent_type: "technical-designer-frontend"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on requirements. UI Spec is at [ui-spec path]. Inherit component structure and state design from UI Spec."`
-- Invoke **document-reviewer** to verify consistency
-  - `subagent_type: "document-reviewer"`, `description: "Document review"`, `prompt: "Review [document path] for consistency and completeness"`
+  - For Design Doc: `subagent_type: "technical-designer-frontend"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on requirements. Codebase analysis: [JSON from codebase-analyzer]. UI Spec is at [ui-spec path]. Inherit component structure and state design from UI Spec."`
+- **(Design Doc only)** Invoke **code-verifier** to verify Design Doc against existing code. Skip for ADR.
+  - `subagent_type: "code-verifier"`, `description: "Design Doc verification"`, `prompt: "doc_type: design-doc document_path: [Design Doc path] Verify Design Doc against existing code."`
+- Invoke **document-reviewer** to verify consistency (pass code-verifier results for Design Doc; omit for ADR)
+  - `subagent_type: "document-reviewer"`, `description: "Document review"`, `prompt: "doc_type: DesignDoc target: [document path] mode: composite code_verification: [JSON from code-verifier] (Design Doc only) Review for consistency and completeness."`
 - **[STOP]**: Present design alternatives and trade-offs, obtain user approval
 
 ## Output Example

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

@@ -52,6 +52,8 @@ After scale determination, **register all steps of the applicable subagents-orch
 - [ ] Identified current progress position
 - [ ] Clarified next step
 - [ ] Recognized stopping points → **Use AskUserQuestion for confirmation at all Stop points**
+- [ ] codebase-analyzer included before each Design Doc creation
+- [ ] code-verifier included before document-reviewer for each Design Doc
 - [ ] Understood the 4-step cycle after task execution (task-executor → escalation judgment/follow-up → quality-fixer → commit)
 
 **Flow Adherence**: Follow "Autonomous Execution Task Management" in subagents-orchestration-guide skill, managing 4 steps with TaskCreate/TaskUpdate

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

@@ -142,9 +142,7 @@ prompt: |
   doc_type: PRD
   target: $STEP_2_OUTPUT
   mode: composite
-
-  ## Code Verification Results
-  $STEP_3_OUTPUT
+  code_verification: $STEP_3_OUTPUT
 
   ## Additional Review Focus
   - Alignment between PRD claims and verification evidence
@@ -308,9 +306,7 @@ prompt: |
   doc_type: DesignDoc
   target: $STEP_7_OUTPUT or $STEP_7_FRONTEND_OUTPUT
   mode: composite
-
-  ## Code Verification Results
-  $STEP_8_OUTPUT
+  code_verification: $STEP_8_OUTPUT
 
   ## Parent PRD
   $APPROVED_PRD_PATH

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

@@ -25,8 +25,8 @@ description: Update existing design documents (Design Doc / PRD / ADR) with revi
 Target document → [Stop: Confirm changes]
                         ↓
               technical-designer / technical-designer-frontend / prd-creator (update mode)
-                        ↓
-              document-reviewer → [Stop: Review approval]
+                        ↓ (Design Doc only)
+              code-verifier → document-reviewer → [Stop: Review approval]
                         ↓ (Design Doc only)
               design-sync → [Stop: Final approval]
 ```
@@ -113,6 +113,18 @@ prompt: |
 
 ### Step 5: Document Review [Stop]
 
+**For Design Doc updates only**: Before document-reviewer, invoke code-verifier:
+```
+subagent_type: code-verifier
+description: "Verify updated Design Doc"
+prompt: |
+  doc_type: design-doc
+  document_path: [path from Step 1]
+  Verify the updated Design Doc against current codebase.
+```
+
+**Store output as**: `$CODE_VERIFICATION_OUTPUT`
+
 Invoke document-reviewer:
 ```
 subagent_type: document-reviewer
@@ -123,6 +135,7 @@ prompt: |
   doc_type: [Design Doc / PRD / ADR]
   target: [path from Step 1]
   mode: standard
+  code_verification: $CODE_VERIFICATION_OUTPUT (Design Doc only, omit for PRD/ADR)
 
   Focus on:
   - Consistency of updated sections with rest of document
@@ -191,6 +204,7 @@ prompt: |
 - [ ] Identified target document
 - [ ] Clarified change content with user
 - [ ] Updated document with appropriate agent (update mode)
+- [ ] Executed code-verifier before document-reviewer (Design Doc only)
 - [ ] Executed document-reviewer and addressed feedback
 - [ ] Executed design-sync for consistency verification (Design Doc only)
 - [ ] Obtained user approval for updated document

package/.claude/commands-ja/design.md

@@ -11,7 +11,8 @@ description: 要件分析から設計書作成まで実行
 **実行プロトコル**:
 1. **全作業をAgentツールでサブエージェントに委譲** — サブエージェントの呼び出し、データの受け渡し、結果の報告（許可ツール: subagents-orchestration-guideスキル「オーケストレーターの許可ツール」参照）
 2. **subagents-orchestration-guideスキルの設計フローに厳密に従う**:
-   - 実行: requirement-analyzer → technical-designer → document-reviewer → design-sync
+   - 実行: requirement-analyzer → codebase-analyzer → technical-designer → code-verifier → document-reviewer → design-sync
+   - **ADRのみの場合**: codebase-analyzerとcode-verifierはスキップ（Design Docにのみ適用）
    - **`[停止: ...]`マーカーで必ず停止** → 次に進む前にユーザー承認を待つ
 3. **スコープ**: 設計書が承認されたら完了
 
@@ -22,7 +23,9 @@ description: 要件分析から設計書作成まで実行
 ```
 要件 → requirement-analyzer → [停止: 規模判定]
                                     ↓
-                            technical-designer → document-reviewer
+                            codebase-analyzer → technical-designer
+                                    ↓
+                            code-verifier → document-reviewer
                                     ↓
                                design-sync → [停止: 設計承認]
 ```
@@ -38,12 +41,16 @@ description: 要件分析から設計書作成まで実行
 
 設計の代替案とトレードオフを明確に提示します。
 
+subagents-orchestration-guideのCall Examplesに従い、codebase-analyzerとcode-verifierを呼び出す。
+
 ## スコープ境界
 
 **実行内容**:
 - requirement-analyzerによる要件分析
+- codebase-analyzerによるコードベース分析（技術設計の前に実施）
 - ADR作成（アーキテクチャ変更、新技術、データフロー変更がある場合）
 - technical-designerによるDesign Doc作成
+- code-verifierによるDesign Doc検証（ドキュメントレビューの前に実施）
 - document-reviewerによるドキュメントレビュー
 - design-syncによるDesign Doc間整合性検証
 
@@ -52,17 +59,21 @@ description: 要件分析から設計書作成まで実行
 ## 実行フロー
 
 1. requirement-analyzer → 要件分析
-2. technical-designer → Design Doc作成
-3. document-reviewer → 単一ドキュメント品質チェック
-4. ユーザー承認（承認を待つ）
-5. design-sync → Design Doc間整合性検証
+2. codebase-analyzer → コードベース分析（要件分析結果を入力）
+3. technical-designer → Design Doc作成（codebase-analyzer出力を入力）
+4. code-verifier → Design Docを既存コードに対して検証
+5. document-reviewer → 単一ドキュメント品質チェック（code-verifier結果を入力）
+6. ユーザー承認（承認を待つ）
+7. design-sync → Design Doc間整合性検証
    - 矛盾あり → ユーザーに報告 → 修正指示待ち → technical-designer(update)で修正
    - 矛盾なし → 終了
 
 ## 完了条件
 
 - [ ] requirement-analyzerを実行し規模を判定した
+- [ ] codebase-analyzerを実行し結果をtechnical-designerに渡した
 - [ ] technical-designerで適切な設計書（ADRまたはDesign Doc）を作成した
+- [ ] code-verifierでDesign Docを検証し結果をdocument-reviewerに渡した（ADRのみの場合はスキップ）
 - [ ] document-reviewerを実行しフィードバックに対応した
 - [ ] design-syncで整合性検証を実行した
 - [ ] ユーザーから設計書の承認を取得した

package/.claude/commands-ja/front-design.md

@@ -20,9 +20,11 @@ description: 要件分析からフロントエンド設計ドキュメント作
 
 **実行内容**:
 - requirement-analyzerによる要件分析
+- codebase-analyzerによるコードベース分析（Design Doc作成前に実施）
 - ui-spec-designerによるUI Spec作成（プロトタイプコード確認を含む）
 - ADR作成（アーキテクチャ変更、新技術、データフロー変更がある場合）
 - technical-designer-frontendによるDesign Doc作成
+- code-verifierによるDesign Doc検証（ドキュメントレビューの前に実施）
 - document-reviewerによるドキュメントレビュー
 
 **責務境界**: このコマンドはフロントエンド設計ドキュメント（UI Spec/ADR/Design Doc）の承認で責務完了。作業計画以降はスコープ外。
@@ -63,12 +65,18 @@ UI Specを作成:
 - **[停止]**: UI Specをユーザーに提示し承認を取得
 
 ### Step 3: 設計ドキュメント作成フェーズ
+まず既存コードベースを分析:
+- Agentツールで**codebase-analyzer**を呼び出す
+  - `subagent_type: "codebase-analyzer"`, `description: "コードベース分析"`, `prompt: "requirement_analysis: [Step 1のJSON]. requirements: [ユーザー要件]. フロントエンド設計ガイダンスのため既存コードベースを分析。"`
+
 規模判定に応じて適切な設計ドキュメントを作成:
 - Agentツールで**technical-designer-frontend**を呼び出す
   - ADRの場合: `subagent_type: "technical-designer-frontend"`, `description: "ADR作成"`, `prompt: "[技術決定]のADRを作成"`
-  - Design Docの場合: `subagent_type: "technical-designer-frontend"`, `description: "Design Doc作成"`, `prompt: "要件に基づいてDesign Docを作成。UI Specは[ui-specパス]。UI Specのコンポーネント構造と状態設計を継承。"`
-- **document-reviewer**で整合性検証
-  - `subagent_type: "document-reviewer"`, `description: "ドキュメントレビュー"`, `prompt: "[ドキュメントパス]の整合性と完成度をレビュー"`
+  - Design Docの場合: `subagent_type: "technical-designer-frontend"`, `description: "Design Doc作成"`, `prompt: "要件に基づいてDesign Docを作成。コードベース分析: [codebase-analyzerのJSON]。UI Specは[ui-specパス]。UI Specのコンポーネント構造と状態設計を継承。"`
+- **（Design Docのみ）** **code-verifier**でDesign Docを既存コードに対して検証。ADRの場合はスキップ。
+  - `subagent_type: "code-verifier"`, `description: "Design Doc検証"`, `prompt: "doc_type: design-doc document_path: [Design Docパス] Design Docを既存コードに対して検証。"`
+- **document-reviewer**で整合性検証（Design Docの場合はcode-verifier結果を渡す。ADRの場合は省略）
+  - `subagent_type: "document-reviewer"`, `description: "ドキュメントレビュー"`, `prompt: "doc_type: DesignDoc target: [ドキュメントパス] mode: composite code_verification: [code-verifierのJSON]（Design Docのみ） 整合性と完成度をレビュー。"`
 - **[停止]**: 設計の選択肢とトレードオフを提示し、ユーザー承認を取得
 
 ## 出力例

package/.claude/commands-ja/implement.md

@@ -52,6 +52,8 @@ requirement-analyzerの`crossLayerScope`がレイヤー横断（backend + fronte
 - [ ] 現在の進捗位置を特定した
 - [ ] 次のステップを明確にした
 - [ ] 停止ポイントを認識した → **全ての停止ポイントでAskUserQuestionを使用**
+- [ ] 各Design Doc作成前にcodebase-analyzerを含めた
+- [ ] 各Design DocレビューでDesign Doc前にcode-verifierを含めた
 - [ ] タスク実行後の4ステップサイクル（task-executor → エスカレーション判定・フォローアップ → quality-fixer → commit）を理解した
 
 **フロー厳守**: subagents-orchestration-guideスキルの「自律実行中のタスク管理」に従い、TaskCreate/TaskUpdateで4ステップを管理する

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

@@ -142,9 +142,7 @@ prompt: |
   doc_type: PRD
   target: $STEP_2_OUTPUT
   mode: composite
-
-  ## コード検証結果
-  $STEP_3_OUTPUT
+  code_verification: $STEP_3_OUTPUT
 
   ## 追加レビュー観点
   - PRD主張と検証evidenceの整合性
@@ -308,9 +306,7 @@ prompt: |
   doc_type: DesignDoc
   target: $STEP_7_OUTPUT または $STEP_7_FRONTEND_OUTPUT
   mode: composite
-
-  ## コード検証結果
-  $STEP_8_OUTPUT
+  code_verification: $STEP_8_OUTPUT
 
   ## 親PRD
   $APPROVED_PRD_PATH

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

@@ -25,8 +25,8 @@ description: 既存設計ドキュメント（Design Doc / PRD / ADR）をレビ
 対象ドキュメント → [停止: 変更内容確認]
                         ↓
               technical-designer / technical-designer-frontend / prd-creator（updateモード）
-                        ↓
-              document-reviewer → [停止: レビュー承認]
+                        ↓（Design Docのみ）
+              code-verifier → document-reviewer → [停止: レビュー承認]
                         ↓（Design Docのみ）
               design-sync → [停止: 最終承認]
 ```
@@ -113,6 +113,18 @@ prompt: |
 
 ### ステップ5: ドキュメントレビュー [停止]
 
+**Design Doc更新時のみ**: document-reviewerの前にcode-verifierを呼び出す:
+```
+subagent_type: code-verifier
+description: "更新されたDesign Docを検証"
+prompt: |
+  doc_type: design-doc
+  document_path: [ステップ1のパス]
+  更新されたDesign Docを現在のコードベースに対して検証する。
+```
+
+**出力を保存**: `$CODE_VERIFICATION_OUTPUT`
+
 document-reviewerを呼び出す:
 ```
 subagent_type: document-reviewer
@@ -123,6 +135,7 @@ prompt: |
   doc_type: [Design Doc / PRD / ADR]
   target: [ステップ1のパス]
   mode: standard
+  code_verification: $CODE_VERIFICATION_OUTPUT（Design Docのみ、PRD/ADRでは省略）
 
   注力ポイント:
   - 更新セクションとドキュメント全体の整合性
@@ -191,6 +204,7 @@ prompt: |
 - [ ] 対象ドキュメントを特定した
 - [ ] ユーザーと変更内容を確認した
 - [ ] 適切なエージェントでドキュメントを更新した（updateモード）
+- [ ] code-verifierをdocument-reviewerの前に実行した（Design Docのみ）
 - [ ] document-reviewerを実行しフィードバックに対応した
 - [ ] design-syncで整合性検証を実行した（Design Docのみ）
 - [ ] 更新されたドキュメントのユーザー承認を取得した

package/.claude/skills-en/documentation-criteria/references/design-template.md

@@ -266,6 +266,26 @@ Evaluate the following for this feature's trust boundaries and data flow:
 
 Mark items as N/A with brief rationale when the feature has no relevant trust boundary.
 
+## Test Boundaries
+
+### Mock Boundary Decisions
+
+| Component/Dependency | Mock? | Rationale |
+|---------------------|-------|-----------|
+| [External API / DB / File system / etc.] | [Yes/No] | [Why this boundary was chosen] |
+
+### Data Layer Testing Strategy
+
+- **Schema dependencies**: [List tables/models this feature reads from or writes to, with paths to their definitions]
+- **Test data approach**: [How test data is provided — fixtures, factories, seed scripts, or real database]
+- **Mock limitations acknowledged**: [What cannot be reliably tested with mocks alone for this feature]
+
+Mark as N/A with brief rationale when the feature has no data layer dependencies.
+
+### Integration Verification Points
+
+- [List critical integration points that require testing beyond unit-level mocks]
+
 ## Alternative Solutions
 
 ### Alternative 1