create-ai-project 1.20.2 → 1.20.4

package/.claude/commands-ja/front-build.md

@@ -4,20 +4,13 @@ description: フロントエンド実装を自律実行モードで実行
 
 ## オーケストレーター定義
 
-**コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」（subagents-orchestration-guideスキル参照）
-
-**実行方法**:
-- タスク分解 → task-decomposerが実行
-- フロントエンド実装 → task-executor-frontendが実行
-- 品質チェックと修正 → quality-fixer-frontendが実行
-- コミット → オーケストレーター（Bashツール）
-
-オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
+**コアアイデンティティ**: 「私はオーケストレーターである。」（subagents-orchestration-guideスキル参照）
 
 **実行プロトコル**:
-1. **全作業をAgentツールでサブエージェントに委譲** — サブエージェントの呼び出し、データの受け渡し、結果の報告（許可ツール: subagents-orchestration-guideスキル「オーケストレーターの許可ツール」参照）
+1. **全作業をAgentツールでサブエージェントに委譲** — サブエージェントの呼び出し、成果物パスの受け渡し、結果の報告（許可ツール: subagents-orchestration-guideスキル「オーケストレーターの許可ツール」参照）
 2. **4ステップサイクルに厳密に従う**: task-executor-frontend → エスカレーションチェック → quality-fixer-frontend → commit
 3. **自律実行モード移行**: ユーザーの実行指示とタスクファイルの存在をもってバッチ承認とする
+4. **スコープ**: 全タスクのコミット完了またはエスカレーションで責務完了
 
 **重要**: 全てのコミット前にquality-fixer-frontendを実行。
 
