create-ai-project 1.18.3 → 1.18.5

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

@@ -92,6 +92,7 @@ For DesignDoc, additionally verify:
 - Technical information verification: When sources exist, verify with WebSearch for latest information and validate claim validity
 - Failure scenario review: Identify failure scenarios across normal usage, high load, and external failures; specify which design element becomes the bottleneck
 - Code inspection evidence review: Verify inspected files are relevant to design scope; flag if key related files are missing
+- Dependency realizability check: For each dependency the Design Doc's Existing Codebase Analysis section describes as "existing", verify its definition exists in the codebase using Grep/Glob. Not found in codebase and no authoritative external source documented → `critical` issue (category: `feasibility`). Found but definition signature (method names, parameter types, return types) diverges from Design Doc description → `important` issue (category: `consistency`)
 - **As-is implementation document review**: When code verification results are provided and the document describes existing implementation (not future requirements), verify that code-observable behaviors are stated as facts; speculative language about deterministic behavior → `important` issue
 
 **Perspective-specific Mode**:
@@ -244,6 +245,7 @@ Include in output when `prior_context_count > 0`:
 - [ ] Gate 0 structural existence checks pass before quality review
 - [ ] Design decision rationales verified against identified standards/patterns
 - [ ] Code inspection evidence covers files relevant to design scope
+- [ ] Dependencies described as "existing" verified against codebase (Grep/Glob)
 - [ ] Field propagation map present when fields cross component boundaries
 
 ## Review Criteria (for Comprehensive Mode)

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

@@ -59,9 +59,17 @@ Must be performed before Design Doc creation:
      - Similar component is technical debt → Create ADR improvement proposal before implementation
      - No similar component → Proceed with new implementation
 
-4. **Include in Design Doc**
+4. **Dependency Existence Verification**
+   - For each component the design assumes already exists, search for its definition in the codebase using Grep/Glob
+   - Typical targets include: components, custom hooks, Context definitions, store/state definitions, API endpoints, type definitions, utility functions
+   - If found in codebase: record file path and definition location
+   - If found outside codebase (external API, separate repository, generated artifact): record the authoritative source and mark as "external dependency"
+   - If not found anywhere: mark as "requires new creation" in the Design Doc and reflect in implementation order dependencies
+
+5. **Include in Design Doc**
    - Always include investigation results in "## Existing Codebase Analysis" section
    - Clearly document similar component search results (found components or "none")
+   - Include dependency existence verification results (verified existing / requires new creation)
    - Record adopted decision (use existing/improvement proposal/new implementation) and rationale
 
 ### Integration Point Analysis【Important】

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

@@ -73,12 +73,20 @@ Must be performed before Design Doc creation:
      - Similar functionality is technical debt → Create ADR improvement proposal before implementation
      - No similar functionality → Proceed with new implementation
 
-4. **Include in Design Doc**
+4. **Dependency Existence Verification**
+   - For each component the design assumes already exists, search for its definition in the codebase using Grep/Glob
+   - Typical targets include: interfaces, classes, repositories, service methods, API endpoints, DB tables/columns, configuration keys, enum values, type definitions
+   - If found in codebase: record file path and definition location
+   - If found outside codebase (external API, separate repository, generated artifact): record the authoritative source and mark as "external dependency"
+   - If not found anywhere: mark as "requires new creation" in the Design Doc and reflect in implementation order dependencies
+
+5. **Include in Design Doc**
    - Always include investigation results in "## Existing Codebase Analysis" section
    - Clearly document similar functionality search results (found implementations or "none")
+   - Include dependency existence verification results (verified existing / requires new creation)
    - Record adopted decision (use existing/improvement proposal/new implementation) and rationale
 
-5. **Code Inspection Evidence**
+6. **Code Inspection Evidence**
    - Record all inspected files and key functions in "Code Inspection Evidence" section of Design Doc
    - Each entry must state relevance (similar functionality / integration point / pattern reference)
 

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

@@ -92,6 +92,7 @@ DesignDocの場合、追加で以下を確認:
 - 技術情報検証：出典がある場合はWebSearchで最新情報を確認、主張の妥当性を検証
 - 失敗シナリオ検証：正常系・高負荷・外部障害の失敗シナリオを特定し、どの設計要素がボトルネックになるか指摘
 - コード調査エビデンス検証：調査ファイルが設計スコープに関連するか確認、主要な関連ファイルの漏れを指摘
