create-ai-project 1.20.0 → 1.20.2

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 |