ln-210-epic-coordinator

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリを基準とします。

Epic コーディネーター

タイプ： L2 ドメインコーディネーター
カテゴリ： 2XX Planning

スコープの分解を通じて、作成と再計画の両方を処理する汎用 Epic 管理コーディネーターです。

目的

スコープの分解に基づいて、Epic の作成（CREATE）と再計画（REPLAN）を調整します。プレビューが承認されるまでは、探索と調査は読み取り専用のままです。実行は引き続き ln-210 内で行います。

このスキルを使用するタイミング

次の場合にこのスキルを使用します：

• 複数の論理ドメインへの分解が必要な、新しいスコープ／イニシアチブを開始する（CREATE モード）
• 大規模なアーキテクチャ要件を Epic に分解する
• スコープ／要件の変更に応じて既存の Epic を更新する（REPLAN モード）
• イニシアチブ内の Epic のスコープを再調整する
• 既存のイニシアチブ構造に新しい Epic を追加する
• プロジェクト計画の最初のステップとして使用する（スコープ → Epic → ストーリー → タスク）
• 各ドメインの明確なスコープ境界と成功基準を定義する

出力： トラッカー上の Epic 3～7 件（論理ドメイン／モジュール。転送方法は設定済みプロバイダーに従います）

ランタイム契約

必須読み込み： references/coordinator_runtime_contract.md、references/epic_planning_runtime_contract.md、references/epic_plan_summary_contract.md を読み込みます。
必須読み込み： プロジェクトに docs/hypotheses/、docs/goals/、または Epic の境界を変更する可能性のあるベンチマーク実行マニフェストがある場合は、references/researchgraph_mcp_usage.md を読み込みます。

ランタイムファミリー：epic-planning-runtime

識別子：

• スコープ識別子

フェーズ：

1. PHASE_0_CONFIG
2. PHASE_1_DISCOVERY
3. PHASE_2_RESEARCH
4. PHASE_3_PLAN
5. PHASE_4_MODE_DETECTION
6. PHASE_5_PREVIEW
7. PHASE_6_DELEGATE
8. PHASE_7_FINALIZE
9. PHASE_8_SELF_CHECK

決定の処理：

• プレビュー／確認時、ランタイムは PAUSED + pending_decision になります
• ln-210 は、下流コーディネーターとして使用される場合、ln-200 向けの最終的な epic-plan サマリーを書き込みます

コーディネーターの成果物フロー：

• 実行は引き続き ln-210 内で行います
• PHASE_7_FINALIZE は、node references/scripts/epic-planning-runtime/cli.mjs record-plan-summary を通じてコーディネーターのサマリーを書き込みます
• 管理対象の親フローは、成果物を .hex-skills/runtime-artifacts/runs/{parent_run_id}/epic-plan/{identifier}.json に保存します

ワーカーの呼び出し（必須）

フェーズ	ワーカー	コンテキスト
6	なし	CREATE／REPLAN の実行は ln-210 内で行います。下流の Skill ワーカーには委任しません

下流契約： ln-210 自体が ln-200 のワーカーであり、Epic の作成／再計画がインラインで完了した後、機械可読な epic-plan 出力を書き込みます。

TodoWrite の形式（必須）

- Phase 1: Discover scope and project context (pending)
- Phase 2: Research only what changes Epic boundaries (pending)
- Phase 3: Build ideal Epic plan (pending)
- Phase 4: Detect mode and validate Infra Epic need (pending)
- Phase 5: Preview and confirm plan (pending)
- Phase 6: Execute create/replan flow (pending)
- Phase 7: Finalize epic-plan summary (pending)
- Phase 8: Self-check (pending)

主な概念

分解優先パターン

重要な原則： まず必ずスコープを分析して理想的な Epic 計画を作成し、その後、既存の Epic を確認してモードを決定します：

