create-ai-project 1.14.11 → 1.14.13

package/.claude/commands-ja/add-integration-tests.md

@@ -1,5 +1,4 @@
 ---
-name: add-integration-tests
 description: Design Docを使用して既存バックエンドコードベースに統合/E2Eテストを追加
 ---
 
@@ -7,110 +6,123 @@ description: Design Docを使用して既存バックエンドコードベース
 
 **スコープ**: バックエンドのみ（acceptance-test-generatorはバックエンドのみ対応）
 
-**Role**: オーケストレーター
+## オーケストレーター定義
+
+**コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」
+
+**初動アクション**: ステップ0-8をTodoWriteに登録してから実行を開始。
+
+**委譲理由**: オーケストレーターとして、レビュー・品質チェックを含む全てのステップを完遂させるために、必要なコンテキストを維持する必要がある。タスクファイルをコンテキスト境界とし、全ての作業をサブエージェントが担うことでこれを実現する。
 
 **実行方法**:
 - スケルトン生成 → acceptance-test-generatorに委譲
-- タスクファイル作成 → オーケストレーターが直接作成
+- タスクファイル作成 → オーケストレーターが作成（テスト、設計書の最小限情報のみ）
 - テスト実装 → task-executorに委譲
 - テストレビュー → integration-test-reviewerに委譲
 - 品質チェック → quality-fixerに委譲
 
 Design Docパス: $ARGUMENTS
 
-**TodoWrite登録**: 各ステップを登録し、完了時に更新。
-
 ## 前提条件
 - Design Docが存在すること（手動またはreverse-engineerで作成）
 - テスト対象の既存実装があること
 
 ## 実行フロー
 
-### 1. Design Doc検証（オーケストレーター）
+### ステップ0: スキル実行
+
+スキル実行: documentation-criteria（ステップ3のタスクファイルテンプレート用）
+
+### ステップ1: Design Doc検証
+
 ```bash
 # Design Docの存在確認
 ls $ARGUMENTS || ls docs/design/*.md | grep -v template | tail -1
 ```
 
-### 2. スケルトン生成
+### ステップ2: スケルトン生成
 
-**Taskツールでの呼び出し**:
-```
-subagent_type: acceptance-test-generator
-prompt: |
-  Design Docからテストスケルトンを生成。
+Taskツールでacceptance-test-generatorを呼び出す:
+- `subagent_type`: "acceptance-test-generator"
+- `description`: "テストスケルトン生成"
+- `prompt`: "[ステップ1のパス]のDesign Docからテストスケルトンを生成"
 
-  Design Doc: [ステップ1のパス]
+**期待される出力**: `generatedFiles`（統合テストとE2Eのパスを含む）
 
-  出力:
-  - 統合テストスケルトン (*.int.test.ts)
-  - 該当する場合はE2Eテストスケルトン (*.e2e.test.ts)
-```
+### ステップ3: タスクファイル作成 [GATE]
 
-**期待される出力**: `generatedFiles`（統合テストとE2Eのパスを含む）
+タスクファイル作成先: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
 
-### 3. タスクファイル作成（オーケストレーター）
+**テンプレート**:
+```markdown
+---
+name: [機能名]の統合テスト実装
+type: test-implementation
+---
 
-タスクテンプレートに従ってタスクファイルを作成（documentation-criteriaスキル参照）:
-- パス: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
-- 内容: 生成されたスケルトンに基づくテスト実装タスク
-- 対象ファイルセクションにステップ2の出力からスケルトンファイルパスを含める
+## 目的
 
-### 4. テスト実装
+スケルトンファイルに定義されたテストケースを実装する。
 
-**Taskツールでの呼び出し**:
-```
-subagent_type: task-executor
-prompt: |
-  タスクファイルに従ってテストを実装。
+## 対象ファイル
 
-  タスクファイル: docs/plans/tasks/integration-tests-YYYYMMDD.md
+- スケルトン: [ステップ2のgeneratedFilesのパス]
+- Design Doc: [ステップ1のパス]
 
