Mission Control: Orchestration Workflow

1c. Check for Matching Playbook

Check .mission-control/playbooks/ for project-specific playbooks. Also check built-in playbooks provided by this plugin (see references/orchestration-patterns.md for pattern-based templates). If a playbook matches the mission type (full-stack-feature, bug-investigation, refactoring, security-audit, migration), suggest it to the user:

PLAYBOOK MATCH: "full-stack-feature"
This playbook provides a pre-built task graph for feature implementation.
Use it? [Y/n]

If the user confirms (or requireApproval is never), load the playbook and skip to Step 3 with the playbook's predefined task structure, adjusting parameters to match the specific goal.

1d. Output Mission Scope

Produce the mission scope now using this format:

MISSION SCOPE
---------------------------------------------------------------------
Outcome:        [One sentence: what success looks like]
Success Metric: [Measurable criteria to verify completion]
Budget:         [Token/time constraints, or "standard session"]
Constraints:    [Forbidden actions, compliance rules, reliability reqs]
In Scope:       [What this mission covers]
Out of Scope:   [What this mission explicitly excludes]
Stop Criteria:  [When to halt if conditions change]
Deliverables:   [Artifacts that must be produced]
---------------------------------------------------------------------

If the user's request is ambiguous, ask one clarifying question. Do not ask more than one.

Step 2: Assess Risk

2a. Classify Risk

Assign a risk tier (0-3) to the overall mission and to each subtask you will create in Step 3. Reference references/risk-tiers.md for full tier definitions and the failure-mode checklist.

Output the tier assignment inline with the mission scope.

2b. Enforce Tier Controls

• Tier 0: Proceed autonomously. No reviewer required.
• Tier 1+: You MUST assign a reviewer agent in Step 5. The reviewer must be a different agent than the implementer.
• Tier 2+: Produce a failure-mode checklist before launching implementation agents. Include: what could fail in production, how to detect it, fastest safe rollback, which dependency could invalidate the plan, which assumption is least certain.
• Tier 3: Require explicit human confirmation before any irreversible action. If the user has not confirmed, pause and ask.

2c. Adaptive Execution Rules

Apply these rules throughout the mission:

1. Model escalation on failure. If an agent fails its task, retry with the next model tier: haiku -> sonnet -> opus. Respect maxRetries from settings. If escalateModelOnRetry is false, retry with the same model.
2. Task splitting on complexity. If an agent reports that a task is too large or produces incomplete output, split the task into smaller subtasks and reassign.
3. Agent replacement on stall. If an agent produces no output after a reasonable period, spawn a replacement with a clearer, more constrained prompt.
4. Budget awareness. Track cumulative token usage across agents. If approaching the budget limit, rescope remaining work or ask the user for guidance.

Step 3: Decompose the Task

3a. Load Agent Registry

Load the agent registry before decomposing. Read .mission-control/settings.md if not already loaded in Step 1. The full registry consists of built-in agents from this plugin plus any custom agents from the project settings file.

Built-in agents:

Always use the exact subagent_type value shown above when spawning built-in agents. This ensures each agent runs with the correct tool permissions and isolation settings defined in its agent file. In particular, mission-control:implementer must be used for all implementation tasks — it is the only agent type that runs in an isolated git worktree.

Custom agents from .mission-control/settings.md extend (never replace) the built-in agents. Each custom agent maps to one of the four core subagent_type values: Explore, Plan, Bash, or general-purpose. Never apply the mission-control:* prefix to custom agents — only built-in agents have registered agent files under that namespace.

Output the merged registry, including the exact subagent_type to use for each agent:

AGENT REGISTRY
---------------------------------------------------------------------
Built-in:
  mission-planner  → mission-control:mission-planner
  researcher       → mission-control:researcher
  implementer      → mission-control:implementer  (isolated worktree)
  reviewer         → mission-control:reviewer
  retrospective    → mission-control:retrospective
Custom:
  [agent-name]     → [subagent_type from settings]  (or "none")
---------------------------------------------------------------------

3b. Select Planning Depth

Choose the planning depth based on task size:

If skip depth is selected, bypass the rest of the orchestration workflow. Execute the change directly with tools. For all other depths, continue.

Reference references/task-decomposition.md for dependency graph construction, parallel grouping, critical path identification, and Kahn's algorithm for topological ordering.

3c. List Subtasks

List all subtasks now in dependency order. For each subtask, produce a task card:

TASK [ID]: [Name]
  Agent Type:     [mission-planner / researcher / implementer / reviewer / retrospective / <custom-type>]
  Deliverable:    [What this task produces]
  Dependencies:   [Task IDs that must complete first, or "none"]
  Risk Tier:      [0-3]
  File Ownership: [Specific files this agent owns, or "read-only"]
  Model:          [haiku / sonnet / opus]

Rules for task cards:

• Every task must have exactly one agent type.
• File ownership must not overlap between concurrent tasks. If two tasks need the same file, they must be sequential.
• Implementation tasks must depend on their corresponding research tasks.
• Reviewer tasks must depend on the implementation they review.
• Tasks with no dependencies form the first wave and launch in parallel.