• 既存の Epic がない → CREATE モード（すべての Epic を生成して作成）
• 既存の Epic がある → REPLAN モード（比較し、KEEP／UPDATE／OBSOLETE／CREATE の操作を決定）

理由： 現在のスコープ要件に基づいて一貫した Epic の分解を行えるためです。既存の Epic 構造（古くなっている、または最適でない可能性があります）に左右されません。

Epic 0 はインフラストラクチャ用に予約

必須読み込み： Epic 0 のルール、使用するタイミング、トラッカーの番号付けについて、references/numbering_conventions.md を読み込みます。

---

入力

入力	必須	ソース	説明
scopeDoc	はい	args、プロジェクトドキュメント、ユーザー	Epic の分解に使用するスコープドキュメント

解決方法： Epic 解決チェーン（適用対象：スコープドキュメントの検出）。
フォールバック： スコープドキュメントが見つからない場合 → AskUserQuestion：「何を Epic に分解しますか？」

ワークフロー

フェーズ 0：ツール設定

必須読み込み： references/environment_state_contract.md、references/storage_mode_detection.md、references/input_resolution_pattern.md を読み込みます。

抽出：task_provider = タスク管理 → プロバイダー

フェーズ 1：探索

目的： プレビューや変更を行う前に、Epic の境界を定めるために必要な最小限のコンテキストを収集します。

ステップ 0：scopeDoc を解決する（scope に合わせて調整した input_resolution_pattern.md に従います）：

• IF args が指定されている（scope の説明またはドキュメントのパス）→ args を使用します
• ELSE IF docs/project/requirements.md が存在する → scope の情報源として使用します
• ELSE IF docs/requirements.md が存在する → scope の情報源として使用します
• ELSE → AskUserQuestion：「何を Epic に分解しますか？」

ステップ 1：設定を読み込む

docs/tasks/kanban_board.md から Team ID と次の Epic 番号を自動検出します：

• Team ID： Tracker Configuration テーブルを読み取ります → 見つからない場合：ユーザーに直接尋ねます
• 次の Epic 番号： Next Epic Number フィールドを読み取ります → 見つからない場合：ユーザーに直接尋ねます

必須の読み込み： CLAUDE.md の「Configuration Auto-Discovery」と「Tracker Integration」の各セクションを読み込みます。

フェーズ 2：調査

目的： エピックの境界、インフラストラクチャエピックの必要性、またはバッチプレビューの品質に影響する事項のみを調査します。

ステップ 1：プロジェクト調査

目的： ユーザーに質問する前に、プロジェクトの背景を把握するため、プロジェクトのドキュメントとフロントエンドコードを調査します。

プロセス：

0. Researchgraph の事前確認（存在する場合）：

   • docs/hypotheses/、docs/goals/、または benchmark/runs/*/manifest.yaml が存在する場合は、最初に読み取り専用の verify_index を実行します。
   • ゴールや仮説がエピックの境界、検証範囲、または昇格・一般化作業に影響する場合にのみ、inspect_goal、trace_goal_tree、find_hypotheses、または audit_goal_alignment を使用します。
   • STALE グラフの負債は計画の背景情報として扱い、それだけを理由にエピックをブロックしないでください。

1. ドキュメントの確認：

   • Glob を使用して、docs/requirements.md、docs/architecture.md、docs/tech_stack.md を検索します。
   • 見つかったドキュメントを Read で読み込みます。

2. フロントエンドコードの確認（該当する場合）：

   • Glob を使用して、**/*.html、src/**/*.html、public/**/*.html、templates/**/*.html を検索します。
   • HTML ファイルを Read で読み込みます。
   • 次の情報から機能ドメインを抽出します。
     • ナビゲーションメニュー： <nav>、<a href> リンクから機能領域がわかります。
     • フォーム： 入力フィールドからデータモデル（ユーザー登録、ログイン、チェックアウト）がわかります。
     • ページタイトル： <h1>、<title> タグから機能名がわかります。
     • ルートパターン： URL の構造からドメインの境界がわかります。

   HTML 抽出の例：

   <nav>
     <a href="/products">Products</a>
     <a href="/cart">Shopping Cart</a>
     <a href="/checkout">Checkout</a>
   </nav>
   
   

