create-ai-project 1.20.0 → 1.20.1

package/.claude/agents-en/codebase-analyzer.md

@@ -13,7 +13,7 @@ You are an AI assistant specializing in existing codebase analysis for technical
 
 ## Input Parameters
 
-- **requirement_analysis**: JSON output from requirement-analyzer (required)
+- **requirement_analysis**: Requirement analysis JSON output (required)
   - Provides: `affectedFiles`, `scale`, `purpose`, `technicalConsiderations`
 
 - **prd_path**: Path to PRD (optional, available for Large scale)
@@ -156,7 +156,7 @@ Return the JSON result as the final response. See Output Format for the schema.
 
 ## Completion Criteria
 
-- [ ] Parsed requirement-analyzer output and identified analysis categories
+- [ ] Parsed requirement analysis output and identified analysis categories
 - [ ] Read all affected files and extracted public interfaces with file:line references
 - [ ] Traced one level of imports for each affected file
 - [ ] Searched for data access, external integration, and validation patterns using Grep

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

@@ -38,7 +38,7 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 - **doc_type**: Document type (`PRD`/`ADR`/`UISpec`/`DesignDoc`)
 - **target**: Document path to review
 
-- **code_verification**: Code-verifier results JSON (optional)
+- **code_verification**: Code verification results JSON (optional)
   - When provided, incorporate as pre-verified evidence in Gate 1 quality assessment
   - Discrepancies and reverse coverage gaps inform consistency and completeness checks
 
@@ -83,6 +83,7 @@ For DesignDoc, additionally verify:
 - [ ] Code inspection evidence recorded (files and functions listed)
 - [ ] Applicable standards listed with explicit/implicit classification
 - [ ] Field propagation map present (when fields cross boundaries)
+- [ ] Verification Strategy section present with: correctness definition, verification method, verification timing, early verification point
 
 #### Gate 1: Quality Assessment (only after Gate 0 passes)
 
@@ -99,7 +100,12 @@ For DesignDoc, additionally verify:
 - 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
 - **Data design completeness check**: When document contains data-storage keywords (database, persistence, storage, migration) or data-access keywords (repository, query, ORM, SQL) or data-schema keywords (table, schema, column) but lacks data design content (no schema references, no "Test Boundaries" section with data layer strategy, no data model documentation) → `important` issue (category: `completeness`). Note: generic terms like "model", "field", "record", "entity" alone are insufficient to trigger this check — require co-occurrence with at least one data-storage or data-access keyword
-- **Code-verifier integration**: When `code_verification` input is provided, each item in `undocumentedDataOperations` absent from the document → `important` issue (category: `completeness`). Each discrepancy from code-verifier with severity `critical` or `major` → incorporate as pre-verified evidence in the corresponding review check
+- **Code verification integration**: When `code_verification` input is provided, each item in `undocumentedDataOperations` absent from the document → `important` issue (category: `completeness`). Each discrepancy from code verification with severity `critical` or `major` → incorporate as pre-verified evidence in the corresponding review check
+- **Verification Strategy quality check** (when Verification Strategy section exists):
+  - Correctness definition is specific and measurable — "tests pass" without specifying which tests or what they verify → `important` issue (category: `completeness`)
+  - Verification method is sufficient for the change's risk and dependency type — method that cannot detect the primary risk category (e.g., schema correctness, behavioral equivalence, integration compatibility) → `important` issue (category: `consistency`)
+  - Early verification point identifies a concrete first target — "TBD" or "final phase" → `important` issue (category: `completeness`)
+  - When vertical slice is selected, verification timing deferred entirely to final phase → `important` issue (category: `consistency`)
 
 **Perspective-specific Mode**:
 - Implement review based on specified mode and focus
@@ -254,7 +260,9 @@ Include in output when `prior_context_count > 0`:
 - [ ] Dependencies described as "existing" verified against codebase (Grep/Glob)
 - [ ] Field propagation map present when fields cross component boundaries
 - [ ] Data-related keywords present → data design content exists (schema references, Test Boundaries, or data model documentation; or explicitly marked N/A)
-- [ ] Code-verifier results (if provided) reconciled with document content
+- [ ] Code verification results (if provided) reconciled with document content
+- [ ] Verification Strategy present with concrete correctness definition and early verification point
+- [ ] Verification Strategy aligns with design_type and implementation approach
 
 ## Review Criteria (for Comprehensive Mode)
 
@@ -320,7 +328,7 @@ Template storage locations follow documentation-criteria skill.
 ## Important Notes
 
 ### Regarding ADR Status Updates
-**Important**: document-reviewer only performs review and recommendation decisions. Actual status updates are made after the user's final decision.
+**Important**: This agent only performs review and recommendation decisions. Actual status updates are made after the user's final decision.
 
 **Presentation of Review Results**:
 - Present decisions such as "Approved (recommendation for approval)" or "Rejected (recommendation for rejection)"

package/.claude/agents-en/solver.md

@@ -1,6 +1,6 @@
 ---
 name: solver
-description: Derives multiple solutions for verified causes and analyzes tradeoffs. Use when verifier has concluded, or when "solution/how to fix/fix method/remedy" is mentioned. Focuses on solutions from given conclusions without investigation.
+description: Derives multiple solutions for verified causes and analyzes tradeoffs. Use when root cause verification has concluded, or when "solution/how to fix/fix method/remedy" is mentioned. Focuses on solutions from given conclusions without investigation.
 tools: Read, Grep, Glob, LS, TaskCreate, TaskUpdate, WebSearch
 skills: project-context, technical-spec, coding-standards, implementation-approach
 ---

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

@@ -30,6 +30,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
    - Understand dependencies between phases and tasks
    - Grasp completion criteria and quality standards
    - **Interface change detection and response**
+   - **Extract Verification Strategy from work plan header**
 
 2. **Task Decomposition**
    - Granularity: 1 commit = 1 task (logical change unit)
@@ -95,6 +96,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
    - Target files
    - **Investigation Targets** (what the executor must read and understand before implementing)
    - Concrete implementation steps
+   - **Operation Verification Methods** (derived from Verification Strategy in work plan)
    - Completion criteria
 
 6. **Investigation Targets Determination**
@@ -107,6 +109,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
    | Test implementation | Test skeleton comments/annotations, the target code being tested, actual API/auth flows |
    | E2E environment setup | Current environment config (startup scripts, docker-compose or equivalent), seed scripts, existing fixture patterns, application auth flow |
    | Bug fix / refactor | The affected code paths, related test coverage, error reproduction context |
+   | Behavior replacement / rewrite | The existing implementation being replaced, its observable outputs, Design Doc Verification Strategy section |
 
    **Principles**:
    - Every task must have at least one Investigation Target (even if just the Design Doc)
@@ -121,6 +124,19 @@ Decompose tasks based on implementation strategy patterns determined in implemen
 8. **Utilizing Test Information**
    When test information (fast-check usage, dependencies, complexity, etc.) is documented in work plans, reflect that information in task files.
 
+## Verification Strategy Propagation
+
+Verification Strategy defines what correctness means and how to prove it at design time. L1/L2/L3 (from implementation-approach skill) define completion verification granularity at task execution time. Both are set per task.
+
+When the work plan includes a Verification Strategy, derive each task's Operation Verification Methods as follows:
+
+1. **Early verification task**: The task whose scope matches the Verification Strategy's "First verification target" field. Copy and instantiate the verification method, success criteria, and failure response from Verification Strategy into Operation Verification Methods for this task's specific target files.
+2. **Per-task verification**: For each task, set Operation Verification Methods by combining:
+   - **Verification method**: Instantiate the Verification Strategy's method for this task's specific target files (e.g., "compare OrderService.calculate() output against existing implementation at src/legacy/order_calc", "run generated API handler against test database and verify response matches contract")
+   - **Success criteria**: Instantiate the Verification Strategy's success criteria for this task's scope (e.g., "output matches existing implementation for all input combinations")
+   - **Verification level**: Select L1/L2/L3 per implementation-approach skill
+3. **Investigation Targets**: Include resources needed for verification (e.g., existing implementation for comparison, schema definitions, seed data paths)
+
 ## Task File Template
 
 See task template in documentation-criteria skill for details.

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

@@ -116,6 +116,14 @@ Must be performed when creating Design Doc:
    - Which task first makes the entire UI operational
    - Verification level for each task (L1/L2/L3 defined in implementation-approach skill)
 