@@ -69,7 +62,7 @@ Agentツールでtask-decomposerを呼び出す:
 ! ls -la docs/plans/tasks/*.md | head -10
 ```
 
-✅ **フロー**: タスク生成 → 自律実行（この順序で実行）
+**フロー**: タスク生成 → 自律実行（この順序で実行）
 
 ## 実行前チェックリスト
 
@@ -79,40 +72,22 @@ Agentツールでtask-decomposerを呼び出す:
   - コミット機能が利用不可 → 自律実行モード前にエスカレーション
   - その他の環境（テスト、品質ツール） → サブエージェントがエスカレーション
 
-## タスク実行サイクル（4ステップサイクル） - フロントエンド特化
-
+## タスク実行サイクル（4ステップサイクル）
 **必須実行サイクル**: `task-executor-frontend → エスカレーションチェック → quality-fixer-frontend → commit`
 
-### サブエージェント呼び出し方法
-Agentツールを使用してサブエージェントを呼び出す：
-- `subagent_type`: エージェント名
-- `description`: タスクの簡潔な説明（3-5語）
-- `prompt`: 具体的な指示内容
-
-### 構造化レスポンス仕様
-各サブエージェントはJSON形式で応答：
-- **task-executor-frontend**: status, filesModified, testsAdded, requiresTestReview, readyForQualityCheck
-- **integration-test-reviewer**: status (approved/needs_revision/blocked), requiredFixes
-- **quality-fixer-frontend**: status, checksPerformed, fixesApplied, approved
-
-### 各タスクの実行フロー
-
 各タスクで必須：
-
 1. **TaskCreateでタスク登録**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」
-2. **task-executor-frontend実行**: フロントエンド実装を実行
-   - 呼び出し例: `subagent_type: "task-executor-frontend"`, `description: "タスク実行"`, `prompt: "タスクファイル: docs/plans/tasks/[ファイル名].md 実装を実行"`
+2. **Agent tool** (subagent_type: "task-executor-frontend") → タスクファイルパスをpromptに渡し、構造化レスポンスを受け取る
 3. **task-executor-frontendレスポンスチェック**:
    - `status: "escalation_needed"` または `"blocked"` → 停止してユーザーにエスカレーション
    - `requiresTestReview` が `true` → **integration-test-reviewer**を実行
      - `needs_revision` → `requiredFixes`を添えてステップ2に戻る
      - `approved` → ステップ4へ
    - `readyForQualityCheck: true` → ステップ4へ
-4. **quality-fixer-frontend実行**: 全フロントエンド品質チェックと修正を実行
-   - 呼び出し例: `subagent_type: "quality-fixer-frontend"`, `description: "品質チェック"`, `prompt: "全てのフロントエンド品質チェックと修正を実行"`
-5. **コミット実行**: `approved: true`確認後、即座にgit commitを実行。`changeSummary`をコミットメッセージに使用。
+4. **quality-fixer-frontend実行**: 全品質チェックと修正を実行
+5. **承認後コミット**: quality-fixer-frontendの`approved: true`確認後 → git commitを実行
 
-**重要**: 例外なく全ての構造化レスポンスを監視し、全ての品質ゲートが通過することを確保。
+**重要**: 全てのサブエージェントレスポンスのstatusフィールドをパースし、4ステップサイクルの対応ブランチを実行。quality-fixer-frontendが`approved: true`を返すまで次のタスクに進まない。
 
 ## サブエージェント呼び出し時の制約
 
@@ -128,14 +103,23 @@ Agentツールを使用してサブエージェントを呼び出す：
 
 承認ステータスを確認してから進む。確認後、自律実行モードを開始。要件変更を検出したら即座に停止。
 
-## Security Review（全タスク完了後）
+## 実装後検証（全タスク完了後）
+
+全タスクサイクル完了後、完了レポートの前に検証エージェントを**並列実行**:
+
+1. **両方を並列で実行** (Agent tool):
+   - code-verifier (subagent_type: "code-verifier") → `doc_type: design-doc`、Design Docパス、`code_paths`: 実装ファイルリスト（`git diff --name-only main...HEAD`）
+   - security-reviewer (subagent_type: "security-reviewer") → Design Docパス、実装ファイルリスト
+
+2. **結果の統合** — 合格/不合格の基準はsubagents-orchestration-guideの実装後検証セクション参照。統合検証レポートをユーザーに提示。
+
+3. **修正サイクル**（いずれかの検証エージェントが不合格の場合、最大2回）:
+   - 全ての対応可能な検出事項を1つのタスクファイルに統合
+   - task-executor-frontendで統合修正を実行 → quality-fixer-frontend
+   - 不合格の検証エージェントのみ再実行
+   - 2回のサイクル後も不合格が残る場合 → 残存する検出事項とともにユーザーにエスカレーション
 
-全タスクサイクル完了後、完了レポートの前にsecurity-reviewerを実行:
-1. **Agent tool** (subagent_type: "security-reviewer") → Design Docパスと実装ファイルリストを渡す
-2. レスポンスを確認:
-   - `approved` または `approved_with_notes` → 完了レポートへ（notesがあれば含める）
-   - `needs_revision` → task-executor-frontendで`requiredFixes`を実行、quality-fixer-frontend実行後、security-reviewerを再実行
-   - `blocked` → ユーザーにエスカレーション
+4. **全て合格** → 完了レポートへ
 
 ## 出力例
 フロントエンド実装フェーズ完了。

package/.claude/commands-ja/front-design.md

@@ -6,26 +6,42 @@ description: 要件分析からフロントエンド設計ドキュメント作
 
 ## オーケストレーター定義
 
-**Role**: オーケストレーター
-
-**実行方法**:
-- 要件分析 → requirement-analyzerが実行
-- UI Spec作成 → ui-spec-designerが実行
-- 設計書作成 → technical-designer-frontendが実行
-- ドキュメントレビュー → document-reviewerが実行
-
-オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
+**コアアイデンティティ**: 「私はオーケストレーターである。」（subagents-orchestration-guideスキル参照）
+
+**実行プロトコル**:
+1. **全ての作業をサブエージェントに委譲** — サブエージェントを呼び出し、データを橋渡しし、結果を報告する
+2. **以下のフロントエンド設計フローに従う**（このコマンドは中規模/大規模のフロントエンドを対象。UI Specはコードベース分析の前に作成する — コンポーネント構造が技術設計に反映されるため）:
+   - 実行: requirement-analyzer → ui-spec-designer → codebase-analyzer → technical-designer-frontend → code-verifier → document-reviewer → design-sync
+   - **`[停止: ...]`マーカーごとに停止** → ユーザー承認を待つ
+3. **スコープ**: 設計ドキュメントの承認をもって完了
+
+**重要**: document-reviewer、design-sync、subagents-orchestration-guideスキルフローで定義された全ての停止ポイントを実行すること — 各ステップが品質ゲートとして機能する。スキップは検出されない不整合のリスクにつながる。
+
+## ワークフロー概要
+
+```
+要件 → requirement-analyzer → [停止: 規模判定]
+                                    ↓
+                            ui-spec-designer → [停止: UI Spec承認]
+                                    ↓
+                            codebase-analyzer → technical-designer-frontend
+                                    ↓
+                            code-verifier → document-reviewer
+                                    ↓
+                               design-sync → [停止: 設計承認]
+```
 
 ## スコープ境界
 
 **実行内容**:
 - requirement-analyzerによる要件分析
-- codebase-analyzerによるコードベース分析（Design Doc作成前に実施）
+- codebase-analyzerによるコードベース分析（技術設計の前に実施）
 - ui-spec-designerによるUI Spec作成（プロトタイプコード確認を含む）
 - ADR作成（アーキテクチャ変更、新技術、データフロー変更がある場合）
 - technical-designer-frontendによるDesign Doc作成
 - code-verifierによるDesign Doc検証（ドキュメントレビューの前に実施）
 - document-reviewerによるドキュメントレビュー
+- design-syncによるDesign Doc横断整合性検証
 
 **責務境界**: このコマンドはフロントエンド設計ドキュメント（UI Spec/ADR/Design Doc）の承認で責務完了。作業計画以降はスコープ外。
 
@@ -39,7 +55,7 @@ description: 要件分析からフロントエンド設計ドキュメント作
 - 期待する成果と成功基準
 - 既存システムとの関係
 
-要件がある程度明確になったら:
+ユーザーが上記3つの質問に回答した後、設計スコープ内で以下のプロセスを実行する。codebase-analyzerとcode-verifierの呼び出しはsubagents-orchestration-guideのCall Examplesに従う。
 - Agentツールで**requirement-analyzer**を呼び出す
   - `subagent_type: "requirement-analyzer"`
   - `description: "要件分析"`
@@ -61,7 +77,7 @@ UI Specを作成:
   - PRDあり＋プロトタイプなし: `prompt: "[パス]のPRDからUI Specを作成。プロトタイプコードなし。"`
   - PRDなし（中規模）: `prompt: "以下の要件に基づいてUI Specを作成: [requirement-analyzerの出力を渡す]。PRDなし。"`（プロトタイプパスがあれば追加）
 - **document-reviewer**でUI Specを検証
-  - `subagent_type: "document-reviewer"`, `description: "UI Specレビュー"`, `prompt: "doc_type: UISpec target: [ui-specパス] 整合性と完成度をレビュー"`
+  - `subagent_type: "document-reviewer"`, `description: "UI Specレビュー"`, `prompt: "doc_type: UISpec target: [ui-specパス] 整合性と完全性をレビュー"`
 - **[停止]**: UI Specをユーザーに提示し承認を取得
 
 ### Step 3: 設計ドキュメント作成フェーズ
@@ -69,15 +85,29 @@ UI Specを作成:
 - Agentツールで**codebase-analyzer**を呼び出す
   - `subagent_type: "codebase-analyzer"`, `description: "コードベース分析"`, `prompt: "requirement_analysis: [Step 1のJSON]. requirements: [ユーザー要件]. フロントエンド設計ガイダンスのため既存コードベースを分析。"`
 
-規模判定に応じて適切な設計ドキュメントを作成:
+規模判定に応じて適切な設計ドキュメントを作成。technical-designer-frontendは技術選択・データフロー設計について少なくとも2つの選択肢をトレードオフとともに提示:
 - Agentツールで**technical-designer-frontend**を呼び出す
-  - ADRの場合: `subagent_type: "technical-designer-frontend"`, `description: "ADR作成"`, `prompt: "[技術決定]のADRを作成"`
-  - Design Docの場合: `subagent_type: "technical-designer-frontend"`, `description: "Design Doc作成"`, `prompt: "要件に基づいてDesign Docを作成。コードベース分析: [codebase-analyzerのJSON]。UI Specは[ui-specパス]。UI Specのコンポーネント構造と状態設計を継承。"`
+  - ADRの場合: `subagent_type: "technical-designer-frontend"`, `description: "ADR作成"`, `prompt: "[技術決定]のADRを作成。少なくとも2つの選択肢をトレードオフとともに提示。"`
+  - Design Docの場合: `subagent_type: "technical-designer-frontend"`, `description: "Design Doc作成"`, `prompt: "要件に基づいてDesign Docを作成。コードベース分析: [codebase-analyzerのJSON]。UI Specは[ui-specパス]。UI Specのコンポーネント構造と状態設計を継承。少なくとも2つのアーキテクチャ選択肢をトレードオフとともに提示。"`
 - **（Design Docのみ）** **code-verifier**でDesign Docを既存コードに対して検証。ADRの場合はスキップ。
-  - `subagent_type: "code-verifier"`, `description: "Design Doc検証"`, `prompt: "doc_type: design-doc document_path: [Design Docパス] Design Docを既存コードに対して検証。"`
+  - `subagent_type: "code-verifier"`, `description: "Design Doc検証"`, `prompt: "doc_type: design-doc document_path: [Design Docパス] mode: pre-implementation (code_paths省略 — verifierがドキュメントからスコープを発見). Design Docを既存コードに対して検証。"`
 - **document-reviewer**で整合性検証（Design Docの場合はcode-verifier結果を渡す。ADRの場合は省略）
-  - `subagent_type: "document-reviewer"`, `description: "ドキュメントレビュー"`, `prompt: "doc_type: DesignDoc target: [ドキュメントパス] mode: composite code_verification: [code-verifierのJSON]（Design Docのみ） 整合性と完成度をレビュー。"`
-- **[停止]**: 設計の選択肢とトレードオフを提示し、ユーザー承認を取得
+  - `subagent_type: "document-reviewer"`, `description: "ドキュメントレビュー"`, `prompt: "doc_type: DesignDoc target: [ドキュメントパス] mode: composite code_verification: [code-verifierのJSON]（Design Docのみ） 整合性と完全性をレビュー。"`
+### Step 4: 設計整合性検証
+- Agentツールで**design-sync**を呼び出す
+  - `subagent_type: "design-sync"`, `description: "設計整合性チェック"`, `prompt: "docs/design/配下の全Design Doc間の整合性をチェック。矛盾と重複を報告。"`
+- **[停止]**: 設計ドキュメントとdesign-sync結果を提示し、ユーザー承認を取得
+
+## 完了条件
+
+- [ ] requirement-analyzerを実行し規模を判定
+- [ ] codebase-analyzerを実行し結果をtechnical-designer-frontendに渡した
+- [ ] ui-spec-designerでUI Specを作成（該当時）
+- [ ] technical-designer-frontendで適切な設計ドキュメント（ADRまたはDesign Doc）を作成
+- [ ] Design Docに対してcode-verifierを実行し結果をdocument-reviewerに渡した（ADRのみの場合はスキップ）
+- [ ] document-reviewerを実行しフィードバックに対応
+- [ ] design-syncで整合性検証を実行
+- [ ] 設計ドキュメントのユーザー承認を取得
 
 ## 出力例
 フロントエンド設計フェーズ完了。

package/.claude/commands-ja/front-plan.md

@@ -6,13 +6,16 @@ description: 設計ドキュメントからフロントエンド作業計画書
 
 ## オーケストレーター定義
 
-**Role**: オーケストレーター
+**コアアイデンティティ**: 「私はオーケストレーターである。」（subagents-orchestration-guideスキル参照）
 
-**実行方法**:
-- テストスケルトン生成 → acceptance-test-generatorが実行
-- 作業計画書作成 → work-plannerが実行
+**実行プロトコル**:
+1. **全ての作業をサブエージェントに委譲** — サブエージェントを呼び出し、データを橋渡しし、結果を報告する
+2. **subagents-orchestration-guideスキルの計画フローに従う**:
+   - 以下に定義されたステップを実行
+   - **完了前に停止し、計画内容の承認を取得する**
+3. **スコープ**: 下記スコープ境界を参照
 
-オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
+**重要**: work-plannerの前に必ずacceptance-test-generatorを実行すること — テストスケルトンはsubagents-orchestration-guideの中規模/大規模フローで必須の入力。
 
 ## スコープ境界
 
@@ -24,29 +27,33 @@ description: 設計ドキュメントからフロントエンド作業計画書
 
 **責務境界**: このコマンドは作業計画書承認で責務完了。
 
-以下のプロセスでフロントエンド作業計画書を作成:
+以下の計画プロセスに従う:
 
 ## 実行プロセス
 
-### 1. 設計ドキュメント選択
-! ls -la docs/design/*.md | head -10
-- 設計ドキュメントの存在を確認、なければユーザーに通知
-- 複数ある場合は選択肢を提示（$ARGUMENTSで指定可能）
+### Step 1: 設計ドキュメント選択
+   ! ls -la docs/design/*.md | head -10
+   - 設計ドキュメントの存在を確認、なければユーザーに通知
+   - 複数ある場合は選択肢を提示（$ARGUMENTSで指定可能）
 
-### 2. テストスケルトン生成
-Agentツールで**acceptance-test-generator**を呼び出す:
+### Step 2: テストスケルトン生成
+Agentツールでacceptance-test-generatorを呼び出す:
 - `subagent_type`: "acceptance-test-generator"
 - `description`: "テストスケルトン生成"
 - UI Specあり: `prompt: "[パス]のDesign Docからテストスケルトンを生成。UI Specは[ui-specパス]。"`
 - UI Specなし: `prompt: "[パス]のDesign Docからテストスケルトンを生成。"`
 
-### 3. 作業計画書作成
-Agentツールで**work-planner**を呼び出す:
+統合テストファイルパスとE2Eテストファイルパスを、subagents-orchestration-guideの「acceptance-test-generator → work-planner」セクションに従いwork-plannerに渡す。
+
+### Step 3: 作業計画書作成
+Agentツールでwork-plannerを呼び出す:
 - `subagent_type`: "work-planner"
 - `description`: "作業計画書作成"
 - `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [ステップ2の統合テストパス]。E2Eテストファイル: [ステップ2のE2Eテストパス]。統合テストは各フェーズ実装と同時に作成、E2Eテストは最終フェーズでのみ実行。"
 
-ユーザーと対話して計画を完成させ、計画内容の承認を得る。具体的な実装ステップとリスクを明確化。
+- subagents-orchestration-guideのPrompt Construction Ruleに従い追加パラメータを構成
+- 作業計画書をユーザーに提示しレビューを受ける。変更要望があればwork-plannerを修正パラメータで再実行
+- スコープが不明確なステップや外部依存があるステップを強調し、ユーザーに確認を求める
 
 **スコープ**: 作業計画書作成と計画内容の承認取得まで。
 

package/.claude/commands-ja/front-review.md

@@ -4,24 +4,25 @@ description: Design Doc準拠検証とセキュリティ検証、必要に応じ
 
 **コマンドコンテキスト**: React/TypeScriptフロントエンド向け実装後品質保証コマンド
 
-## 実行方法
+## オーケストレーター定義
 
-- 準拠検証 -> code-reviewerが実行
-- セキュリティ検証 -> security-reviewerが実行
-- ルール分析 -> rule-advisorが実行
-- 修正実装 -> task-executor-frontendが実行
-- 品質チェック -> quality-fixer-frontendが実行
-- 再検証 -> code-reviewer / security-reviewerが実行
+**コアアイデンティティ**: 「私はオーケストレーターである。」（subagents-orchestration-guideスキル参照）
 
-オーケストレーターがサブエージェントを呼び出し、構造化JSONを受け渡す。
+**初回アクション**: 実行前にTaskCreateでStep 1-11を登録する。
 
-Design Doc（省略時は直近のもの）: $ARGUMENTS
+## 実行方法
+
+- 準拠検証 → code-reviewerが実行
+- セキュリティ検証 → security-reviewerが実行
+- 修正実装 → task-executor-frontendが実行
+- 品質チェック → quality-fixer-frontendが実行
+- 再検証 → code-reviewer / security-reviewerが実行
 
-**Think deeply** 準拠検証の本質を理解し、以下のステップで実行:
+Design Doc（省略時は直近のもの）: $ARGUMENTS
 
 ## 実行フロー
 
-### 1. 前提条件チェック
+### Step 1: 前提条件チェック
 ```bash
 # Design Docを特定
 ls docs/design/*.md | grep -v template | tail -1
@@ -30,15 +31,15 @@ ls docs/design/*.md | grep -v template | tail -1
 git diff --name-only main...HEAD
 ```
 
-### 2. code-reviewer実行
+### Step 2: code-reviewer実行
 Agent toolでcode-reviewerを呼び出す:
 - `subagent_type`: "code-reviewer"
 - `description`: "コード準拠レビュー"
-- `prompt`: "Design Doc: [path]. Implementation files: [git diff file list]. Review mode: full. Design Doc準拠を検証し、complianceRate、verdict、acceptanceCriteria、qualityIssuesを含む構造化JSONレポートを返却。"
+- `prompt`: "Design Doc: [path]. Implementation files: [git diff file list]. Review mode: full. Design Doc準拠を検証し、構造化JSONレポートを返却。"
 
 **出力を保存**: `$STEP_2_OUTPUT`
 
-### 3. security-reviewer実行
+### Step 3: security-reviewer実行
 Agent toolでsecurity-reviewerを呼び出す:
 - `subagent_type`: "security-reviewer"
 - `description`: "セキュリティレビュー"
@@ -46,7 +47,7 @@ Agent toolでsecurity-reviewerを呼び出す:
 
 **出力を保存**: `$STEP_3_OUTPUT`
 
-### 4. 判定と対応
+### Step 4: 判定と対応
 
 **security-reviewerが`blocked`を返した場合**: 即座に停止。blockedの検出結果を報告しユーザーにエスカレーション。修正ステップには進まない。
 
@@ -63,10 +64,15 @@ Agent toolでsecurity-reviewerを呼び出す:
 ```
 Code Compliance: [code-reviewerのcomplianceRate]
   Verdict: [code-reviewerのverdict]
+  Identifier Match Rate: [code-reviewerのidentifierMatchRate]
   Acceptance Criteria:
-  - [fulfilled] [item]
+  - [fulfilled] [item] (confidence: [high/medium/low])
   - [partially_fulfilled] [item]: [gap] — [suggestion]
   - [unfulfilled] [item]: [gap] — [suggestion]
+  Identifier Mismatches:
+  - [identifier]: DD=[designDocValue] Code=[codeValue] at [location]
+  Quality Findings:
+  - [category] [location]: [description] — [rationale]
 
 Security Review: [security-reviewerのstatus]
   Findings by category:
@@ -79,46 +85,44 @@ Security Review: [security-reviewerのstatus]
 修正を実行しますか？ (y/n):
 ```
 
-両方合格でユーザーが`n`を選択: 修正ステップをスキップし、最終レポートへ。
+両方合格でユーザーが`n`を選択: Steps 5-10をスキップし、Step 11へ。
 
-ユーザーが`y`を選択した場合:
+### Step 5: タスクテンプレートの読み込み
 
-## 修正実行前のメタ認知
+documentation-criteriaスキルを読み込み、Step 6用のタスクファイルテンプレート（references/task-template.md）を取得。
 
-### 5. rule-advisor実行
-Agent toolでrule-advisorを呼び出す:
-- `subagent_type`: "rule-advisor"
-- `description`: "修正アプローチの分析"
-- `prompt`: "Task: レビュー検出結果の修正。Code issues: $STEP_2_OUTPUT. Security findings: $STEP_3_OUTPUT. 修正の本質を分析し適切なルールを選択。"
+### Step 6: タスクファイル作成
 
-### 6. タスクファイル作成
-TaskCreateで作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。タスクテンプレートに従ってタスクファイル作成（documentation-criteriaスキル参照） → `docs/plans/tasks/review-fixes-YYYYMMDD.md`。コード準拠の問題とセキュリティのrequiredFixesの両方を含める。
+`docs/plans/tasks/review-fixes-YYYYMMDD.md` にタスクファイルを作成。
+コード準拠の問題とセキュリティのrequiredFixesの両方を含める。
 
-### 7. 修正実行
+### Step 7: 修正実行
 Agent toolでtask-executor-frontendを呼び出す:
 - `subagent_type`: "task-executor-frontend"
 - `description`: "レビュー修正の実行"
 - `prompt`: "Task file: docs/plans/tasks/review-fixes-YYYYMMDD.md. 段階的修正を適用（5ファイルで停止）。"
 
-### 8. 品質チェック
+### Step 8: 品質チェック
 Agent toolでquality-fixer-frontendを呼び出す:
 - `subagent_type`: "quality-fixer-frontend"
 - `description`: "品質ゲートチェック"
 - `prompt`: "修正ファイルの品質ゲート通過を確認。"
 
-### 9. code-reviewer再検証
+### Step 9: code-reviewer再検証
+
 Agent toolでcode-reviewerを呼び出す:
 - `subagent_type`: "code-reviewer"
 - `description`: "準拠の再検証"
-- `prompt`: "修正後のDesign Doc準拠を再検証。前回の問題: $STEP_2_OUTPUT。Design Doc: [path]. Implementation files: [file list]。"
+- `prompt`: "修正後のDesign Doc準拠を再検証。Design Doc: [path]. Implementation files: [file list]. 前回の準拠問題: $STEP_2_OUTPUT。各問題が解決されたことを確認。"
 
-### 10. security-reviewer再検証（セキュリティ修正が実行された場合のみ）
-Agent toolでsecurity-reviewerを呼び出す:
+### Step 10: security-reviewer再検証
+
+Agent toolでsecurity-reviewerを呼び出す（セキュリティ修正が実行された場合のみ）:
 - `subagent_type`: "security-reviewer"
 - `description`: "セキュリティの再検証"
 - `prompt`: "修正後のセキュリティを再検証。前回の検出結果: $STEP_3_OUTPUT。Design Doc: [path]. Implementation files: [file list]。"
 
-### 最終レポート
+### Step 11: 最終レポート
 ```
 Code Compliance:
   初回: [X]%

package/.claude/commands-ja/review.md

@@ -33,7 +33,7 @@ git diff --name-only main...HEAD
 Agent toolでcode-reviewerを呼び出す:
 - `subagent_type`: "code-reviewer"
 - `description`: "コード準拠レビュー"
-- `prompt`: "Design Doc: [path]. Implementation files: [git diff file list]. Review mode: full. Design Doc準拠を検証し、complianceRate、verdict、acceptanceCriteria、qualityIssuesを含む構造化JSONレポートを返却。"
+- `prompt`: "Design Doc: [path]. Implementation files: [git diff file list]. Review mode: full. Design Doc準拠を検証し、構造化JSONレポートを返却。"
 
 **出力を保存**: `$STEP_2_OUTPUT`
 
@@ -62,10 +62,15 @@ Agent toolでsecurity-reviewerを呼び出す:
 ```
 Code Compliance: [code-reviewerのcomplianceRate]
   Verdict: [code-reviewerのverdict]
+  Identifier Match Rate: [code-reviewerのidentifierMatchRate]
   Acceptance Criteria:
-  - [fulfilled] [item]
+  - [fulfilled] [item] (confidence: [high/medium/low])
   - [partially_fulfilled] [item]: [gap] — [suggestion]
   - [unfulfilled] [item]: [gap] — [suggestion]
+  Identifier Mismatches:
+  - [identifier]: DD=[designDocValue] Code=[codeValue] at [location]
+  Quality Findings:
+  - [category] [location]: [description] — [rationale]
 
 Security Review: [security-reviewerのstatus]
   Findings by category:
@@ -80,9 +85,9 @@ Security Review: [security-reviewerのstatus]
 
 両方合格でユーザーが`n`を選択: Steps 5-10をスキップし、Step 11へ。
 
-### 5. Skill実行
+### 5. タスクテンプレートの読み込み
 
-Skill: documentation-criteria を実行（タスクファイルテンプレート用）
+documentation-criteriaスキルを読み込み、Step 6用のタスクファイルテンプレート（references/task-template.md）を取得。
 
 ### 6. タスクファイル作成
 
@@ -108,7 +113,7 @@ Agent toolでquality-fixerを呼び出す:
 Agent toolでcode-reviewerを呼び出す:
 - `subagent_type`: "code-reviewer"
 - `description`: "準拠の再検証"
-- `prompt`: "修正後のDesign Doc準拠を再検証。前回の準拠問題: $STEP_2_OUTPUT。各問題が解決されたことを確認。"
+- `prompt`: "修正後のDesign Doc準拠を再検証。Design Doc: [path]. Implementation files: [file list]. 前回の準拠問題: $STEP_2_OUTPUT。各問題が解決されたことを確認。"
 
 ### 10. security-reviewer再検証
 

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

@@ -49,12 +49,14 @@ Sources: OWASP Top 10:2025, DryRun Agentic Coding Security Report (2026-03)
 - Endpoints or route handlers defined without authentication middleware
 - Resource access operations (read, update, delete) without authorization verification
 - Administrative or destructive operations accessible without elevated permissions
-- Recent research indicates this pattern appears at elevated rates in AI-generated code — treat as high-priority review target
+- AI-generated code frequently omits authentication middleware and authorization checks — flag every route handler and resource access operation for explicit verification during review
+- Detection approach: search for route/endpoint handler definitions that lack authentication middleware, and resource operations (read, update, delete) without authorization checks in the call chain
 
 ### Mishandling of Exceptional Conditions (OWASP A10:2025)
 - Error handlers that expose internal system details (stack traces, database errors, file paths) in responses
-- Error handlers that fail open (grant access or skip validation on error)
+- Error handlers that grant access, skip authentication, or bypass authorization when an exception occurs (fail-open behavior)
 - Missing error handling on security-critical operations (authentication, authorization, cryptographic operations)
+- Detection approach: search for catch/error handler blocks that return stack traces, database error messages, or file paths in responses; search for catch blocks that call next() or return success without re-validating security state
 
 ### Software Supply Chain Patterns (OWASP A03:2025)
 - Dependencies imported without version pinning

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

@@ -50,18 +50,14 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
 
 **Includes**:
 - Business requirements and user value
-- Success metrics and KPIs (measurable format)
+- Success metrics and KPIs (each metric specifies a numeric target, measurement method, and timeframe)
 - User stories and use cases
 - MoSCoW prioritization (Must/Should/Could/Won't)
 - MVP and Future phase separation
 - User journey diagram (required)
 - Scope boundary diagram (required)
 
-**Excludes**:
-- Technical implementation details (->Design Doc)
-- Technical selection rationale (->ADR)
-- **Implementation phases** (->Work Plan)
-- **Task breakdown** (->Work Plan)
+**Scope**: Business requirements, user value, success metrics, user stories, and prioritization only. Implementation details belong in Design Doc, technical selection rationale in ADR, phases and task breakdown in Work Plan.
 
 ### ADR (Architecture Decision Record)
 
@@ -74,11 +70,7 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
 - Architecture impact
 - Principled implementation guidelines (e.g., "Use dependency injection")
 
-**Excludes**:
-- Implementation schedule, duration (->Work Plan)
-- Detailed implementation procedures (->Design Doc)
-- Specific code examples (->Design Doc)
-- Resource assignments (->Work Plan)
+**Scope**: Decision, rationale, option comparison, architecture impact, and principled guidelines only. Implementation procedures and code examples belong in Design Doc, schedule and resource assignments in Work Plan.
 
 ### UI Specification
 
@@ -94,11 +86,7 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
 - Visual acceptance criteria (golden states, layout constraints)
 - Accessibility requirements (keyboard, screen reader, contrast)
 
-**Excludes**:
-- Technical implementation details (-> Design Doc)
-- API contracts and data layer design (-> Design Doc)
-- Test implementation (-> acceptance-test-generator skeletons)
-- Implementation schedule (-> Work Plan)
+**Scope**: Screen structure, transitions, component decomposition, interaction design, and visual acceptance criteria only. Technical implementation and API contracts belong in Design Doc, test implementation in acceptance-test-generator skeletons, schedule in Work Plan.
 
 **Required Structural Elements**:
 - At least one component with state x display matrix and interaction table
@@ -123,7 +111,7 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
 - **Technical dependencies and implementation constraints** (required implementation order)
 - Interface and type definitions
 - Data flow and component design
-- **Acceptance criteria (EARS format: When/While/If-then/none)**
+- **Acceptance criteria (EARS format — see design-template.md; each criterion specifies a verifiable condition with pass/fail threshold)**
 - Change impact map (clearly specify direct impact/indirect impact/no ripple effect)
 - Complete enumeration of integration points
 - Data contract clarification
@@ -137,10 +125,7 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
   - 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)
-- When to implement, duration (->Work Plan)
-- Who will implement (->Work Plan)
+**Scope**: Technical implementation methods, interfaces, data flow, acceptance criteria, and verification strategy only. Technology selection rationale belongs in ADR, schedule and assignments in Work Plan.
 
 ### Work Plan
 
@@ -154,28 +139,23 @@ description: Guides PRD, ADR, Design Doc, and Work Plan creation. Use when creat
 - **Final Quality Assurance Phase (required)**
 - Progress records (checkbox format)
 
-**Excludes**:
-- Technical rationale (->ADR)
-- Design details (->Design Doc)
+**Scope**: Task breakdown, dependencies, schedule, verification strategy summary, and progress tracking only. Technical rationale belongs in ADR, design details in Design Doc.
 
 **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. **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.
+**All approaches**: Final phase is always Quality Assurance (acceptance criteria achievement, all tests passing, quality checks). 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/adr-template.md

@@ -2,7 +2,7 @@
 
 ## Status
 
-[Proposed | Accepted | Deprecated | Superseded]
+[Proposed | Accepted | Deprecated | Superseded | Rejected]
 
 ## Context
 
@@ -54,6 +54,10 @@
 
 - [List changes that are neither good nor bad]
 
+## Architecture Impact
+
+[Describe how this decision affects existing architecture: (1) components that change, (2) new dependencies introduced, (3) architectural constraints added or removed]
+
 ## Implementation Guidance
 
 [Principled direction only. Implementation procedures go to Design Doc]