Mission orchestrator
Skill athola/claude-night-market/plugins/attune/skills/mission-orchestrator
23 Claude Code plugins: TDD enforcement hooks, git/PR workflows, spec-driven development, code review, project lifecycle, fix-from-error, maintenance automation, context optimization, research, and multi-LLM delegation. 186 skills, 128 commands, 54 agents.
npx -y skills add athola/claude-night-market --skill mission-orchestratorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
Orchestrates full project lifecycle by auto-detecting state and routing to the correct phase. Use when starting or resuming a project mid-workflow.
SKILL.md
11.2 KB, as published. Nobody here has run it
Table of Contents
- Overview
- When to Use
- Mission Lifecycle
- Interactive Plan Review
- Mission Types
- Phase-to-Skill Mapping
- 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 |
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.mdwhen 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 phaseSkill(attune:project-specification)- Specify phaseSkill(attune:project-planning)- Plan phaseSkill(attune:project-execution)- Execute phaseSkill(attune:war-room-checkpoint)- Risk assessment for RED/CRITICAL tasksSkill(leyline:risk-classification)- Task risk classificationSkill(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