3. ドキュメントと HTML から主要情報を抽出：

   • ビジネス目標： プロジェクトは何を達成しようとしていますか？（requirements.md から）
   • ユーザーペルソナ： 誰がシステムを使用しますか？（requirements.md から）
   • 主要な機能ドメイン： 主なモジュールや領域は何ですか？（requirements.md、architecture.md、HTML のナビゲーションから）
   • 技術スタック： どのような技術が記載されていますか？（tech_stack.md、architecture.md、HTML の meta/script タグから）
   • インフラストラクチャ要件： ロギング、監視、デプロイ、CI/CD、セキュリティ、パフォーマンス最適化についての記述はありますか？

4. 調査結果を統合：

   • ドキュメントと HTML から得たドメインを統合します（重複を除き、類似するものをまとめます）。
   • 例：「ユーザー認証」（ドキュメントから）＋「ログイン」（HTML から）→「ユーザー管理」

フォールバック： ドキュメントと HTML の両方がない場合は、スコープに関する質問に進みます。調査が必要な詳細を捏造しないでください。

ステップ 2：インフラストラクチャエピックの判断

目的： インフラストラクチャエピック（エピック 0）を提案するべきか判断します。

インフラストラクチャエピックの基準：

✅ 次のいずれかに該当する場合、インフラストラクチャエピック（エピック 0）を提案します。

1. 新規プロジェクト（docs/infrastructure.md が見つからず、kanban_board.md のエピックストーリーカウンターにも「Infrastructure」というエピックがない）
2. 複数の技術スタック（requirements.md または tech_stack.md に、異なるスタックのフロントエンドとバックエンドが記載されている（例：React + Python））
3. requirements.md または architecture.md にインフラストラクチャ要件の記載がある：
   • ロギング、エラー処理
   • 監視、アラート
   • ホスティング、デプロイ、CI/CD
   • セキュリティ（認証、認可、暗号化、シークレット管理）
   • パフォーマンス最適化（キャッシュ、レート制限、データベース最適化）

❌ 次の場合は提案しないでください。

1. 既存のプロジェクト（docs/infrastructure.md が見つかった）
2. エピックストーリーカウンターに、タイトルに「Infrastructure」を含む既存のエピックがある
3. ユーザーが以前のやり取りで明示的に辞退した

判断： フェーズ 2 で使用するため、YES/NO の判断を保存します。

ディスカバリーと調査の出力：

• チーム ID、次のエピック番号
• プロジェクトの背景情報（ビジネス目標、ドキュメントと HTML から得たドメイン、技術スタック、インフラストラクチャのニーズ）。見つかった場合のみ
• インフラストラクチャエピックの判断（YES/NO）

フェーズ 2：スコープ分析とエピック計画

目的： 論理的なドメインを特定し、エピック構成をその場で作成します。

プロセス：

ステップ 1：ドメインの自動特定

フェーズ 1 のステップ 2 で得た調査コンテキストを使用します。

• プロジェクトのドキュメントが見つかった場合 → requirements.md、architecture.md からドメインを抽出します（モジュール名、機能領域）。
• HTML が見つかった場合 → ナビゲーション、フォーム、ページ構造からドメインを抽出します。
• ドメインを統合して重複を削除します。
• 例：「ユーザー認証」＋「プロフィール管理」→「ユーザー管理」

フォールバック： ドキュメント／HTML が見つからない場合 → ユーザーに基本的な質問をします（スコープ、目的、機能領域）。

ステップ 2：エピックリストの作成（その場で）

インフラストラクチャが必要な場合（フェーズ 1 のステップ 3 に基づく）：

