create-ai-project 1.20.1 → 1.20.3

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

@@ -16,25 +16,13 @@ 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
+- **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
 
-### 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
+### First Action Rule
 
-**First Action Rule**: To accurately analyze user requirements, pass them directly to requirement-analyzer and determine the workflow based on its analysis results.
-
-## Decision Flow When Receiving Tasks
-
-```mermaid
-graph TD
-    Start[Receive New Task] --> RA[Analyze requirements with requirement-analyzer]
-    RA --> Scale[Scale assessment]
-    Scale --> Flow[Execute flow based on scale]
-```
-
-**During flow execution, determine next subagent according to scale determination table**
+When receiving a new task, pass user requirements directly to requirement-analyzer. Determine the workflow based on its scale assessment result.
 
 ### Requirement Change Detection During Flow
 
@@ -62,12 +50,42 @@ graph TD
 10. **technical-designer**: ADR/Design Doc creation (latest technology research, Property annotation assignment)
 11. **work-planner**: Work plan creation from Design Doc and test skeletons
 12. **document-reviewer**: Single document quality, completeness, and rule compliance check
-13. **code-verifier**: Verify Design Doc claims against existing codebase (used pre-review in design flow)
+13. **code-verifier**: Verify document-code consistency. Pre-implementation: Design Doc claims against existing codebase. Post-implementation: implementation against Design Doc
 14. **design-sync**: Design Doc consistency verification (detects explicit conflicts only)
 15. **acceptance-test-generator**: Generate separate integration and E2E test skeletons from Design Doc ACs and optional UI Spec
 
 ## 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 +127,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 | status (consistent/mostly_consistent/needs_review/inconsistent), consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent). Pre-implementation: verifies Design Doc claims against existing codebase. Post-implementation: verifies implementation consistency against Design Doc (pass `code_paths` scoped to changed files) | 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
 
@@ -146,9 +173,9 @@ According to scale determination:
 ### Medium Scale (3-5 Files) - 9 Steps (backend) / 11 Steps (frontend/fullstack)
 
 1. requirement-analyzer → Requirement analysis **[Stop]**
-2. codebase-analyzer → Codebase analysis (pass requirement-analyzer output)
-3. **(frontend/fullstack only)** Ask user for prototype code → ui-spec-designer → UI Spec creation
-4. **(frontend/fullstack only)** document-reviewer → UI Spec review **[Stop: UI Spec Approval]**
+2. **(frontend/fullstack only)** Ask user for prototype code → ui-spec-designer → UI Spec creation (UI Spec informs component structure for technical design)
+3. **(frontend/fullstack only)** document-reviewer → UI Spec review **[Stop: UI Spec Approval]**
+4. codebase-analyzer → Codebase analysis (pass requirement-analyzer output)
 5. technical-designer → Design Doc creation (pass codebase-analyzer output as additional context; cross-layer: per layer, see Cross-Layer Orchestration)
 6. code-verifier → Verify Design Doc against existing code (doc_type: design-doc)
 7. document-reviewer → Design Doc review (pass code-verifier results as code_verification; cross-layer: per Design Doc)
@@ -291,9 +318,7 @@ Construct the prompt from the agent's Input Parameters section and the deliverab
    - E2E test file: [path] (execute only in final phase)
 
    **On error**: Escalate to user if files are not generated
-3. **Quality Assurance and Commit Execution**: After confirming `status: "approved"`, immediately execute git commit
-4. **Autonomous Execution Mode Management**: Start/stop autonomous execution after approval, escalation decisions
-5. **ADR Status Management**: Update ADR status after user decision (Accepted/Rejected)
+3. **ADR Status Management**: Update ADR status after user decision (Accepted/Rejected)
 
 ## Important Constraints
 