-  要件:
-  - TDD原則に従う（Red-Green-Refactor）
-  - 各スケルトンテストケースを実装
-  - テストを実行してパスを確認
-```
+## タスク
 
-**期待される出力**: `status`, `testsAdded`
+- [ ] スケルトンの各テストケースを実装
+- [ ] 全テストがパスすることを確認
+- [ ] カバレッジが要件を満たすことを確認
 
-### 5. テストレビュー
+## 受入条件
 
-**Taskツールでの呼び出し**:
+- 全スケルトンテストケースが実装済み
+- 全テストがパス
+- 品質チェック全項目パス
 ```
-subagent_type: integration-test-reviewer
-prompt: |
-  テスト品質をレビュー。
 
-  テストファイル: [ステップ2のgeneratedFilesのパス]
-  スケルトンファイル: [元のスケルトンパス]
-```
+**出力**: "タスクファイルを[パス]に作成しました。ステップ4へ進む準備完了。"
+
+### ステップ4: テスト実装
+
+Taskツールでtask-executorを呼び出す:
+- `subagent_type`: "task-executor"
+- `description`: "統合テスト実装"
+- `prompt`: "タスクファイル: docs/plans/tasks/integration-tests-YYYYMMDD.md。タスクファイルに従ってテストを実装。"
+
+**期待される出力**: `status`, `testsAdded`
+
+### ステップ5: テストレビュー
+
+Taskツールでintegration-test-reviewerを呼び出す:
+- `subagent_type`: "integration-test-reviewer"
+- `description`: "テスト品質レビュー"
+- `prompt`: "テスト品質をレビュー。テストファイル: [ステップ4のtestsAdded]。スケルトンファイル: [ステップ2のgeneratedFiles]"
 
 **期待される出力**: `status` (approved/needs_revision), `requiredFixes`
 
-**フロー制御**:
-- `status: needs_revision` → `requiredFixes`と共にステップ4に戻る
-- `status: approved` → ステップ6に進む
+### ステップ6: レビュー修正の適用
 
-### 6. 品質チェック
+ステップ5の結果を確認:
+- `status: approved` → 完了としてマーク、ステップ7へ進む
+- `status: needs_revision` → requiredFixesでtask-executorを呼び出し、ステップ5に戻る
 
-**Taskツールでの呼び出し**:
-```
-subagent_type: quality-fixer
-prompt: |
-  テストファイルの最終品質保証。
+Taskツールでtask-executorを呼び出す:
+- `subagent_type`: "task-executor"
+- `description`: "レビュー指摘の修正"
+- `prompt`: "テストファイルの以下の問題を修正: [ステップ5のrequiredFixes]"
 
-  スコープ: このワークフローで追加されたテストファイル
+### ステップ7: 品質チェック
 
-  要件:
-  - 全テストを実行
-  - カバレッジが要件を満たすことを確認
-  - 品質問題を修正
-```
+Taskツールでquality-fixerを呼び出す:
+- `subagent_type`: "quality-fixer"
+- `description`: "最終品質保証"
+- `prompt`: "このワークフローで追加されたテストファイルの最終品質保証。全テストを実行しカバレッジを確認。"
 
 **期待される出力**: `approved` (true/false)
 
-### 7. コミット（オーケストレーター）
+### ステップ8: コミット
 
 quality-fixerから`approved: true`の場合:
 - Bashで適切なメッセージを付けてテストファイルをコミット

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

@@ -19,7 +19,7 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
 
 ### タスク生成判定フロー
 
-**Think deeply** タスクファイルの存在状態を確認し、適切な対応を決定：
+タスクファイルの存在状態を確認し、適切な対応を決定:
 
 | 状態 | 判定基準 | 次のアクション |
 |------|---------|--------------|
@@ -40,12 +40,11 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
 ```
 
 ### 2. タスク分解実行（承認時）