+3. **Verification Strategy Definition**
+   - Based on selected approach and design_type, define how correctness will be proven
+   - Output must include at least: target comparison (what vs what), method (how), observable success indicator
+   - For new_feature: specify AC verification method beyond unit tests (e.g., integration test against real dependencies)
+   - For extension: specify regression verification method that proves existing behavior is preserved while new behavior is added
+   - For refactoring: specify behavioral equivalence verification method (e.g., output comparison with existing implementation)
+   - Define early verification point: what is the first thing to verify, and how, to confirm the approach is correct before scaling
+
 ### Change Impact Map【Required】
 Must be included when creating Design Doc:
 
@@ -173,7 +181,7 @@ When a UI Spec exists for the feature (`docs/ui-spec/{feature-name}-ui-spec.md`)
   - `reverse-engineer`: Document existing frontend architecture as-is (see Reverse-Engineer Mode section)
 
 - **Requirements Analysis Results**: Requirements analysis results (scale determination, technical requirements, etc.)
-- **Codebase Analysis** (optional, from codebase-analyzer):
+- **Codebase Analysis** (optional, from codebase analysis phase):
   - When provided, use as the primary source for the "Existing Codebase Analysis" section
   - `existingElements` → populate Implementation Path Mapping and Code Inspection Evidence
   - `dataModel` → populate data-related sections (schema references, data contracts)