• エピック 0：インフラストラクチャと運用 — numbering_conventions.md §Epic 0 Content Template に従います。
• エピック 1-N： ビジネスドメイン（ステップ 1 に基づく）

それ以外の場合：

• エピック 1-N： ビジネスドメインのみ

ステップ 3：エピック数の決定

• インフラストラクチャエピック（該当する場合）：エピックを 1 件追加
• シンプルなイニシアチブ（ドメイン 1～3 件）：エピック合計 3～4 件
• 中規模のイニシアチブ（ドメイン 4～6 件）：エピック合計 5～7 件
• 複雑なイニシアチブ（ドメイン 7 件以上）：エピック合計 7～10 件（まれ）
• イニシアチブあたりのエピックは最大 10 件（厳守）

ステップ 4：提案するエピック構成の表示（ユーザー確認ポイント 1）

イニシアチブ内のインデックスを付けて、特定したエピックを表示します。

📋 Proposed Epic Structure:

Epic 0: Infrastructure & Operations
Epic 1: User Management
Epic 2: Product Catalog
Epic 3: Shopping Cart
Epic 4: Payment Processing
Epic 5: Order Management

Total: 6 Epics
Type "confirm" to proceed, or modify the list

ステップ 5：ユーザーによる確認

• ユーザーが「confirm」と入力 → フェーズ 3 に進みます。
• ユーザーが変更 → ドメインリストを更新し、再度表示します。

出力： 次のフェーズで使用する、承認済みのエピックリスト（エピック 0-N またはエピック 1-N）

読み取り専用の準備ルール： ドメインの抽出、HTML のスキャン、インフラストラクチャエピックの検出は、事前に実施してもかまいません。プレビューが確認されるまで、作成／再計画に進まないでください。

エピック品質ゲート

コンテキスト： エピック作成前に構造化された品質チェックを行うことで、スコープを明確にし、ストーリー分解時の手戻りを防ぎます。

提案する各エピックについて、次の 5 つの基準を検証します。

#	基準	合格	不合格
1	スコープの明確さ	対象範囲／対象外の境界が明確	曖昧、または他のエピックと重複
2	成功基準	測定可能（「<200ms」、「>98%」）	曖昧（「高速」、「信頼性が高い」）
3	リスクの文書化	依存関係／ブロッカーを特定済み	リスクのセクションが空、または一般的な内容
4	バランス	エピック間でスコープの規模がほぼ同じ（±30%）	1 つのエピックが作業の 80% を占める
5	独立性	エピック間に循環依存がない	エピック同士が互いをブロックする

品質スコア = 合格基準の数（0～5）

• 5/5：作成に進みます。
• 3～4/5：警告を表示し、ユーザーが判断します。
• 3 未満：作成前にエピック構成を見直します。

---

フェーズ 3：既存エピックの確認

目的： CREATE モードと REPLAN モードのどちらにするかを判断します。

kanban_board.md とタスクプロバイダーを照会し、既存のエピックを確認します。

1. kanban_board.md の Epic Story Counters テーブルを読み取ります。
2. task_provider == "linear" の場合： list_projects(team=teamId) で照合します。
   それ以外で task_provider == "github" の場合： gh issue list -R {REPO} --label epic --state all --json number,title で照合します。
   それ以外の場合： Glob("docs/tasks/epics/*/epic.md") でファイルベースのエピックを一覧表示します。
3. 既存のエピック行数を数えます（ヘッダー行を除く）。

判断ポイント：

• 件数 = 0 → 既存のエピックなし → フェーズ 4+5a（CREATE モード）に進みます
• 件数 ≥ 1 → 既存のエピックあり → フェーズ 5b（REPLAN モード）に進みます

---

フェーズ 4：エピックの準備（CREATE モードのみ）

トリガー： フェーズ 3 で Count = 0 と判定された場合（CREATE モード）

目的： 一括プレビューの前に、すべてのエピック文書を準備します。

