create-ai-project 1.20.2 → 1.20.3

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

@@ -20,18 +20,9 @@ This document provides practical behavioral guidelines for me (Claude) to effici
 - **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.
+### First Action Rule
 
-## 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
 
@@ -59,7 +50,7 @@ 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
 
@@ -141,7 +132,7 @@ Subagents respond in JSON format. Key fields for orchestrator decisions:
 |-------|-----------|----------------|
 | 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 |
+| 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 |
@@ -182,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)
@@ -327,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
 
@@ -339,22 +328,16 @@ Construct the prompt from the agent's Input Parameters section and the deliverab
 - **Flow confirmation**: After getting approval, ALWAYS check next step with work planning flow (large/medium/small scale)
 - **Consistency verification**: When subagent outputs conflict, apply Decision precedence (see Delegation Boundary section)
 
-## 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)
+### 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 @@
 
 ## 備考
 - 影響範囲: [変更が波及する可能性のある領域]
-- 制約: [変更してはいけない領域]
+- スコープ境界: [変更せず維持するファイル — パスと理由]

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

@@ -20,18 +20,9 @@ description: サブエージェントのタスク分担と連携を調整。規
 - **分析・設計**: 該当するサブエージェントに委譲
 - **初動**: ユーザー要件はrequirement-analyzerに渡してから他のステップへ進む
 
-**初動アクション規則**: ユーザー要件を正確に分析するため、requirement-analyzerに直接渡し、その分析結果に基づいてワークフローを決定する。
+### 初動アクション規則
 
-## タスク受領時の判断
-
-```mermaid
-graph TD
-    Start[新規タスク受領] --> RA[requirement-analyzerで要件分析]
-    RA --> Scale[規模判定]
-    Scale --> Flow[規模に応じたフロー実行]
-```
-
-**フロー実行中は規模判定表に従って次のサブエージェントを決定する**
+新しいタスクを受け取ったら、ユーザー要件をrequirement-analyzerに直接渡す。その規模判定結果に基づいてワークフローを決定する。
 
 ### フロー実行中の要件変更検知
 
@@ -59,7 +50,7 @@ graph TD
 10. **technical-designer**: ADR/Design Doc作成（最新技術情報の調査、Property注釈付与）
 11. **work-planner**: 作業計画書作成（テストスケルトンからメタ情報を抽出・反映）
 12. **document-reviewer**: 単一ドキュメントの品質・完成度・ルール準拠チェック
-13. **code-verifier**: Design Docの主張を既存コードベースに対して検証（設計フローでレビュー前に使用）
+13. **code-verifier**: ドキュメントとコードの整合性を検証。実装前: Design Docの主張を既存コードベースに対して検証。実装後: 実装がDesign Docに準拠しているか検証
 14. **design-sync**: Design Doc間の整合性検証（明示的矛盾のみ検出）
 15. **acceptance-test-generator**: Design DocのACとUI Spec（任意）から統合テストとE2Eテストのスケルトン生成
 
@@ -139,7 +130,7 @@ graph TD
 |-------|---------------|-------------|
 | requirement-analyzer | scale, confidence, adrRequired, crossLayerScope, scopeDependencies, questions | scaleでフローを選択。adrRequiredでADRステップ要否を判断 |
 | codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, focusAreas[], existingElements count, limitations | focusAreasをtechnical-designerにコンテキストとして渡す |
-| code-verifier | consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent) | discrepanciesをdocument-reviewerに連携 |
+| code-verifier | status (consistent/mostly_consistent/needs_review/inconsistent), consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent). 実装前: Design Docの主張を既存コードに対して検証。実装後: 実装のDesign Doc整合性を検証（`code_paths`で変更ファイルにスコープ） | discrepanciesをdocument-reviewerに連携 |
 | task-executor | status (escalation_needed/completed), escalation_type, testsAdded, requiresTestReview | escalation_needed時: 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[] | blocked時: 下記quality-fixer blockedハンドリング参照 |
 | document-reviewer | approvalReady (true/false) | trueで次ステップへ。falseで修正を依頼 |
@@ -177,9 +168,9 @@ quality-fixerが `status: "blocked"` を返した場合、`reason`で判別：
 ### 中規模（3-5ファイル） - 9ステップ（バックエンド） / 11ステップ（フロントエンド/フルスタック）
 
 1. requirement-analyzer → 要件分析 **[停止]**