@@ -326,11 +334,12 @@ class Button extends React.Component {
 - [ ] **Change impact map created** (required)
 - [ ] Response to requirements and design validity
 - [ ] Error handling strategy
-- [ ] Acceptance criteria written in testable format (concrete trigger, action, and expected result)
+- [ ] Acceptance criteria written in testable format (user-observable behaviors, integration/E2E oriented, CI-isolatable)
 - [ ] Props change matrix completeness
 - [ ] Implementation approach selection rationale (vertical/horizontal/hybrid)
 - [ ] Latest best practices researched and references cited
 - [ ] **Complexity assessment**: complexity_level set; if medium/high, complexity_rationale specifies (1) requirements/ACs, (2) constraints/risks
+- [ ] **Verification Strategy defined** (correctness definition, verification method, timing, early verification point)
 
 **Reverse-engineer mode only**:
 - [ ] Every architectural claim cites file:line as evidence

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

@@ -147,6 +147,14 @@ Must be performed when creating Design Doc:
    - Which task first makes the whole system operational
    - Verification level for each task (L1/L2/L3 defined in implementation-approach skill)
 
+3. **Verification Strategy Definition**
+   - Based on selected approach and design_type, define how correctness will be proven
+   - Output must include at least: target comparison (what vs what), method (how), observable success indicator
+   - For new_feature: specify AC verification method beyond unit tests (e.g., integration test against real dependencies)
+   - For extension: specify regression verification method that proves existing behavior is preserved while new behavior is added
+   - For refactoring: specify behavioral equivalence verification method (e.g., output comparison with existing implementation)
+   - Define early verification point: what is the first thing to verify, and how, to confirm the approach is correct before scaling
+
 ### Change Impact Map【Required】
 Must be included when creating Design Doc:
 
@@ -200,7 +208,7 @@ Document state definitions and transitions for stateful components.
   - `reverse-engineer`: Document existing architecture as-is (see Reverse-Engineer Mode section)
 
 - **Requirements Analysis Results**: Requirements analysis results (scale determination, technical requirements, etc.)
-- **Codebase Analysis** (optional, from codebase-analyzer):
+- **Codebase Analysis** (optional, from codebase analysis phase):
   - When provided, use as the primary source for the "Existing Codebase Analysis" section
   - `existingElements` → populate Implementation Path Mapping and Code Inspection Evidence
   - `dataModel` → populate data-related sections (schema references, data contracts)
@@ -293,13 +301,14 @@ Implementation sample creation checklist:
 - [ ] **Change impact map created** (required)
 - [ ] Response to requirements and design validity
 - [ ] Error handling strategy
-- [ ] Acceptance criteria written in testable format (concrete trigger, action, and expected result)
+- [ ] Acceptance criteria written in testable format (user-observable behaviors, integration/E2E oriented, CI-isolatable)
 - [ ] Interface change matrix completeness
 - [ ] Implementation approach selection rationale (vertical/horizontal/hybrid)
 - [ ] Latest best practices researched and references cited
 - [ ] **Complexity assessment**: complexity_level set; if medium/high, complexity_rationale specifies (1) requirements/ACs, (2) constraints/risks
 - [ ] **Data representation decision documented** (when new structures introduced)
 - [ ] **Field propagation map included** (when fields cross boundaries)
+- [ ] **Verification Strategy defined** (correctness definition, verification method, timing, early verification point)
 
 **Reverse-engineer mode only**:
 - [ ] Every architectural claim cites file:line as evidence

package/.claude/agents-en/ui-spec-designer.md

@@ -26,7 +26,7 @@ Operates in an independent context without CLAUDE.md principles, executing auton
 
 ## Required Information
 
-- **PRD**: PRD document path (required if exists; otherwise requirement-analyzer output is used)
+- **PRD**: PRD document path (required if exists; otherwise requirement analysis output is used)
 - **Prototype code path**: Path to prototype code (optional, placed in `docs/ui-spec/assets/{feature-name}/`)
 - **Existing frontend codebase**: Will be investigated automatically
 

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

@@ -1,6 +1,6 @@
 ---
 name: verifier
-description: Critically evaluates investigation results and identifies oversights. Use when investigator completes investigation, or when "verify/really/confirm/oversight/other possibilities" is mentioned. Uses ACH and Devil's Advocate to verify validity and derive conclusions.
+description: Critically evaluates investigation results and identifies oversights using ACH and Devil's Advocate methods. Use when investigation has completed, or when "verify/validate/double-check/confirm findings" is mentioned. Uses ACH and Devil's Advocate to verify validity and derive conclusions.
 tools: Read, Grep, Glob, LS, Bash, WebSearch, TaskCreate, TaskUpdate
 skills: project-context, technical-spec, coding-standards
 ---

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

@@ -26,6 +26,7 @@ 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 and their contracts
+- **Verification Strategy**: Correctness Proof Method (correctness definition, verification method, verification timing) and Early Verification Point (first verification target, success criteria, failure response)
 
 ### 2. Process Test Design Information (when provided)
 Read test skeleton files and extract meta information (see Test Design Information Processing section).
@@ -34,11 +35,15 @@ Read test skeleton files and extract meta information (see Test Design Informati
 Choose Strategy A (TDD) if test skeletons are provided, Strategy B (implementation-first) otherwise. See Implementation Strategy Selection section.
 
 ### 4. Compose Phases
-Structure phases based on technical dependencies from Design Doc:
-- Place tasks with lowest dependencies in earlier phases
+
+**Common rules (all approaches)**:
+- **Include Verification Strategy summary in work plan header** for downstream task reference
+- Include verification tasks in the phase corresponding to Verification Strategy's verification timing
 - 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
+- Final phase is always Quality Assurance
+
+**Phase structure**: Select based on implementation approach from Design Doc. See Phase Division Criteria in documentation-criteria skill for detailed definitions. Use plan-template Option A (Vertical) or Option B (Horizontal) accordingly. For hybrid, use Option A as the base and add horizontal foundation phases where needed.
 
 ### 5. Define Tasks with Completion Criteria
 For each task, derive completion criteria from Design Doc acceptance criteria. Apply the 3-element completion definition (Implementation Complete, Quality Complete, Integration Complete).
@@ -53,7 +58,7 @@ Write the work plan following the plan template from documentation-criteria skil
 - **uiSpec** (optional): Path to UI Specification (frontend/fullstack features)
 - **prd** (optional): Path to PRD document
 - **adr** (optional): Path to ADR document
-- **testSkeletons** (optional): Paths to integration/E2E test skeleton files from acceptance-test-generator
+- **testSkeletons** (optional): Paths to integration/E2E test skeleton files (comment-based skeletons describing test intent, not implemented tests)
 - **updateContext** (update mode only): Path to existing plan, reason for changes
 
 ## Work Plan Output Format
@@ -216,7 +221,9 @@ When creating work plans, **Phase Structure Diagrams** and **Task Dependency Dia
 ## Quality Checklist
 
 - [ ] Design Doc(s) consistency verification
-- [ ] Phase composition based on technical dependencies
+- [ ] Verification Strategy extracted from Design Doc and included in plan header
+- [ ] Phase structure matches implementation approach (vertical → value unit phases, horizontal → layer phases)
+- [ ] Early verification point placed in Phase 1 (when Verification Strategy specifies one)
 - [ ] All requirements converted to tasks
 - [ ] Quality assurance exists in final phase
 - [ ] Test skeleton file paths listed in corresponding phases (when provided)

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

@@ -38,7 +38,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - **doc_type**: ドキュメントタイプ（`PRD`/`UISpec`/`ADR`/`DesignDoc`）
 - **target**: レビュー対象のドキュメントパス
 
-- **code_verification**: code-verifier結果JSON（任意）
+- **code_verification**: コード検証結果のJSON（任意）
   - 提供された場合、Gate 1品質評価の事前検証エビデンスとして組み込む
   - 不整合と逆方向カバレッジのギャップが整合性・完全性チェックに反映される
 
@@ -83,6 +83,7 @@ DesignDocの場合、追加で以下を確認:
 - [ ] コード調査エビデンスの記録（ファイルと関数の一覧）
 - [ ] 適用基準のexplicit/implicit分類付き一覧
 - [ ] フィールド伝播マップの存在（フィールドが境界を越える場合）
+- [ ] 検証戦略セクションの存在（正しさの定義、検証手法、検証タイミング、早期検証ポイント）
 
 #### Gate 1: 品質評価（Gate 0通過後のみ実施）
 
@@ -99,7 +100,12 @@ DesignDocの場合、追加で以下を確認:
 - 依存先の実在性検証：Design Docの「既存コードベース分析」セクションが「既存」と記述する依存先について、Grep/Globでコードベース内の定義を確認。コードベースに見つからず公式の外部出典の記載もない → `critical`（カテゴリ: `feasibility`）。存在するが定義のシグネチャ（メソッド名、パラメータ型、戻り値型）がDesign Docの記述と乖離 → `important`（カテゴリ: `consistency`）
 - **既存実装ドキュメント検証**: コード検証結果が提供され、ドキュメントが既存実装を記述している場合（将来の要件ではなく）、コードから観察可能な振る舞いが事実として記述されていることを検証する。確定的な振る舞いに対する推測的な表現 → `important`
 - **データ設計完全性チェック**: ドキュメントにデータ格納キーワード（database, persistence, storage, migration）またはデータアクセスキーワード（repository, query, ORM, SQL）またはデータスキーマキーワード（table, schema, column）が含まれるにもかかわらず、データ設計コンテンツが不足している場合（スキーマ参照なし、データ層戦略を含む「テスト境界」セクションなし、データモデル文書なし） → `important`（カテゴリ: `completeness`）。注: 「model」「field」「record」「entity」等の汎用語のみでは本チェックを発火しない — データ格納またはデータアクセスキーワードとの共起が必要
-- **code-verifier連携**: `code_verification`入力が提供された場合、`undocumentedDataOperations`の各項目がドキュメントに不在 → `important`（カテゴリ: `completeness`）。code-verifierのseverityが`critical`または`major`の不整合 → 対応するレビューチェックの事前検証エビデンスとして組み込む
+- **コード検証連携**: `code_verification`入力が提供された場合、`undocumentedDataOperations`の各項目がドキュメントに不在 → `important`（カテゴリ: `completeness`）。コード検証のseverityが`critical`または`major`の不整合 → 対応するレビューチェックの事前検証エビデンスとして組み込む
+- **検証戦略の品質チェック**（検証戦略セクションが存在する場合）:
+  - 正しさの定義が具体的かつ測定可能であること — どのテストで何を確認するかを特定せず「テストがパス」とだけ記述 → `important`（カテゴリ: `completeness`）
+  - 検証手法が変更のリスクと依存タイプに対して十分であること — 主要なリスクカテゴリ（スキーマの正しさ、振る舞いの同等性、統合互換性等）を検出できない手法 → `important`（カテゴリ: `consistency`）
+  - 早期検証ポイントが具体的な最初の対象を特定していること — 「TBD」や「最終フェーズ」→ `important`（カテゴリ: `completeness`）
+  - 垂直スライス選択時に、検証タイミングが最終フェーズのみに後回し → `important`（カテゴリ: `consistency`）
 
 **観点特化モード**:
 - 指定されたmodeとfocusに基づいてレビューを実施
@@ -254,7 +260,9 @@ DesignDocの場合、追加で以下を確認:
 - [ ] 「既存」と記述された依存先がコードベースに対して検証されていること（Grep/Glob）
 - [ ] フィールドが境界を越える場合にフィールド伝播マップが存在すること
 - [ ] データ関連キーワードが存在する場合 → データ設計コンテンツが存在（スキーマ参照、テスト境界、データモデル文書。または明示的にN/A）
-- [ ] code-verifier結果（提供された場合）がドキュメント内容と照合済み
+- [ ] コード検証結果（提供された場合）がドキュメント内容と照合済み
+- [ ] 検証戦略に具体的な正しさの定義と早期検証ポイントが存在すること
+- [ ] 検証戦略がdesign_typeと実装アプローチに整合していること
 
 ## レビュー基準（総合モード用）
 
@@ -320,7 +328,7 @@ DesignDocの場合、追加で以下を確認:
 ## 重要な注意事項
 
 ### ADRステータス更新について
-**重要**: document-reviewerはレビューと推奨判定のみを行います。実際のステータス更新はユーザーの最終判断後に行われます。
+**重要**: このエージェントはレビューと推奨判定のみを行います。実際のステータス更新はユーザーの最終判断後に行われます。
 
 **レビュー結果の提示**:
 - 「Approved（承認推奨）」「Rejected（却下推奨）」等の判定を提示

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

@@ -1,6 +1,6 @@
 ---
 name: solver
-description: 検証済み原因に対して複数の解決策を導出しトレードオフを分析。Use when verifierが結論を出した後、または「解決策/どうすれば/修正方法/対処法」が言及された時。調査は行わず与えられた結論から解決に集中。
+description: 検証済み原因に対して複数の解決策を導出しトレードオフを分析。Use when 根本原因の検証が完了した後、または「解決策/どうすれば/修正方法/対処法」が言及された時。調査は行わず与えられた結論から解決に集中。
 tools: Read, Grep, Glob, LS, TaskCreate, TaskUpdate, WebSearch
 skills: project-context, technical-spec, coding-standards, implementation-approach
 ---

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

@@ -18,7 +18,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 **各タスクは適切なレベルで確認可能でなければならない**
 
 ### 確認可能性の基準
-implementation-approachスキルで定義された確認レベル（L1/L2/L3）に基づいてタスクを設計。
+implementation-approachスキルで定義された検証レベル（L1/L2/L3）に基づいてタスクを設計。
 
 ### 実装戦略の適用
 implementation-approachスキルで決定された実装戦略パターンに基づいてタスクを分解する。
@@ -30,6 +30,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
    - 各フェーズとタスクの依存関係を理解
    - 完了条件と品質基準を把握
    - **インターフェース変更の検出と対応**
+   - **作業計画書ヘッダーから検証戦略を抽出**
 
 2. **タスクの分解**
    - 粒度: 1コミット = 1タスク（論理的変更単位）
@@ -95,6 +96,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
    - 対象ファイル
    - **調査対象**（executorが実装前に読んで理解すべきもの）
    - 具体的な実装手順
+   - **動作検証方法**（作業計画書の検証戦略から導出）
    - 完了条件
 
 6. **調査対象の決定**
@@ -107,6 +109,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
    | テスト実装 | テストスケルトンのコメント/アノテーション、テスト対象コード、実際のAPI/認証フロー |
    | E2E環境セットアップ | 現在の環境設定（起動スクリプト、docker-compose等）、seed scripts、既存のfixtureパターン、アプリケーション認証フロー |
    | バグ修正 / リファクタリング | 影響を受けるコードパス、関連テストカバレッジ、エラー再現コンテキスト |
+   | 振る舞いの置換・リライト | 置換対象の既存実装、その観察可能な出力、Design Docの検証戦略セクション |
 
    **原則**:
    - 全タスクに最低1つの調査対象を設定する（Design Docのみでも可）
@@ -121,6 +124,19 @@ implementation-approachスキルで決定された実装戦略パターンに基
 8. **テスト情報の活用**
    作業計画書にテスト情報（fast-check使用、依存関係、複雑度等）が記載されている場合、その情報をタスクファイルに反映する。
 
+## 検証戦略の伝播
+
+検証戦略は設計時に「正しさとは何か」「どう証明するか」を定義する。L1/L2/L3（implementation-approachスキル）はタスク実行時の完了検証の粒度を定義する。両方をタスクごとに設定する。
+
+作業計画書に検証戦略が含まれる場合、各タスクの動作検証方法を以下のように導出する:
+
+1. **早期検証タスク**: 検証戦略の「最初の検証対象」フィールドとスコープが一致するタスク。検証戦略の検証手法、成功基準、失敗時の対応を転記し、このタスクの具体的な対象ファイルに即して具体化する。
+2. **タスクごとの検証**: 各タスクの動作検証方法を以下を組み合わせて設定:
+   - **検証手法**: 検証戦略の手法をこのタスクの対象ファイルに具体化（例: 「OrderService.calculate()の出力をsrc/legacy/order_calcの既存実装と比較」「生成したAPIハンドラをテストDBに対して実行しレスポンスがコントラクトに一致することを確認」）
+   - **成功基準**: 検証戦略の成功基準をこのタスクのスコープに具体化（例: 「全入力パターンで既存実装と出力が一致」）
+   - **検証レベル**: implementation-approachスキルに従いL1/L2/L3を選択
+3. **調査対象**: 検証に必要なリソースを含める（例: 比較対象の既存実装、スキーマ定義、seed dataのパス）
+
 ## タスクファイルテンプレート
 
 詳細はdocumentation-criteriaスキルのタスクテンプレートを参照。

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

@@ -149,7 +149,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 #### 動作確認
 - タスク内の「動作確認方法」セクションを実行
-- implementation-approachスキルで定義された確認レベルに応じた確認を実施
+- implementation-approachスキルで定義された検証レベルに応じた確認を実施
 - 確認できない場合は理由を記録
 - 結果を構造化レスポンスに含める
 

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

@@ -126,6 +126,14 @@ Design Doc作成時に必ず実施：
    - どのタスクで初めて全体のUIが動作するか
    - 各タスクの検証レベル（implementation-approachスキルで定義されたL1/L2/L3）
 
+3. **検証戦略の定義**
+   - 選択したアプローチとdesign_typeに基づき、正しさの証明方法を定義する
+   - 最低限含める項目: 比較対象（何と何を）、手法（どうやって）、観察可能な成功指標
+   - new_featureの場合: ユニットテスト以上のAC検証手法を明記（例: 実依存に対する統合テスト）
+   - extensionの場合: 既存の振る舞いが維持されつつ新しい振る舞いが追加されることを証明する回帰検証手法を明記
+   - refactoringの場合: 振る舞いの同等性を検証する手法を明記（例: 既存実装との出力比較）
+   - 早期検証ポイントを定義: アプローチの妥当性を本格展開前に確認するため、最初に何を、どうやって検証するか
+
 ### 変更影響マップ【必須】
 Design Doc作成時に必ず含める：
 
@@ -173,7 +181,7 @@ Design Doc作成前に実施：
   - `reverse-engineer`: 既存フロントエンドアーキテクチャの現状ドキュメント化（reverse-engineerモードセクション参照）
 
 - **要件分析結果**: 要件分析の結果（規模判定、技術要件等）
-- **コードベース分析**（任意、コードベース分析エージェントから提供）:
+- **コードベース分析**（任意、コードベース分析フェーズから提供）:
   - 提供された場合、「既存コードベース分析」セクションの主要ソースとして使用
   - `existingElements` → Implementation Path MappingとCode Inspection Evidenceに反映
   - `dataModel` → データ関連セクション（スキーマ参照、データ契約）に反映
@@ -326,11 +334,12 @@ class Button extends React.Component {
 - [ ] **変更影響マップの作成**（必須）
 - [ ] 要件への対応と設計の妥当性
 - [ ] エラーハンドリング戦略
-- [ ] 受入条件がテスト可能な形式で記述されていること（具体的なトリガー、操作、期待結果）
+- [ ] 受入条件がテスト可能な形式で記述されていること（ユーザーから観察可能な振る舞い、統合/E2E指向、CI隔離可能）
 - [ ] Props変更マトリクスの完成度
 - [ ] 実装アプローチ（垂直/水平/ハイブリッド）の選択根拠
 - [ ] 最新のベストプラクティスの調査と参考資料の記載
 - [ ] **複雑性評価**: complexity_levelを設定。medium/highの場合、complexity_rationaleに(1)要件/AC、(2)制約/リスクを明記
+- [ ] **検証戦略の定義**（正しさの定義、検証手法、タイミング、早期検証ポイント）
 
 **reverse-engineerモード限定**:
 - [ ] すべてのアーキテクチャ主張がfile:lineをevidenceとして引用

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

@@ -145,7 +145,15 @@ Design Doc作成時に必ず実施：
 
 2. **統合ポイントの定義**
    - どのタスクで全体が初めて動作するか
-   - 各タスクの確認レベル（implementation-approachスキルで定義されたL1/L2/L3）
+   - 各タスクの検証レベル（implementation-approachスキルで定義されたL1/L2/L3）
+
+3. **検証戦略の定義**
+   - 選択したアプローチとdesign_typeに基づき、正しさの証明方法を定義する
+   - 最低限含める項目: 比較対象（何と何を）、手法（どうやって）、観察可能な成功指標
+   - new_featureの場合: ユニットテスト以上のAC検証手法を明記（例: 実依存に対する統合テスト）
+   - extensionの場合: 既存の振る舞いが維持されつつ新しい振る舞いが追加されることを証明する回帰検証手法を明記
+   - refactoringの場合: 振る舞いの同等性を検証する手法を明記（例: 既存実装との出力比較）
+   - 早期検証ポイントを定義: アプローチの妥当性を本格展開前に確認するため、最初に何を、どうやって検証するか
 
 ### 変更影響マップ【必須】
 Design Doc作成時に必ず含める:
@@ -200,7 +208,7 @@ Design Doc作成前に実施：
   - `reverse-engineer`: 既存アーキテクチャの現状ドキュメント化（reverse-engineerモードセクション参照）
 
 - **要件分析結果**: 要件分析の結果（規模判定、技術要件等）
-- **コードベース分析**（任意、コードベース分析エージェントから提供）:
+- **コードベース分析**（任意、コードベース分析フェーズから提供）:
   - 提供された場合、「既存コードベース分析」セクションの主要ソースとして使用
   - `existingElements` → Implementation Path MappingとCode Inspection Evidenceに反映
   - `dataModel` → データ関連セクション（スキーマ参照、データ契約）に反映
@@ -292,13 +300,14 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 - [ ] **変更影響マップの作成**（必須）
 - [ ] 要件への対応と設計の妥当性
 - [ ] エラーハンドリング戦略
-- [ ] 受入条件がテスト可能な形式で記述されていること（具体的なトリガー、操作、期待結果）
+- [ ] 受入条件がテスト可能な形式で記述されていること（ユーザーから観察可能な振る舞い、統合/E2E指向、CI隔離可能）
 - [ ] インターフェース変更マトリクスの完成度
 - [ ] 実装アプローチ（垂直/水平/ハイブリッド）の選択根拠
 - [ ] 最新のベストプラクティスの調査と参考資料の記載
 - [ ] **複雑性評価**: complexity_levelを設定。medium/highの場合、complexity_rationaleに(1)要件/AC、(2)制約/リスクを明記
 - [ ] **データ構造の採用判断の文書化**（新規構造導入時）
 - [ ] **フィールド伝播マップの記載**（フィールドが境界を越える場合）
+- [ ] **検証戦略の定義**（正しさの定義、検証手法、タイミング、早期検証ポイント）
 
 **reverse-engineerモード限定**:
 - [ ] すべてのアーキテクチャ主張がfile:lineをevidenceとして引用

package/.claude/agents-ja/ui-spec-designer.md

@@ -26,7 +26,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 必要情報
 
-- **PRD**: PRDドキュメントパス（存在する場合は必須、なければrequirement-analyzerの出力を使用）
+- **PRD**: PRDドキュメントパス（存在する場合は必須、なければ要件分析の出力を使用）
 - **プロトタイプコードパス**: プロトタイプコードへのパス（任意、`docs/ui-spec/assets/{feature-name}/`に配置）
 - **既存フロントエンドコードベース**: 自動的に調査
 

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

@@ -1,6 +1,6 @@
 ---
 name: verifier
-description: 調査結果を批判的に評価し見落としを探す。Use when investigatorの調査完了後、または「検証/本当に/確認/見落とし/他の可能性」が言及された時。ACH・Devil's Advocate手法で妥当性を検証し結論を導出。
+description: 調査結果を批判的に評価し見落としを探す。ACH・Devil's Advocate手法で妥当性を検証し結論を導出。Use when 調査が完了した後、または「検証/妥当性確認/ダブルチェック/調査結果の確認」が言及された時。
 tools: Read, Grep, Glob, LS, Bash, WebSearch, TaskCreate, TaskUpdate
 skills: project-context, technical-spec, coding-standards
 ---

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

@@ -17,7 +17,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - documentation-criteriaスキルでドキュメント作成基準を適用
 - technical-specスキルで技術仕様を確認
 - project-contextスキルでプロジェクトコンテキストを把握
-- implementation-approachスキルで実装戦略パターンと確認レベル定義（タスク分解で使用）
+- implementation-approachスキルで実装戦略パターンと検証レベル定義（タスク分解で使用）
 
 ## 計画プロセス
 
@@ -26,6 +26,7 @@ Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み
 - 受入条件と実装アプローチ
 - 技術的依存関係と実装順序
 - 統合ポイントとそのコントラクト
+- **検証戦略**: 正しさの証明方法（正しさの定義、検証手法、検証タイミング）と早期検証ポイント（最初の検証対象、成功基準、失敗時の対応）
 
 ### 2. テスト設計情報の処理（提供時）
 テストスケルトンファイルを読み込み、メタ情報を抽出（テスト設計情報の処理セクションを参照）。
@@ -34,11 +35,15 @@ Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み
 テストスケルトンが提供されている場合は戦略A（TDD）、そうでなければ戦略B（実装優先）を選択。実装戦略の選択セクションを参照。
 
 ### 4. フェーズの構成
-Design Docの技術的依存関係に基づいてフェーズを構成:
-- 依存が最も少ないタスクを前のフェーズに配置
+
+**全アプローチ共通**:
+- **検証戦略の要約を作業計画書ヘッダーに記載**（後続タスクへの参照用）
+- 検証戦略の検証タイミングに対応するフェーズに検証タスクを配置
 - テストスケルトンが提供されている場合、統合テスト実装を対応するフェーズに配置し、E2Eテスト実行を最終フェーズに配置
 - テストスケルトンが提供されていない場合、Design Docの受入条件に基づくテスト実装タスクを含める
-- 最終フェーズに品質保証を含める
+- 最終フェーズは常に品質保証
+
+**フェーズ構成**: Design Docの実装アプローチに基づいて選択。詳細はdocumentation-criteriaスキルのフェーズ分割基準を参照。plan-templateのOption A（垂直）またはOption B（水平）に従う。ハイブリッドの場合はOption Aをベースに、必要に応じて水平基盤フェーズを追加する。
 
 ### 5. 完了条件付きタスクの定義
 各タスクについて、Design Docの受入条件から完了条件を導出。3要素の完了定義（実装完了、品質完了、統合完了）を適用。
@@ -53,7 +58,7 @@ documentation-criteriaスキルの計画テンプレートに従って作業計
 - **uiSpec**（オプション）: UI Specificationのパス（フロントエンド/フルスタック機能）
 - **prd**（オプション）: PRDドキュメントのパス
 - **adr**（オプション）: ADRドキュメントのパス
-- **testSkeletons**（オプション）: acceptance-test-generatorからの統合/E2Eテストスケルトンファイルパス
+- **testSkeletons**（オプション）: 統合/E2Eテストスケルトンファイルパス（コメントベースのテスト意図記述。実装済みテストではない）
 - **updateContext**（updateモード時のみ）: 既存計画書のパス、変更理由
 
 ## 作業計画書出力形式
@@ -189,7 +194,7 @@ E2Eテストスケルトンが提供された場合、2段階で環境前提条
 - E2Eテスト: 「E2Eテスト実行」を最終Phaseに配置（実装は不要、実行のみ）
 
 ### 実装アプローチの適用
-Design Docで決定された実装アプローチと技術的依存関係に基づき、implementation-approachスキルの確認レベル（L1/L2/L3）に従ってタスクを分解する。
+Design Docで決定された実装アプローチと技術的依存関係に基づき、implementation-approachスキルの検証レベル（L1/L2/L3）に従ってタスクを分解する。
 
 ### タスク依存の最小化ルール
 - 依存は最大2階層まで（A→B→Cは可、A→B→C→Dは再設計）
@@ -215,7 +220,9 @@ Design Docの技術的依存関係と実装アプローチに基づいてフェ
 ## 品質チェックリスト
 
 - [ ] Design Doc（複数時は各Doc）の整合性確認
-- [ ] 技術的依存関係に基づくフェーズ構成
+- [ ] Design Docから検証戦略を抽出し計画書ヘッダーに記載
+- [ ] フェーズ構成が実装アプローチと整合（垂直 → 価値単位フェーズ、水平 → レイヤーフェーズ）
+- [ ] 早期検証ポイントをPhase 1に配置（検証戦略で指定されている場合）
 - [ ] 全要件のタスク化
 - [ ] 最終フェーズに品質保証の存在
 - [ ] テストスケルトンファイルパスを対応するフェーズに記載（提供時）

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

@@ -41,8 +41,8 @@ Target document → [Stop: Confirm changes]
 - Consistency verification with design-sync (Design Doc only)
 
 **NOT included**:
-- New requirement analysis (use /design for new documents)
-- Work planning or implementation (use /plan or /task after this command)
+- New requirement analysis
+- Work planning or implementation
 
 **Responsibility Boundary**: This command completes with updated document approval.
 
@@ -64,7 +64,7 @@ ls docs/design/*.md docs/prd/*.md docs/adr/*.md 2>/dev/null | grep -v template
 | $ARGUMENTS specifies a path | Use specified document |
 | $ARGUMENTS describes a topic | Search documents matching the topic |
 | Multiple candidates found | Present options with AskUserQuestion |
-| No documents found | Report and end (suggest /design instead) |
+| No documents found | Report and end (document creation is out of scope) |
 
 ### Step 2: Document Type and Layer Determination
 
@@ -194,7 +194,7 @@ prompt: |
 
 | Error | Action |
 |-------|--------|
-| Target document not found | Report and end (suggest /design instead) |
+| Target document not found | Report and end (document creation is out of scope) |
 | Sub-agent update fails | Log failure, present error to user, retry once |
 | Review rejects after 2 revisions | Stop loop, flag for human intervention |
 | design-sync detects conflicts | Present to user for resolution decision |

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

@@ -41,8 +41,8 @@ description: 既存設計ドキュメント（Design Doc / PRD / ADR）をレビ
 - design-syncによる整合性検証（Design Docのみ）
 
 **実行しない**:
-- 新規要件分析（新規ドキュメントには/designを使用）
-- 作業計画や実装（本コマンド後に/planまたは/taskを使用）
+- 新規要件分析
+- 作業計画や実装
 
 **責務境界**: このコマンドは更新されたドキュメントの承認で責務完了。
 
@@ -64,7 +64,7 @@ ls docs/design/*.md docs/prd/*.md docs/adr/*.md 2>/dev/null | grep -v template
 | $ARGUMENTSがパスを指定 | 指定ドキュメントを使用 |
 | $ARGUMENTSがトピックを記述 | トピックに合致するドキュメントを検索 |
 | 複数の候補が見つかった | AskUserQuestionで選択肢を提示 |
-| ドキュメントが見つからない | 報告して終了（代わりに/designを推奨） |
+| ドキュメントが見つからない | 報告して終了（ドキュメント新規作成は本コマンドの対象外） |
 
 ### ステップ2: ドキュメントタイプとレイヤーの判定
 
@@ -194,7 +194,7 @@ prompt: |
 
 | エラー | アクション |
 |--------|-----------|
-| 対象ドキュメントが見つからない | 報告して終了（代わりに/designを推奨） |
+| 対象ドキュメントが見つからない | 報告して終了（ドキュメント新規作成は本コマンドの対象外） |
 | サブエージェントの更新が失敗 | 失敗をログ、エラーをユーザーに提示、1回リトライ |
 | 2回の修正後もレビューがリジェクト | ループを停止、人間介入用にフラグ |
 | design-syncが矛盾を検出 | 解決判断のためユーザーに提示 |

package/.claude/skills-en/documentation-criteria/SKILL.md

@@ -133,6 +133,9 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
 - **Data representation decision** (when introducing new structures)
 - **Applicable standards** (explicit/implicit classification)
 - **Prerequisite ADRs** (including common ADRs)
+- **Verification Strategy** (required)
+  - Correctness proof method (what "correct" means for this change, how it's verified, when)
+  - Early verification point (first target to prove the approach works, success criteria, failure response)
 
 **Excludes**:
 - Why that technology was chosen (->Reference ADR)
@@ -146,19 +149,33 @@ 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
-- **Include test skeleton file paths from acceptance-test-generator** (integration and E2E)
-- **Phase 4 Quality Assurance Phase (required)**
+- **Include test skeleton file paths** (integration and E2E)
+- **Verification Strategy summary** (extracted from Design Doc)
+- **Final Quality Assurance Phase (required)**
 - Progress records (checkbox format)
 
 **Excludes**:
 - Technical rationale (->ADR)
 - Design details (->Design Doc)
 
-**Phase Division Criteria**:
+**Phase Division Criteria** (adapt to implementation approach from Design Doc):
+
+**When Vertical Slice selected**:
+- Each phase = one value unit (feature, component, or migration target)
+- Each phase includes its own implementation + verification per Verification Strategy
+- Final Phase: Quality Assurance (cross-cutting verification, all tests passing)
+
+**When Horizontal Slice selected**:
 1. **Phase 1: Foundation Implementation** - Type definitions, interfaces, test preparation
 2. **Phase 2: Core Feature Implementation** - Business logic, unit tests
 3. **Phase 3: Integration Implementation** - External connections, presentation layer
-4. **Phase 4: Quality Assurance (Required)** - Acceptance criteria achievement, all tests passing, quality checks
+4. **Final Phase: Quality Assurance (Required)** - Acceptance criteria achievement, all tests passing, quality checks
+
+**When Hybrid selected**:
+- Combine vertical and horizontal as defined in Design Doc implementation approach
+- Final Phase: Quality Assurance (Required)
+
+**All approaches**: Final phase is always Quality Assurance. Each phase's verification method follows Verification Strategy from Design Doc.
 
 **Three Elements of Task Completion Definition**:
 1. **Implementation Complete**: Code is functional

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

@@ -286,6 +286,26 @@ Mark as N/A with brief rationale when the feature has no data layer dependencies
 
 - [List critical integration points that require testing beyond unit-level mocks]
 
+## Verification Strategy
+
+Verification Strategy defines what correctness means and how to prove it at design time. L1/L2/L3 (from implementation-approach skill) define completion verification granularity at task execution time.
+
+### Correctness Proof Method
+
+How will this change's correctness be demonstrated?
+
+- **Correctness definition**: [What "correct" means for this change — e.g., "output matches existing behavior", "all ACs pass in production-equivalent environment", "generated queries execute without error on target DB"]
+- **Verification method**: [Specific technique — e.g., "compare new implementation output against existing implementation", "run against staging DB", "contract test with real API"]
+- **Verification timing**: [When verification occurs — e.g., "after first vertical slice", "per repository", "at integration phase"]
+
+### Early Verification Point
+
+What is verified first, and how, to confirm the approach is correct before scaling?
+
+- **First verification target**: [The smallest unit that proves the approach works — e.g., "first repository migration", "single API endpoint", "one screen flow"]
+- **Success criteria**: [Observable outcome — e.g., "CSV download produces identical output to legacy", "API returns 200 with expected schema"]
+- **Failure response**: [What to do if early verification fails — e.g., "reassess approach before proceeding", "escalate to user"]
+
 ## Alternative Solutions
 
 ### Alternative 1

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

@@ -12,6 +12,18 @@ Related Issue/PR: #XXX (if any)
 - ADR: [docs/adr/ADR-XXXX.md] (if any)
 - PRD: [docs/prd/XXX.md] (if any)
 
+## Verification Strategy (from Design Doc)
+
+### Correctness Proof Method
+- **Correctness definition**: [extracted from Design Doc]
+- **Verification method**: [extracted from Design Doc]
+- **Verification timing**: [extracted from Design Doc]
+
+### Early Verification Point
+- **First verification target**: [extracted from Design Doc]
+- **Success criteria**: [extracted from Design Doc]
+- **Failure response**: [extracted from Design Doc]
+
 ## Objective
 [Why this change is necessary, what problem it solves]
 
@@ -31,51 +43,90 @@ Related Issue/PR: #XXX (if any)
 - [ ] Design Doc update needed
 - [ ] README update needed
 
-## Implementation Plan
+## Implementation Phases
 
-(Note: Phase structure is determined based on Design Doc technical dependencies and implementation approach)
+Select ONE phase structure based on implementation approach from Design Doc.
+See documentation-criteria skill for detailed Phase Division Criteria.
+**Delete the unused Option entirely from the final plan.** For hybrid approach, use Option A as the base and add horizontal foundation phases where needed.
 
-### Phase 1: [Phase Name] (Estimated commits: X)
-**Purpose**: [What this phase aims to achieve]
+### Option A: Vertical Slice Phase Structure
 
-#### Tasks
+Use when implementation approach is Vertical Slice. Each phase = one value unit with verification.
+
+#### Phase 1: [Value Unit 1 Name] (Estimated commits: X)
+**Purpose**: [First vertical slice — proves approach works]
+**Verification**: [From Verification Strategy: early verification point]
+
+##### Tasks
+- [ ] Task 1: Implementation
+- [ ] Task 2: Verification per Verification Strategy
+- [ ] Quality check: Implement staged quality checks (refer to technical-spec skill)
+
+##### Phase Completion Criteria
+- [ ] Early verification point passed
+- [ ] [Functional criteria]
+
+#### Phase 2: [Value Unit 2 Name] (Estimated commits: X)
+**Purpose**: [Subsequent value unit]
+**Verification**: [From Verification Strategy]
+
+##### Tasks
+- [ ] Task 1: Implementation
+- [ ] Task 2: Verification per Verification Strategy
+- [ ] Quality check
+
+##### Phase Completion Criteria
+- [ ] [Functional criteria]
+- [ ] [Quality criteria]
+
+### Option B: Horizontal Slice Phase Structure
+
+Use when implementation approach is Horizontal Slice. Phases follow Foundation → Core → Integration → QA.
+
+#### Phase 1: [Foundation] (Estimated commits: X)
+**Purpose**: Contract definitions, interfaces, test preparation
+
+##### Tasks
 - [ ] Task 1: Specific work content
 - [ ] Task 2: Specific work content
 - [ ] Quality check: Implement staged quality checks (refer to technical-spec skill)
 - [ ] Unit tests: All related tests pass
 
-#### Phase Completion Criteria
+##### Phase Completion Criteria
 - [ ] [Functional completion criteria]
 - [ ] [Quality completion criteria]
 
-### Phase 2: [Phase Name] (Estimated commits: X)
-**Purpose**: [What this phase aims to achieve]
+#### Phase 2: [Core Feature] (Estimated commits: X)
+**Purpose**: Business logic, unit tests
 
-#### Tasks
+##### Tasks
 - [ ] Task 1: Specific work content
 - [ ] Task 2: Specific work content
-- [ ] Quality check: Implement staged quality checks (refer to technical-spec skill)
+- [ ] Quality check
 - [ ] Integration tests: Verify overall feature functionality
 
-#### Phase Completion Criteria
+##### Phase Completion Criteria
 - [ ] [Functional completion criteria]
 - [ ] [Quality completion criteria]
 
-### Phase 3: [Phase Name] (Estimated commits: X)
-**Purpose**: [What this phase aims to achieve]
+#### Phase 3: [Integration] (Estimated commits: X)
+**Purpose**: External connections, presentation layer
 
-#### Tasks
+##### Tasks
 - [ ] Task 1: Specific work content
 - [ ] Task 2: Specific work content
-- [ ] Quality check: Implement staged quality checks (refer to technical-spec skill)
+- [ ] Quality check
 - [ ] Integration tests: Verify component coordination
 
-#### Phase Completion Criteria
+##### Phase Completion Criteria
 - [ ] [Functional completion criteria]
 - [ ] [Quality completion criteria]
 
 ### Final Phase: Quality Assurance (Required) (Estimated commits: 1)
-**Purpose**: Overall quality assurance and Design Doc consistency verification
+
+This phase is required for ALL implementation approaches.
+
+**Purpose**: Cross-cutting quality assurance and Design Doc consistency verification
 
 #### Tasks
 - [ ] Verify all Design Doc acceptance criteria achieved

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

@@ -33,9 +33,16 @@ Files to read before starting implementation (file path, with optional search hi
 - [ ] Improve code (maintain passing tests)
 - [ ] Confirm added tests still pass
 
+## Operation Verification Methods
+(Derived from Verification Strategy in work plan)
+- **Verification method**: [What to verify and how — e.g., "compare new implementation output against existing implementation at src/legacy/order_calc", "run endpoint against test database and verify response matches contract"]
+- **Success criteria**: [Observable outcome that proves correctness — e.g., "output matches existing implementation for all input combinations", "API returns 200 with expected schema"]
+- **Failure response**: [What to do if verification fails — e.g., "reassess approach before proceeding", "escalate to user"]
+- **Verification level**: [L1/L2/L3, per implementation-approach skill]
+
 ## Completion Criteria
 - [ ] All added tests pass
-- [ ] Operation verified (select L1/L2/L3, per implementation-approach skill)
+- [ ] Operation verified per Operation Verification Methods above
 - [ ] Deliverables created (for research/design tasks)
 
 ## Notes

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

@@ -272,6 +272,10 @@ Construct the prompt from the agent's Input Parameters section and the deliverab
    **Pass to code-verifier**: Design Doc path (doc_type: design-doc). `code_paths` is intentionally omitted — the verifier independently discovers code scope from the document.
    **Pass to document-reviewer**: code-verifier JSON output as `code_verification` parameter.
 
+   #### technical-designer → work-planner
+
+   **Pass to work-planner**: Design Doc path. Work-planner extracts Verification Strategy from the Design Doc and includes it in the work plan header.
+
    #### *1 acceptance-test-generator → work-planner
 
    **Pass to acceptance-test-generator**:

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

@@ -102,7 +102,7 @@ skills:
 
   documentation-criteria:
     skill: "documentation-criteria"
-    tags: [documentation, adr, prd, ui-spec, design-doc, work-plan, decision-matrix]
+    tags: [documentation, adr, prd, ui-spec, design-doc, work-plan, decision-matrix, verification-strategy]
     typical-use: "Implementation start scale assessment, document creation decisions, ADR/PRD/Design Doc/work plan creation criteria"
     size: medium
     key-references:
@@ -119,11 +119,12 @@ skills:
       - "AI Automation Rules"
       - "Diagram Requirements"
       - "Common ADR Relationships"
+      - "Phase Division Criteria"
       - "Templates"
 
   implementation-approach:
     skill: "implementation-approach"
-    tags: [architecture, implementation, task-decomposition, strategy-patterns, strangler-pattern, facade-pattern, design, planning, confirmation-levels]
+    tags: [architecture, implementation, task-decomposition, strategy-patterns, strangler-pattern, facade-pattern, design, planning, verification-levels]
     typical-use: "Implementation strategy selection, task decomposition, design decisions, large-scale change planning"
     size: medium
     key-references:

package/.claude/skills-ja/documentation-criteria/SKILL.md

@@ -133,6 +133,9 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 - **データ構造の採用判断**（新規構造導入時）
 - **適用基準**（explicit/implicit分類）
 - **前提となるADR**（共通ADR含む）
+- **検証戦略**（必須）
+  - 正しさの証明方法（この変更で「正しい」とは何か、どう検証するか、いつ検証するか）
+  - 早期検証ポイント（アプローチの妥当性を証明する最初の対象、成功基準、失敗時の対応）
 
 **必須構造要素**:
 ```yaml
@@ -162,7 +165,8 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 - **フェーズ構成**（Design Docの技術的依存関係を基に作成）
 - タスク分解と依存関係（最大2階層まで）
 - スケジュールと期間見積もり
-- **acceptance-test-generatorのテストスケルトンファイルパスを配置**（統合テスト・E2E）
+- **テストスケルトンファイルパスを配置**（統合テスト・E2E）
+- **検証戦略の要約**（Design Docから抽出）
 - **最終フェーズに品質保証を含む**（必須）
 - 進捗記録（チェックボックス形式）
 
@@ -171,6 +175,25 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 - 設計の詳細（→Design Doc）
 - 技術的依存関係の決定（→Design Doc）
 
+**フェーズ分割基準**（Design Docの実装アプローチに応じて適用）:
+
+**垂直スライス選択時**:
+- 各フェーズ = 1つの価値単位（機能、コンポーネント、移行対象）
+- 各フェーズに検証戦略に基づく実装＋検証を含む
+- 最終フェーズ: 品質保証（横断的検証、全テストパス）
+
+**水平スライス選択時**:
+1. **Phase 1: 基盤実装** - 型定義、インターフェース、テスト準備
+2. **Phase 2: コア機能実装** - ビジネスロジック、ユニットテスト
+3. **Phase 3: 統合実装** - 外部接続、プレゼンテーション層
+4. **最終Phase: 品質保証（必須）** - 受入条件達成、全テストパス、品質チェック
+
+**ハイブリッド選択時**:
+- Design Docの実装アプローチに基づき垂直と水平を組み合わせる
+- 最終フェーズ: 品質保証（必須）
+
+**全アプローチ共通**: 最終フェーズは常に品質保証。各フェーズの検証手法はDesign Docの検証戦略に従う。
+
 **タスク完了定義の3要素**:
 1. **実装完了**: コードが動作する
 2. **品質完了**: テスト・型チェック・リントがパス

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

@@ -286,6 +286,26 @@ unknowns:
 
 - [ユニットレベルのモックを超えるテストが必要な重要な統合ポイントの一覧]
 
+## 検証戦略
+
+設計時に「正しさとは何か」「どう証明するか」を定義する。L1/L2/L3（implementation-approachスキル）はタスク実行時の完了検証の粒度を定義する。
+
+### 正しさの証明方法
+
+この変更の正しさをどう示すか?
+
+- **正しさの定義**: [この変更における「正しい」の意味 — 例: 「既存の振る舞いと出力が一致」「全ACが本番同等環境でパス」「生成クエリが対象DBでエラーなく実行」]
+- **検証手法**: [具体的な技法 — 例: 「新旧実装の出力を比較」「ステージングDBに対して実行」「実APIとのコントラクトテスト」]
+- **検証タイミング**: [検証の実施時期 — 例: 「最初の垂直スライス完了後」「リポジトリごと」「統合フェーズ」]
+
+### 早期検証ポイント
+
+アプローチの妥当性を本格展開前に確認するため、最初に何を、どうやって検証するか?
+
+- **最初の検証対象**: [アプローチが機能することを証明する最小単位 — 例: 「最初のリポジトリ移行」「単一のAPIエンドポイント」「1つの画面フロー」]
+- **成功基準**: [観察可能な成果 — 例: 「CSVダウンロードが既存と同一の出力を生成」「APIが期待スキーマで200を返す」]
+- **失敗時の対応**: [早期検証が失敗した場合の対処 — 例: 「続行前にアプローチを再評価」「ユーザーにエスカレーション」]
+
 ## 代替案
 
 ### 代替案1

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

@@ -12,6 +12,18 @@
 - ADR: [docs/adr/ADR-XXXX.md]（該当する場合）
 - PRD: [docs/prd/XXX.md]（該当する場合）
 
+## 検証戦略（Design Docより）
+
+### 正しさの証明方法
+- **正しさの定義**: [Design Docから抽出]
+- **検証手法**: [Design Docから抽出]
+- **検証タイミング**: [Design Docから抽出]
+
+### 早期検証ポイント
+- **最初の検証対象**: [Design Docから抽出]
+- **成功基準**: [Design Docから抽出]
+- **失敗時の対応**: [Design Docから抽出]
+
 ## 目的
 [なぜこの変更が必要か、何を解決するか]
 
@@ -31,51 +43,90 @@
 - [ ] 設計書更新が必要
 - [ ] README更新が必要
 
-## 実装計画
+## 実装フェーズ
 
-（注: フェーズ構成はDesign Docの技術的依存関係と実装アプローチに基づいて決定）
+Design Docの実装アプローチに基づいてフェーズ構成をひとつ選択する。
+詳細はdocumentation-criteriaスキルのフェーズ分割基準を参照。
+**未使用のOptionは最終計画書から削除すること。** ハイブリッドの場合はOption Aをベースに、必要に応じて水平基盤フェーズを追加する。
 
-### Phase 1: [フェーズ名]（想定コミット数: X）
-**目的**: [このフェーズで達成すること]
+### Option A: 垂直スライスのフェーズ構成
 
-#### タスク
+実装アプローチが垂直スライスの場合に使用。各フェーズ = 検証付きの1価値単位。
+
+#### Phase 1: [価値単位1の名前]（想定コミット数: X）
+**目的**: [最初の垂直スライス — アプローチの妥当性を証明]
+**検証**: [検証戦略の早期検証ポイントから]
+
+##### タスク
+- [ ] タスク1: 実装
+- [ ] タスク2: 検証戦略に基づく検証
+- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
+
+##### フェーズ完了条件
+- [ ] 早期検証ポイント通過
+- [ ] [機能条件]
+
+#### Phase 2: [価値単位2の名前]（想定コミット数: X）
+**目的**: [後続の価値単位]
+**検証**: [検証戦略から]
+
+##### タスク
+- [ ] タスク1: 実装
+- [ ] タスク2: 検証戦略に基づく検証
+- [ ] 品質チェック
+
+##### フェーズ完了条件
+- [ ] [機能条件]
+- [ ] [品質条件]
+
+### Option B: 水平スライスのフェーズ構成
+
+実装アプローチが水平スライスの場合に使用。Foundation → Core → Integration → QAの順。
+
+#### Phase 1: [基盤]（想定コミット数: X）
+**目的**: 契約定義、インターフェース、テスト準備
+
+##### タスク
 - [ ] タスク1: 具体的な作業内容
 - [ ] タスク2: 具体的な作業内容
 - [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
 - [ ] 単体テスト: 関連する全テストがパス
 
-#### フェーズ完了条件
+##### フェーズ完了条件
 - [ ] [機能完了条件]
 - [ ] [品質完了条件]
 
-### Phase 2: [フェーズ名]（想定コミット数: X）
-**目的**: [このフェーズで達成すること]
+#### Phase 2: [コア機能]（想定コミット数: X）
+**目的**: ビジネスロジック、ユニットテスト
 
-#### タスク
+##### タスク
 - [ ] タスク1: 具体的な作業内容
 - [ ] タスク2: 具体的な作業内容
-- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
+- [ ] 品質チェック
 - [ ] 統合テスト: 機能全体の動作確認
 
-#### フェーズ完了条件
+##### フェーズ完了条件
 - [ ] [機能完了条件]
 - [ ] [品質完了条件]
 
-### Phase 3: [フェーズ名]（想定コミット数: X）
-**目的**: [このフェーズで達成すること]
+#### Phase 3: [統合]（想定コミット数: X）
+**目的**: 外部接続、プレゼンテーション層
 
-#### タスク
+##### タスク
 - [ ] タスク1: 具体的な作業内容
 - [ ] タスク2: 具体的な作業内容
-- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
+- [ ] 品質チェック
 - [ ] 統合テスト: コンポーネント連携の検証
 
-#### フェーズ完了条件
+##### フェーズ完了条件
 - [ ] [機能完了条件]
 - [ ] [品質完了条件]
 
 ### 最終Phase: 品質保証（必須）（想定コミット数: 1）
-**目的**: 全体品質保証とDesign Doc整合性検証
+
+このフェーズは全実装アプローチで必須。
+
+**目的**: 横断的品質保証とDesign Doc整合性検証
 
 #### タスク
 - [ ] Design Docの全受入条件達成を確認

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

@@ -33,9 +33,16 @@
 - [ ] コードを改善（テストはパス状態を維持）
 - [ ] 追加したテストが引き続きパスすることを確認
 
+## 動作検証方法
+（作業計画書の検証戦略から導出）
+- **検証手法**: [何をどう検証するか — 例: 「新実装の出力をsrc/legacy/order_calcの既存実装と比較」「エンドポイントをテストDBに対して実行しレスポンスがコントラクトに一致することを確認」]
+- **成功基準**: [正しさを証明する観察可能な成果 — 例: 「全入力パターンで既存実装と出力が一致」「APIが期待スキーマで200を返す」]
+- **失敗時の対応**: [検証失敗時の対処 — 例: 「続行前にアプローチを再評価」「ユーザーにエスカレーション」]
+- **検証レベル**: [L1/L2/L3、implementation-approachスキル参照]
+
 ## 完了条件
 - [ ] 追加した全テストがパス
-- [ ] 動作確認完了（L1/L2/L3を選択、implementation-approachスキル参照）
+- [ ] 動作検証方法に基づく動作確認完了
 - [ ] 成果物作成完了（調査・設計タスクの場合）
 
 ## 備考

package/.claude/skills-ja/implementation-approach/SKILL.md

@@ -105,7 +105,7 @@ description: 実装戦略（垂直スライス、水平、ハイブリッド）
 
 **Design Docでの記載**：実装戦略の選択理由と根拠を明記する。
 
-## 確認レベル定義
+## 検証レベル定義
 
 各タスクの完了確認における優先順位：
 

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

@@ -266,6 +266,10 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
    **code-verifierへの入力**: Design Docパス（doc_type: design-doc）。`code_paths`は意図的に未指定 — verifierがドキュメントからコードスコープを独自に発見する。
    **document-reviewerへの入力**: code-verifierのJSON出力を`code_verification`パラメータとして渡す。
 
+   #### technical-designer → work-planner
+
+   **work-plannerへの入力**: Design Docパス。work-plannerがDesign Docから検証戦略を抽出し、作業計画書ヘッダーに記載する。
+
    #### *1 acceptance-test-generator → work-planner
 
    **acceptance-test-generatorへの入力**:

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

@@ -93,7 +93,7 @@ skills:
 
   documentation-criteria:
     skill: "documentation-criteria"
-    tags: [documentation, decision-making, adr, prd, ui-spec, design-doc, planning, process]
+    tags: [documentation, decision-making, adr, prd, ui-spec, design-doc, planning, process, verification-strategy]
     typical-use: "実装開始時の規模判定、ドキュメント作成判定、ADR/PRD/Design Doc/作業計画書の作成基準"
     size: medium
     key-references:
@@ -110,11 +110,12 @@ skills:
       - "AI自動化ルール"
       - "図表作成要件"
       - "共通ADRとの関係性"
+      - "フェーズ分割基準"
       - "テンプレート"
 
   implementation-approach:
     skill: "implementation-approach"
-    tags: [architecture, implementation, task-decomposition, strategy-patterns, strangler-pattern, facade-pattern, design, planning, confirmation-levels]
+    tags: [architecture, implementation, task-decomposition, strategy-patterns, strangler-pattern, facade-pattern, design, planning, verification-levels]
     typical-use: "実装戦略の選択、タスク分解、設計判断、大規模変更の計画"
     size: medium
     key-references:
@@ -124,7 +125,7 @@ skills:
       - "Facade Pattern - Gang of Four"
     sections:
       - "メタ認知的戦略選択プロセス"
-      - "確認レベル定義"
+      - "検証レベル定義"
       - "統合ポイントの定義"
       - "アンチパターン"
       - "メタ認知的実行のための指針"

package/CHANGELOG.md

@@ -5,6 +5,25 @@ 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.20.1] - 2026-04-02
+
+### Added
+
+- **Verification Strategy flow**: Design Doc → Work Plan → Task pipeline now propagates how correctness is proven. Design template includes Correctness Proof Method and Early Verification Point sections. Work Plan template carries the strategy summary. Task template includes Operation Verification Methods derived from the strategy.
+- **Adaptive Phase Division Criteria**: Work Plan phase structure now adapts to implementation approach — vertical slice produces value-unit phases, horizontal slice retains Foundation → Core → Integration → QA, hybrid uses vertical as base with horizontal foundation phases. Plan template provides Option A/B with explicit instruction to delete the unused option.
+- **Verification Strategy review gates**: document-reviewer Gate 0 checks existence; Gate 1 checks quality (measurability, risk coverage, early verification concreteness, timing alignment with approach)
+- **Verification Strategy propagation in task-decomposer**: New section derives per-task Operation Verification Methods from the work plan's strategy, with concrete instantiation rules for early verification and per-task verification
+- **technical-designer → work-planner bridging**: Orchestration guide documents Verification Strategy handoff between design and planning phases
+
+### Changed
+
+- **Agent cross-references removed**: Agent definitions no longer reference other agents by name. `requirement-analyzer` → `requirement analysis`, `code-verifier` → `code verification`, `codebase-analyzer` → `codebase analysis phase`, etc. Orchestration layers own routing decisions.
+- **Acceptance criteria format**: technical-designer and technical-designer-frontend checklist item updated from "concrete trigger, action, and expected result" to "user-observable behaviors, integration/E2E oriented, CI-isolatable"
+- **testSkeletons input contract**: work-planner now describes format expectations (comment-based skeletons, not implemented tests) instead of naming the producer agent
+- **Command self-references removed**: update-doc no longer redirects to other commands; out-of-scope items stated without naming alternatives
+- **Japanese terminology unified**: `確認レベル` (confirmation level) → `検証レベル` (verification level) across all agents, skills, and skills-index to match English `Verification Level Definitions`
+- **skills-index.yaml updated**: `confirmation-levels` tag → `verification-levels`; `verification-strategy` tag and `Phase Division Criteria` section added to documentation-criteria
+
 ## [1.20.0] - 2026-04-01
 
 ### Added

package/package.json

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