ステップ 1：すべてのドメインの情報を自動抽出する

各ドメイン（フェーズ 2 のもの）について、プロジェクトのドキュメントから 5 つの重要な質問への回答を抽出します。

1. Q1：ビジネス目標 - このエピック／ドメインが重要である理由

   • ソース： requirements.md（ドメインの目標セクション）
   • 抽出内容： 「[domain] モジュールの目的は...」または「目標：[objective]」
   • 代替ソース： architecture.md（モジュールの目的）

2. Q2：対象範囲内の主な機能 - 機能を 3～5 個、箇条書きで列挙

   • ソース： requirements.md（このドメインの機能要件）
   • 抽出内容： ドメイン見出しの下にある箇条書き、機能の説明
   • 代替ソース： architecture.md（コンポーネントの責務）

3. Q3：対象範囲外 - スコープクリープを防止

   • ソース： requirements.md（明示的に除外された機能のセクション）
   • 抽出内容： 「対象範囲外：」、「今後のバージョン：」、「[domain] の対象範囲外：」
   • 代替ソース： requirements.md から推測（ドメイン内で言及されていない機能）

4. Q4：成功基準 - 測定可能な成果

   • ソース： requirements.md（このドメインの受け入れ基準、指標、KPI）
   • 抽出内容： パフォーマンス目標、ユーザー指標、品質ゲート
   • 代替ソース： ドメインの種類に基づく一般的な基準（例：バックエンドの場合「API 応答時間 <200ms」）

5. Q5：既知のリスク（任意）- ブロッカー、依存関係

   • ソース： architecture.md（技術的制約、依存関係のセクション）
   • 抽出内容： 「リスク：」、「依存関係：」、「制約：」
   • 代替ソース： 重大な場合はユーザーに確認し、それ以外は「ストーリー計画中に決定」とする

抽出が不完全な場合：

• 抽出した情報をユーザーに提示します
• すべてのドメインにわたる不足情報をまとめて一度だけ質問します（ドメインごとではなく、一括質問）
• 例：「エピック 1（ユーザー管理）の成功基準が見つかりませんでした。エピック 2（決済）のリスクが見つかりませんでした。情報を提供してください...」

ステップ 2：すべてのエピック文書を生成する

各ドメインについて、epic_template_universal.md を使用して完全なエピック文書を生成します。

エピックのインデックス付け：

• インフラストラクチャエピックが存在する場合（フェーズ 1 のステップ 3 から）→ エピック 0（インフラストラクチャ）、エピック 1～N（ビジネスドメイン）
• それ以外 → エピック 1～N（ビジネスドメインのみ）

トラッカーのタイトル（フェーズ 5a で作成）：

• 連番には kanban_board.md の次のエピック番号を使用します
• 形式：「Epic {Next Epic Number}: {Domain Title}」
• 例：次の番号が 11 → 「Epic 11: Infrastructure & Operations」

セクション： 目標、対象範囲内／外、成功基準、依存関係、リスクと軽減策、アーキテクチャへの影響、フェーズ

すべてのセクションに、ステップ 1 で抽出した情報を使用します

出力： イニシアチブ内でインデックス付けされた、準備完了のすべてのエピック文書（エピック 0～N）

---

フェーズ 5a：エピックの作成（CREATE モード）

トリガー： フェーズ 4 の準備が完了

目的： プレビューを表示して確認を得た後、設定済みのトラッカープロバイダーを介してすべてのエピックを作成します。

ステップ 1：一括プレビューを表示する（ユーザー確認ポイント 2）

イニシアチブ内のインデックスを付けた、生成済みのすべてのエピックを表示します。

📋 Epic Batch Preview (6 Epics to create)

═══════════════════════════════════════════════
Epic 0: Infrastructure & Operations
═══════════════════════════════════════════════
Goal: Establish foundational infrastructure, deployment pipeline, and operational capabilities to support all business Epics

