mission-orchestrator

ミッションオーケストレーター

概要

attune の開発ライフサイクル全体（ブレインストーミング → 仕様策定 → 計画 → 実行）を、自動的な状態検出、タイプ選択、フェーズ振り分けによって単一のミッションにまとめます。spec-kit:speckit-orchestrator の「永続的なプレゼンスレンズ」パターンに従い、既存のスキルを Skill() 呼び出しによって全面的に委譲し、フェーズロジックを再実装することはありません。

使用する場面

• 新しいプロジェクトをゼロから開始する場合（ライフサイクル全体）
• 中断したプロジェクトのワークフローを再開する場合
• 既存の仕様から、焦点を絞った戦術的な実装を行う場合
• 既存の実装計画から、すばやく修正する場合

使用しない場面

• 単一のフェーズを直接実行する場合（/attune:brainstorm、/attune:specify などを使用してください）
• プロジェクト以外の作業（コードレビュー、デバッグ、調査）
• フェーズの移行をきめ細かく制御する必要がある場合

ミッションのライフサイクル

1. State Detection
   Scan for existing artifacts (project-brief.md, specification.md, etc.)
       |
2. Mission Type Selection
   Auto-detect type based on artifacts, or accept user override
       |
3. Phase Routing Loop
   For each phase in the mission type:
       a. Pre-phase validation (check prerequisites)
       b. Invoke Skill(attune:{phase-skill})
       c. Post-phase artifact check (verify output exists)
       d. Post-phase backlog triage (create GitHub issues
          for out-of-scope items after brainstorm/specify)
       e. Update mission state
       f. User checkpoint (skippable with --auto)
       g. Error handling via leyline:damage-control
       |
4. Completion
   All phases complete, final state saved

ミッションのタイプ

タイプ	フェーズ	自動検出の条件
full	ブレインストーミング → 仕様策定 → 計画 → 実行	成果物が存在しない
standard	仕様策定 → 計画 → 実行	docs/project-brief.md が存在する
tactical	計画 → 実行	docs/specification.md が存在する
quickfix	実行	docs/implementation-plan.md が存在する
review	スコープ設定 → 調査 → 検証 → レポート作成	リクエストで、監査、実地検証、またはレビューの対象となる既存のソフトウェアが指定されている

review は、成果物からではなくリクエストの意図から選択される唯一のタイプです。ビルド成果物のツリーは、「これをリリースする」と「これを監査する」のどちらが依頼された場合でも同じに見えるためです。この判定は最初に行われます。reports/<topic>-<YYYY-MM-DD>.md を作成し、レビューのミッションには存在しない計画から実行への移行を制御するウォールームゲートには入りません。

タイプの定義とカスタムタイプのサポートの詳細については、modules/mission-types.md を参照してください。

フェーズとスキルの対応

フェーズ	呼び出すスキル	作成される成果物
ブレインストーミング	Skill(attune:project-brainstorming)	docs/project-brief.md
仕様策定	Skill(attune:project-specification)	docs/specification.md
計画	Skill(attune:project-planning)	docs/implementation-plan.md
実行	Skill(attune:project-execution)	実装済みのコードとテスト

レビューのミッションでは、attune のフェーズスキルではなく、既存のレビュー用スキルに振り分けられます。

フェーズ	呼び出すスキル	作成される成果物
スコープ設定	Skill(pensive:tiered-audit)	ティアの選択と限定されたスコープ
調査	Skill(imbue:feature-review) および pensive:* のドメインレンズ	未整理の調査結果
検証	Skill(imbue:proof-of-work)	各調査結果の証拠への参照
レポート作成	Skill(imbue:structured-output)	reports/<topic>-<YYYY-MM-DD>.md

オーケストレーターがフェーズロジックを再実装することはありません。各フェーズは、独自のワークフローを処理する完全な Skill() 呼び出しです。

ミッション中の委任

ミッションでは、デフォルトで実行を委任します。 Skill(conjure:delegation-core) が判断を規定し、デフォルトの 姿勢は有効です。実行作業に入ったフェーズは、依頼されるのを 待たずに外部 CLI に引き渡します。

フェーズ	委任する内容	理由
brainstorm	いいえ	推論であり、「ローカルにとどめる」条項が適用されます
specify	いいえ	推論
plan	いいえ	推論
execute	タスクごとに、はい	タスク実行は委任対象となる部分です
scope、investigate、verify、report	報告と検証のみ	調査結果の判断は委任対象ではありませんが、大量の抽出は対象です

この分担は、conjure 独自の方針に沿っています。実行は委任し、 推論は保持します。 判断だけで完結するミッションフェーズはローカルで行い、委任機能には 一切問い合わせません。