-2. codebase-analyzer → コードベース分析（要件分析結果を入力）
-3. **（フロントエンド/フルスタックのみ）** プロトタイプコードの有無を確認 → ui-spec-designer → UI Spec作成
-4. **（フロントエンド/フルスタックのみ）** document-reviewer → UI Specレビュー **[停止: UI Spec承認]**
+2. **（フロントエンド/フルスタックのみ）** プロトタイプコードの有無を確認 → ui-spec-designer → UI Spec作成（コンポーネント構造が技術設計に反映されるため先に実施）
+3. **（フロントエンド/フルスタックのみ）** document-reviewer → UI Specレビュー **[停止: UI Spec承認]**
+4. codebase-analyzer → コードベース分析（要件分析結果を入力）
 5. technical-designer → Design Doc作成（codebase-analyzer出力を追加コンテキストとして入力。レイヤー横断時: レイヤー別に作成、レイヤー横断オーケストレーション参照）
 6. code-verifier → Design Docを既存コードに対して検証（doc_type: design-doc）
 7. document-reviewer → Design Docレビュー（code-verifier結果をcode_verificationとして入力。レイヤー横断時: Design Doc毎に実行）
@@ -323,9 +314,7 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
    - E2Eテストファイル: [パス]（最終フェーズでのみ実行）
 
    **エラー時**: ファイルが生成されない場合はユーザーにエスカレーション
-3. **品質保証とコミット実行**: `status: "approved"`確認後、即座にgit commit実行
-4. **自律実行モード管理**: 承認後の自律実行開始・停止・エスカレーション判断
-5. **ADRステータス管理**: ユーザー判断後のADRステータス更新（Accepted/Rejected）
+3. **ADRステータス管理**: ユーザー判断後のADRステータス更新（Accepted/Rejected）
 
 ## 重要な制約
 
@@ -335,19 +324,15 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
 - **フロー確認**: 承認取得後は必ず作業計画フロー（大規模/中規模/小規模）で次のステップを確認
 - **整合性検証**: サブエージェントの出力が矛盾した場合、優先順位に従って解決（委譲の境界セクション参照）
 
-## 人間との必須対話ポイント
-
-### 基本原則
-- **停止は必須**: 以下のタイミングでは必ず人間の応答を待つ
-- **AskUserQuestionを使用**: 全ての停止ポイントで確認と質問を提示
-- **確認→合意のサイクル**: ドキュメント生成後は合意またはupdateモードでの修正指示を受けてから次へ進む
-- **具体的な質問**: 選択肢（A/B/C）や比較表を用いて判断しやすく
-- **効率より対話**: 手戻りを防ぐため、早い段階で確認を取る
-
-### 主要な停止ポイント
-- **requirement-analyzer完了後**: 要件分析結果と質問事項の確認
-- **PRD作成→document-reviewer実行後**: 要件理解と整合性の確認
-- **UI Spec作成→document-reviewer実行後**（フロントエンド/フルスタック）: UI仕様の完全性と整合性の確認
-- **ADR作成→document-reviewer実行後**: 技術方針と整合性の確認
-- **Design Doc作成→document-reviewer実行後**: 設計内容と整合性の確認
-- **計画書作成後**: 実装フェーズ全体の一括承認
+### 進捗管理
+
+TaskCreateで全体フェーズを登録。各フェーズ完了時にTaskUpdateで更新。
+
+### 実装後検証のPass/Fail基準
+
+| Verifier | Pass | Fail | Blocked |
+|----------|------|------|---------|
+| code-verifier | `status`が`consistent`または`mostly_consistent` | `status`が`needs_review`または`inconsistent` | — |
+| security-reviewer | `status`が`approved`または`approved_with_notes` | `status`が`needs_revision` | `status`が`blocked` → ユーザーにエスカレーション |
+
+**再実行ルール**: 修正サイクル後、**Fail**を返した検証エージェントのみ再実行。前回Passした検証エージェントは再実行しない。最大2回の修正サイクル — 2回後も不合格が残る場合、残存する検出事項とともにユーザーにエスカレーション。

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

@@ -159,7 +159,6 @@ skills:
       - "エージェント連携パターン"
     sections:
       - "最重要原則：オーケストレーターとして振る舞う"
-      - "タスク受領時の判断"
       - "活用できるサブエージェント"
       - "オーケストレーション原則"
       - "Sub-agent間の制約"
@@ -170,7 +169,6 @@ skills:
       - "自律実行モード"
       - "オーケストレーターの主な役割"
       - "重要な制約"
-      - "人間との必須対話ポイント"
 
   skill-optimization:
     skill: "skill-optimization"

package/CHANGELOG.md

