mission-orchestrator

Table of Contents

• Overview
• When to Use
• Mission Lifecycle
• Interactive Plan Review
• Mission Types
• Phase-to-Skill Mapping
• Delegation During a Mission
• Session Recovery
• Module Reference
• Related Skills
• Related Commands
• 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
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 do the task in the mission itself. This is the ordinary path on a machine with no CLI installed and it does not fail the phase.
• fallback_reason is delegation_disabled: the operator declined. Do the task locally and do not offer to re-enable it.

To run a whole mission without external models, set CONJURE_DELEGATION=off before invoking it.

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
review (scope -> investigate -> verify -> report)	yes	--	if revising	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
• Skill(conjure:delegation-core) - Default-on delegation of execution work

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)
• Execute-phase work either delegated or held back by a named Keep Local clause, never skipped for want of a delegation decision
• Any providers_exhausted result completed locally and reported with the providers it tried
• No unresolved errors or blockers