報告ではなく、対処が必要な結果が 2 つあります。

• fallback_reason が providers_exhausted の場合：応答した CLI がありません。試したものを伝えたうえで、 セッションのモデルを使うサブエージェントにタスクを引き渡します。 Skill(attune:project-execution) の subagent-fallback.md モジュールに、各フェーズで使うエージェント、モデルとブランチを 維持する方法、インライン作業が許可される条件が記載されています。CLI がインストールされていない マシンでは通常この経路をたどり、フェーズは失敗しません。 conjure がインストールされておらず、スキルを読み込めない場合も同じ経路をたどります。
• fallback_reason が delegation_disabled の場合：オペレーターが拒否しました。 サブエージェントへの依頼も委任にあたるため、タスクはローカルで行い、 委任を再び有効にすることは提案しません。

外部モデルを使わずにミッション全体を実行するには、ミッションの開始前に CONJURE_DELEGATION=off を設定します。

セッションの復元

ミッションの状態は .attune/mission-state.json に保存されます。再開時には次の手順を実行します。

1. ミッション状態ファイルを読み込みます
2. 参照されている成果物がディスク上にまだ存在することを検証します
3. 最後に完了したフェーズを特定します
4. 次のフェーズから順番に続行します

状態スキーマと復元プロトコルについては、modules/mission-state.md を参照してください。

インタラクティブな計画レビュー

計画から実行への移行では、単純なチェックポイントの代わりに、 インタラクティブなレビューループを使用します。計画はセクションごとに レビューされ、フィードバックに基づいて修正され、実行前に必須の ウォールームゲートを通過する必要があります。

主な機能：

• ターミナルでのセクションごとのレビュー（まずアーキテクチャ、 次にフェーズ）
• 根拠を添えた承認／修正／却下の判定
• 差分の要約を含む計画のバージョン管理
• 構造化されたフィードバックによるコンテキストの改善
• ユーザーレビュー前の加算的なバイアススキャン
• 強制的な決定に進むまでの修正は最大 3 ラウンド
• 検察担当顧問による必須のウォールーム承認

完全なプロトコルについては、modules/plan-review.md を参照してください。

レビューモジュール

• plan-review.md：レビューループのメインオーケストレーター
• plan-versioner.md：バージョン管理と差分の生成
• feedback-collector.md：判定の記録と JSON 出力
• context-injector.md：修正プロンプトの作成
• iteration-governor.md：ラウンドの追跡とエスカレーション

ユーザー指示による上書き

オーケストレーターはミッション開始時に、ユーザーのコマンド引数と フリーテキストを解析し、自然言語による信頼のシグナルを確認します。 「スコープガードを無視して」「徹底的に考えて」「何度も聞かないで」、 「自律的に動いて」などのフレーズは、明示的な --constraints= フラグを必要とせずに制約プロファイルを調整する 指示の上書きとして認識されます。

指示の上書きはミッション種別のデフォルトより優先されますが、 安全の最低基準（コミット前フック、 作業証明のエビデンス、破壊的操作の確認、外部に影響するアクション）を 回避することはありません。指示が検出されると、オーケストレーターは ミッション開始時に一度だけそれを確認し、該当するチェックポイントについて それ以上尋ねません。指示による上書きの後に承認を繰り返し求めることは、 それ自体がワークフローの不具合です。

解析テーブルについては、modules/adaptive-constraints.md の「ユーザー指示による 上書き」セクションを参照してください。

ミッション憲章

references/mission-charter.md の構造化テンプレートを使って、ミッションの範囲を定義します。ミッション憲章では、次の項目を指定します。

• 成果：成功がどのような状態か
• 成功指標：測定可能な完了基準
• 期限：時間の境界（セッション、日付、期間）
• 制約：トークン数・時間の予算、禁止されている操作
• 範囲：対象範囲と対象外の範囲
• 停止条件：ミッションを終了する条件

テンプレートと例の全文については、references/mission-charter.md を参照してください。

進捗レポート

references/progress-report.md を使い、構造化されたチェックポイントで進捗を追跡します。次のタイミングでレポートを作成します。

• フェーズの境界（brainstorm→specify→plan→execute の各フェーズ間）
• ブロッカーの特定時
• リスクのエスカレーション時
• 予算のしきい値（50%、75%、90%）

テンプレートとチェックポイントのリズムに関するガイダンスについては、references/progress-report.md を参照してください。

モジュールリファレンス

コアモジュール（常に読み込み）