@@ -5,6 +5,46 @@ 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.3] - 2026-04-04
+
+### Added
+
+- **code-reviewer: Identifier Verification** — Extract identifier specifications (resource names, endpoint paths, config keys, schema names) from Design Doc and verify exact string match against implementation. Added `identifierMatchRate` and `identifierVerification[]` to output schema
+- **code-reviewer: Evidence-Based Confidence** — Multi-source evidence collection (primary: implementation, secondary: tests, tertiary: config/types) with high/medium/low confidence per AC. Added `evidence_source` field to track tool provenance per determination
+- **code-reviewer: Finding Classification** — Quality findings categorized as `dd_violation`/`maintainability`/`reliability`/`coverage_gap` with category-specific rationale requirements. Output Self-Check ensures every finding cites file:line and tool name
+- **Post-Implementation Verification** (commands, skills) — `build` and `front-build` now run code-verifier and security-reviewer in parallel after all tasks complete. Pass/fail criteria defined in orchestration guide with max 2 fix cycles before escalation
+- **front-design: Workflow Overview** — ASCII flow diagram showing the full design pipeline with stop points
+- **front-design: Completion Criteria** — Explicit checklist of required steps before design phase is complete
+- **front-design: design-sync step** — Added Step 4 for cross-document consistency verification before final approval
+- **ADR template: Architecture Impact section** — Documents how the decision affects existing components, dependencies, and constraints
+- **ADR template: Rejected status** — Added to status options alongside Proposed/Accepted/Deprecated/Superseded
+- **PRD template: User Journey and Scope Boundary diagrams** — Required mermaid diagrams added to template
+- **PRD template: MoSCoW prioritization** — Must Have(P1)/Should Have(P2)/Could Have(P3)/Won't Have structure replaces Must/Nice to Have/Out of Scope
+- **PRD template: Quantitative success metrics format** — Each metric specifies numeric target, measurement method, and timeframe
+- **Design template: Error Handling table** — Free-text placeholder replaced with structured table (Category, Example, Detection, Recovery, User Impact)
+- **Design template: Logging sub-categories** — Structured log events, levels, sensitive data handling, and monitoring requirements
+- **Plan template: Hybrid option** — Option C added for hybrid implementation approach alongside Vertical Slice and Horizontal Slice
+- **Security checks: Detection approach** — Added concrete detection methods for Access Control Gaps and Mishandling of Exceptional Conditions patterns
+
+### Changed
+
+- **BP-001 Negative → Positive form** (agents, 17 files) — Converted negative instructions to positive directives across all agent definitions. "Don't forget test creation" → "Include test creation in every task", "No contradiction with PRD" → "All requirements align with PRD", "any prohibited" → "use strict types", etc.
+- **BP-002 Vague → Concrete** (agents, skills) — Replaced ambiguous expressions with measurable criteria. "avoid excessive detail" → "include only information required for task execution and verification", "measurable format" → "each metric specifies a numeric target, measurement method, and timeframe"
+- **Emoji markers removed** (agents) — Removed ✅/❌ markers from instruction contexts (quality-fixer, requirement-analyzer, technical-designer-frontend, build, front-build). Retained only in user-facing output templates
+- **documentation-criteria: Excludes → Scope** (skills) — Separate Includes/Excludes blocks consolidated into single Scope statement per document type, reducing duplication
+- **documentation-criteria: QA phase unified** (skills) — Per-approach "Final Phase: Quality Assurance" entries consolidated into single "All approaches" statement
+- **orchestration-guide: First Action Rule simplified** (skills) — Mermaid diagram and duplicate text replaced with single-line rule
+- **orchestration-guide: Redundant sections removed** (skills) — Required Dialogue Points, Decision Flow diagram, duplicate orchestrator roles compressed
+- **orchestration-guide: Medium frontend flow reordered** (skills) — UI Spec creation moved before codebase analysis to match large-scale flow and front-design command — component structure informs technical design
+- **orchestration-guide: code-verifier description expanded** (skills) — Now documents both pre-implementation and post-implementation verification modes with status field values
+- **front-design: Execution Protocol** (commands) — Replaced role/method block with structured protocol referencing orchestration guide. Documents UI Spec → codebase-analyzer ordering rationale
+- **front-plan: Test skeleton mandatory** (commands) — Removed optional user confirmation — acceptance-test-generator always executes before work-planner per orchestration guide flow
+- **front-build: Streamlined** (commands) — Removed redundant Execution Method, Sub-agent Invocation Method, and Structured Response Specification sections. Scope line added to Execution Protocol
+- **front-review: Orchestrator identity** (commands) — Added Orchestrator Definition with TaskCreate-first action. Replaced rule-advisor with documentation-criteria in fix flow. Step numbering unified (Step 1-11)
+- **review/front-review: Re-validation context** (commands) — Re-validation prompts now include Design Doc path and implementation file list alongside prior issues
+- **review/front-review: Report template** (commands) — Added identifierMatchRate, confidence levels, identifier mismatches, and quality findings sections
+- **skills-index.yaml** (skills) — Removed deleted sections from orchestration-guide entry (Decision Flow, Required Dialogue Points)
+
 ## [1.20.2] - 2026-04-03
 
 ### Added