Missions are a research preview. We are actively exploring open questions: Is parallelization necessary or even value-add? How do you maximize correctness across long-running plans? How do you make the right tradeoffs between cost and quality? Your feedback shapes where this goes.
Missions とは？
Missions は、Droid を使って大規模でマルチ機能の作業を構造化された方法で取り組むための仕組みです。すべてを単一のセッションで処理するのではなく、まず Droid と協力してプラン（機能、マイルストーン、各部分を達成するために必要なスキル）を構築し、その後作業を管理するオーケストレーション層に実行を委ねます。 Missions には/missions コマンドでアクセスできます（/mission と /enter-mission でも利用可能）。
Collaborative Planning
Work with Droid to define features, milestones, and success criteria before any code is written.
Skill-Aware Execution
Existing skills are leveraged and new specialized skills are developed for each part of the work.
Structured Orchestration
Mission Control manages execution across agents, tracking progress through your plan.
Your Config Carries Over
MCP integrations, skills, hooks, and custom droids all work inside missions.
動作の仕組み
Collaborate on the plan
Droid interacts with you back and forth to understand your goal. It asks clarifying questions, probes for constraints, and works with you to define what you actually want built. This is a conversation, not a one-shot prompt.
Build features and milestones
Based on the conversation, Droid constructs a structured plan: a set of features organized into milestones. Each milestone represents a meaningful checkpoint in the work.
Skills are leveraged or developed
Droid pulls in your existing skills where they apply, and develops specialized skills for parts of the work that need them. This means the execution is tailored to your project and workflow, not generic.
計画段階が最も重要
Missions において最も価値があるのは計画段階です。事前のプランを正しく組み立てる（機能、順序、マイルストーン、関連するスキル）ことが、実行の成功を決定します。Droid は異議を唱え、質問を投げかけ、プランが確実になるまであなたと反復作業を行います。 これは意図的なものです。明確なマイルストーンを持つ適切にスコープされたプランは、曖昧な目標でいきなり実行に飛び込むよりもはるかに良い結果を生み出します。検証
- マイルストーンは検証頻度を定義します。検証ワーカーは各マイルストーンの終了時に実行され、その作業を検証します。シンプルなプロジェクトでは1つのマイルストーンで十分なことが多いですが、より長期または複雑なプロジェクトでは、より頻繁なマイルストーン検証が作業の規模拡大時の基盤安定性を保つのに役立ちます。
コストと期間の見積もり
大まかな計画のヒューリスティックとして、ミッションの期間とコストはワーカーの実行回数に比例します：- 機能ワーカー： 機能あたり約1回の実行
- 検証ワーカー： マイルストーンあたり約1回の実行
total runs ≈ #features + 2 * #milestones
実際には、これは上限ではなく下限です。検証でフォローアップ作業が必要な問題が浮上する可能性があり、オーケストレーターは実行中に追加の修正機能を作成できます。
Missions が適している用途
私たちは様々な作業で Missions を構築・テストしてきました：- フルスタック開発 — フロントエンド、バックエンド、データベース、デプロイメントを含む完全なアプリケーションの構築
- リサーチ — 複数のアプローチを探索し、発見を統合し、構造化された出力を生成する深い調査タスク
- ブラウンフィールド移行 — 既存の動作を保持しながら、既存コードベースの現代化、フレームワークの交換、大規模プロジェクトの再構築
- 野心的なプロトタイプ — 単なるスケッチではなく、機能的である必要がある製品実験
Mission Control での作業
プランが承認されると、Droid は実行を管理するオーケストレーションビューである Mission Control に入ります。ここから機能とマイルストーンの進捗を追跡し、どのエージェントが何に取り組んでいるかを確認し、調整が必要な時に介入できます。介入とリダイレクト
Missions は設定したら放置するものではありません。オーケストレーターはエージェントであり、会話することができます。Missions を最も効果的に使用する方法は、自分をプロジェクトマネージャーとして扱うことです - 進捗を監視し、ワーカーのブロックを解除し、プランの変更が必要な時にリダイレクトします。The mission freezes or stops making progress
The mission freezes or stops making progress
If the mission appears stuck and nothing is happening, pause the orchestrator and tell it what you are seeing. Be direct: explain that the mission appears frozen or broken, describe what the last visible activity was, and ask it to recover. The orchestrator can re-assess the state and pick back up.Example: “The mission seems frozen — the last worker finished 10 minutes ago and nothing new has started. Re-assess and continue.”
A worker is taking too long on a single item
A worker is taking too long on a single item
If one worker is spinning on a task for too long without making meaningful progress, you do not need to wait for it to finish. Pause the orchestrator and tell it to mark the current item as complete and move on. You can always come back to that item later, or handle it manually.Example: “The worker on the auth integration has been stuck for 20 minutes. Mark it as complete and move to the next feature.”
The mission is stuck on a milestone
The mission is stuck on a milestone
Sometimes the orchestrator hits a milestone that has become blocked — maybe an earlier assumption was wrong, or a dependency is missing. When this happens, ask the orchestrator to re-assess the remaining work and figure out why it has become blocked. It can re-plan around the obstacle, reorder features, or adjust the milestone scope.Example: “We are stuck on Milestone 3. Re-assess the remaining work and tell me what is blocking progress.”
You want to change direction mid-mission
You want to change direction mid-mission
If you realize the plan needs to change — a feature should be dropped, a new requirement has come in, or the approach is wrong — pause and tell the orchestrator. It can update the plan, re-scope milestones, and continue from the new direction.Example: “Drop the email notification feature and add Slack integration instead. Re-plan the remaining milestones.”
新しい種類のデバッグ
Missions で作業するスキルセットは、従来のデバッグというよりもエージェントのプロジェクト管理に近いものです。コードを1行ずつステップ実行するのではなく、ワーカーチームを監視し、詰まった時にブロックを解除し、優先順位が変わった時にリダイレクトし、押し通すか再計画するかの判断を下します。 これは AI との意味的に異なる作業方法です。核となるスキルは、いつどのように介入するかを知ることであり、自分でコードを書くことではありません。設定の継承
Missions は既存の Droid 設定を継承します：- MCP 統合 — ワーカーは接続されたツール（Linear、Sentry、Notion など）を使用できます
- カスタムスキル — 既存のスキルが利用可能で、計画中に新しいものを開発できます
- フック — ライフサイクルフックはミッション実行中に発火します
- カスタム droids — プロジェクトで設定されたサブエージェントがワーカーで利用できます
- AGENTS.md — ワーカーはプロジェクトの慣例とコーディング標準に従います
未解決の問題
Missions は初期段階です。まだ取り組んでいる根本的な問題があるため、これをリサーチプレビューとして提供しています：- 並列化は必要か？ 複数のエージェントを並列実行するのは理論的には良く聞こえますが、実際に逐次実行よりも良い結果を生み出すのでしょうか？これをテストしています。
- 正確性を最大化するには？ 長期間のプランはエラーが蓄積されます。各段階でどの検証と修正戦略が最も効果的でしょうか？
- コスト vs. 品質のトレードオフ — オーケストレーターはどの程度積極的であるべきでしょうか？より多くの計画と検証は高コストを意味しますが、潜在的により良い出力をもたらします。適切なバランスはどこでしょうか？
関連項目
- Specification Mode — 実装前の計画から恩恵を受ける適切にスコープされたタスクに対して
- Implementing Large Features — マルチフェーズプロジェクトのマニュアルワークフロー
- Custom Droids — ミッションが使用できる専門的なサブエージェントを構築
- Skills — ミッションが活用できるスキルの作成と管理