+- 依存先の実在性検証：Design Docの「既存コードベース分析」セクションが「既存」と記述する依存先について、Grep/Globでコードベース内の定義を確認。コードベースに見つからず公式の外部出典の記載もない → `critical`（カテゴリ: `feasibility`）。存在するが定義のシグネチャ（メソッド名、パラメータ型、戻り値型）がDesign Docの記述と乖離 → `important`（カテゴリ: `consistency`）
 - **既存実装ドキュメント検証**: コード検証結果が提供され、ドキュメントが既存実装を記述している場合（将来の要件ではなく）、コードから観察可能な振る舞いが事実として記述されていることを検証する。確定的な振る舞いに対する推測的な表現 → `important`
 
 **観点特化モード**:
@@ -244,6 +245,7 @@ DesignDocの場合、追加で以下を確認:
 - [ ] Gate 0の存在チェックが品質レビュー前に通過していること
 - [ ] 設計判断の根拠が特定された基準/パターンに照合されていること
 - [ ] コード調査エビデンスが設計スコープに関連するファイルを網羅していること
+- [ ] 「既存」と記述された依存先がコードベースに対して検証されていること（Grep/Glob）
 - [ ] フィールドが境界を越える場合にフィールド伝播マップが存在すること
 
 ## レビュー基準（総合モード用）

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

@@ -69,9 +69,17 @@ Design Doc作成前に必ず実施：
      - 類似コンポーネントが技術的負債 → ADRで改善提案を作成してから実装
      - 類似コンポーネントなし → 新規実装を進める
 
-4. **Design Docへの記載**
+4. **依存先の存在検証**
+   - 設計が「既存」と想定するコンポーネントについて、Grep/Globでコードベース内の定義を検索
+   - 典型的な対象: コンポーネント、カスタムフック、Context定義、ストア/状態定義、APIエンドポイント、型定義、ユーティリティ関数
+   - コードベースに存在 → ファイルパスと定義箇所を記録
+   - コードベース外に存在（外部API、別リポジトリ、生成物など） → 公式の出典を記録し「外部依存」としてマーク
+   - どこにも見つからない → Design Docで「新規作成が必要」とマークし、実装順序の依存関係に反映
+
+5. **Design Docへの記載**
    - 「## 既存コードベース分析」セクションに調査結果を必ず記載
    - 類似コンポーネントの検索結果（発見したコンポーネント、または「なし」）を明記
+   - 依存先の存在検証結果（既存確認済み / 新規作成が必要）を記載
    - 採用した判断（既存使用/改善提案/新規実装）とその根拠を記録
 
 ### 統合ポイント分析【重要】

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

@@ -73,12 +73,20 @@ Design Doc作成前に必ず実施：
      - 類似機能が技術的負債 → ADRで改善提案を作成してから実装
      - 類似機能なし → 新規実装を進める
 
-4. **Design Docへの記載**
+4. **依存先の存在検証**
+   - 設計が「既存」と想定するコンポーネントについて、Grep/Globでコードベース内の定義を検索
+   - 典型的な対象: インターフェース、クラス、リポジトリ、サービスメソッド、APIエンドポイント、DBテーブル/カラム、設定キー、enum値、型定義
+   - コードベースに存在 → ファイルパスと定義箇所を記録
+   - コードベース外に存在（外部API、別リポジトリ、生成物など） → 公式の出典を記録し「外部依存」としてマーク
+   - どこにも見つからない → Design Docで「新規作成が必要」とマークし、実装順序の依存関係に反映
+
+5. **Design Docへの記載**
    - 「## 既存コードベース分析」セクションに調査結果を必ず記載
    - 類似機能の検索結果（発見した実装、または「なし」）を明記
+   - 依存先の存在検証結果（既存確認済み / 新規作成が必要）を記載
    - 採用した判断（既存使用/改善提案/新規実装）とその根拠を記録
 