@@ -301,24 +326,18 @@ 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
-
-## Required Dialogue Points with Humans
-
-### Basic Principles
-- **Stopping is mandatory**: Always wait for human response at the following timings
-- **Use AskUserQuestion**: Present confirmations and questions at all Stop points
-- **Confirmation -> Agreement cycle**: After document generation, proceed to next step after agreement or fix instructions in update mode
-- **Specific questions**: Make decisions easy with options (A/B/C) or comparison tables
-- **Dialogue over efficiency**: Get confirmation at early stages to prevent rework
-
-### Main Stop Points
-- **After requirement-analyzer completion**: Confirm requirement analysis results and questions
-- **After PRD creation -> document-reviewer execution**: Confirm requirement understanding and consistency (confirm with question list)
-- **After UI Spec creation -> document-reviewer execution** (frontend/fullstack): Confirm UI specification completeness and consistency
-- **After ADR creation -> document-reviewer execution**: Confirm technical direction and consistency (present multiple options with comparison table)
-  - On user approval: Main AI (me) updates Status to Accepted
-  - On user rejection: Main AI (me) updates Status to Rejected
-- **After Design Doc creation -> document-reviewer execution**: Confirm design content and consistency
-- **After work plan creation**: Batch approval for entire implementation phase (confirm with plan summary)
+- **Consistency verification**: When subagent outputs conflict, apply Decision precedence (see Delegation Boundary section)
+
+### Progress Tracking
+
+Register overall phases using TaskCreate. Update each phase with TaskUpdate as it completes.
+
+### Post-Implementation Verification Pass/Fail Criteria
+
+| Verifier | Pass | Fail | Blocked |
+|----------|------|------|---------|
+| code-verifier | `status` is `consistent` or `mostly_consistent` | `status` is `needs_review` or `inconsistent` | — |
+| security-reviewer | `status` is `approved` or `approved_with_notes` | `status` is `needs_revision` | `status` is `blocked` → Escalate to user |
+
+**Re-run rule**: After fix cycle, re-run only verifiers that returned **fail**. Verifiers that passed on the previous run are not re-run. Maximum 2 fix cycles — if still failing after 2 cycles, escalate to user with remaining findings.
 

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

@@ -168,7 +168,6 @@ skills:
       - "Agent Coordination Patterns"
     sections:
       - "Core Principle: I Am an Orchestrator"
-      - "Decision Flow When Receiving Tasks"
       - "Subagents I Can Utilize"
       - "My Orchestration Principles"
       - "Constraints Between Subagents"
@@ -179,7 +178,6 @@ skills:
       - "Autonomous Execution Mode"
       - "My Main Roles as Orchestrator"
       - "Important Constraints"
-      - "Required Dialogue Points with Humans"
 
   skill-optimization:
     skill: "skill-optimization"

package/.claude/skills-ja/coding-standards/references/security-checks.md

@@ -49,12 +49,14 @@ Sources: OWASP Top 10:2025, DryRun Agentic Coding Security Report (2026-03)
 - 認証ミドルウェアなしで定義されたエンドポイントやルートハンドラ
 - 認可検証なしのリソースアクセス操作（読み取り、更新、削除）
 - 昇格された権限なしでアクセス可能な管理操作や破壊的操作
-- 最近の研究でこのパターンがAI生成コードで高い発生率を示す — 高優先度のレビュー対象として扱う
+- AI生成コードでは認証ミドルウェアと認可チェックの欠落が頻発する — 全ルートハンドラとリソースアクセス操作をレビュー時に明示的に検証対象とする
+- 検出方法: 認証ミドルウェアを持たないルート/エンドポイントハンドラ定義を検索し、呼び出しチェーン内で認可チェックなしのリソース操作（読み取り、更新、削除）を検索
 
 ### 例外条件の不適切な処理（OWASP A10:2025）
 - レスポンスに内部システム詳細（スタックトレース、データベースエラー、ファイルパス）を露出するエラーハンドラ
-- フェイルオープン（エラー時にアクセスを許可または検証をスキップ）するエラーハンドラ
+- 例外発生時にアクセスを許可、認証をスキップ、または認可をバイパスするエラーハンドラ（フェイルオープン動作）
 - セキュリティ上重要な操作（認証、認可、暗号操作）でのエラーハンドリング欠如
+- 検出方法: レスポンスにスタックトレース、データベースエラーメッセージ、ファイルパスを返すcatch/エラーハンドラブロックを検索。セキュリティ状態を再検証せずにnext()を呼び出すまたは成功を返すcatchブロックを検索
 
 ### ソフトウェアサプライチェーンパターン（OWASP A03:2025）
 - バージョン固定なしでインポートされた依存関係

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

@@ -50,18 +50,14 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 
 **含むもの**:
 - ビジネス要件とユーザー価値
-- 成功指標とKPI（測定可能な形式）
+- 成功指標とKPI（各指標に数値目標、測定方法、期間を明記）
 - ユーザーストーリーとユースケース
 - MoSCoW法による優先順位（Must/Should/Could/Won't）
 - MVPとFutureフェーズの分離
 - ユーザージャーニー図（必須）
 - スコープ境界図（必須）
 
