create-ai-project 1.18.2 → 1.18.4

package/.claude/agents-en/task-decomposer.md

@@ -85,7 +85,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
    - **Phase Completion Task Auto-generation (Required)**:
      - Based on "Phase X" notation in work plan, generate after each phase's final task
      - Filename: `{plan-name}-phase{number}-completion.md`
-     - Content: Copy E2E verification procedures from Design Doc, all task completion checklist
+     - Content: All task completion checklist, list test skeleton file paths for verification
      - Criteria: Always generate if the plan contains the string "Phase"
 
 5. **Task Structuring**

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

@@ -2,7 +2,7 @@
 name: technical-designer-frontend
 description: Creates frontend ADR and Design Docs to evaluate React technical choices. Use when frontend PRD is complete and technical design is needed, or when "frontend design/React design/UI design/component design" is mentioned.
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, frontend-technical-spec, frontend-typescript-rules, coding-standards, project-context, implementation-approach
+skills: documentation-criteria, frontend-technical-spec, frontend-typescript-rules, coding-standards, project-context, implementation-approach, typescript-testing
 ---
 
 You are a frontend technical design specialist AI assistant for creating Architecture Decision Records (ADR) and Design Documents.
@@ -22,6 +22,7 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 - Apply coding-standards skill for universal coding standards and pre-implementation existing code investigation process
 - Apply project-context skill for project context
 - Apply implementation-approach skill for metacognitive strategy selection process (used for implementation approach decisions)
+- Apply typescript-testing skill for test design standards (testable AC format, coverage requirements)
 
 ## Main Responsibilities
 