• mission-types.md：型定義、自動検出ロジック、カスタム型
• state-detection.md：成果物の存在確認、品質検証、古さの判定
• phase-routing.md：フェーズ実行プロトコル、遷移フック、エラー処理
• mission-state.md：状態スキーマ、永続化、復旧プロトコル

計画レビュー用モジュール（計画フェーズの実行時に読み込み）

• plan-review.md：バイアスのスキャンを含む、セクションごとの対話型レビュー
• plan-versioner.md：バージョンの追跡と差分の要約
• feedback-collector.md：判定の記録とフィードバックファイルの作成
• context-injector.md：フィードバックに基づく修正プロンプトの作成
• iteration-governor.md：ラウンドの追跡、上限の適用、エスカレーション

条件付きモジュール（起動条件を満たした場合のみ読み込み）

• reflexion-buffer.md：セッションをまたいで学習内容を保持するバッファ。反復回数が 1 を超えた場合、または修正ラウンドに失敗した後に読み込みます。
• trust-tier.md：制約プロファイルの分類器。ミッション開始時にユーザーによる指示の上書きを検出した場合に読み込みます。
• adaptive-constraints.md：制約の適応ルール。指示の上書きが有効な場合、trust-tier.md とともに読み込みます。

ミッションタイプごとのモジュール読み込み

このスキルは progressive_loading: true を宣言しています。オーケストレーターが常時保持するトークンコストを最小限に抑えるため、各ミッションタイプで実際に必要となるモジュールだけを読み込みます。オーケストレーター自体は、ミッション開始時に4つのコアモジュールのみを読み込みます。それ以外のモジュールは、対応するフェーズの実行時に必要に応じて読み込みます。

ミッションタイプ	コア	計画レビュー	Reflexion	Trust と adaptive
quickfix（実行のみ）	はい	--	--	指示がある場合
tactical（plan -> execute）	はい	はい	修正時	指示がある場合
standard（specify -> plan -> execute）	はい	はい	修正時	指示がある場合
full（brainstorm -> specify -> plan -> execute）	はい	はい	はい	指示がある場合
review（scope -> investigate -> verify -> report）	はい	--	修正時	指示がある場合

トークンコスト（hub と読み込み済みモジュールの wc -w の結果を基に算出し、1語あたり約1.3トークンとして換算した概算）：

ミッションタイプ	読み込みモジュール	概算トークン数
quickfix	hub とコア（4）	~4,100
tactical	hub、コア、計画レビュー（9）	~6,900
standard	tactical と同じ（9）	~6,900
full	hub、コア、計画レビュー、reflexion（10）	~7,900

以前の全読み込み方式では、実行フェーズのみが必要な quickfix の実行も含め、すべてのミッションで約10,100トークンを読み込んでいました。タイプ別に読み込む方式では、quickfix のコストが約60%減り、standard／tactical／full の各経路では22〜32%削減されます。

指示の上書きが発生した場合、trust-tier と adaptive-constraints のペアにより、ミッションタイプごとの基準値に約2,200トークンが追加されます。

参照モジュール

• mission-charter.md：ミッション定義の構造化 テンプレート（憲章の定義時にのみ読み込みます）
• progress-report.md：チェックポイント状況報告のテンプレート （進捗レポートの作成時にのみ読み込みます）

関連スキル

• Skill(attune:project-brainstorming) - ブレインストーミングフェーズ
• Skill(attune:project-specification) - 仕様策定フェーズ
• Skill(attune:project-planning) - 計画フェーズ
• Skill(attune:project-execution) - 実行フェーズ
• Skill(attune:war-room-checkpoint) - RED／CRITICAL タスクのリスク評価
• Skill(leyline:risk-classification) - タスクのリスク分類
• Skill(leyline:damage-control) - 各フェーズでのエラー復旧
• Skill(conjure:delegation-core) - 実行作業のデフォルトで有効な委任

関連コマンド

• /attune:mission - このスキルを実行します
• /attune:mission --resume - 保存された状態から再開します
• /attune:mission --type tactical - ミッションタイプを上書きします

完了条件

• ミッションタイプ内のすべてのフェーズが正常に完了している
• 完了した各フェーズの成果物が存在する
• ミッションの状態が .attune/mission-state.json に保存されている
• リスク概要が生成されている（全タスクのティア数）
• 実行フェーズの作業は委任されるか、名前付きのローカル保持条項によって保留されていること。委任するかどうかの判断を理由に、作業を省略してはいけません
• providers_exhausted の結果は、セッションモデルのサブエージェントによって完了していること。ハーネスにサブエージェント用ツールがない場合はインラインで完了し、試したプロバイダーを報告していること
• 未解決のエラーやブロッカーがないこと