-**含まないもの**:
-- 技術実装詳細（→Design Doc）
-- 技術選定理由（→ADR）
-- **実装フェーズ**（→作業計画書）
-- **タスク分解**（→作業計画書）
+**スコープ**: ビジネス要件、ユーザー価値、成功指標、ユーザーストーリー、優先順位のみ。技術実装詳細はDesign Doc、技術選定理由はADR、フェーズとタスク分解は作業計画書に記載。
 
 ### ADR（Architecture Decision Record）
 
@@ -74,11 +70,7 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 - アーキテクチャへの影響
 - 実装への原則的な指針（例:「依存性注入を使用」）
 
-**含まないもの**:
-- 実装スケジュール、期間（→作業計画書）
-- 実装手順の詳細（→Design Doc）
-- 具体的なコード例（→Design Doc）
-- 担当者の割り当て（→作業計画書）
+**スコープ**: 決定事項、根拠、選択肢比較、アーキテクチャへの影響、原則的な指針のみ。実装手順とコード例はDesign Doc、スケジュールと担当割り当ては作業計画書に記載。
 
 ### UI Spec
 
@@ -94,11 +86,7 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 - ビジュアル受入条件(AC)（ゴールデンステート、レイアウト制約）
 - アクセシビリティ要件（キーボード、スクリーンリーダー、コントラスト）
 
-**含まないもの**:
-- 技術実装詳細（→ Design Doc）
-- APIコントラクトとデータレイヤー設計（→ Design Doc）
-- テスト実装（→ acceptance-test-generatorのスケルトン）
-- 実装スケジュール（→ 作業計画書）
+**スコープ**: 画面構造、遷移、コンポーネント分解、インタラクション設計、ビジュアル受入条件のみ。技術実装とAPIコントラクトはDesign Doc、テスト実装はacceptance-test-generatorスケルトン、スケジュールは作業計画書に記載。
 
 **必須構造要素**:
 - 状態×表示マトリクスとインタラクション表を含むコンポーネントが1つ以上
@@ -123,7 +111,7 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 - **技術的依存関係と実装制約**（実装の必要順序）
 - インターフェース定義と型定義
 - データフローとコンポーネント設計
-- **受入条件（EARS形式: When/While/If-then/無印）**
+- **受入条件（EARS形式 — design-template.md参照。各条件に検証可能な条件と合否閾値を明記）**
 - 変更影響マップ（直接影響/間接影響/波及なしを明記）
 - 統合点の完全な列挙
 - データ契約の明確化