3d. Identify Waves

Group tasks into execution waves based on dependencies:

EXECUTION PLAN
---------------------------------------------------------------------
Wave 1 (parallel): Task 1, Task 2, Task 3, Task 4   [no dependencies]
Wave 2 (sequential): Task 5                          [depends on Wave 1]
Wave 3 (parallel): Task 6, Task 7                    [depends on Task 5]
Wave 4 (sequential): Task 8                          [depends on Wave 3]
Wave 5 (sequential): Task 9                          [depends on Wave 4]
---------------------------------------------------------------------
Critical path: Task 1 -> Task 5 -> Task 7 -> Task 8 -> Task 9

Step 4: Select Orchestration Pattern

4a. Choose a Pattern

Select the pattern that best fits the mission's structure:

1. Fan-Out / Fan-In — Multiple independent queries, then synthesize results. Use when: several independent research queries, searching across different areas, running independent analyses.

Orchestrator
  |-- Agent A (area 1) --\
  |-- Agent B (area 2) ---+-> Synthesize
  \-- Agent C (area 3) --/

2. Pipeline — Sequential stages where each output feeds the next. Use when: natural ordering exists (research -> plan -> implement -> validate).

Agent A -> Agent B -> Agent C -> Final Output
(research)  (plan)    (implement)

3. Explore-Then-Act — Deep exploration phase, then focused action. Use when: unfamiliar codebases, complex bugs, refactoring where understanding must precede changes.

Explore agents (parallel) -> Orchestrator decides -> Action agents

4. Competitive — Multiple agents attempt the same task with different approaches; pick the best. Use when: algorithm design, performance optimization, uncertain best approach.

Orchestrator
  |-- Agent A (approach 1) --\
  |-- Agent B (approach 2) ---+-> Evaluate & Select
  \-- Agent C (approach 3) --/

5. Iterative Refinement — Implement, review, fix loop until quality threshold is met. Use when: code review cycles, documentation quality, complex implementations needing validation.

Agent A (implement) -> Agent B (review) -> [issues?] -> Agent A (fix) -> Agent B (re-review)

6. Supervisor with Workers — Persistent supervisor delegates to short-lived workers. Use when: many small subtasks across files, project-wide refactoring, batch operations.

Supervisor (persistent)
  |-- Worker 1 (file A) -> done
  |-- Worker 2 (file B) -> done
  |-- Worker 3 (file C) -> done
  \-- ... continues until all complete

7. Adaptive Retry — Automatic retry with escalated model on failure. Wraps any of the above patterns. Use when: retryOnFailure is true in settings. Applied automatically when an agent fails.

Agent A (haiku) -> [fail] -> Agent A' (sonnet) -> [fail] -> Agent A'' (opus) -> [fail] -> Escalate to user

Reference references/orchestration-patterns.md for detailed examples of each pattern.

4b. Choose Execution Mode

Select the execution mode based on mission characteristics:

Default to agent-team mode. Only use standalone subagents for trivial fan-out of 2-3 read-only research agents where no coordination is needed. Only use direct tools for skip planning depth.

State your pattern and execution mode choice explicitly:

ORCHESTRATION
---------------------------------------------------------------------
Pattern:        [Pattern name]
Execution Mode: [direct / standalone / agent-team / agent-team+messaging]
Rationale:      [One sentence justification]
---------------------------------------------------------------------

Step 5: Create Team & Launch Agents

Execute this step NOW. Do not describe what you plan to do. Act.

5a. Create the Team

Use TeamCreate to establish the team:

TeamCreate(team_name: "<mission-name>", description: "<brief mission description>")

Name the team after the mission goal (kebab-case, descriptive).

5b. Create Tasks with Dependencies

Use TaskCreate for every subtask from Step 3. Set up dependencies with TaskUpdate(addBlockedBy) to enforce execution order.

5c. Spawn All Independent Agents in ONE Message

Identify every task with no dependencies (Wave 1). Spawn agents for ALL of them in a single message. Do not spawn them one at a time.

For each agent, write a self-contained prompt that includes:

1. Role context — "You are a [agent type]: [description from registry]."
2. Exact file paths — Specific files to search, read, or modify.
3. Task specification — Precisely what to find, implement, or validate.
4. Expected output format — What the deliverable looks like (report, code, review verdict).
5. Constraints — Forbidden actions, file ownership boundaries, risk tier.
6. Task management — "Claim your task via TaskUpdate when starting. Mark it completed when done."

Choose the right model per agent:

• haiku — Simple searches, running commands, straightforward tasks.
• sonnet — Moderate complexity, most implementation work (default).
• opus — Complex reasoning, architecture decisions, security review.

For Tier 1+ tasks, spawn a reviewer agent AFTER the implementation agent completes. Never spawn implementer and reviewer for the same work simultaneously.

5d. Save Mission State

