Epic — 大規模タスクの多段オーケストレーション

親が全体の計画、依存関係、所有境界、統合、受入、最終判断を保持し、サブタスクを現在のランタイムの委譲機構で実行します。サブタスクごとのワークフローは、実際に読み込んだ利用可能な skill の契約に従います。

親は実装しません。対象成果物の実装・修正は、小変更、失敗後の修正、統合時の接続修正・競合解消を含め、すべて実装担当へ渡します。親の統合責任は、差分と境界の照合、修正の割当、結果の確認、受入判断です。親による探索、計画・引継ぎ記録の更新、レビュー、許可された検証の実行は妨げませんが、それを理由に実装を肩代わりしません。

以下の境界を保って進めます:

• 親が探索結果を統合して計画と依存関係を作り、各サブタスクの所有を明確にする。
• 並列化は、書き込みファイル、共有契約、生成物、lockfile、実装順序に競合がない独立単位だけに限る。競合する単位は直列化する。
• サブタスクは親の計画、スコープ、受入条件、権限境界を変更しない。ユーザー判断が必要な事項は親へ戻す。

タスク: $ARGUMENTS

Review/test の接続

各サブタスクの review/test が必要な場合、同じ親が shared skill package の実体にある ../reviewer/SKILL.md または ../tester/SKILL.md を存在確認して読み込み、その手順を実行する。別の進行担当を起動せず、親はサブタスクの対象版、要件、ユーザー指定、実在する差分・計画、必要な確認範囲を渡し、選定・配分・集約は shared skill に委ねる。

shared reviewer は評価者へ code-review-guidance/SKILL.md の実体絶対パスと対応する reference だけを渡し、reviewer の進行手順を評価者へ渡さない。shared tester は tester/references/test-procedure.md と結果契約の実体を実行担当へ渡す。親が自ら評価・検証する場合だけ、必要な専門手順を読む。この workflow では観点、未知指定、担当間の分離、判定規則を再定義しない。

---

ステップ 1: 実行コンテキストの確認

対象リポジトリの実体、現在の status/diff、依頼の範囲を確認する。長い run や再開に記録が役立つ場合だけ、親またはランタイムが提示した実在の artifact path を使う。再開時に親から実在する plan または handoff path が渡された場合は、その実体を読み、完了済み・決定済みの項目を保持したまま未完了項目だけを同じ path へ増分更新する。path を推測したり、未指定の artifact を作ったりしない。小さい run のために固定のメモリ、run、台帳、計画ファイルを先行生成しない。

サブタスクの skill は、親が実際に読み込める skill package から選び、その SKILL.md の契約を確認して渡す。特定ランタイムのホームディレクトリ、パス正規化、agent/API 名、別名の skill を推測しない。

---

ステップ 2: 探索とエピック計画

親が対象、既存差分、既存パターン、主なリスクを確認する。分割・DAGを決める前に、同じ shared skill package の実体から references/decomposition.md の実在を確認して読み込み、その分割基準を使う。独立した問いに分ける価値がある場合だけ、現在のランタイムの read-only 委譲 primitive へ渡す。探索結果は、後続判断に必要な場合だけ親が選んだ実在の保存先へ記録する。

親が確認済み事実と依頼を照合し、サブタスクごとの目標、非目標、対象・禁止範囲、排他的な書き込み所有、依存関係、完了条件、対応する検証を計画へまとめる。計画の作成・更新責任を別の計画担当へ移さない。

サブタスクをまたぐ状態所有・API・依存方向などの判断は、同じshared packageの PIR²の専門検討から実装条件へ を読み、関係する観点だけ検討して一つの方針へ統合する。各サブタスクへ守る条件・理由・根拠・確認方法・再検討条件を渡し、同じ専門検討を全サブタスクで繰り返さない。個別単位に新たな判断が見つかった場合はその部分だけ扱う。実装・再修正の受け渡しは implementation-delegation.md を使い、Epicの親は実装を担当へ渡す境界を保持する。

未確認事項が正しさ・安全性・権限・受入に影響する場合だけ、具体的な問いを追加調査またはユーザー判断へ戻す。解消したら計画の該当箇所だけを更新し、計画全体を破棄・再生成しない。

---

ステップ 2.5: 分割結果の確認

親が計画、依存関係、所有範囲、受入条件を確認し、元の依頼の範囲内で安全に実行できるか判断する。計画の見出しや未解決ラベルだけで停止せず、結果を実質的に変える設計選択、未許可の外部・破壊的操作、権限不足だけをユーザーへ確認する。

サブタスクに依存しない read-only 作業は続けてもよい。ユーザーの無応答を承認とみなさず、必要な判断が得られない範囲だけを blocker として残す。親がこの確認と統合判断を保持し、不要な承認ファイルや固定待機を作らない。

---

ステップ 3: サブタスクの実行

親が各サブタスクへ、目的、確認済み事実、対象・禁止範囲、排他的な書き込み所有、依存関係、完了条件、focused check を渡す。サブタスクの skill を使う場合は、その実体の SKILL.md を読み、runtime 自身の委譲 primitive を使う。

依存のない単位は、共有契約・生成物・lockfile・実装順序に競合がない場合だけ並列化する。依存する単位、共有状態を扱う単位、所有が重なる単位は直列化する。容量やネスト機能の不足時は、親から実装担当を直接起動するか、担当の空きを待って直列に委譲する。実装を委譲できる経路がなければ、その範囲を blocker として返す。親の直接実装へ切り替えず、形式だけの完遂や架空の結果を作らない。

サブタスク担当は、親の計画・スコープ・受入条件を変更せず、別担当のファイルを編集しない。ユーザー判断、権限、外部状態、不可逆操作が必要になった場合は、対象、影響、復旧方法とともに親へ戻す。親は各完了報告を status、diff、実際の確認結果と照合する。

各サブタスクの review/test は前節の shared skill へ接続する。親は実差分が起こし得る実害、サブタスクの要件、必要な安全確認を渡し、返却された実在の結果を受入判断へ使う。サブタスクが別の workflow skill（例: pir2）へ委譲する場合は、読み込んだその本文の接続規則に従う。ただし、別の workflow に親の直接実装を許す規則があっても、Epicの親には適用しない。Epicの親は進行・統合・受入を保持し、実装は担当へ渡す。

---

ステップ 4: 統合確認と任意の振り返り

全サブタスク完了後、親が status、対象 diff、サブタスク境界をまたぐインターフェース、命名、未接続実装、生成整合性を確認する。問題があれば、原因と所有範囲が明確な最小の統合修正を実装担当へ渡す。親は自ら修正せず、返却された差分を照合し、影響する確認だけを再実行する。

振り返りは、複数担当や失敗分析を分離する価値がある場合、またはユーザーが求めた場合だけ行う。実際に読み込んだログ、差分、計画、検証結果を使い、未生成の実験資料、固定台帳、メタ改善を完了条件にしない。

---

ステップ 5: 最終サマリー

サブタスクごとの目的、変更ファイル、実際に行った確認、統合結果、未確認事項・blocker、必要なら実在する記録先を提示する。実行していない担当、未生成の path、推測の verdict を補完しない。