@@ -152,10 +140,7 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
   互換性確保: [方法]
 ```
 
-**含まないもの**:
-- なぜその技術を選んだか（→ADR参照）
-- いつ実装するか、期間（→作業計画書）
-- 誰が実装するか（→作業計画書）
+**スコープ**: 技術実装方法、インターフェース、データフロー、受入条件、検証戦略のみ。技術選定理由はADR、スケジュールと担当は作業計画書に記載。
 
 ### 作業計画書
 
@@ -170,29 +155,23 @@ description: PRD、ADR、Design Doc、作業計画書の作成を支援。技術
 - **最終フェーズに品質保証を含む**（必須）
 - 進捗記録（チェックボックス形式）
 
-**含まないもの**:
-- 技術的な根拠（→ADR）
-- 設計の詳細（→Design Doc）
-- 技術的依存関係の決定（→Design Doc）
+**スコープ**: タスク分解、依存関係、スケジュール、検証戦略の要約、進捗追跡のみ。技術的な根拠はADR、設計詳細はDesign Docに記載。
 
 **フェーズ分割基準**（Design Docの実装アプローチに応じて適用）:
 
 **垂直スライス選択時**:
 - 各フェーズ = 1つの価値単位（機能、コンポーネント、移行対象）
 - 各フェーズに検証戦略に基づく実装＋検証を含む
-- 最終フェーズ: 品質保証（横断的検証、全テストパス）
 
 **水平スライス選択時**:
 1. **Phase 1: 基盤実装** - 型定義、インターフェース、テスト準備
 2. **Phase 2: コア機能実装** - ビジネスロジック、ユニットテスト
 3. **Phase 3: 統合実装** - 外部接続、プレゼンテーション層
-4. **最終Phase: 品質保証（必須）** - 受入条件達成、全テストパス、品質チェック
 
 **ハイブリッド選択時**:
 - Design Docの実装アプローチに基づき垂直と水平を組み合わせる
-- 最終フェーズ: 品質保証（必須）
 
-**全アプローチ共通**: 最終フェーズは常に品質保証。各フェーズの検証手法はDesign Docの検証戦略に従う。
+**全アプローチ共通**: 最終フェーズは常に品質保証（受入条件達成、全テストパス、品質チェック）。各フェーズの検証手法はDesign Docの検証戦略に従う。
 
 **タスク完了定義の3要素**:
 1. **実装完了**: コードが動作する

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

@@ -2,7 +2,7 @@
 
 ## ステータス
 
-[Proposed | Accepted | Deprecated | Superseded]
+[Proposed | Accepted | Deprecated | Superseded | Rejected]
 
 ## 経緯
 
@@ -54,6 +54,10 @@
 
 - [良くも悪くもない変化をリストアップ]
 
+## アーキテクチャへの影響
+
+[この決定が既存アーキテクチャにどう影響するか: (1) 変更されるコンポーネント、(2) 新たに導入される依存関係、(3) 追加または撤廃されるアーキテクチャ制約]
+
 ## 実装指針
 
 [原則的な方向性のみ。実装手順はDesign Docへ]

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

@@ -222,11 +222,16 @@ unknowns:
 
 ### エラーハンドリング
 
-[エラーの種類とその処理方法]
+| エラーカテゴリ | 例 | 検出方法 | 復旧戦略 | ユーザーへの影響 |
+|-------------|-----|---------|---------|---------------|
+| [検証 / 外部 / インフラ / ビジネスロジック] | [具体的なエラー] | [検出方法] | [リトライ / フォールバック / 伝播 / ログ後続行] | [ユーザー向けメッセージまたはサイレント処理] |
 
 ### ロギングとモニタリング
 
-[ログに記録する内容とモニタリング方法]
+- **ログイベント**: [記録すべきイベント: 状態遷移、外部呼び出し、エラー発生、パフォーマンス閾値]
+- **ログレベル**: [DEBUG/INFO/WARN/ERRORの振り分け]
+- **機密データ**: [マスクまたは除外するフィールド — セキュリティ考慮事項と連携]
+- **モニタリング**: [追跡する指標、アラート閾値、ダッシュボード要件]
 
 ## 実装計画
 

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

@@ -47,7 +47,8 @@
 
 Design Docの実装アプローチに基づいてフェーズ構成をひとつ選択する。
 詳細はdocumentation-criteriaスキルのフェーズ分割基準を参照。
-**未使用のOptionは最終計画書から削除すること。** ハイブリッドの場合はOption Aをベースに、必要に応じて水平基盤フェーズを追加する。
+全品質チェックはcoding-standardsスキルの品質チェックワークフローに従う。
+**未使用のOptionは最終計画書から削除すること。** ハイブリッドの場合はOption Cを使用する。
 
 ### Option A: 垂直スライスのフェーズ構成
 
@@ -60,7 +61,7 @@ Design Docの実装アプローチに基づいてフェーズ構成をひとつ
 ##### タスク
 - [ ] タスク1: 実装
 - [ ] タスク2: 検証戦略に基づく検証
-- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
+- [ ] 品質チェック（段階的）
 
 ##### フェーズ完了条件
 - [ ] 早期検証ポイント通過
@@ -89,7 +90,7 @@ Design Docの実装アプローチに基づいてフェーズ構成をひとつ
 ##### タスク
 - [ ] タスク1: 具体的な作業内容
 - [ ] タスク2: 具体的な作業内容
-- [ ] 品質チェック: 段階的品質チェック実施（technical-specスキル参照）
+- [ ] 品質チェック（段階的）
 - [ ] 単体テスト: 関連する全テストがパス
 
 ##### フェーズ完了条件
@@ -102,7 +103,7 @@ Design Docの実装アプローチに基づいてフェーズ構成をひとつ
 ##### タスク
 - [ ] タスク1: 具体的な作業内容
 - [ ] タスク2: 具体的な作業内容
-- [ ] 品質チェック
+- [ ] 品質チェック（段階的）
 - [ ] 統合テスト: 機能全体の動作確認
 
 ##### フェーズ完了条件
@@ -115,13 +116,17 @@ Design Docの実装アプローチに基づいてフェーズ構成をひとつ
 ##### タスク
 - [ ] タスク1: 具体的な作業内容
 - [ ] タスク2: 具体的な作業内容
-- [ ] 品質チェック
+- [ ] 品質チェック（段階的）
 - [ ] 統合テスト: コンポーネント連携の検証
 
 ##### フェーズ完了条件
 - [ ] [機能完了条件]
 - [ ] [品質完了条件]
 
+### Option C: ハイブリッドのフェーズ構成
+
+実装アプローチがハイブリッドの場合に使用。Design Docの実装アプローチに基づき垂直と水平を組み合わせる。各フェーズにタスク、検証、フェーズ完了条件のセクションを上記フォーマットに合わせて記載。
+
 ### 最終Phase: 品質保証（必須）（想定コミット数: 1）
 
 このフェーズは全実装アプローチで必須。
@@ -137,7 +142,7 @@ Design Docの実装アプローチに基づいてフェーズ構成をひとつ
 - [ ] ドキュメント更新
 
 ### 品質保証
-- [ ] 段階的品質チェック実施（詳細: technical-specスキル参照）
+- [ ] 品質チェック（段階的）
 
 ## リスクと対策
 | リスク | 対策 |

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

@@ -25,23 +25,45 @@
 2. [具体的な利用シナリオ2]
 3. [具体的な利用シナリオ3]
 
+### ユーザージャーニー図
+```mermaid
+journey
+    title [機能名] ユーザージャーニー
+    section [フェーズ1]
+      [ステップ]: [満足度スコア]: [アクター]
+```
+[トリガーイベントから目標達成までのエンドツーエンドのユーザー体験をマッピング]
+
+### スコープ境界図
+```mermaid
+C4Context
+    Boundary(scope, "スコープ内") {
+        [スコープ内のコンポーネント]
+    }
+    Boundary(out, "スコープ外") {
+        [スコープ外のコンポーネント]
+    }
+```
+[この機能に含まれるものと含まれないものを明確化]
+
 ## 機能要件
 
-### Must Have（MVP）
+### Must Have (P1 - MVP)
 - [ ] 要件1: [詳細説明]
   - AC: [受入条件 - Given/When/Then形式または測定可能な基準]
 - [ ] 要件2: [詳細説明]
   - AC: [受入条件]
-- [ ] 要件3: [詳細説明]
+
+### Should Have (P2)
+- [ ] 要件1: [詳細説明]
   - AC: [受入条件]
 
-### Nice to Have
+### Could Have (P3)
 - [ ] 要件1: [詳細説明]
-- [ ] 要件2: [詳細説明]
 
-### スコープ外
-- 項目1: [説明と理由]
-- 項目2: [説明と理由]
+### Won't Have（今回のリリース対象外）
+- 項目1: [説明と除外理由]
+- 項目2: [説明と除外理由]
 
 ## 非機能要件
 
@@ -69,9 +91,9 @@
 ## 成功基準
 
 ### 定量的指標
-1. [測定可能な成功指標1]
-2. [測定可能な成功指標2]
-3. [測定可能な成功指標3]
+1. [指標名]: [数値目標] を [測定方法] で [期間] 以内に達成
+2. [指標名]: [数値目標] を [測定方法] で [期間] 以内に達成
+3. [指標名]: [数値目標] を [測定方法] で [期間] 以内に達成
 
 ### 定性的指標
 1. [ユーザー体験の指標1]

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

@@ -38,7 +38,7 @@
 - **検証手法**: [何をどう検証するか — 例: 「新実装の出力をsrc/legacy/order_calcの既存実装と比較」「エンドポイントをテストDBに対して実行しレスポンスがコントラクトに一致することを確認」]
 - **成功基準**: [正しさを証明する観察可能な成果 — 例: 「全入力パターンで既存実装と出力が一致」「APIが期待スキーマで200を返す」]
 - **失敗時の対応**: [検証失敗時の対処 — 例: 「続行前にアプローチを再評価」「ユーザーにエスカレーション」]
-- **検証レベル**: [L1/L2/L3、implementation-approachスキル参照]
+- **検証レベル**: [L1: エンドユーザー機能としての動作確認 / L2: 新規テスト追加・パス / L3: ビルドエラーなし]
 
 ## 完了条件
 - [ ] 追加した全テストがパス
@@ -47,4 +47,4 @@
 
 ## 備考
 - 影響範囲: [変更が波及する可能性のある領域]
-- 制約: [変更してはいけない領域]
+- スコープ境界: [変更せず維持するファイル — パスと理由]