-```
-@task-decomposer 作業計画書を読み込み、1コミット粒度の独立したタスクに分解：
-- 入力: docs/plans/[計画書名].md
-- 出力: docs/plans/tasks/配下に個別タスクファイル生成
-- 粒度: 1タスク = 1コミット = 独立して実行可能
-```
+
+Taskツールでtask-decomposerを呼び出す:
+- `subagent_type`: "task-decomposer"
+- `description`: "作業計画をタスクに分解"
+- `prompt`: "作業計画書を読み込み、1コミット粒度の独立したタスクに分解。入力: docs/plans/[計画書名].md。出力: docs/plans/tasks/配下に個別タスクファイル生成。粒度: 1タスク = 1コミット = 独立して実行可能"
 
 ### 3. 生成確認
 ```bash

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

@@ -29,7 +29,7 @@ description: 要件分析から設計書作成まで実行
 
 要件: $ARGUMENTS
 
-**Think harder** 設計への影響を深く考慮し、まず要件の背景と目的を理解するため対話を行い：
+設計への影響を深く考慮し、まず要件の背景と目的を理解するため対話を行い:
 - どのような問題を解決したいか
 - 期待される成果と成功基準
 - 既存システムとの関係性
@@ -42,7 +42,7 @@ description: 要件分析から設計書作成まで実行
 
 **実行内容**:
 - requirement-analyzerによる要件分析
-- ADR作成（アーキテクチャ変更、データフロー変更がある場合）
+- ADR作成（アーキテクチャ変更、新技術、データフロー変更がある場合）
 - technical-designerによるDesign Doc作成
 - document-reviewerによるドキュメントレビュー
 - design-syncによるDesign Doc間整合性検証
@@ -54,7 +54,7 @@ description: 要件分析から設計書作成まで実行
 1. requirement-analyzer → 要件分析
 2. technical-designer → Design Doc作成
 3. document-reviewer → 単一ドキュメント品質チェック
-4. ユーザー承認
+4. ユーザー承認（承認を待つ）
 5. design-sync → Design Doc間整合性検証
    - 矛盾あり → ユーザーに報告 → 修正指示待ち → technical-designer(update)で修正
    - 矛盾なし → 終了
@@ -72,4 +72,4 @@ description: 要件分析から設計書作成まで実行
 - 設計書: docs/design/[ドキュメント名].md
 - 整合性: 他Design Docと矛盾なし（または修正完了）
 
-**重要**: 本コマンドは設計承認＋整合性確認で終了。次フェーズへの移行提案は行わない。
+**重要**: 本コマンドは設計承認＋整合性確認で終了。次フェーズへの移行提案は行わない。

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

@@ -37,11 +37,10 @@ description: 問題を調査し、検証を経て解決策を導出する
 
 ### 0.3 問題の本質理解
 
-**Taskツールでrule-advisorを呼び出す**:
-```
-subagent_type: rule-advisor
-prompt: 以下の問題について、本質と必要なルールを特定してください: [ユーザーが報告した問題]
-```
+Taskツールでrule-advisorを呼び出す:
+- `subagent_type`: "rule-advisor"
+- `description`: "問題の本質特定"
+- `prompt`: "以下の問題について、本質と必要なルールを特定してください: [ユーザーが報告した問題]"
 
 rule-advisorの出力から以下を確認：
 - `taskAnalysis.mainFocus`: 問題の主要な焦点
@@ -79,13 +78,10 @@ rule-advisorの出力から以下を確認：
 
 ### ステップ1: 調査（investigator）
 
-**Taskツールでの呼び出し**:
-```
-subagent_type: investigator
-prompt: 以下の現象について、関連する情報を網羅的に収集してください。
-
-現象: [ユーザーが報告した問題]
-```
+Taskツールでinvestigatorを呼び出す:
+- `subagent_type`: "investigator"
+- `description`: "問題情報の収集"
+- `prompt`: "以下の現象について、関連する情報を網羅的に収集してください。現象: [ユーザーが報告した問題]"
 
 **期待される出力**: 証拠マトリクス、比較分析結果、因果追跡結果、未探索領域のリスト、調査の限界
 
@@ -115,13 +111,10 @@ investigatorの出力で`causeCategory: design_gap`または`recurrenceRisk: hig
 
 ### ステップ3: 検証（verifier）
 
