[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:

Load mission state file
Validate referenced artifacts still exist on disk
Identify last completed phase
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 -> ex

mission-orchestrator

Como adicionar

Cole no README do seu repo

Skills relacionadas

MoneyPrinterTurbo

weather-svg-creator

asana-automation

payment-integration

Receba novas skills de Automação toda segunda

Table of Contents