Scope In:
- Logging and error handling framework
- Monitoring and alerting system
- CI/CD pipeline (GitHub Actions)
- Security baseline (secrets management, encryption)
- Performance optimization (caching, rate limiting)

Scope Out:
- Application-specific business logic
- User-facing features
- Domain-specific integrations

Success Criteria:
- All deployments automated via CI/CD (<10 min deployment time)
- System uptime ≥99.9%
- API response time <200ms (p95)
- Security audit passed

═══════════════════════════════════════════════
Epic 1: User Management
═══════════════════════════════════════════════
Goal: Enable users to register, authenticate, and manage their accounts securely

Scope In:
- User registration with email verification
- Login/logout with JWT authentication
- Password reset flow
- Profile management

Scope Out:
- Social login (OAuth) - planned for Epic 5
- Multi-factor authentication - future version
- User roles and permissions - part of Epic 3

Success Criteria:
- User registration <2 seconds
- Login success rate >98%
- Password reset completion rate >90%

[... all other Epics ...]

───────────────────────────────────────────────
Total: 6 Epics (Epic 0: Infrastructure, Epic 1-5: Business domains)
Type "confirm" to create all Epics via the configured tracker provider

ステップ 2：ユーザーの確認

• ユーザーが「confirm」と入力 → ステップ 3 に進みます
• ユーザーからフィードバックがある → フェーズ 4 で文書を調整し、プレビューを再生成して、繰り返します

停止条件（プレビューループ）

条件	アクション
ユーザーが確認する（「confirm」と入力する、または承認する）	停止 — 作成に進みます
ユーザーのフィードバックサイクルが3以上	停止 — 質問：「改訂サイクルが3回に達しました。現在の内容で進めますか、それとも中止しますか？」
2回の再作業後もエピック品質ゲートのスコアが3/5未満	停止 — エスカレーション：「品質基準を達成できません。スコープを見直してください。」

ステップ3：すべてのエピックを作成する

番号の一貫性を保つため、各エピックを順番に処理します。

1. 次のエピック番号を取得する：

   • kanban_board.md から現在の次のエピック番号を読み取ります
   • 例：11

2. エピックを作成する（プロバイダーに依存）：

   task_provider == "linear" の場合：

   • save_project({name: "Epic {N}: {Title}", description: epic_markdown, team: teamId, state: "planned"})
   • 返された URL を取得します

   task_provider == "github" の場合：

   • gh issue create -R {REPO} --title "Epic {N}: {Title}" --body "{epic_markdown}" --label "epic"
   • プロジェクトに追加し、ステータスを Backlog に設定します（provider_github.md に従う）
   • 返された Issue の URL を取得します

   それ以外（ファイルモード）の場合：

   • mkdir -p docs/tasks/epics/epic-{N}-{slug}/stories/
   • Epic の Markdown とファイルヘッダー（**Status:** Backlog、**Created:** {date}）を含めて Write("docs/tasks/epics/epic-{N}-{slug}/epic.md") を実行します

3. kanban_board.md を更新する：

   • Tracker Configuration テーブルの Next Epic Number を1増やします
   • Epic Story Counters に新しい行を追加します：Epic {N} | - | US001 | - | EPN_01
   • 「Epics Overview」→ Active に追加します：- [Epic {N}: Title](link) - Backlog

4. references/provider_file.md, references/provider_github.md, references/provider_linear.md に従い、URL（Linear/GitHub モード）またはファイルパス（ファイルモード）を取得します

ステップ4：概要を表示する

✅ Created 6 Epics for initiative

Epics created:
- Epic 11: Infrastructure & Operations (Epic 0 index) [link]
- Epic 12: User Management (Epic 1 index) [link]
- Epic 13: Product Catalog (Epic 2 index) [link]
- Epic 14: Shopping Cart (Epic 3 index) [link]
- Epic 15: Payment Processing (Epic 4 index) [link]
- Epic 16: Order Management (Epic 5 index) [link]