-**Taskツールでの呼び出し**:
-```
-subagent_type: verifier
-prompt: 以下の調査結果を検証してください。
-
-調査結果: [調査のJSON出力]
-```
+Taskツールでverifierを呼び出す:
+- `subagent_type`: "verifier"
+- `description`: "調査結果の検証"
+- `prompt`: "以下の調査結果を検証してください。調査結果: [調査のJSON出力]"
 
 **期待される出力**: 代替仮説（最低3つ）、Devil's Advocate評価、最終結論、信頼度
 
@@ -132,15 +125,10 @@ prompt: 以下の調査結果を検証してください。
 
 ### ステップ4: 解決策導出（solver）
 
-**Taskツールでの呼び出し**:
-```
-subagent_type: solver
-prompt: 以下の検証済み結論に基づいて、解決策を導出してください。
-
-原因: [verifierのconclusion.causes]
-原因の関係性: [causesRelationship: independent/dependent/exclusive]
-信頼度: [high/medium/low]
-```
+Taskツールでsolverを呼び出す:
+- `subagent_type`: "solver"
+- `description`: "解決策の導出"
+- `prompt`: "以下の検証済み結論に基づいて、解決策を導出してください。原因: [verifierのconclusion.causes]。原因の関係性: [causesRelationship: independent/dependent/exclusive]。信頼度: [high/medium/low]"
 
 **期待される出力**: 複数の解決策（最低3つ）、トレードオフ分析、推奨案と実装ステップ、残存リスク
 

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

@@ -31,7 +31,7 @@ description: フロントエンド実装を自律実行モードで実行
 
 ### タスク生成判定フロー
 
-**THINK DEEPLY AND SYSTEMATICALLY**: タスクファイルの存在状態を分析し、必要なアクションを決定：
+タスクファイルの存在状態を分析し、必要なアクションを決定:
 
 | 状態 | 基準 | 次のアクション |
 |------|------|--------------|
@@ -52,12 +52,11 @@ description: フロントエンド実装を自律実行モードで実行
 ```
 
 ### 2. タスク分解（承認された場合）
-```
-@task-decomposer 作業計画を読み込み、アトミックなタスクに分解：
-- 入力: docs/plans/[plan-name].md
-- 出力: docs/plans/tasks/ 配下の個別タスクファイル
-- 粒度: 1タスク = 1コミット = 独立実行可能
-```
+
+Taskツールでtask-decomposerを呼び出す:
+- `subagent_type`: "task-decomposer"
+- `description`: "作業計画をタスクに分解"
+- `prompt`: "作業計画を読み込み、アトミックなタスクに分解。入力: docs/plans/[plan-name].md。出力: docs/plans/tasks/配下に個別タスクファイル。粒度: 1タスク = 1コミット = 独立実行可能"
 
 ### 3. 生成確認
 ```bash

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

@@ -4,18 +4,22 @@ description: 要件分析からフロントエンド設計ドキュメント作
 
 **コマンドコンテキスト**: このコマンドはフロントエンド設計フェーズ専用です。
 
-subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
+## オーケストレーター定義
+
+**Role**: オーケストレーター
 
 **実行方法**:
-- 要件分析 → requirement-analyzer
-- 設計書作成 → technical-designer-frontend
-- ドキュメントレビュー → document-reviewer
+- 要件分析 → requirement-analyzerが実行
+- 設計書作成 → technical-designer-frontendが実行
+- ドキュメントレビュー → document-reviewerが実行
 
 オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
 
+## スコープ境界
+
 **実行内容**:
 - requirement-analyzerによる要件分析
-- ADR作成（アーキテクチャ変更、データフロー変更がある場合）
+- ADR作成（アーキテクチャ変更、新技術、データフロー変更がある場合）
 - technical-designer-frontendによるDesign Doc作成
 - document-reviewerによるドキュメントレビュー
 
@@ -26,24 +30,24 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
 ## 実行フロー
 
 ### 1. 要件分析フェーズ
