/mission-orchestrator

name: mission-orchestrator
description: Orchestrates full project lifecycle by auto-detecting state and routing to the correct phase. Use when starting or resuming a project mid-workflow.
alwaysApply: false
category: workflow-orchestration
tags:
- mission
- orchestrator
- lifecycle
- full-cycle
- automation
dependencies:
- attune:project-brainstorming
- attune:project-specification
- attune:project-planning
- attune:project-execution
- attune:war-room-checkpoint
- attune:war-room
- leyline:risk-classification
- leyline:damage-control
- leyline:additive-bias-defense
- imbue:justify
- imbue:vow-enforcement
- abstract:friction-detector
tools: []
provides:
  workflow:
  - mission-lifecycle
  - state-detection
  - phase-routing
  - session-recovery
  - reflexion-buffer
  - trust-tier
  - adaptive-constraints
usage_patterns:
- full-cycle-development
- mission-resume
- phase-routing
complexity: advanced
estimated_tokens: 600
progressive_loading: true
modules:
- modules/mission-types.md
- modules/state-detection.md
- modules/phase-routing.md
- modules/mission-state.md
- modules/plan-review.md
- modules/plan-versioner.md
- modules/feedback-collector.md
- modules/context-injector.md
- modules/iteration-governor.md
- modules/reflexion-buffer.md
- modules/trust-tier.md
- modules/adaptive-constraints.md
references:
- references/mission-charter.md
- references/progress-report.md
role: entrypoint

Mission Orchestrator

Overview

Wraps the entire attune development lifecycle (brainstorm → specify → plan → execute) into a single mission with automatic state detection, type selection, and phase routing. Follows the "persistent presence lens" pattern from `spec-kit:speckit-orchestrator`: delegates entirely to existing skills via `Skill()` calls, never re-implements phase logic.

When To Use

• Starting a new project from scratch (full lifecycle)
• Resuming an interrupted project workflow
• Running a focused tactical implementation from existing specs
• Quick-fixing from an existing implementation plan

When NOT To Use

• Running a single phase directly (use `/attune:brainstorm`, `/attune:specify`, etc.)
• Non-project work (code review, debugging, research)
• When you need fine-grained control over phase transitions

Mission Lifecycle

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

Mission Types

| Type | Phases | Auto-detected When | |------|--------|--------------------| | `full` | brainstorm → specify → plan → execute | No artifacts exist | | `standard` | specify → plan → execute | `docs/project-brief.md` exists | | `tactical` | plan → execute | `docs/specification.md` exists | | `quickfix` | execute | `docs/implementation-plan.md` exists | | `review` | scope → investigate → verify → report | the request names existing software to audit, dogfood, or review |

`review` is the one type selected from request intent rather than from artifacts, because a tree of build artifacts looks the same whether the ask is "ship this" or "audit this". Its check runs first. It produces `reports/<topic>-<YYYY-MM-DD>.md` and never enters the war-room gate, which guards a plan-to-execute transition a review mission does not have.

See `modules/mission-types.md` for full type definitions and custom type support.

Phase-to-Skill Mapping

| Phase | Skill Invoked | Artifact Produced | |-------|--------------|-------------------| | brainstorm | `Skill(attune:project-brainstorming)` | `docs/project-brief.md` | | specify | `Skill(attune:project-specification)` | `docs/specification.md` | | plan | `Skill(attune:project-planning)` | `docs/implementation-plan.md` | | execute | `Skill(attune:project-execution)` | Implemented code and tests |

Review missions route to the existing review skills rather than to attune phase skills:

| Phase | Skill Invoked | Artifact Produced | |-------|--------------|-------------------| | scope | `Skill(pensive:tiered-audit)` | Tier selection and bounded scope | | investigate | `Skill(imbue:feature-review)` plus the `pensive:*` domain lenses | Raw findings | | verify | `Skill(imbue:proof-of-work)` | Evidence references per finding | | report | `Skill(imbue:structured-output)` | `reports/<topic>-<YYYY-MM-DD>.md` |

The orchestrator **never** re-implements phase logic. Each phase is a complete `Skill()` invocation that handles its own workflow.

Delegation During a Mission

Missions delegate execution by default. `Skill(conjure:delegation-core)` governs the decision, and its default posture is on: a phase that reaches execution work hands it to an external CLI without waiting to be asked.

| Phase | Delegates | Why | |-------|-----------|-----| | brainstorm | No | Reasoning; the Keep Local clause holds | | specify | No | Reasoning | | plan | No | Reasoning | | execute | Yes, per task | Task execution is the eligible half | | scope, investigate, verify, report | Report and verify only | Findings are judgment; bulk extraction is not |

The split follows conjure's own line: delegate execution, retain reasoning. A mission phase that is entirely judgment stays local and does not consult the delegator at all.

Two outcomes need handling rather than reporting:

• `fallback_reason` is `providers_exhausted`: no CLI answered. Say which

were tried, then hand the task to a subagent on the session's mod