@@ -308,9 +309,9 @@ class Button extends React.Component {
 - [ ] **Agreement checklist completed** (most important)
 - [ ] **Prerequisite common ADRs referenced** (required)
 - [ ] **Change impact map created** (required)
-- [ ] **Component verification procedures for each phase** (required)
 - [ ] Response to requirements and design validity
-- [ ] Test strategy and error handling
+- [ ] Error handling strategy
+- [ ] Acceptance criteria written in testable format (concrete trigger, action, and expected result)
 - [ ] Props change matrix completeness
 - [ ] Implementation approach selection rationale (vertical/horizontal/hybrid)
 - [ ] Latest best practices researched and references cited

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

@@ -276,9 +276,9 @@ Implementation sample creation checklist:
 - [ ] **Agreement checklist completed** (most important)
 - [ ] **Prerequisite common ADRs referenced** (required)
 - [ ] **Change impact map created** (required)
-- [ ] **E2E verification procedures for each phase** (required)
 - [ ] Response to requirements and design validity
-- [ ] Test strategy and error handling
+- [ ] Error handling strategy
+- [ ] Acceptance criteria written in testable format (concrete trigger, action, and expected result)
 - [ ] Interface change matrix completeness
 - [ ] Implementation approach selection rationale (vertical/horizontal/hybrid)
 - [ ] Latest best practices researched and references cited

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

@@ -25,7 +25,7 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 Read the Design Doc(s), UI Spec, PRD, and ADR (if provided). Extract:
 - Acceptance criteria and implementation approach
 - Technical dependencies and implementation order
-- Integration points requiring E2E verification
+- Integration points and their contracts
 
 ### 2. Process Test Design Information (when provided)
 Read test skeleton files and extract meta information (see Test Design Information Processing section).
@@ -36,7 +36,8 @@ Choose Strategy A (TDD) if test skeletons are provided, Strategy B (implementati
 ### 4. Compose Phases
 Structure phases based on technical dependencies from Design Doc:
 - Place tasks with lowest dependencies in earlier phases
-- Include operational verification at integration points
+- When test skeletons are provided, place integration test implementation in corresponding phases and E2E test execution in the final phase
+- When test skeletons are not provided, include test implementation tasks based on Design Doc acceptance criteria
 - Include quality assurance in final phase
 
 ### 5. Define Tasks with Completion Criteria
@@ -180,8 +181,8 @@ Decompose tasks based on implementation approach and technical dependencies deci
 Compose phases based on technical dependencies and implementation approach from Design Doc.
 Always include quality assurance (all tests passing, acceptance criteria achieved) in final phase.
 
-### Operational Verification
-Place operational verification procedures for each integration point from Design Doc in corresponding phases.
+### Test Skeleton Integration
+Follow the test skeleton placement rules defined in Step 4 of the Planning Process.
 
 ### Task Dependencies
 - Clearly define dependencies
@@ -198,7 +199,7 @@ When creating work plans, **Phase Structure Diagrams** and **Task Dependency Dia
 - [ ] Phase composition based on technical dependencies
 - [ ] All requirements converted to tasks
 - [ ] Quality assurance exists in final phase
-- [ ] E2E verification procedures placed at integration points
+- [ ] Test skeleton file paths listed in corresponding phases (when provided)
 - [ ] Test design information reflected (only when provided)
   - [ ] Setup tasks placed in first phase
   - [ ] Risk level-based prioritization applied

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

@@ -85,7 +85,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
    - **フェーズ完了タスクの自動生成（必須）**:
      - 作業計画書の「Phase X」表記を基準に、各フェーズ最終タスクの後に生成
      - ファイル名: `{計画書名}-phase{番号}-completion.md`
-     - 内容: Design DocのE2E確認手順をコピー、全タスク完了チェックリスト
+     - 内容: 全タスク完了チェックリスト、テストスケルトンファイルパスを検証用に記載
      - 判断基準: 計画書に「Phase」という文字列があれば必ず生成
 
 5. **タスクの構造化**

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

@@ -2,7 +2,7 @@
 name: technical-designer-frontend
 description: フロントエンドADRとDesign Docを作成しReact技術選択肢を評価。Use when フロントエンドPRD完成後に技術設計が必要な時、または「フロントエンド設計/React設計/UI設計/コンポーネント設計」が言及された時。
 tools: Read, Write, Edit, MultiEdit, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
-skills: documentation-criteria, frontend-technical-spec, frontend-typescript-rules, coding-standards, project-context, implementation-approach
+skills: documentation-criteria, frontend-technical-spec, frontend-typescript-rules, coding-standards, project-context, implementation-approach, typescript-testing
 ---
 
 あなたはArchitecture Decision Record (ADR) と Design Document を作成するフロントエンド技術設計専門のAIアシスタントです。
@@ -22,6 +22,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - coding-standardsスキルで普遍的コーディング規約を適用
 - project-contextスキルでプロジェクトコンテキストを把握
 - implementation-approachスキルでメタ認知的戦略選択プロセスを実行
+- typescript-testingスキルでテスト設計基準を適用（テスト可能なAC形式、カバレッジ要件）
 
 ## UI Spec統合
 
@@ -308,9 +309,9 @@ class Button extends React.Component {
 - [ ] **合意事項チェックリストの完了**（最重要）
 - [ ] **前提となる共通ADRの参照**（必須）
 - [ ] **変更影響マップの作成**（必須）
-- [ ] **各フェーズのコンポーネント検証手順**（必須）
 - [ ] 要件への対応と設計の妥当性
-- [ ] テスト戦略とエラーハンドリング
+- [ ] エラーハンドリング戦略
+- [ ] 受入条件がテスト可能な形式で記述されていること（具体的なトリガー、操作、期待結果）
 - [ ] Props変更マトリクスの完成度
 - [ ] 実装アプローチ（垂直/水平/ハイブリッド）の選択根拠
 - [ ] 最新のベストプラクティスの調査と参考資料の記載

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

@@ -275,9 +275,9 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 - [ ] **合意事項チェックリストの完了**（最重要）
 - [ ] **前提となる共通ADRの参照**（必須）
 - [ ] **変更影響マップの作成**（必須）
-- [ ] **各フェーズのE2E確認手順**（必須）
 - [ ] 要件への対応と設計の妥当性
-- [ ] テスト戦略とエラーハンドリング
+- [ ] エラーハンドリング戦略
+- [ ] 受入条件がテスト可能な形式で記述されていること（具体的なトリガー、操作、期待結果）
 - [ ] インターフェース変更マトリクスの完成度
 - [ ] 実装アプローチ（垂直/水平/ハイブリッド）の選択根拠
 - [ ] 最新のベストプラクティスの調査と参考資料の記載

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

@@ -25,7 +25,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み、以下を抽出:
 - 受入条件と実装アプローチ
 - 技術的依存関係と実装順序
-- E2E検証が必要な統合ポイント
+- 統合ポイントとそのコントラクト
 
 ### 2. テスト設計情報の処理（提供時）
 テストスケルトンファイルを読み込み、メタ情報を抽出（テスト設計情報の処理セクションを参照）。
@@ -36,7 +36,8 @@ Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み
 ### 4. フェーズの構成
 Design Docの技術的依存関係に基づいてフェーズを構成:
 - 依存が最も少ないタスクを前のフェーズに配置
-- 統合ポイントに動作確認を含める
+- テストスケルトンが提供されている場合、統合テスト実装を対応するフェーズに配置し、E2Eテスト実行を最終フェーズに配置
+- テストスケルトンが提供されていない場合、Design Docの受入条件に基づくテスト実装タスクを含める
 - 最終フェーズに品質保証を含める
 
 ### 5. 完了条件付きタスクの定義
@@ -179,8 +180,8 @@ Design Docで決定された実装アプローチと技術的依存関係に基
 Design Docの技術的依存関係と実装アプローチに基づいてフェーズを構成。
 最終フェーズには必ず品質保証（全テスト通過、受入条件達成）を含める。
 
-### 動作確認
-Design Docの統合ポイントごとの動作確認手順を、対応するフェーズに配置。
+### テストスケルトンの統合
+計画プロセスのステップ4で定義したテストスケルトン配置ルールに従う。
 
 ### タスクの依存関係
 - 依存関係を明確に定義
@@ -197,7 +198,7 @@ Design Docの統合ポイントごとの動作確認手順を、対応するフ
 - [ ] 技術的依存関係に基づくフェーズ構成
 - [ ] 全要件のタスク化
 - [ ] 最終フェーズに品質保証の存在
-- [ ] 統合ポイントの動作確認手順配置
+- [ ] テストスケルトンファイルパスを対応するフェーズに記載（提供時）
 - [ ] テスト設計情報の反映（提供された場合のみ）
   - [ ] セットアップタスクが最初のフェーズに配置されている
   - [ ] リスクレベルに基づく優先順位付けが適用されている

package/.claude/commands-en/add-integration-tests.md

@@ -1,10 +1,8 @@
 ---
-description: Add integration/E2E tests to existing backend codebase using Design Doc
+description: Add integration/E2E tests to existing codebase using Design Docs
 ---
 
-**Command Context**: Test addition workflow for existing backend implementations
-
-**Scope**: Backend only (acceptance-test-generator supports backend only)
+**Command Context**: Test addition workflow for existing implementations (backend, frontend, or fullstack)
 
 ## Orchestrator Definition
 
@@ -21,10 +19,11 @@ description: Add integration/E2E tests to existing backend codebase using Design
 - Test review → delegate to integration-test-reviewer
 - Quality checks → delegate to quality-fixer
 
-Design Doc path: $ARGUMENTS
+Document paths: $ARGUMENTS
 
 ## Prerequisites
-- Design Doc must exist (created manually or via reverse-engineer)
+
+- At least one Design Doc must exist (created manually or via reverse-engineer)
 - Existing implementation to test
 
 ## Execution Flow
@@ -33,30 +32,51 @@ Design Doc path: $ARGUMENTS
 
 Execute Skill: documentation-criteria (for task file template in Step 3)
 
-### Step 1: Validate Design Doc
+### Step 1: Discover and Validate Documents
 
 ```bash
-# Verify Design Doc exists
-ls $ARGUMENTS || ls docs/design/*.md | grep -v template | tail -1
+# Verify at least one document path was provided
+test -n "$ARGUMENTS" || { echo "ERROR: No document paths provided"; exit 1; }
+
+# Verify provided paths exist
+ls $ARGUMENTS
+
+# Discover additional documents
+ls docs/design/*.md 2>/dev/null | grep -v template
+ls docs/ui-spec/*.md 2>/dev/null
 ```
 
+Classify discovered documents by filename:
+- Filename contains `backend` → **Design Doc (backend)**
+- Filename contains `frontend` → **Design Doc (frontend)**
+- Located in `docs/ui-spec/` → **UI Spec** (optional)
+- None of the above → **single-layer Design Doc** (layer TBD in gate below)
+
+**[GATE] Present classification results to user as candidates and ask for confirmation before proceeding.** The user may exclude irrelevant documents discovered by the automatic search. If a single-layer Design Doc is detected, ask the user whether it targets backend or frontend to determine correct agent routing.
+
 ### Step 2: Skeleton Generation
 
-Invoke acceptance-test-generator using Agent tool:
+Invoke acceptance-test-generator **once per Design Doc** (the agent expects a single designDocPath):
+
+For each Design Doc from Step 1:
 - `subagent_type`: "acceptance-test-generator"
-- `description`: "Generate test skeletons"
-- `prompt`: "Generate test skeletons from Design Doc at [path from Step 1]"
+- `description`: "Generate test skeletons for [layer/name]"
+- `prompt`: "Generate test skeletons from Design Doc at [path]." + If UI Spec exists: "UI Spec at [ui-spec path] is available as additional context."
 
-**Expected output**: `generatedFiles` containing integration and e2e paths
+**Expected output per invocation**: `generatedFiles` containing integration and e2e paths
 
-### Step 3: Create Task File [GATE]
+### Step 3: Create Task Files [GATE]
 
-Create task file at: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
+Create one task file per layer, using the monorepo-flow.md naming convention for deterministic agent routing:
+- Backend Design Doc → `docs/plans/tasks/integration-tests-backend-task-YYYYMMDD.md`
+- Frontend Design Doc → `docs/plans/tasks/integration-tests-frontend-task-YYYYMMDD.md`
+- Single-layer confirmed as backend → `docs/plans/tasks/integration-tests-backend-task-YYYYMMDD.md`
+- Single-layer confirmed as frontend → `docs/plans/tasks/integration-tests-frontend-task-YYYYMMDD.md`
 
-**Template**:
+**Template** (per task file):
 ```markdown
 ---
-name: Implement integration tests for [feature name]
+name: Implement [layer] integration tests for [feature name]
 type: test-implementation
 ---
 
@@ -66,8 +86,8 @@ Implement test cases defined in skeleton files.
 
 ## Target Files
 
-- Skeleton: [path from Step 2 generatedFiles]
-- Design Doc: [path from Step 1]
+- Skeleton: [layer-specific paths from Step 2 generatedFiles]
+- Design Doc: [layer-specific Design Doc from Step 1]
 
 ## Tasks
 
@@ -82,14 +102,17 @@ Implement test cases defined in skeleton files.
 - No quality issues
 ```
 
-**Output**: "Task file created at [path]. Ready for Step 4."
+**Output**: "Task file(s) created at [path(s)]. Ready for Step 4."
 
 ### Step 4: Test Implementation
 
-Invoke task-executor using Agent tool:
-- `subagent_type`: "task-executor"
+For each task file from Step 3, invoke task-executor routed by filename pattern:
+- `*-backend-task-*` → `subagent_type`: "task-executor"
+- `*-frontend-task-*` → `subagent_type`: "task-executor-frontend"
 - `description`: "Implement integration tests"
-- `prompt`: "Task file: docs/plans/tasks/integration-tests-YYYYMMDD.md. Implement tests following the task file."
+- `prompt`: "Task file: [task file path from Step 3]. Implement tests following the task file."
+
+Execute one task file at a time through Steps 4→5→6→7 before starting the next.
 
 **Expected output**: `status`, `testsAdded`
 
@@ -98,7 +121,7 @@ Invoke task-executor using Agent tool:
 Invoke integration-test-reviewer using Agent tool:
 - `subagent_type`: "integration-test-reviewer"
 - `description`: "Review test quality"
-- `prompt`: "Review test quality. Test files: [paths from Step 4 testsAdded]. Skeleton files: [paths from Step 2 generatedFiles]"
+- `prompt`: "Review test quality. Test files: [paths from Step 4 testsAdded]. Skeleton files: [layer-specific paths from Step 2 generatedFiles matching current task's layer]"
 
 **Expected output**: `status` (approved/needs_revision), `requiredFixes`
 
@@ -108,15 +131,17 @@ Check Step 5 result:
 - `status: approved` → Mark complete, proceed to Step 7
 - `status: needs_revision` → Invoke task-executor with requiredFixes, then return to Step 5
 
-Invoke task-executor using Agent tool:
-- `subagent_type`: "task-executor"
+Invoke task-executor routed by task filename pattern:
+- `*-backend-task-*` → `subagent_type`: "task-executor"
+- `*-frontend-task-*` → `subagent_type`: "task-executor-frontend"
 - `description`: "Fix review findings"
 - `prompt`: "Fix the following issues in test files: [requiredFixes from Step 5]"
 
 ### Step 7: Quality Check
 
-Invoke quality-fixer using Agent tool:
-- `subagent_type`: "quality-fixer"
+Invoke quality-fixer routed by task filename pattern:
+- `*-backend-task-*` → `subagent_type`: "quality-fixer"
+- `*-frontend-task-*` → `subagent_type`: "quality-fixer-frontend"
 - `description`: "Final quality assurance"
 - `prompt`: "Final quality assurance for test files added in this workflow. Run all tests and verify coverage."
 

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/add-integration-tests.md

@@ -1,10 +1,8 @@
 ---
-description: Design Docを使用して既存バックエンドコードベースに統合/E2Eテストを追加
+description: Design Docを使用して既存コードベースに統合/E2Eテストを追加
 ---
 
-**コマンドコンテキスト**: 既存バックエンド実装へのテスト追加ワークフロー
-
-**スコープ**: バックエンドのみ（acceptance-test-generatorはバックエンドのみ対応）
+**コマンドコンテキスト**: 既存実装へのテスト追加ワークフロー（バックエンド、フロントエンド、フルスタック対応）
 
 ## オーケストレーター定義
 
@@ -12,7 +10,7 @@ description: Design Docを使用して既存バックエンドコードベース
 
 **初動アクション**: ステップ0-8をTaskCreateで登録してから実行を開始。
 
-**委譲理由**: オーケストレーターとして、レビュー・品質チェックを含む全てのステップを完遂させるために、必要なコンテキストを維持する必要がある。タスクファイルをコンテキスト境界とし、全ての作業をサブエージェントが担うことでこれを実現する。
+**委譲理由**: オーケストレーターのコンテキストは全ステップで共有される。直接実装するとレビューや品質チェックに必要なコンテキストを消費してしまう。タスクファイルをコンテキスト境界とし、サブエージェントが隔離されたコンテキストで作業することでこれを回避する。
 
 **実行方法**:
 - スケルトン生成 → acceptance-test-generatorに委譲
@@ -21,10 +19,11 @@ description: Design Docを使用して既存バックエンドコードベース
 - テストレビュー → integration-test-reviewerに委譲
 - 品質チェック → quality-fixerに委譲
 
-Design Docパス: $ARGUMENTS
+ドキュメントパス: $ARGUMENTS
 
 ## 前提条件
-- Design Docが存在すること（手動またはreverse-engineerで作成）
+
+- Design Docが少なくとも1つ存在すること（手動またはreverse-engineerで作成）
 - テスト対象の既存実装があること
 
 ## 実行フロー
@@ -33,30 +32,51 @@ Design Docパス: $ARGUMENTS
 
 スキル実行: documentation-criteria（ステップ3のタスクファイルテンプレート用）
 
-### ステップ1: Design Doc検証
+### ステップ1: ドキュメントの探索と検証
 
 ```bash
-# Design Docの存在確認
-ls $ARGUMENTS || ls docs/design/*.md | grep -v template | tail -1
+# ドキュメントパスが指定されているか確認
+test -n "$ARGUMENTS" || { echo "ERROR: ドキュメントパスが指定されていません"; exit 1; }
+
+# 指定パスの存在確認
+ls $ARGUMENTS
+
+# 追加ドキュメントの探索
+ls docs/design/*.md 2>/dev/null | grep -v template
+ls docs/ui-spec/*.md 2>/dev/null
 ```
 
+探索されたドキュメントをファイル名で分類:
+- ファイル名に`backend`を含む → **Design Doc（バックエンド）**
+- ファイル名に`frontend`を含む → **Design Doc（フロントエンド）**
+- `docs/ui-spec/`配下 → **UI Spec**（任意）
+- 上記いずれにも該当しない → **単一レイヤーのDesign Doc**（レイヤーは下記のゲートで確定）
+
+**[GATE] 分類結果を候補としてユーザーに提示し、続行前に確認を得る。** 自動探索で検出された無関係なドキュメントはユーザーが除外できる。単一レイヤーのDesign Docが検出された場合、バックエンドとフロントエンドのどちらを対象とするかユーザーに確認し、正しいエージェントルーティングを決定する。
+
 ### ステップ2: スケルトン生成
 
-Agentツールでacceptance-test-generatorを呼び出す:
+**Design Docごとに**acceptance-test-generatorを呼び出す（エージェントは単一のdesignDocPathを前提とするため）:
+
+各Design Docに対して:
 - `subagent_type`: "acceptance-test-generator"
-- `description`: "テストスケルトン生成"
-- `prompt`: "[ステップ1のパス]のDesign Docからテストスケルトンを生成"
+- `description`: "[レイヤー/名称]のテストスケルトン生成"
+- `prompt`: "[パス]のDesign Docからテストスケルトンを生成。" + UI Specが存在する場合: "[UI Specパス]のUI Specを追加コンテキストとして利用可能。"
 
-**期待される出力**: `generatedFiles`（統合テストとE2Eのパスを含む）
+**呼び出しごとの期待出力**: `generatedFiles`（統合テストとE2Eのパスを含む）
 
 ### ステップ3: タスクファイル作成 [GATE]
 
-タスクファイル作成先: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
+レイヤーごとに1つのタスクファイルを作成。monorepo-flow.mdの命名規則に従い、エージェントルーティングを決定的にする:
+- バックエンドのDesign Doc → `docs/plans/tasks/integration-tests-backend-task-YYYYMMDD.md`
+- フロントエンドのDesign Doc → `docs/plans/tasks/integration-tests-frontend-task-YYYYMMDD.md`
+- 単一レイヤー（バックエンド確定） → `docs/plans/tasks/integration-tests-backend-task-YYYYMMDD.md`
+- 単一レイヤー（フロントエンド確定） → `docs/plans/tasks/integration-tests-frontend-task-YYYYMMDD.md`
 
-**テンプレート**:
+**テンプレート**（タスクファイルごと）:
 ```markdown
 ---
-name: [機能名]の統合テスト実装
+name: [機能名]の[レイヤー]統合テスト実装
 type: test-implementation
 ---
 
@@ -66,8 +86,8 @@ type: test-implementation
 
 ## 対象ファイル
 
-- スケルトン: [ステップ2のgeneratedFilesのパス]
-- Design Doc: [ステップ1のパス]
+- スケルトン: [ステップ2のgeneratedFilesからレイヤー別パス]
+- Design Doc: [ステップ1のレイヤー別Design Doc]
 
 ## タスク
 
@@ -82,14 +102,17 @@ type: test-implementation
 - 品質チェック全項目パス
 ```
 
-**出力**: "タスクファイルを[パス]に作成しました。ステップ4へ進む準備完了。"
+**出力**: "タスクファイルを[パス（複数の場合は全パス）]に作成しました。ステップ4へ進む準備完了。"
 
 ### ステップ4: テスト実装
 
-Agentツールでtask-executorを呼び出す:
-- `subagent_type`: "task-executor"
+ステップ3の各タスクファイルに対し、ファイル名パターンでルーティングしてtask-executorを呼び出す:
+- `*-backend-task-*` → `subagent_type`: "task-executor"
+- `*-frontend-task-*` → `subagent_type`: "task-executor-frontend"
 - `description`: "統合テスト実装"
-- `prompt`: "タスクファイル: docs/plans/tasks/integration-tests-YYYYMMDD.md。タスクファイルに従ってテストを実装。"
+- `prompt`: "タスクファイル: [ステップ3のタスクファイルパス]。タスクファイルに従ってテストを実装。"
+
+1つのタスクファイルにつきステップ4→5→6→7を完了してから次に進む。
 
 **期待される出力**: `status`, `testsAdded`
 
@@ -98,7 +121,7 @@ Agentツールでtask-executorを呼び出す:
 Agentツールでintegration-test-reviewerを呼び出す:
 - `subagent_type`: "integration-test-reviewer"
 - `description`: "テスト品質レビュー"
-- `prompt`: "テスト品質をレビュー。テストファイル: [ステップ4のtestsAdded]。スケルトンファイル: [ステップ2のgeneratedFiles]"
+- `prompt`: "テスト品質をレビュー。テストファイル: [ステップ4のtestsAdded]。スケルトンファイル: [ステップ2のgeneratedFilesから現在のタスクのレイヤーに該当するパス]"
 
 **期待される出力**: `status` (approved/needs_revision), `requiredFixes`
 
@@ -108,15 +131,17 @@ Agentツールでintegration-test-reviewerを呼び出す:
 - `status: approved` → 完了としてマーク、ステップ7へ進む
 - `status: needs_revision` → requiredFixesでtask-executorを呼び出し、ステップ5に戻る
 
-Agentツールでtask-executorを呼び出す:
-- `subagent_type`: "task-executor"
+タスクファイル名パターンでルーティングしてtask-executorを呼び出す:
+- `*-backend-task-*` → `subagent_type`: "task-executor"
+- `*-frontend-task-*` → `subagent_type`: "task-executor-frontend"
 - `description`: "レビュー指摘の修正"
 - `prompt`: "テストファイルの以下の問題を修正: [ステップ5のrequiredFixes]"
 
 ### ステップ7: 品質チェック
 
-Agentツールでquality-fixerを呼び出す:
-- `subagent_type`: "quality-fixer"
+タスクファイル名パターンでルーティングしてquality-fixerを呼び出す:
+- `*-backend-task-*` → `subagent_type`: "quality-fixer"
+- `*-frontend-task-*` → `subagent_type`: "quality-fixer-frontend"
 - `description`: "最終品質保証"
 - `prompt`: "このワークフローで追加されたテストファイルの最終品質保証。全テストを実行しカバレッジを確認。"
 

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/documentation-criteria/SKILL.md

@@ -97,7 +97,7 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
 **Excludes**:
 - Technical implementation details (-> Design Doc)
 - API contracts and data layer design (-> Design Doc)
-- Test implementation (-> Test Strategy in Design Doc)
+- Test implementation (-> acceptance-test-generator skeletons)
 - Implementation schedule (-> Work Plan)
 
 **Required Structural Elements**:
@@ -123,7 +123,6 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
 - **Technical dependencies and implementation constraints** (required implementation order)
 - Interface and type definitions
 - Data flow and component design
-- **E2E verification procedures at integration points**
 - **Acceptance criteria (EARS format: When/While/If-then/none)**
 - Change impact map (clearly specify direct impact/indirect impact/no ripple effect)
 - Complete enumeration of integration points
@@ -147,7 +146,7 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
 **Includes**:
 - Task breakdown and dependencies (maximum 2 levels)
 - Schedule and duration estimates
-- **Copy E2E verification procedures from Design Doc** (cannot delete, can add)
+- **Include test skeleton file paths from acceptance-test-generator** (integration and E2E)
 - **Phase 4 Quality Assurance Phase (required)**
 - Progress records (checkbox format)
 

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

@@ -247,34 +247,15 @@ Invariants:
    - Prerequisites: [Required pre-implementations]
 
 ### Integration Points
-Each integration point requires E2E verification:
 
 **Integration Point 1: [Name]**
 - Components: [Component A] -> [Component B]
-- Verification: [How to verify integration works]
+- Contract: [Interface/API contract between components]
 
 ### Migration Strategy
 
 [Technical migration approach, ensuring backward compatibility]
 
-## Test Strategy
-
-### Unit Tests
-
-[Unit testing policy and coverage goals]
-- Verify individual elements of functional acceptance criteria
-
-### Integration Tests
-
-[Integration testing policy and important test cases]
-- Verify combined operations of functional acceptance criteria
-
-### E2E Tests
-
-[E2E testing policy]
-- Verify entire scenarios of acceptance criteria
-- Confirm functional operation from user perspective
-
 ## Security Considerations
 
 Evaluate the following for this feature's trust boundaries and data flow:

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

@@ -48,11 +48,6 @@ Related Issue/PR: #XXX (if any)
 - [ ] [Functional completion criteria]
 - [ ] [Quality completion criteria]
 
-#### Operational Verification Procedures
-1. [Operation verification steps]
-2. [Expected result verification]
-3. [Performance verification (when applicable)]
-
 ### Phase 2: [Phase Name] (Estimated commits: X)
 **Purpose**: [What this phase aims to achieve]
 
@@ -66,11 +61,6 @@ Related Issue/PR: #XXX (if any)
 - [ ] [Functional completion criteria]
 - [ ] [Quality completion criteria]
 
-#### Operational Verification Procedures
-1. [Operation verification steps]
-2. [Expected result verification]
-3. [Performance verification (when applicable)]
-
 ### Phase 3: [Phase Name] (Estimated commits: X)
 **Purpose**: [What this phase aims to achieve]
 
@@ -84,9 +74,6 @@ Related Issue/PR: #XXX (if any)
 - [ ] [Functional completion criteria]
 - [ ] [Quality completion criteria]
 
-#### Operational Verification Procedures
-[Copy relevant integration point E2E verification from Design Doc]
-
 ### Final Phase: Quality Assurance (Required) (Estimated commits: 1)
 **Purpose**: Overall quality assurance and Design Doc consistency verification
 
@@ -94,13 +81,10 @@ Related Issue/PR: #XXX (if any)
 - [ ] Verify all Design Doc acceptance criteria achieved
 - [ ] Security review: Verify security considerations from Design Doc are implemented
 - [ ] Quality checks (types, lint, format)
-- [ ] Execute all tests
+- [ ] Execute all tests (including integration/E2E from test skeletons, when provided)
 - [ ] Coverage 70%+
 - [ ] Document updates
 
-#### Operational Verification Procedures
-[Copy E2E verification procedures from Design Doc]
-
 ### Quality Assurance
 - [ ] Implement staged quality checks (details: refer to technical-spec skill)
 
@@ -111,7 +95,7 @@ Related Issue/PR: #XXX (if any)
 
 ## Completion Criteria
 - [ ] All phases completed
-- [ ] Each phase's operational verification procedures executed
+- [ ] All integration/E2E tests passing (when test skeletons provided)
 - [ ] Design Doc acceptance criteria satisfied
 - [ ] Staged quality checks completed (zero errors)
 - [ ] All tests pass

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/documentation-criteria/SKILL.md

@@ -97,7 +97,7 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 **含まないもの**:
 - 技術実装詳細（→ Design Doc）
 - APIコントラクトとデータレイヤー設計（→ Design Doc）
-- テスト実装（→ Design Docのテスト戦略）
+- テスト実装（→ acceptance-test-generatorのスケルトン）
 - 実装スケジュール（→ 作業計画書）
 
 **必須構造要素**:
@@ -123,7 +123,6 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 - **技術的依存関係と実装制約**（実装の必要順序）
 - インターフェース定義と型定義
 - データフローとコンポーネント設計
-- **統合ポイントでのE2E確認手順**
 - **受入条件（EARS形式: When/While/If-then/無印）**
 - 変更影響マップ（直接影響/間接影響/波及なしを明記）
 - 統合点の完全な列挙
@@ -163,7 +162,7 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 - **フェーズ構成**（Design Docの技術的依存関係を基に作成）
 - タスク分解と依存関係（最大2階層まで）
 - スケジュールと期間見積もり
-- **Design DocのE2E確認手順を各フェーズに配置**
+- **acceptance-test-generatorのテストスケルトンファイルパスを配置**（統合テスト・E2E）
 - **最終フェーズに品質保証を含む**（必須）
 - 進捗記録（チェックボックス形式）
 

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

@@ -247,34 +247,15 @@ unknowns:
    - 前提条件: [事前に必要な実装]
 
 ### 統合ポイント
-各統合ポイントでE2E確認が必要：
 
 **統合ポイント1: [名称]**
 - コンポーネント: [コンポーネントA] -> [コンポーネントB]
-- 確認方法: [統合が動作することの検証方法]
+- コントラクト: [コンポーネント間のインターフェース/API契約]
 
 ### 移行戦略
 
 [技術的な移行アプローチ、後方互換性の確保方法]
 
-## テスト戦略
-
-### 単体テスト
-
-[単体テストの方針とカバレッジ目標]
-- 機能受入条件の個別要素を検証
-
-### 統合テスト
-
-[統合テストの方針と重要なテストケース]
-- 機能受入条件の組み合わせ動作を検証
-
-### E2Eテスト
-
-[E2Eテストの方針]
-- 受入条件のシナリオ全体を検証
-- ユーザー視点での機能動作を確認
-
 ## セキュリティ考慮事項
 
 この機能の信頼境界とデータフローについて以下を評価:

package/.claude/skills-ja/documentation-criteria/references/plan-template.md

@@ -48,11 +48,6 @@
 - [ ] [機能完了条件]
 - [ ] [品質完了条件]
 
-#### 動作確認手順
-1. [動作確認ステップ]
-2. [期待結果の確認]
-3. [パフォーマンス確認（該当する場合）]
-
 ### Phase 2: [フェーズ名]（想定コミット数: X）
 **目的**: [このフェーズで達成すること]
 
@@ -66,11 +61,6 @@
 - [ ] [機能完了条件]
 - [ ] [品質完了条件]
 
-#### 動作確認手順
-1. [動作確認ステップ]
-2. [期待結果の確認]
-3. [パフォーマンス確認（該当する場合）]
-
 ### Phase 3: [フェーズ名]（想定コミット数: X）
 **目的**: [このフェーズで達成すること]
 
@@ -84,9 +74,6 @@
 - [ ] [機能完了条件]
 - [ ] [品質完了条件]
 
-#### 動作確認手順
-[Design Docの該当する統合ポイントE2E確認をコピー]
-
 ### 最終Phase: 品質保証（必須）（想定コミット数: 1）
 **目的**: 全体品質保証とDesign Doc整合性検証
 
@@ -94,13 +81,10 @@
 - [ ] Design Docの全受入条件達成を確認
 - [ ] セキュリティレビュー: Design Docのセキュリティ考慮事項が実装されていることを確認
 - [ ] 品質チェック（型、lint、format）
-- [ ] 全テスト実行
+- [ ] 全テスト実行（テストスケルトン提供時は統合/E2Eテスト含む）
 - [ ] カバレッジ70%以上
 - [ ] ドキュメント更新
 
-#### 動作確認手順
-[Design DocからE2E確認手順をコピー]
-
 ### 品質保証
 - [ ] 段階的品質チェック実施（詳細: technical-specスキル参照）
 
@@ -111,7 +95,7 @@
 
 ## 完了条件
 - [ ] 全フェーズ完了
-- [ ] 各フェーズの動作確認手順を実施
+- [ ] 全統合/E2Eテストがパス（テストスケルトン提供時）
 - [ ] Design Docの受入条件を満たす
 - [ ] 段階的品質チェック完了（エラー0件）
 - [ ] 全テストパス

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,45 @@ 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.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
+
+#### Test Workflow: Skeleton-Based Single Source of Truth
+- `design-template`: Remove Test Strategy section — test design responsibility moved to acceptance-test-generator skeletons
+- `design-template`: Integration Points change from Verification to Contract (interface/API contract)
+- `plan-template`: Remove Operational Verification Procedures from all phases — replaced by test skeleton file path references
+- `plan-template`: Completion criteria updated to reference skeleton-based test results
+- `work-planner`: Replace operational verification with test skeleton placement rules (integration tests in corresponding phases, E2E in final phase)
+- `work-planner`: Add fallback for when test skeletons are not provided (AC-based test planning)
+- `documentation-criteria`: Design Doc definition removes E2E verification; Work Plan references skeleton file paths
+- `task-decomposer`: Phase completion content references skeleton file paths instead of copying E2E verification from Design Doc
+- `technical-designer` / `technical-designer-frontend`: Replace E2E verification checklist with testable AC quality gate (concrete trigger, action, expected result)
+- `technical-designer-frontend`: Add typescript-testing skill with Applying to Implementation entry
+
+#### add-integration-tests: Fullstack Support
+- Support backend, frontend, and fullstack test generation (previously backend-only)
+- Document discovery with filename-based classification and user confirmation GATE
+- Per-Design-Doc skeleton generation (aligned with acceptance-test-generator single-doc contract)
+- Layer-specific task file naming for deterministic agent routing (`*-backend-task-*` / `*-frontend-task-*`)
+- Input validation for empty arguments
+
 ## [1.18.2] - 2026-03-26
 
 ### Changed

package/package.json

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