-**Think harder**: 設計への影響が深いことを考慮し、まず対話により要件の背景と目的を理解：
+設計への影響が深いことを考慮し、まず対話により要件の背景と目的を理解:
 - 何の問題を解決したいか
 - 期待する成果と成功基準
 - 既存システムとの関係
 
-要件がある程度明確になったら：
-- Taskツールで **requirement-analyzer** を呼び出し
+要件がある程度明確になったら:
+- Taskツールで**requirement-analyzer**を呼び出す
   - `subagent_type: "requirement-analyzer"`
   - `description: "要件分析"`
   - `prompt: "要件: [ユーザー要件] 要件分析と規模判定を実施してください"`
 - **[停止]**: 要件分析結果を確認し、質問事項に対応
 
 ### 2. 設計ドキュメント作成フェーズ
-規模判定に応じて適切な設計ドキュメントを作成：
-- Taskツールで **technical-designer-frontend** を呼び出し
+規模判定に応じて適切な設計ドキュメントを作成:
+- Taskツールで**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を作成"`
-- Taskツールで **document-reviewer** を呼び出して整合性検証
+- Taskツールで**document-reviewer**を呼び出して整合性検証
   - `subagent_type: "document-reviewer"`, `description: "ドキュメントレビュー"`, `prompt: "[ドキュメントパス]の整合性と完成度をレビュー"`
 - **[停止]**: 設計の選択肢とトレードオフを提示し、ユーザー承認を取得
 

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

@@ -4,13 +4,17 @@ description: 設計ドキュメントからフロントエンド作業計画書
 
 **コマンドコンテキスト**: このコマンドはフロントエンド計画フェーズ専用です。
 
-subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
+## オーケストレーター定義
+
+**Role**: オーケストレーター
 
 **実行方法**:
-- 作業計画書作成 → work-planner
+- 作業計画書作成 → work-plannerが実行
 
 オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
 
+## スコープ境界
+
 **実行内容**:
 - 設計書の選択
 - work-plannerによる作業計画書作成
@@ -18,7 +22,7 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
 
 **責務境界**: このコマンドは作業計画書承認で責務完了。
 
-以下のプロセスでフロントエンド作業計画書を作成：
+以下のプロセスでフロントエンド作業計画書を作成:
 
 ## 実行プロセス
 
@@ -28,13 +32,13 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
 - 複数ある場合は選択肢を提示（$ARGUMENTSで指定可能）
 
 ### 2. 作業計画書作成
-Taskツールで **work-planner** を呼び出し：
+Taskツールで**work-planner**を呼び出す:
 - `subagent_type: "work-planner"`
 - `description: "作業計画書作成"`
 - `prompt: "[パス]のDesign Docから作業計画を作成"`
 - ユーザーと対話して計画を完成させ、計画内容の承認を得る
 
-**深く考える** 選択された設計ドキュメントから作業計画を作成し、具体的な実装ステップとリスクを明確化。
+選択された設計ドキュメントから作業計画を作成し、具体的な実装ステップとリスクを明確化。
 
 **スコープ**: 作業計画書作成と計画内容の承認取得まで。
 

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

@@ -1,5 +1,4 @@
 ---
-name: front-reverse-design
 description: 既存PRDを使用して既存コードベースからフロントエンドDesign Docを生成
 ---
 

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

@@ -1,5 +1,4 @@
 ---
-name: front-review
 description: Design Doc準拠検証と必要に応じた自動修正
 ---
 

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

@@ -21,13 +21,13 @@ description: 設計書から作業計画書を作成し計画承認を取得
 
 **実行内容**:
 - 設計書の選択
-- acceptance-test-generatorによるテストスケルトン生成
+- E2Eテストスケルトン生成（オプション、ユーザー確認後）
 - work-plannerによる作業計画書作成
 - 計画承認の取得
 
 **責務境界**: このコマンドは作業計画書承認で責務完了。
 
-以下のプロセスで作業計画書を作成します：
+以下のプロセスで作業計画書を作成:
 
 ## 実行プロセス
 
