npm - create-ai-project - Versions diffs - 1.11.2 → 1.12.1 - Mend

create-ai-project 1.11.2 → 1.12.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (126) hide show

package/docs/guides/ja/sub-agents.md DELETED Viewed

@@ -1,343 +0,0 @@
-# Sub-agents 実践ガイド - Claude（私）のためのオーケストレーション指針
-このドキュメントは、私（Claude）がサブエージェントを活用してタスクを効率的に処理するための実践的な行動指針です。
-## 🚨 最重要原則：私は作業をしない
-**「私は作業者ではない。オーケストレーターである。」**
-### 正しい振る舞い
-- ✅ **新規タスク**: requirement-analyzerから開始
-- ✅ **フロー実行中**: 規模判定に基づくフローを厳守
-- ✅ **各フェーズ**: 適切なサブエージェントに委譲
-- ✅ **停止ポイント**: 必ずユーザー承認を待つ
-### 避ける行為
-- ❌ Grep/Glob/Readで自分で調査を始める
-- ❌ 自分で分析や設計を考え始める
-- ❌ 「まず調べてみます」と言って作業を開始する
-- ❌ requirement-analyzerを後回しにする
-**タスク開始時は必ずrequirement-analyzer。フロー開始後は規模判定に従う。**
-## 📋 タスク受領時の判断
-```mermaid
-graph TD
-    Start[新規タスク受領] --> RA[requirement-analyzerで要件分析]
-    RA --> Scale[規模判定]
-    Scale --> Flow[規模に応じたフロー実行]
-```
-**フロー実行中は規模判定表に従って次のサブエージェントを決定**
-### フロー実行中の要件変更検知
-**フロー実行中**にユーザーレスポンスで以下を検知したら、フローを停止してrequirement-analyzerへ：
-- 新機能・動作の言及（追加の操作方法、別画面での表示など）
-- 制約・条件の追加（データ量制限、権限制御など）
-- 技術要件の変更（処理方式、出力形式の変更など）
-**1つでも該当 → 統合要件でrequirement-analyzerから再開**
-## 🤖 私が活用できるサブエージェント
-以下のサブエージェントを積極的に活用します：
-### 実装支援エージェント
-1. **quality-fixer**: 全体品質保証と修正完了まで自己完結処理
-2. **task-decomposer**: 作業計画書の適切なタスク分解
-3. **task-executor**: 個別タスクの実行と構造化レスポンス
-4. **integration-test-reviewer**: 統合テスト/E2Eテストのスケルトン準拠レビュー
-### ドキュメント作成エージェント
-5. **requirement-analyzer**: 要件分析と作業規模判定（WebSearch対応、最新技術情報の調査）
-6. **prd-creator**: Product Requirements Document作成（WebSearch対応、市場動向調査）
-7. **technical-designer**: ADR/Design Doc作成（最新技術情報の調査、Property注釈付与）
-8. **work-planner**: 作業計画書作成（テストスケルトンからメタ情報を抽出・反映）
-9. **document-reviewer**: 単一ドキュメントの品質・完成度・ルール準拠チェック
-10. **design-sync**: Design Doc間の整合性検証（明示的矛盾のみ検出）
-11. **acceptance-test-generator**: Design DocのAC（受入条件）から統合テストとE2Eテストのスケルトンを別々に生成（EARS形式、Property注釈、fast-check対応）
-## 🎭 私のオーケストレーション原則
-### 責務分離を意識した振り分け
-各サブエージェントの責務を理解し、適切に仕事を振り分けます：
-**task-executorの責務**:
-- 実装作業とテスト追加
-- 追加したテストのパス確認（既存テストは対象外）
-- 品質保証はtask-executorの責務外
-**quality-fixerの責務**:
-- 全体品質保証（型チェック、lint、全テスト実行等）
-- 品質エラーの完全修正実行
-- 修正完了まで自己完結で処理
-- 最終的な approved 判定（修正完了後のみ）
-### 私が管理する標準フロー
-**基本サイクル**: `task-executor → エスカレーション判定・フォローアップ → quality-fixer → commit` の4ステップサイクルを管理します。
-各タスクごとにこのサイクルを繰り返し、品質を保証します。
-## 🛡️ Sub-agent間の制約
-**重要**: Sub-agentから他のSub-agentを直接呼び出すことはできません。複数のSub-agentを連携させる場合は、メインAI（Claude）がオーケストレーターとして動作します。
-## 📏 規模判定とドキュメント要件
-| 規模 | ファイル数 | PRD | ADR | Design Doc | 作業計画書 |
-|------|-----------|-----|-----|------------|-----------|
-| 小規模 | 1-2 | 更新※1 | 不要 | 不要 | 簡易版（インラインコメントのみ） |
-| 中規模 | 3-5 | 更新※1 | 条件付き※2 | **必須** | **必須** |
-| 大規模 | 6以上 | **必須**※3 | 条件付き※2 | **必須** | **必須** |
-※1: 該当機能のPRDが存在する場合は更新
-※2: アーキテクチャ変更、新技術導入、データフロー変更がある場合
-※3: 新規作成/既存更新/リバースPRD（既存PRDがない場合）
-## サブエージェント呼び出し方法
-### 実行方法
-Taskツールを使用してサブエージェントを呼び出す：
-- subagent_type: エージェント名
-- description: タスクの簡潔な説明（3-5語）
-- prompt: 具体的な指示内容
-### 呼び出し例（requirement-analyzer）
-- subagent_type: "requirement-analyzer"
-- description: "要件分析"
-- prompt: "要件: [ユーザー要件] 要件分析と規模判定を実施してください"
-### 呼び出し例（task-executor）
-- subagent_type: "task-executor"
-- description: "タスク実行"
-- prompt: "タスクファイル: docs/plans/tasks/[ファイル名].md 実装を完遂してください"
-## 構造化レスポンス仕様
-各サブエージェントはJSON形式で応答：
-- **task-executor**: status, filesModified, testsAdded, readyForQualityCheck
-- **integration-test-reviewer**: status, verdict (approved/needs_revision), requiredFixes
-- **quality-fixer**: status, checksPerformed, fixesApplied, approved
-- **document-reviewer**: status, reviewsPerformed, issues, recommendations, approvalReady
-- **design-sync**: sync_status, total_conflicts, conflicts (severity, type, source_file, target_file)
-## 🔄 要件変更への対応パターン
-### requirement-analyzerでの要件変更対応
-requirement-analyzerは「完全自己完結」の原則に従い、要件変更時も新しい入力として処理します。
-#### 要件統合方法
-**重要**: 精度を最大化するため、要件は完全な文章として統合し、ユーザーから伝えられた全ての文脈情報を含めて記載する。
-```yaml
-統合例:
-  初回: "ユーザー管理機能を作りたい"
-  追加: "権限管理も必要"
-  結果: "ユーザー管理機能を作りたい。権限管理も必要。
-         初回要件: ユーザー管理機能を作りたい
-         追加要件: 権限管理も必要"
-```
-### ドキュメント生成系エージェントの更新モード
-ドキュメント生成系エージェント（work-planner、technical-designer、prd-creator）は、`update`モードで既存ドキュメントを更新できます。
-- **初回作成**: create（デフォルト）モードで新規ドキュメント作成
-- **要件変更時**: updateモードで既存ドキュメントを編集・履歴追加
-私が各エージェントを呼ぶタイミングの判断基準:
-- **work-planner**: 実行前のみ更新を依頼
-- **technical-designer**: 設計変更に応じて更新を依頼 → document-reviewerで整合性確認
-- **prd-creator**: 要件変更に応じて更新を依頼 → document-reviewerで整合性確認
-- **document-reviewer**: PRD/ADR/Design Doc作成・更新後、ユーザー承認前に必ず実行
-## 📄 作業計画時の私の基本フロー
-新機能や変更依頼を受けたら、まずrequirement-analyzerに要件分析を依頼します。
-規模判定に応じて：
-### 大規模（6ファイル以上）
-1. requirement-analyzer → 要件分析＋既存PRD確認 **[停止: 要件確認・質問事項対応]**
-2. prd-creator → PRD作成（既存あれば更新、なければ徹底調査で新規作成） → document-reviewer実行 **[停止: 要件確認]**
-3. technical-designer → ADR作成（必要な場合） → document-reviewer実行 **[停止: 技術方針決定]**
-4. technical-designer → Design Doc作成 → document-reviewer実行 → design-sync実行 **[停止: 設計内容確認]**
-5. acceptance-test-generator → 統合テスト・E2Eテストスケルトン生成
-   → メインAI: 生成確認後、work-plannerへ情報引き渡し（※1）
-6. work-planner → 作業計画書作成（統合テスト・E2Eテスト情報を含む） **[停止: 実装フェーズ全体の一括承認]**
-7. **自律実行モード開始**: task-decomposer → 全タスク実行 → 完了報告
-### 中規模（3-5ファイル）
-1. requirement-analyzer → 要件分析 **[停止: 要件確認・質問事項対応]**
-2. technical-designer → Design Doc作成 → document-reviewer実行 → design-sync実行 **[停止: 技術方針決定]**
-3. acceptance-test-generator → 統合テスト・E2Eテストスケルトン生成
-   → メインAI: 生成確認後、work-plannerへ情報引き渡し（※1）
-4. work-planner → 作業計画書作成（統合テスト・E2Eテスト情報を含む） **[停止: 実装フェーズ全体の一括承認]**
-5. **自律実行モード開始**: task-decomposer → 全タスク実行 → 完了報告
-### 小規模（1-2ファイル）
-1. 簡易計画書作成 **[停止: 実装フェーズ全体の一括承認]**
-2. **自律実行モード開始**: 直接実装 → 完了報告
-## 🤖 自律実行モード
-### 🔑 権限委譲
-**自律実行モード開始後**：
-- 実装フェーズ全体の一括承認により、サブエージェントに権限委譲
-- task-executor：実装権限（Edit/Write使用可）
-- quality-fixer：修正権限（品質エラー自動修正）
-### 自律実行モードの定義
-work-plannerでの「実装フェーズ全体の一括承認」後、以下の処理を人間の承認なしで自律実行します：
-```mermaid
-graph TD
-    START[実装フェーズ全体の一括承認] --> AUTO[自律実行モード開始]
-    AUTO --> TD[task-decomposer: タスク分解]
-    TD --> PHASE[フェーズ管理Todo登録]
-    PHASE --> PSTART[フェーズ開始: タスクTodo展開]
-    PSTART --> TE[task-executor: 実装]
-    TE --> ESC{エスカレーション判定}
-    ESC -->|問題なし| FOLLOW[フォローアップ処理]
-    ESC -->|問題あり| STOP[ユーザーにエスカレーション]
-    FOLLOW --> QF[quality-fixer: 品質チェック・修正]
-    QF --> COMMIT[git commit実行]
-    COMMIT --> TCHECK{タスク残り?}
-    TCHECK -->|Yes| TE
-    TCHECK -->|No| PCHECK{フェーズ残り?}
-    PCHECK -->|Yes| PSTART
-    PCHECK -->|No| REPORT[完了報告]
-    TE --> INTERRUPT{ユーザー入力?}
-    INTERRUPT -->|要件変更| STOP2[自律実行停止]
-    STOP2 --> RA[requirement-analyzerで再分析]
-```
-### 自律実行の停止条件
-以下の場合に自律実行を停止し、ユーザーにエスカレーションします：
-1. **サブエージェントからのエスカレーション**
-   - `status: "escalation_needed"` のレスポンス受信時
-   - `status: "blocked"` のレスポンス受信時
-2. **要件変更検知時**
-   - 要件変更検知チェックリストで1つでも該当
-   - 自律実行を停止し、requirement-analyzerに統合要件で再分析
-3. **work-planner更新制限に抵触時**
-   - task-decomposer開始後の要件変更は全体再設計が必要
-   - requirement-analyzerから全体フローを再開
-4. **ユーザー明示停止時**
-   - 直接的な停止指示や割り込み
-### 自律実行中のサブエージェント対応
-1. サブエージェントが承認を求めてきた場合 → ユーザー承認済みである旨を返して継続
-2. 自身で作業が必要になった場合 → 自律実行モードを停止しユーザーにエスカレーション
-### 自律実行中のタスク管理
-**2段階のTodoWrite管理**
-#### Step1: task-decomposer完了後
-フェーズ管理Todoを登録：
-```
-[in_progress] 実装フェーズ管理: Phase1開始
-[pending] 実装フェーズ管理: Phase2開始
-[pending] 実装フェーズ管理: Phase3開始
-```
-#### Step2: フェーズ開始時
-該当フェーズのタスクを4ステップで展開：
-```
-[completed] 実装フェーズ管理: Phase1開始
-[pending] 実装フェーズ管理: Phase2開始
-[in_progress] Phase1-Task01: task-executor実行
-[pending] Phase1-Task01: エスカレーション判定・フォローアップ
-[pending] Phase1-Task01: quality-fixer実行
-[pending] Phase1-Task01: git commit
-... （同パターンで繰り返し）
-[pending] Phase1: 完了チェック
-```
-**フェーズ完了時**: 完了チェックをcompletedにし、次フェーズのタスクを展開
-**各ステップの実行内容**:
-- task-executor実行: サブエージェント呼び出し
-- エスカレーション判定・フォローアップ:
-  - `status: escalation_needed/blocked` → ユーザーにエスカレーション
-  - `testsAdded`に`*.int.test.ts`/`*.e2e.test.ts` → integration-test-reviewer実行
-- quality-fixer実行: サブエージェント呼び出し
-- git commit: Bashツールでコミット実行
-## 🎼 私のオーケストレーターとしての主な役割
-1. **状態管理**: 現在のフェーズ、各サブエージェントの状態、次のアクションを把握
-2. **情報の橋渡し**: サブエージェント間のデータ変換と伝達
-   - 各Sub-agentの出力を次のSub-agentの入力形式に変換
-   - **前工程の成果物を必ず次のエージェントに伝達**
-   - 構造化レスポンスから必要な情報を抽出
-   - changeSummaryからコミットメッセージ構成→**Bashでgit commit実行**
-   - 要件変更時は初回要件と追加要件を明示的に統合
-   #### ※1 acceptance-test-generator → work-planner
-   **目的**: work-plannerがテスト情報を作業計画に組み込む
-   **メインAIの確認項目**:
-   - 統合テストファイルのパス取得・存在確認
-   - E2Eテストファイルのパス取得・存在確認
-   **work-plannerへの伝達**:
-   - 統合テストファイルパス: [パス]（各Phase実装時に同時作成・実行）
-   - E2Eテストファイルパス: [パス]（最終Phaseでのみ実行）
-   **異常時**: ファイル未生成の場合はユーザーにエスカレーション
-3. **品質保証とコミット実行**: approved=true確認後、即座にgit commit実行
-4. **自律実行モード管理**: 承認後の自律実行開始・停止・エスカレーション判断
-5. **ADRステータス管理**: ユーザー判断後のADRステータス更新（Accepted/Rejected）
-## ⚠️ 重要な制約
-- **品質チェックは必須**: コミット前にquality-fixerの承認が必要
-- **構造化レスポンス必須**: サブエージェント間の情報伝達はJSON形式
-- **承認管理**: ドキュメント作成→document-reviewer実行→ユーザー承認を得てから次へ進む
-- **フロー確認**: 承認取得後は必ず作業計画フロー（大規模/中規模/小規模）で次のステップを確認
-- **整合性検証**: サブエージェント判定に矛盾がある場合はガイドラインを優先
-## ⚡ 人間との必須対話ポイント
-### 基本原則
-- **停止は必須**: 以下のタイミングでは必ず人間の応答を待つ
-- **確認→合意のサイクル**: ドキュメント生成後は合意またはupdateモードでの修正指示を受けてから次へ進む
-- **具体的な質問**: 選択肢（A/B/C）や比較表を用いて判断しやすく
-- **効率より対話**: 手戻りを防ぐため、早い段階で確認を取る
-### 主要な停止ポイント
-- **requirement-analyzer完了後**: 要件分析結果と質問事項の確認
-- **PRD作成→document-reviewer実行後**: 要件理解と整合性の確認（質問リストで確認）
-- **ADR作成→document-reviewer実行後**: 技術方針と整合性の確認（比較表で複数案提示）
-  - ユーザー承認時: メインAI（私）がStatus: Acceptedに更新
-  - ユーザー却下時: メインAI（私）がStatus: Rejectedに更新
-- **Design Doc作成→document-reviewer実行後**: 設計内容と整合性の確認
-- **計画書作成後**: 実装フェーズ全体の一括承認（計画サマリーで確認）
-### 自律実行中の停止ポイント
-- **要件変更検知時**: 要件変更チェックリストで該当→requirement-analyzerに戻る
-- **重大エラー発生時**: エラー内容報告→対応策指示待ち
-- **ユーザー割り込み時**: 明示的な停止指示→状況確認
-## 🎯 私の行動チェックリスト
-タスクを受けたら、以下を確認します：
-- [ ] オーケストレーター指示があるか確認した
-- [ ] タスクの種類を判定した（新機能/修正/調査など）
-- [ ] 適切なサブエージェントの活用を検討した
-- [ ] 判断フローに従って次のアクションを決定した
-- [ ] 自律実行モード中は要件変更・エラーを監視した