-5. **コード調査エビデンス**
+6. **コード調査エビデンス**
    - 調査したすべてのファイルと主要関数をDesign Docの「コード調査エビデンス」セクションに記録
    - 各エントリの関連性（類似機能 / 統合点 / パターン参照）を明記
 

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

@@ -35,7 +35,8 @@ Analyze task file existence state and determine the action required:
 |-------|----------|-------------|
 | Tasks exist | .md files in tasks/ directory | User's execution instruction serves as batch approval → Enter autonomous execution immediately |
 | No tasks + plan exists | Plan exists but no task files | Confirm with user → run task-decomposer |
-| Neither exists | No plan or task files | Error: Prerequisites not met |
+| Neither exists + Design Doc exists | No plan or task files, but docs/design/*.md exists | Invoke work-planner to create work plan from Design Doc, then proceed to task decomposition |
+| Neither exists | No plan, no task files, no Design Doc | Report missing prerequisites to user and stop |
 
 ## Task Decomposition Phase (Conditional)
 

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

@@ -42,7 +42,8 @@ Analyze task file existence state and determine the action required:
 |-------|----------|-------------|
 | Tasks exist | .md files in tasks/ directory | User's execution instruction serves as batch approval → Enter autonomous execution immediately |
 | No tasks + plan exists | Plan exists but no task files | Confirm with user → run task-decomposer |
-| Neither exists | No plan or task files | Error: Prerequisites not met |
+| Neither exists + Design Doc exists | No plan or task files, but docs/design/*.md exists | Invoke work-planner to create work plan from Design Doc, then proceed to task decomposition |
+| Neither exists | No plan, no task files, no Design Doc | Report missing prerequisites to user and stop |
 
 ## Task Decomposition Phase (Conditional)
 

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

@@ -44,7 +44,7 @@ Invoke acceptance-test-generator using Agent tool:
 Invoke work-planner using Agent tool:
 - `subagent_type`: "work-planner"
 - `description`: "Work plan creation"
-- `prompt`: "Create work plan from Design Doc at [path]. Integration test file: [path from step 2]. E2E test file: [path from step 2]. Integration tests are created simultaneously with each phase implementation, E2E tests are executed only in final phase."
+- `prompt`: "Create work plan from Design Doc at [path]. Integration test file: [integration test path from step 2]. E2E test file: [E2E test path from step 2]. Integration tests are created simultaneously with each phase implementation, E2E tests are executed only in final phase."
 
 Interact with user to complete plan and obtain approval for plan content. Clarify specific implementation steps and risks.
 

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

@@ -87,7 +87,7 @@ After all task cycles finish, invoke security-reviewer before the completion rep
    - `blocked` → Escalate to user
 
 ### Test Information Communication
-After acceptance-test-generator execution, when calling work-planner, communicate:
+After acceptance-test-generator execution, when invoking work-planner (subagent_type: "work-planner"), communicate:
 - Generated integration test file path
 - Generated E2E test file path
 - Explicit note that integration tests run with implementation, E2E tests run after all implementations

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

@@ -42,8 +42,15 @@ Follow subagents-orchestration-guide skill strictly and create work plan with th
    - Pass generation results to next process according to subagents-orchestration-guide skill coordination specification
 
 3. **Work Plan Creation**
-   - Create work plan with work-planner
-   - Utilize deliverables from previous process according to subagents-orchestration-guide skill coordination specification
+   Invoke work-planner using Agent tool:
+   - `subagent_type`: "work-planner"
+   - `description`: "Work plan creation"
+   - If test skeletons were generated in Step 2:
+     `prompt`: "Create work plan from Design Doc at [path]. Integration test file: [integration test path from step 2]. E2E test file: [E2E test path from step 2]. Integration tests are created simultaneously with each phase implementation, E2E tests are executed only in final phase."
+   - If test skeletons were not generated:
+     `prompt`: "Create work plan from Design Doc at [path]."
+
+   - Follow subagents-orchestration-guide Prompt Construction Rule for additional prompt parameters
    - Interact with user to complete plan and obtain approval for plan content
 
 Create a work plan from the selected design document, clarifying specific implementation steps and risks.

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

@@ -35,7 +35,8 @@ description: 分解済みタスクを自律実行モードで実装
 |------|---------|--------------|
 | タスク存在 | tasks/ディレクトリに.mdファイルあり | ユーザーの実行指示をバッチ承認として自律実行へ移行 |
 | タスクなし＋計画書あり | 計画書は存在するがタスクファイルなし | ユーザーに確認 → task-decomposer実行 |
-| 両方なし | 計画書もタスクファイルもなし | エラー：実行条件を満たさない |
+| 両方なし＋Design Docあり | 計画書・タスクファイルなし、docs/design/*.mdあり | work-plannerでDesign Docから作業計画書を作成し、タスク分解へ進む |
+| 両方なし | 計画書・タスクファイル・Design Docすべてなし | 前提条件未達成をユーザーに報告して停止 |
 
 ## タスク分解フェーズ（条件付き実行）
 

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

@@ -42,7 +42,8 @@ description: フロントエンド実装を自律実行モードで実行
 |------|------|--------------|
 | タスク存在 | tasks/ディレクトリに.mdファイルあり | ユーザーの実行指示をバッチ承認として自律実行へ移行 |
 | タスクなし+計画あり | 計画書は存在するがタスクファイルなし | ユーザー確認 → task-decomposer実行 |
-| どちらもなし | 計画書もタスクファイルもなし | エラー: 前提条件未達成 |
+| どちらもなし＋Design Docあり | 計画書・タスクファイルなし、docs/design/*.mdあり | work-plannerでDesign Docから作業計画書を作成し、タスク分解へ進む |
+| どちらもなし | 計画書・タスクファイル・Design Docすべてなし | 前提条件未達成をユーザーに報告して停止 |
 
 ## タスク分解フェーズ（条件付き）
 

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

@@ -44,7 +44,7 @@ Agentツールで**acceptance-test-generator**を呼び出す:
 Agentツールで**work-planner**を呼び出す:
 - `subagent_type`: "work-planner"
 - `description`: "作業計画書作成"
-- `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [step 2からのパス]。E2Eテストファイル: [step 2からのパス]。統合テストは各フェーズ実装と同時に作成、E2Eテストは最終フェーズでのみ実行。"
+- `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [ステップ2の統合テストパス]。E2Eテストファイル: [ステップ2のE2Eテストパス]。統合テストは各フェーズ実装と同時に作成、E2Eテストは最終フェーズでのみ実行。"
 
 ユーザーと対話して計画を完成させ、計画内容の承認を得る。具体的な実装ステップとリスクを明確化。
 

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

@@ -87,7 +87,7 @@ subagents-orchestration-guideスキルの「自律実行中のタスク管理」
    - `blocked` → ユーザーにエスカレーション
 
 ### テスト情報の伝達
-acceptance-test-generator実行後、work-planner呼び出し時には以下を伝達：
+acceptance-test-generator実行後、work-planner（subagent_type: "work-planner"）呼び出し時には以下を伝達：
 - 生成された統合テストファイルパス
 - 生成されたE2Eテストファイルパス
 - 統合テストは実装と同時、E2Eは全実装後に実行する旨の明示

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

@@ -42,8 +42,15 @@ description: 設計書から作業計画書を作成し計画承認を取得
    - 生成結果を subagents-orchestration-guideスキル の連携仕様に従って次工程に引き継ぐ
 
 3. **作業計画書の作成**
-   - work-planner で作業計画書を作成
-   - 前工程の成果物を subagents-orchestration-guideスキル の連携仕様に従って活用
+   Agentツールでwork-plannerを呼び出す:
+   - `subagent_type`: "work-planner"
+   - `description`: "作業計画書作成"
+   - ステップ2でテストスケルトンを生成した場合:
+     `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [ステップ2の統合テストパス]。E2Eテストファイル: [ステップ2のE2Eテストパス]。統合テストは各フェーズ実装と同時に作成、E2Eテストは最終フェーズでのみ実行。"
+   - テストスケルトンを生成しなかった場合:
+     `prompt`: "[パス]のDesign Docから作業計画を作成。"
+
+   - subagents-orchestration-guideのプロンプト構成ルールに従い追加パラメータを設定
    - ユーザーと対話して計画を完成させ、計画内容の承認を得る
 
 選択された設計書から作業計画書を作成し、実装の具体的なステップとリスクを明確にします。

package/.claude/skills-en/subagents-orchestration-guide/SKILL.md

@@ -151,7 +151,7 @@ According to scale determination:
 
 ### Small Scale (1-2 Files) - 2 Steps
 
-1. Create simplified plan **[Stop: Batch approval]**
+1. work-planner → Simplified work plan creation **[Stop: Batch approval]**
 2. Direct implementation → Completion report
 
 ## Cross-Layer Orchestration

package/.claude/skills-en/task-analyzer/references/skills-index.yaml

@@ -30,7 +30,7 @@ skills:
       - "Red-Green-Refactor Process (Test-First Development)"
       - "Test Design Principles"
       - "Test Granularity Principles"
-      - "Security Principles (Secure Defaults, Input and Output Boundaries, Access Control, Knowledge Cutoff Supplement)"
+      - "Security Principles"
 
   typescript-rules:
     skill: "typescript-rules"
@@ -230,6 +230,7 @@ skills:
       - "Test Implementation Conventions"
       - "Mock Type Safety Enforcement"
       - "Basic React Testing Library Example"
+      - "Test Design Patterns"
 
   frontend-technical-spec:
     skill: "frontend-technical-spec"

package/.claude/skills-ja/subagents-orchestration-guide/SKILL.md

@@ -144,7 +144,7 @@ graph TD
 
 ### 小規模（1-2ファイル） - 2ステップ
 
-1. 簡易計画書作成 **[停止: 一括承認]**
+1. work-planner → 簡易作業計画書を作成 **[停止: 一括承認]**
 2. 直接実装 → 完了報告
 
 ## レイヤー横断オーケストレーション

package/.claude/skills-ja/task-analyzer/references/skills-index.yaml

@@ -212,14 +212,13 @@ skills:
       - "ADR-0002 Co-location原則"
       - "references/e2e.md - Playwright E2Eパターン"
     sections:
-      - "References"
       - "テストフレームワーク"
       - "テストの基本方針"
       - "テストの実装規約"
       - "モックの型安全性の徹底"
       - "React Testing Libraryの基本例"
       - "テスト品質基準"
-      - "アンチパターン"
+      - "テスト設計パターン"
 
   frontend-technical-spec:
     skill: "frontend-technical-spec"

package/CHANGELOG.md

@@ -5,6 +5,32 @@ 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.5] - 2026-03-29
+
+### Fixed
+
+#### Dependency Existence Verification in Design Workflow
+Design documents could describe components as "existing" without verification, causing implementation failures when those dependencies turned out to be missing or mismatched.
+
+- `technical-designer` / `technical-designer-frontend`: Add **Dependency Existence Verification** step to Existing Code Investigation — each assumed dependency is now verified via Grep/Glob before design proceeds, with three-way classification (found in codebase / external dependency / requires new creation)
+- `document-reviewer`: Add **dependency realizability check** to Gate 1 — cross-checks claimed "existing" dependencies against the codebase during review. Missing dependency with no external source → `critical` (feasibility). Signature mismatch (method names, parameter types, return types) → `important` (consistency)
+
+## [1.18.4] - 2026-03-28
+
+### Fixed
+
+#### Work-Planner Invocation Clarity
+- `subagents-orchestration-guide`: Small Scale flow now explicitly names work-planner agent
+- `plan` command: Step 3 rewritten with explicit `subagent_type` and conditional prompt branching (with/without test skeletons)
+- `front-plan` command: Differentiate placeholder names (`[integration test path]` / `[E2E test path]` instead of identical `[path from step 2]`)
+- `build` / `front-build` commands: Split "Neither exists" state into Design Doc present (invoke work-planner) vs absent (report and stop)
+- `implement` command: Add explicit `subagent_type: "work-planner"` to test information communication section
+
+#### Skills Index Sync
+- `skills-index.yaml` (en): Remove stale parenthetical from coding-standards Security Principles section name
+- `skills-index.yaml` (en): Add missing `Test Design Patterns` section to frontend-typescript-testing
+- `skills-index.yaml` (ja): Remove stale `References` and `アンチパターン` sections from frontend-typescript-testing, add missing `テスト設計パターン`
+
 ## [1.18.3] - 2026-03-26
 
 ### Changed

package/package.json

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