@@ -46,16 +46,16 @@ description: 設計書から作業計画書を作成し計画承認を取得
    - 前工程の成果物を subagents-orchestration-guideスキル の連携仕様に従って活用
    - ユーザーと対話して計画を完成させ、計画内容の承認を得る
 
-**Think deeply** 選択された設計書から作業計画書を作成し、実装の具体的なステップとリスクを明確にします。
+選択された設計書から作業計画書を作成し、実装の具体的なステップとリスクを明確にします。
 
 **スコープ**: 作業計画書作成と計画内容の承認取得まで。
 
 ## 終了時の応答
-✅ **推奨**: 計画内容の承認後は以下の定型応答で終了
+✅ **必須**: 計画内容の承認後は以下の定型応答で終了
 ```
 計画フェーズが完了しました。
 - 作業計画書: docs/plans/[計画書名].md
 - 状態: 承認済み
 
 実装は別途ご指示ください。
-```
+```

package/.claude/commands-ja/reverse-engineer.md

@@ -1,5 +1,4 @@
 ---
-name: reverse-engineer
 description: 既存コードベースからPRDとDesign Docを生成するリバースエンジニアリングワークフロー
 ---
 

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

@@ -4,20 +4,18 @@ description: Design Doc準拠検証と必要に応じた自動修正
 
 **コマンドコンテキスト**: 実装完了後の品質保証専用コマンド
 
-subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
+## 実行方法
 
-**実行方法**:
-- Design Doc準拠検証 → code-reviewer
-- 修正の本質理解 → rule-advisor
-- 実装修正 → task-executor
-- 品質チェック → quality-fixer
-- 再検証 → code-reviewer
+- 準拠検証 → code-reviewerが実行
+- 修正実装 → task-executorが実行
+- 品質チェック → quality-fixerが実行
+- 再検証 → code-reviewerが実行
 
 オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
 
 Design Doc（省略時は直近のもの）: $ARGUMENTS
 
-**Think deeply** 準拠検証の本質を理解し、以下のステップで実行：
+準拠検証の本質を理解し、以下のステップで実行:
 
 ## 実行フロー
 
@@ -31,7 +29,7 @@ git diff --name-only main...HEAD
 ```
 
 ### 2. code-reviewer実行
-Design Doc準拠率を検証：
+Design Doc準拠率を検証:
 - 受入条件の充足確認
 - コード品質チェック
 - 実装完全性の評価
@@ -51,19 +49,18 @@ Design Doc準拠率を検証：
 未充足項目:
 - [項目リスト]
 
-修正を実行しますか？ (y/n): 
+修正を実行しますか？ (y/n):
 ```
 
 ユーザーが `y` を選択した場合:
 
-## 修正実行前のメタ認知
-**必須**: `rule-advisor → TodoWrite → task-executor → quality-fixer`
+#### 修正実行手順
+**必須**: `TodoWrite → task-executor → quality-fixer`
 
-1. **rule-advisor実行**: 修正の本質を理解（表面的な対症療法 vs 根本解決）
-2. **TodoWrite更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。タスクテンプレート（documentation-criteriaスキル参照）に従いタスクファイル作成 → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
-3. **task-executor実行**: 自動修正を段階的実行（5ファイル超過で停止）
-4. **quality-fixer実行**: 品質ゲート通過を確認
-5. **再検証**: code-reviewerで改善度を測定
+1. **TodoWrite更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。タスクテンプレート（documentation-criteriaスキル参照）に従いタスクファイル作成 → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
+2. **task-executor実行**: 自動修正を段階的実行（5ファイル超過で停止）
+3. **quality-fixer実行**: 品質ゲート通過を確認
+4. **再検証**: code-reviewerで改善度を測定
 
 ### 4. 最終レポート
 ```
@@ -86,4 +83,4 @@ Design Doc準拠率を検証：
 - アーキテクチャレベルの修正
 - Design Doc自体の不備
 
-**スコープ**: Design Doc準拠検証と自動修正まで。
+**スコープ**: Design Doc準拠検証と自動修正まで。