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."
allowed-tools: "[]"
category: ai-agents-and-harness
source_repo: athola/claude-night-market
source_path: "plugins/attune/skills/mission-orchestrator/SKILL.md"
source_url: https://github.com/athola/claude-night-market/blob/HEAD/plugins/attune/skills/mission-orchestrator/SKILL.md
---

## Table of Contents

- [Overview](#overview)
- [When to Use](#when-to-use)
- [Mission Lifecycle](#mission-lifecycle)
- [Interactive Plan Review](#interactive-plan-review)
- [Mission Types](#mission-types)
- [Phase-to-Skill Mapping](#phase-to-skill-mapping)
- [Session Recovery](#session-recovery)
- [Module Reference](#module-reference)
- [Related Skills](#related-skills)
- [Related Commands](#related-commands)
- [Exit Criteria](#exit-criteria)


# 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 |

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 |

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

## Session Recovery

Missions persist state to `.attune/mission-state.json`. On resume:

1. Load mission state file
2. Validate referenced artifacts still exist on disk
3. Identify last completed phase
4. Continue from next phase in sequence

See `modules/mission-state.md` for the state schema and recovery protocol.

## Interactive Plan Review

The plan-to-execute transition uses an interactive
review loop instead of a simple checkpoint. Plans are
reviewed section by section, revised based on feedback,
and must pass a mandatory war-room gate before execution.

**Key capabilities:**

- Section-by-section terminal review (architecture
  first, then phases)
- Approve/revise/reject verdicts with rationale
- Plan version tracking with diff summaries
- Context improvement from structured feedback
- Additive bias scanning before user review
- Maximum 3 revision rounds before forced decision
- Mandatory war-room approval with Prosecution Counsel

See `modules/plan-review.md` for the full protocol.

### Review Modules

- **plan-review.md**: Main orchestrator for the review loop
- **plan-versioner.md**: Version tracking and diff generation
- **feedback-collector.md**: Verdict capture and JSON output
- **context-injector.md**: Revision prompt construction
- **iteration-governor.md**: Round tracking and escalation

## User Directive Overrides

The orchestrator parses the user's command-args and
free-text at mission start for natural-language trust
signals. Phrases like "ignore scope guard", "ultrathink",
"don't keep asking", and "be autonomous" are recognized
as directive overrides that adjust the constraint
profile without requiring an explicit
`--constraints=` flag.

Directive overrides win over mission-type defaults but
never bypass the Safety Floor (pre-commit hooks,
proof-of-work evidence, destructive-operation
confirmation, external-facing actions). When a directive
is detected, the orchestrator acknowledges it once at
mission start and stops asking for the corresponding
checkpoints. Repeated approval-seeking after a directive
override is itself a workflow bug.

See `modules/adaptive-constraints.md` "User Directive
Override" section for the parsing table.

## Mission Charter

Define mission boundaries using the structured template from
`references/mission-charter.md`. A Mission Charter specifies:

- **Outcome**: What success looks like
- **Success metric**: Measurable completion criteria
- **Deadline**: Time boundary (session, date, or duration)
- **Constraints**: Token/time budgets, forbidden actions
- **Scope**: In-scope and out-of-scope areas
- **Stop criteria**: Conditions that halt the mission

See `references/mission-charter.md` for the full template and
examples.

## Progress Reports

Track progress with structured checkpoints using
`references/progress-report.md`. Generate reports at:

- Phase boundaries (between brainstorm→specify→plan→execute)
- Blocker identification
- Risk escalation
- Budget thresholds (50%, 75%, 90%)

See `references/progress-report.md` for the template and
checkpoint rhythm guidance.

## Module Reference

### Core modules (always loaded)

- **mission-types.md**: Type definitions, auto-detection logic,
  custom types
- **state-detection.md**: Artifact existence checks, quality
  validation, staleness
- **phase-routing.md**: Phase execution protocol, transition
  hooks, error handling
- **mission-state.md**: State schema, persistence, recovery
  protocol

### Plan-review modules (load when plan phase runs)

- **plan-review.md**: Interactive section-by-section review
  with bias scanning
- **plan-versioner.md**: Version tracking and diff summaries
- **feedback-collector.md**: Verdict capture and feedback files
- **context-injector.md**: Revision prompt construction from
  feedback
- **iteration-governor.md**: Round tracking, cap enforcement,
  escalation

### Conditional modules (load only when triggered)

- **reflexion-buffer.md**: Cross-session learning buffer; load
  when iteration count > 1 or after a failed revision round.
- **trust-tier.md**: Constraint-profile classifier; load when
  a user directive override is detected at mission start.
- **adaptive-constraints.md**: Constraint adaptation rules;
  load alongside `trust-tier.md` when directive overrides are
  active.

## Module Loading by Mission Type

This skill declares `progressive_loading: true`. To keep the
orchestrator's resident token cost minimal, load only the
subset of modules each mission type actually needs. The
orchestrator itself loads only the four core modules at
mission start; the rest are loaded on-demand when their
phase runs.

| Mission type | Core | Plan-review | Reflexion | Trust and adaptive |
|--------------|------|-------------|-----------|------------------|
| `quickfix` (execute only) | yes | -- | -- | if directive |
| `tactical` (plan -> execute) | yes | yes | if revising | if directive |
| `standard` (specify -> plan -> execute) | yes | yes | if revising | if directive |
| `full` (brainstorm -> specify -> plan -> execute) | yes | yes | yes | if directive |

Token cost (approximate, computed from `wc -w` on hub +
loaded modules and converted at ~1.3 tokens per word):

| Mission type | Loaded modules | Approx tokens |
|--------------|----------------|---------------|
| `quickfix`   | hub and core (4) | ~4,100 |
| `tactical`   | hub, core, and plan-review (9) | ~6,900 |
| `standard`   | same as tactical (9) | ~6,900 |
| `full`       | hub, core, plan-review, and reflexion (10) | ~7,900 |

The previous load-all pattern brought in roughly 10,100
tokens for every mission, including `quickfix` runs that
only need the execute phase. With per-type loading, quickfix
is ~60% lighter and the standard / tactical / full paths
save 22-32%.

When a directive override fires, the trust-tier +
adaptive-constraints pair adds ~2,200 tokens on top of the
mission-type baseline.

## Reference Modules

- **mission-charter.md**: Structured mission definition
  template (load only when defining a charter)
- **progress-report.md**: Checkpoint status report template
  (load only when emitting a progress report)

## Related Skills

- `Skill(attune:project-brainstorming)` - Brainstorm phase
- `Skill(attune:project-specification)` - Specify phase
- `Skill(attune:project-planning)` - Plan phase
- `Skill(attune:project-execution)` - Execute phase
- `Skill(attune:war-room-checkpoint)` - Risk assessment for RED/CRITICAL tasks
- `Skill(leyline:risk-classification)` - Task risk classification
- `Skill(leyline:damage-control)` - Error recovery during phases

## Related Commands

- `/attune:mission` - Invoke this skill
- `/attune:mission --resume` - Resume from saved state
- `/attune:mission --type tactical` - Override mission type

## Exit Criteria

- All phases in mission type completed successfully
- Artifacts exist for each completed phase
- Mission state saved to `.attune/mission-state.json`
- Risk summary generated (tier counts across all tasks)
- No unresolved errors or blockers

---

**Source:** [`athola/claude-night-market`](https://github.com/athola/claude-night-market) → `plugins/attune/skills/mission-orchestrator/SKILL.md`