Save the mission state to .mission-control/missions/active.json. Include the mission scope, risk tier, task graph, pattern, settings, and current status. This enables session recovery if the conversation is interrupted.

{
  "id": "mission-<timestamp>",
  "name": "<mission name>",
  "goal": "<goal>",
  "status": "active",
  "createdAt": "<ISO-8601>",
  "updatedAt": "<ISO-8601>",
  "scope": { ... },
  "settings": { ... },
  "pattern": "<pattern>",
  "riskTier": <tier>,
  "tasks": [ ... ],
  "log": [],
  "playbook": "<playbook name or null>"
}

Standalone Subagent Fallback

Only skip team creation for trivial fan-out of 2-3 read-only research agents where no coordination is needed. In that case, launch standalone Task calls without team_name.

Example Team Launch

TeamCreate(team_name: "preferences-feature", description: "Add user preferences page")

TaskCreate(subject: "Find auth patterns", ...)
TaskCreate(subject: "Find routing config", ...)
TaskCreate(subject: "Find theme implementation", ...)
TaskCreate(subject: "Find i18n config", ...)

[Spawn 4 agents in ONE message — all with no dependencies]
Task(team_name: "preferences-feature", name: "researcher-auth", subagent_type: "mission-control:researcher", ...)
Task(team_name: "preferences-feature", name: "researcher-routing", subagent_type: "mission-control:researcher", ...)
Task(team_name: "preferences-feature", name: "researcher-theme", subagent_type: "mission-control:researcher", ...)
Task(team_name: "preferences-feature", name: "researcher-i18n", subagent_type: "mission-control:researcher", ...)

Step 6: Monitor & Adjust

6a. Track Progress

Use TaskList to check team progress after each wave. Teammates send messages when they complete tasks or need help.

6b. Produce Checkpoint Reports

After each wave completes, produce a checkpoint report:

CHECKPOINT REPORT
---------------------------------------------------------------------
Wave:              [Current wave number]
Tasks Completed:   [IDs and names]
Tasks In Progress: [IDs and agents]
Tasks Blocked:     [IDs -> Blocker -> Next Action]
Budget Burn:       [Tokens used / estimated total]
Risk Updates:      [New risks discovered during execution]
Decision:          CONTINUE | RESCOPE | STOP
Rationale:         [Why this decision]
---------------------------------------------------------------------

6c. Adaptive Execution

Apply these adjustments in real time:

1. Agent failure. If an agent fails its task and retryOnFailure is true:

   • Retry attempt 1: Escalate model (haiku -> sonnet, or sonnet -> opus) if escalateModelOnRetry is true. Otherwise retry with same model and a refined prompt.
   • Retry attempt 2+: Escalate model again if not already at opus. Refine the prompt with additional context from the failure.
   • After maxRetries exhausted: Mark task as blocked, report to user, recommend action.

2. Task too complex. If an agent reports the task exceeds its scope:

   • Split into 2-3 smaller subtasks with tighter file ownership.
   • Assign new agents and update the task graph.

3. Agent stalled. If an agent produces no meaningful output:

   • Send a status check message via SendMessage.
   • If still unresponsive, spawn a replacement agent with a clearer prompt and mark the original as abandoned.

4. Drift detection. If completed work diverges from the success metric:

   • Rescope immediately. Do not continue on a divergent path.
   • Update the mission scope and remaining tasks.

6d. Launch Next Waves

After each wave, identify tasks whose dependencies are now satisfied. Spawn agents for all newly unblocked tasks in a single message. Use TaskUpdate to assign owners and update status.

6e. Save Checkpoint to Mission State

After each checkpoint, update .mission-control/missions/active.json with current progress: task statuses, completed artifacts, log entries, and timestamp.

Step 7: Close Out

7a. Merge Findings

When all tasks are complete:

1. Collect deliverables from every agent.
2. Merge findings into a coherent result. Do not dump raw agent outputs.
3. Resolve conflicts between agent outputs — if two agents disagree, evaluate evidence and pick the better-supported conclusion.
4. Identify gaps — if critical work is missing, spawn follow-up agents before closing.

7b. Produce Completion Summary

COMPLETION SUMMARY
---------------------------------------------------------------------
Planned Outcome:     [From Step 1]
Achieved Outcome:    [What actually got delivered]
Artifacts:           [Files created/modified with full paths]
Key Decisions:       [Important choices made during execution]
Validation Evidence: [Test results, review outcomes, manual verification]
Open Risks:          [Unresolved issues or technical debt]
Follow-Ups:          [Work items for future sessions]
Lessons Learned:     [Reusable patterns or anti-patterns discovered]
---------------------------------------------------------------------

Present this summary to the user as the final deliverable.

7c. Extract Learnings

If autoLearn is enabled in settings:

1. Spawn a retrospective agent to analyze the completed mission.
2. The retrospective agent examines: which patterns worked, which failed, what the root causes were, which models were right for which tasks, and what prompt patterns produced good results.
3. Save extracted learnings to .mission-control/memory/ as tagged markdown files.
4. Each learning file uses this format:

---