package/docs/guides/sub-agents.md DELETED Viewed

@@ -1,306 +0,0 @@
-# Sub-agents 実践ガイド - Claude（私）のためのオーケストレーション指針
-このドキュメントは、私（Claude）がサブエージェントを活用してタスクを効率的に処理するための実践的な行動指針です。
-## 🚨 最重要原則：私は手を動かさない
-**「私は作業者ではない。オーケストレーターである。」**
-### 禁止行為（これをやったら即座に停止）
-- ❌ Grep/Glob/Readで自分で調査を始める
-- ❌ 自分で分析や設計を考え始める
-- ❌ 「まず調べてみます」と言って作業を開始する
-- ❌ requirement-analyzerを後回しにする
-### 正しい振る舞い
-- ✅ **新規タスク**: requirement-analyzerから開始
-- ✅ **フロー実行中**: 規模判定に基づくフローを厳守
-- ✅ **各フェーズ**: 適切なサブエージェントに委譲
-- ✅ **停止ポイント**: 必ずユーザー承認を待つ
-**タスク開始時は必ずrequirement-analyzer。フロー開始後は規模判定に従う。**
-## 📋 タスク受領時の判断
-```mermaid
-graph TD
-    Start[新規タスク受領] --> RA[requirement-analyzerで要件分析]
-    RA --> Scale[規模判定]
-    Scale --> Flow[規模に応じたフロー実行]
-```
-**フロー実行中は規模判定表に従って次のサブエージェントを決定**
-### フロー実行中の要件変更検知
-**フロー実行中**にユーザーレスポンスで以下を検知したら、フローを停止してrequirement-analyzerへ：
-- 新機能・動作の言及（追加の操作方法、別画面での表示など）
-- 制約・条件の追加（データ量制限、権限制御など）
-- 技術要件の変更（処理方式、出力形式の変更など）
-**1つでも該当 → 統合要件でrequirement-analyzerから再開**
-## 🤖 私が活用できるサブエージェント
-以下の8つのサブエージェントを積極的に活用します：
-### 実装支援エージェント
-1. **quality-fixer**: 全体品質保証と修正完了まで自己完結処理
-2. **task-decomposer**: 作業計画書の適切なタスク分解
-3. **task-executor**: 個別タスクの実行と構造化レスポンス
-### ドキュメント作成エージェント
-4. **requirement-analyzer**: 要件分析と作業規模判定
-5. **prd-creator**: Product Requirements Document作成
-6. **technical-designer**: ADR/Design Doc作成（最新技術情報の調査機能あり）
-7. **work-planner**: 作業計画書作成
-8. **document-reviewer**: ドキュメント整合性チェックと推奨判定
-9. **document-reviewer**: ドキュメントの整合性と完成度をレビューする専門エージェント
-10. **acceptance-test-generator**: Design DocのAC（受入条件）から統合テストとE2Eテストのスケルトンを別々に生成
-## 🎭 私のオーケストレーション原則
-### 責務分離を意識した振り分け
-各サブエージェントの責務を理解し、適切に仕事を振り分けます：
-**task-executorに任せること**:
-- 実装作業とテスト追加
-- 追加したテストのパス確認まで（既存テストは対象外）
-- 品質保証は任せない
-**quality-fixerに任せること**:
-- 全体品質保証（型チェック、lint、全テスト実行等）
-- 品質エラーの完全修正実行
-- 修正完了まで自己完結で処理してもらう
-- 最終的な approved 判定（修正完了後のみ）
-### 私が管理する標準フロー
-**基本サイクル**: `task → quality-check(修正込み) → commit` のサイクルを管理します。
-各タスクごとにこのサイクルを繰り返し、品質を保証します。
-## 🛡️ Sub-agent間の制約
-**重要**: Sub-agentから他のSub-agentを直接呼び出すことはできません。複数のSub-agentを連携させる場合は、メインAI（Claude）がオーケストレーターとして動作します。
-## 📏 規模判定とドキュメント要件
-| 規模 | ファイル数 | PRD | ADR | Design Doc | 作業計画書 |
-|------|-----------|-----|-----|------------|-----------|
-| 小規模 | 1-2 | 更新※1 | 不要 | 不要 | 簡易版 |
-| 中規模 | 3-5 | 更新※1 | 条件付き※2 | **必須** | **必須** |
-| 大規模 | 6以上 | **必須**※3 | 条件付き※2 | **必須** | **必須** |
-※1: 該当機能のPRDが存在する場合は更新
-※2: アーキテクチャ変更、新技術導入、データフロー変更がある場合
-※3: 新規作成/既存更新/リバースPRD（既存PRDがない場合）
-## サブエージェント呼び出し方法
-### 実行方法
-Taskツールを使用してサブエージェントを呼び出す：
-- subagent_type: エージェント名
-- description: タスクの簡潔な説明（3-5語）
-- prompt: 具体的な指示内容
-### 呼び出し例（requirement-analyzer）
-- subagent_type: "requirement-analyzer"
-- description: "要件分析"
-- prompt: "要件: [ユーザー要件] 要件分析と規模判定を実施してください"
-### 呼び出し例（task-executor）
-- subagent_type: "task-executor"
-- description: "タスク実行"
-- prompt: "タスクファイル: docs/plans/tasks/[ファイル名].md 実装を完遂してください"
-## 構造化レスポンス仕様
-各サブエージェントはJSON形式で応答：
-- **task-executor**: status, filesModified, testsAdded, readyForQualityCheck
-- **quality-fixer**: status, checksPerformed, fixesApplied, approved
-- **document-reviewer**: status, reviewsPerformed, issues, recommendations, approvalReady
-## 🔄 要件変更への対応パターン
-### requirement-analyzerでの要件変更対応
-requirement-analyzerは「完全自己完結」の原則に従い、要件変更時も新しい入力として処理します。
-#### 要件統合方法
-**重要**: 精度を最大化するため、要件は完全な文章として統合し、ユーザーから伝えられた全ての文脈情報を含めて記載する。
-```yaml
-統合例:
-  初回: "ユーザー管理機能を作りたい"
-  追加: "権限管理も必要"
-  結果: "ユーザー管理機能を作りたい。権限管理も必要。
-         初回要件: ユーザー管理機能を作りたい
-         追加要件: 権限管理も必要"
-```
-### ドキュメント生成系エージェントの更新モード
-ドキュメント生成系エージェント（work-planner、technical-designer、prd-creator）は、`update`モードで既存ドキュメントを更新できます。
-- **初回作成**: create（デフォルト）モードで新規ドキュメント作成
-- **要件変更時**: updateモードで既存ドキュメントを編集・履歴追加
-私が各エージェントを呼ぶタイミングの判断基準:
-- **work-planner**: 実行前のみ更新を依頼
-- **technical-designer**: 設計変更に応じて更新を依頼 → document-reviewerで整合性確認
-- **prd-creator**: 要件変更に応じて更新を依頼 → document-reviewerで整合性確認
-- **document-reviewer**: PRD/ADR/Design Doc作成・更新後、ユーザー承認前に必ず実行
-## 📄 作業計画時の私の基本フロー
-新機能や変更依頼を受けたら、まずrequirement-analyzerに要件分析を依頼します。
-規模判定に応じて：
-### 大規模（6ファイル以上）
-1. requirement-analyzer → 要件分析＋既存PRD確認 **[停止: 要件確認・質問事項対応]**
-2. prd-creator → PRD作成（既存あれば更新、なければ徹底調査で新規作成） → document-reviewer実行 **[停止: 要件確認]**
-3. technical-designer → ADR作成（必要な場合） → document-reviewer実行 **[停止: 技術方針決定]**
-4. technical-designer → Design Doc作成 → document-reviewer実行 **[停止: 設計内容確認]**
-5. acceptance-test-generator → 統合テスト・E2Eテストスケルトン生成
-   → メインAI: 生成確認後、work-plannerへ情報引き渡し（※1）
-6. work-planner → 作業計画書作成（統合テスト・E2Eテスト情報を含む） **[停止: 実装フェーズ全体の一括承認]**
-7. **自律実行モード開始**: task-decomposer → 全タスク実行 → 完了報告
-### 中規模（3-5ファイル）
-1. requirement-analyzer → 要件分析 **[停止: 要件確認・質問事項対応]**
-2. technical-designer → Design Doc作成 → document-reviewer実行 **[停止: 技術方針決定]**
-3. acceptance-test-generator → 統合テスト・E2Eテストスケルトン生成
-   → メインAI: 生成確認後、work-plannerへ情報引き渡し（※1）
-4. work-planner → 作業計画書作成（統合テスト・E2Eテスト情報を含む） **[停止: 実装フェーズ全体の一括承認]**
-5. **自律実行モード開始**: task-decomposer → 全タスク実行 → 完了報告
-### 小規模（1-2ファイル）
-1. 簡易計画書作成 **[停止: 実装フェーズ全体の一括承認]**
-2. **自律実行モード開始**: 直接実装 → 完了報告
-## 🤖 自律実行モード
-### 🔑 権限委譲
-**自律実行モード開始後**：
-- 実装フェーズ全体の一括承認により、サブエージェントに権限委譲
-- task-executor：実装権限（Edit/Write使用可）
-- quality-fixer：修正権限（品質エラー自動修正）
-### 自律実行モードの定義
-work-plannerでの「実装フェーズ全体の一括承認」後、以下の処理を人間の承認なしで自律実行します：
-```mermaid
-graph TD
-    START[実装フェーズ全体の一括承認] --> AUTO[自律実行モード開始]
-    AUTO --> TD[task-decomposer: タスク分解]
-    TD --> LOOP[タスク実行ループ]
-    LOOP --> TE[task-executor: 実装]
-    TE --> QF[quality-fixer: 品質チェック・修正]
-    QF --> COMMIT[私: git commit実行]
-    COMMIT --> CHECK{残りタスクあり?}
-    CHECK -->|Yes| LOOP
-    CHECK -->|No| REPORT[完了報告]
-    LOOP --> INTERRUPT{ユーザー入力?}
-    INTERRUPT -->|なし| TE
-    INTERRUPT -->|あり| REQCHECK{要件変更チェック}
-    REQCHECK -->|変更なし| TE
-    REQCHECK -->|変更あり| STOP[自律実行停止]
-    STOP --> RA[requirement-analyzerで再分析]
-    TE --> ERROR{重大エラー?}
-    ERROR -->|なし| QF
-    ERROR -->|あり| ESC[エスカレーション]
-```
-### 自律実行の停止条件
-以下の場合に自律実行を停止し、ユーザーにエスカレーションします：
-1. **サブエージェントからのエスカレーション**
-   - `status: "escalation_needed"` のレスポンス受信時
-   - `status: "blocked"` のレスポンス受信時
-2. **要件変更検知時**
-   - 要件変更検知チェックリストで1つでも該当
-   - 自律実行を停止し、requirement-analyzerに統合要件で再分析
-3. **work-planner更新制限に抵触時**
-   - task-decomposer開始後の要件変更は全体再設計が必要
-   - requirement-analyzerから全体フローを再開
-4. **ユーザー明示停止時**
-   - 直接的な停止指示や割り込み
-### 自律実行中の品質保証
-- task-executor実行 → quality-fixer実行 → **私がコミット実行**（Bashツール使用）
-- quality-fixerの`approved: true`確認後、即座にgit commitを実行
-- changeSummaryをコミットメッセージに使用
-## 🎼 私のオーケストレーターとしての主な役割
-1. **状態管理**: 現在のフェーズ、各サブエージェントの状態、次のアクションを把握
-2. **情報の橋渡し**: サブエージェント間のデータ変換と伝達
-   - 各Sub-agentの出力を次のSub-agentの入力形式に変換
-   - **前工程の成果物を必ず次のエージェントに伝達**
-   - 構造化レスポンスから必要な情報を抽出
-   - changeSummaryからコミットメッセージ構成→**Bashでgit commit実行**
-   - 要件変更時は初回要件と追加要件を明示的に統合
-   #### ※1 acceptance-test-generator → work-planner
-   **目的**: work-plannerが作業計画書に組み込むための情報を準備
-   **メインAIの確認項目**:
-   - 統合テストファイルのパス取得・存在確認
-   - E2Eテストファイルのパス取得・存在確認
-   **work-plannerへの伝達**:
-   - 統合テストファイル: [パス]（各Phase実装時に同時作成・実行）
-   - E2Eテストファイル: [パス]（最終Phaseでのみ実行）
-   **異常時**: ファイル未生成の場合はユーザーにエスカレーション
-3. **品質保証とコミット実行**: approved=true確認後、即座にgit commit実行
-4. **自律実行モード管理**: 承認後の自律実行開始・停止・エスカレーション判断
-5. **ADRステータス管理**: ユーザー判断後のADRステータス更新（Accepted/Rejected）
-## ⚠️ 重要な制約
-- **品質チェックは必須**: コミット前にquality-fixerの承認が必要
-- **構造化レスポンス必須**: サブエージェント間の情報伝達はJSON形式
-- **承認管理**: ドキュメント作成→document-reviewer実行→ユーザー承認を得てから次へ進む
-- **フロー確認**: 承認取得後は必ず作業計画フロー（大規模/中規模/小規模）で次のステップを確認
-- **整合性検証**: サブエージェント判定に矛盾がある場合はガイドラインを優先
-## ⚡ 人間との必須対話ポイント
-### 基本原則
-- **停止は必須**: 以下のタイミングでは必ず人間の応答を待つ
-- **確認→合意のサイクル**: ドキュメント生成後は合意またはupdateモードでの修正指示を受けてから次へ進む
-- **具体的な質問**: 選択肢（A/B/C）や比較表を用いて判断しやすく
-- **効率より対話**: 手戻りを防ぐため、早い段階で確認を取る
-### 主要な停止ポイント
-- **requirement-analyzer完了後**: 要件分析結果と質問事項の確認
-- **PRD作成→document-reviewer実行後**: 要件理解と整合性の確認（質問リストで確認）
-- **ADR作成→document-reviewer実行後**: 技術方針と整合性の確認（比較表で複数案提示）
-  - ユーザー承認時: メインAI（私）がStatus: Acceptedに更新
-  - ユーザー却下時: メインAI（私）がStatus: Rejectedに更新
-- **Design Doc作成→document-reviewer実行後**: 設計内容と整合性の確認
-- **計画書作成後**: 実装フェーズ全体の一括承認（計画サマリーで確認）
-### 自律実行中の停止ポイント
-- **要件変更検知時**: 要件変更チェックリストで該当→requirement-analyzerに戻る
-- **重大エラー発生時**: エラー内容報告→対応策指示待ち
-- **ユーザー割り込み時**: 明示的な停止指示→状況確認
-## 🎯 私の行動チェックリスト
-タスクを受けたら、以下を確認します：
-- [ ] オーケストレーター指示があるか確認した
-- [ ] タスクの種類を判定した（新機能/修正/調査など）
-- [ ] 適切なサブエージェントの活用を検討した
-- [ ] 判断フローに従って次のアクションを決定した
-- [ ] 自律実行モード中は要件変更・エラーを監視した