Next Epic Number updated to: 17

Next Steps:
1. Use ln-220-story-coordinator to create Stories for each Epic (run 6 times)
2. OR use ln-200-scope-decomposer to automate Epic + Story creation

出力： 作成したエピックの URL と概要

TodoWrite 形式： フェーズ1～5aの Todo と、エピックごとに1つの Todo、kanban の更新を追加します。ステータスを in_progress/completed に設定します。

---

フェーズ5b：再計画モード（既存のエピックが見つかった場合）

トリガー： フェーズ3で件数が1以上と判定（再計画モード）

全ワークフロー： 必ず読み込むこと： 完全な再計画プロセスについて、references/replan_workflow.md を読み込みます。

概要：

1. 既存のエピックを読み込みます（task_provider == "linear" の場合：Linear API から | task_provider == "github" の場合：gh issue list --label epic から | それ以外の場合：docs/tasks/epics/*/epic.md から）
2. 理想の計画と既存の内容を比較し、KEEP/UPDATE/OBSOLETE/CREATE に分類します
3. 差分と警告を含む再計画の概要を表示します
4. ユーザーの確認が必要です
5. 操作を実行し（provider_*.md に従う）、kanban_board.md を更新します

制約： 進行中のストーリーがあるエピックを自動更新またはアーカイブしてはいけません。削除せず（アーカイブを使用）、必ず確認を求めてください。

---

重要なルール

• 分解優先： 既存のエピックを確認する前に、必ず理想のエピック計画を作成します（古い構成への固執を防ぎます）
• エピック0はインフラストラクチャ用に予約： ビジネスドメインはエピック1から開始します。新規プロジェクト、複数スタック、またはインフラ要件が検出された場合は、エピック0を自動的に提案します
• 質問する前に自動抽出： ドキュメント（requirements.md、architecture.md、tech_stack.md）と HTML から Q1～Q5 を抽出し、不足している情報のみをまとめて一度にユーザーに尋ねます
• 進行中のストーリーがあるエピックを自動更新しない： 再計画モードではユーザーの確認が必要です。アクティブなストーリーがあるエピックには警告を表示し、無断で変更してはいけません
• トラッカーのタイトル形式： 「Epic {Next Epic Number}: {Domain Title}」— kanban_board.md に基づく連番

完了の定義

作業を完了する前に、すべてのチェックポイントを確認してください。

✅ 発見完了（フェーズ 1）：

• kanban_board.md からチーム ID を読み込み済み
• kanban_board.md から次のエピック番号を読み込み済み
• ドキュメントをスキャン済み（requirements.md、architecture.md、tech_stack.md）
• HTML ファイルをスキャン済み（フロントエンドが存在する場合）
• インフラストラクチャエピックの要否を決定済み（プロジェクトの条件に基づき YES/NO）

✅ スコープ分析完了（フェーズ 2）：

• ドメインをドキュメントと HTML から自動特定済み
• 該当する場合はインフラストラクチャエピック（エピック 0）を含め済み
• エピック一覧を作成済み（エピック 0-N またはエピック 1-N）
• ユーザーがエピック構成を確認済み（コントロールポイント 1）

✅ 既存エピックの確認完了（フェーズ 3）：

• エピックのストーリーカウンターを kanban_board.md から読み込み済み
• 既存のエピック数を判定済み（0 → 作成、≥1 → 再計画）

✅ エピックの準備完了（フェーズ 4 - 作成のみ）：

• すべてのドメインについて Q1-Q5 を自動抽出済み
• 必要に応じて、ユーザーから不足情報を取得済み（まとめて質問）
• すべてのエピックドキュメントを生成済み（エピック 0-N のインデックス）

✅ エピックの作成完了（フェーズ 5a - 作成のみ）：

• エピック 0-N のインデックスを含む一括プレビューを表示済み
• ユーザーがプレビューを確認済み（コントロールポイント 2）
• 設定済みのトラッカープロバイダーを使用して、「Epic {N}: {Title}」形式ですべてのエピックを作成済み（N = 次のエピック番号）
• 各エピックの作成後に kanban_board.md を更新済み：
  • 次のエピック番号を 1 つ増加
  • エピックのストーリーカウンター行を追加
  • エピック概要を更新
• すべてのエピック URL を含む概要を表示済み
• 確定処理中にコーディネーターの epic-plan 概要を記録済み

✅ エピックの再計画完了（フェーズ 5b - 再計画のみ）：

• 必須の読み込み： 完全なチェックリストを確認するため、references/replan_workflow.md を読み込みます
• 確定処理中にコーディネーターの epic-plan 概要を記録済み

出力： エピック URL の一覧（Epic {N}: {Title}）＋次のエピック番号

---

使用例

リクエスト：「e コマースプラットフォームのエピックを作成」

フロー： フェーズ 1（チーム ID=Product、次の番号=11 を確認し、ドキュメントと HTML をスキャン）→ フェーズ 2（6 つのドメインを特定：インフラストラクチャ、ユーザー、製品、カート、決済、注文）→ フェーズ 3（件数=0 → 作成）→ フェーズ 4（Q1-Q5 を自動抽出し、ドキュメントを生成）→ フェーズ 5a（プレビュー、確認後、設定済みのトラッカープロバイダーを使用して作成：エピック 11-16）

結果： 6 つのエピックを作成（内部インデックスはエピック 0-5、トラッカー上のタイトルはエピック 11-16）

---

フェーズ 6：メタ分析

任意の参照先：ユーザーが実行後のメタ分析またはプロトコル形式の実行振り返りを求めた場合に限り、references/meta_analysis_protocol.md を読み込みます。

スキルタイプ：planning-coordinator。要求された場合は、すべてのフェーズの完了後に実行します。planning-coordinator 形式を使用して、チャットに出力します。

参照ファイル

• 必須の読み込み： references/environment_state_contract.md を読み込みます
• 必須の読み込み： references/storage_mode_detection.md を読み込みます
• [必須] 問題解決のアプローチ： references/problem_solving.md
• オーケストレーターのライフサイクル： references/orchestrator_pattern.md
• 自動発見のパターン： references/auto_discovery_pattern.md
• 分解優先のパターン： references/decompose_first_pattern.md
• 番号付けの規則： references/numbering_conventions.md（エピック 0 を予約、トラッカーでの番号付け）
• イシュー作成ワークフロー： references/issue_creation_workflow.md
• linear_integration.md： 発見パターン＋Linear API リファレンス（references/templates/linear_integration.md に移動）
• epic_template_universal.md： エピックテンプレートの構成
• replan_workflow.md： 再計画モードの完全なワークフロー（フェーズ 5b）

---

ベストプラクティス

• まず調査する： ユーザーに質問する前に、ドキュメント（requirements.md、architecture.md、tech_stack.md）と HTML を確認します
• インフラストラクチャには Epic 0 を使用する： インフラストラクチャ Epic 用に予約されたインデックスです。ビジネスドメインは Epic 1 から開始します
• ビジネス Epic のグループ化： 1 Epic = 5～10 個のストーリー = 1 つのビジネス機能（技術コンポーネントではありません）
• 自動抽出： ユーザーに質問する前に、ドキュメントから Q1～Q5 を抽出し、不足している情報のみを尋ねます
• トラッカーのタイトル： 「Epic {Next Epic Number}: {Domain}」形式
• ビジネス重視のスコープ： 技術的なタスクではなく、ユーザーが実行できることを列挙します
• 測定可能な基準： 「高速」ではなく「<200ms」、「信頼性が高い」ではなく「ログイン率 >98%」とします
• コードスニペットは含めない： 概要レベルの機能と目標のみを記載します

---

バージョン： 8.0.0 最終更新日： 2026-04-05