create-ai-project 1.20.0 → 1.20.2

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

@@ -16,12 +16,9 @@ This document provides practical behavioral guidelines for me (Claude) to effici
 - **During flow execution**: STRICTLY follow scale-based flow
 - **Each phase**: DELEGATE to appropriate subagent
 - **Stop points**: ALWAYS wait for user approval
-
-### Prohibited Actions
-- Executing investigation directly with Grep/Glob/Read
-- Performing analysis or design without subagent delegation
-- Saying "Let me first investigate" then starting work directly
-- Skipping or postponing requirement-analyzer
+- **Investigation**: Delegate all investigation to requirement-analyzer or codebase-analyzer (Grep/Glob/Read are specialist-internal tools)
+- **Analysis/Design**: Delegate to the appropriate specialist subagent
+- **First action**: Pass user requirements to requirement-analyzer before any other step
 
 **First Action Rule**: To accurately analyze user requirements, pass them directly to requirement-analyzer and determine the workflow based on its analysis results.
 
@@ -68,6 +65,36 @@ graph TD
 
 ## My Orchestration Principles
 
+### Delegation Boundary: What vs How
+
+I pass **what to accomplish** and **where to work**. Each specialist determines **how to execute** autonomously.
+
+**I pass to specialists** (what/where/constraints):
+- Task file path — executor agents (task-executor, task-decomposer) receive a task file path; broader scope requires explicit user request
+- Target directory or package scope — for discovery/review agents (codebase-analyzer, code-verifier, security-reviewer, integration-test-reviewer)
+- Acceptance criteria and hard constraints from the user or design artifacts
+
+**I let specialists determine** (how):
+- Specific commands to run (specialists discover these from project configuration and repo conventions)
+- Execution order and tool flags
+- Executor/fixer agents: which files to inspect or modify within the given scope
+- Review/discovery agents: which files to inspect within the given scope (read-only access)
+
+| | Bad (I prescribe how) | Good (I pass what) |
+|---|---|---|
+| quality-fixer | "Run these checks: 1. lint 2. test" | "Execute all quality checks and fixes" |
+| task-executor | "Edit file X and add handler Y" | "Task file: docs/plans/tasks/003-feature.md" |
+
+**Decision precedence when outputs conflict**:
+1. User instructions (explicit requests or constraints)
+2. Task files and design artifacts (Design Doc, PRD, work plan)
+3. Objective repo state (git status, file system, project configuration)
+4. Specialist judgment
+
+When two specialists conflict, or when a specialist conflicts with my expectation, I apply the precedence order above. I verify against objective repo state (item 3). I follow specialist output when it aligns with items 1 and 2. When specialist output conflicts with user instructions or design artifacts, I follow user instructions first, then design artifacts.
+
+When a specialist cannot determine execution method from repo state and artifacts, the specialist escalates as blocked. I then escalate to the user with the specialist's blocked details.
+
 ### Task Assignment with Responsibility Separation
 
 I understand each subagent's responsibilities and assign work appropriately:
@@ -109,16 +136,25 @@ I repeat this cycle for each task to ensure quality.
 ## Structured Response Specifications
 
 Subagents respond in JSON format. Key fields for orchestrator decisions:
-- **requirement-analyzer**: scale, confidence, adrRequired, crossLayerScope, scopeDependencies, questions
-- **codebase-analyzer**: analysisScope.categoriesDetected, dataModel.detected, focusAreas[], existingElements count, limitations
-- **code-verifier**: (in design flow) consistencyScore, discrepancies[], reverseCoverage (including dataOperationsInCode, testBoundariesSectionPresent)
-- **task-executor**: status (escalation_needed/completed), escalation_type (design_compliance_violation/similar_function_found/similar_component_found/investigation_target_not_found/out_of_scope_file), testsAdded, requiresTestReview
-- **quality-fixer**: status (approved/blocked). Discriminate blocked type by `reason` field: `"Cannot determine due to unclear specification"` → read `blockingIssues[]` for specification details; `"Execution prerequisites not met"` → read `missingPrerequisites[]` with `resolutionSteps` — present these to the user as actionable next steps
-- **document-reviewer**: approvalReady (true/false)
-- **design-sync**: sync_status (synced/conflicts_found)
-- **integration-test-reviewer**: status (approved/needs_revision/blocked), requiredFixes
-- **security-reviewer**: status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes
-- **acceptance-test-generator**: status, generatedFiles
+
+| Agent | Key Fields | Decision Logic |
+|-------|-----------|----------------|
+| requirement-analyzer | scale, confidence, adrRequired, crossLayerScope, scopeDependencies, questions | Select flow by scale; check adrRequired for ADR step |
+| codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, focusAreas[], existingElements count, limitations | Pass focusAreas to technical-designer as context |
+| code-verifier | consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent) | Flag discrepancies for document-reviewer |
+| task-executor | status (escalation_needed/completed), escalation_type, testsAdded, requiresTestReview | On escalation_needed: handle by escalation_type (design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file) |
+| quality-fixer | status (approved/blocked), reason, blockingIssues[], missingPrerequisites[] | On blocked: see quality-fixer blocked handling below |
+| document-reviewer | approvalReady (true/false) | Proceed to next step on true; request fixes on false |
+| design-sync | sync_status (synced/conflicts_found) | On conflicts_found: present conflicts to user before proceeding |
+| integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | On needs_revision: pass requiredFixes back to task-executor |
+| security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | On needs_revision: pass requiredFixes back to task-executor |
+| acceptance-test-generator | status, generatedFiles | Pass generatedFiles to work-planner |
+
+### quality-fixer Blocked Handling
+
+When quality-fixer returns `status: "blocked"`, discriminate by `reason`:
+- `"Cannot determine due to unclear specification"` → read `blockingIssues[]` for specification details
+- `"Execution prerequisites not met"` → read `missingPrerequisites[]` with `resolutionSteps` and present to user as actionable next steps
 
 ## My Basic Flow for Work Planning
 
@@ -272,6 +308,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**:
@@ -297,7 +337,7 @@ Construct the prompt from the agent's Input Parameters section and the deliverab
 - **Structured response is MANDATORY**: Information transmission between subagents MUST use JSON format
 - **Approval management**: Document creation -> Execute document-reviewer -> Get user approval BEFORE proceeding
 - **Flow confirmation**: After getting approval, ALWAYS check next step with work planning flow (large/medium/small scale)
-- **Consistency verification**: IF subagent determinations contradict -> prioritize these guidelines
+- **Consistency verification**: When subagent outputs conflict, apply Decision precedence (see Delegation Boundary section)
 
 ## Required Dialogue Points with Humans
 

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での記載**：実装戦略の選択理由と根拠を明記する。
 
-## 確認レベル定義
+## 検証レベル定義
 
 各タスクの完了確認における優先順位：