mission-control

namespace	aiwg
name	mission-control
platforms	["all"]
description	Orchestrate multi-loop background operations via the Mission Control dashboard — start sessions, dispatch missions, monitor, and stop

Mission Control

You orchestrate multi-loop background operations using the Mission Control dashboard.

Triggers

Alternate expressions and non-obvious activations (primary phrases are matched automatically from the skill description):

• "mc start" / "mc dispatch" / "mc status" → Mission Control operations shorthand
• "background this" → dispatch as background mission
• "war room" for multi-task coordination → Mission Control session

Trigger Patterns Reference

Pattern	Example	Action
Background tasks	"run these tasks in the background"	Start session + dispatch
Parallel orchestration	"orchestrate X and Y in parallel"	Start session + dispatch each
Monitor loops	"monitor background tasks"	aiwg mc status or aiwg mc watch
Start session	"start a mission control session"	aiwg mc start
Check status	"how are the background tasks doing?"	aiwg mc status --json
Stop missions	"stop background work"	aiwg mc stop

Behavior

When triggered:

1. Determine intent:

   • Starting new background work → aiwg mc start + aiwg mc dispatch
   • Checking on existing work → aiwg mc status
   • Stopping work → aiwg mc stop

2. For new background orchestration — Mission Control has a four-step lifecycle: start → dispatch → run → status. Missions stay queued until mc run launches them as ralph loops; status syncs back to mc.session.json automatically when mc status or mc watch is called.

   Apply the LFD loop-control contract before dispatching long-running or eval-driven missions:

   • Give each mission a measurable completion criterion and at least one mechanical verifier; self-report is secondary evidence.
   • Declare hard limits for iterations, wall-clock, token/tool/spend budgets where the surface can observe them. Budget exhaustion stops the mission and emits a best-output report instead of continuing randomly.
   • Record the pre-change hypothesis, expected failure mode, distinguishing diagnostic, and structural variant for each retry cycle.
   • After flat/non-improving cycles, require a structurally different approach within the configured exploration quota.
   • For eval/holdout missions, expose only aggregate score/probe/status or VOID to workers; keep holdout answers and detailed lint diagnostics outside optimizer-readable mission output.

   # 1. Start a named session (creates the state file)
   aiwg mc start --name "Sprint 4 Construction"
   
   # 2. Dispatch missions (queues them — does NOT execute)
   #    --completion is REQUIRED; `mc run` will skip missions without one.
   #    --max-iterations N caps ralph iterations per mission (default: 10).
   #    Optional LFD hard stops: --max-total-tokens, --max-output-tokens,
   #    --max-tool-calls, --max-total-cost, --max-wall-clock-minutes,
   #    --exploration-quota.
   aiwg mc dispatch <session-id> "Fix auth service" --completion "npm test passes" --priority high --max-iterations 50 --max-total-tokens 50000 --exploration-quota 3
   aiwg mc dispatch <session-id> "Add pagination" --completion "all list endpoints paginated"
   aiwg mc dispatch <session-id> "Write integration tests" --completion "coverage > 80%" --max-iterations 25
   
   # 3. RUN — drains the queue by launching each mission as a detached ralph
   #    loop. Without this step missions sit in QUEUED forever (#1439).
   aiwg mc run <session-id>
   
   # 4. Monitor — `mc status` polls each ralph loop's session-state.json and
   #    syncs progress back to mc (queued → running → done|failed|aborted).
   aiwg mc status <session-id>
   aiwg mc watch <session-id>
   

3. For monitoring:

   # Dashboard view
   aiwg mc status
   
   # Machine-readable for agent orchestration
   aiwg mc status --json
   
   # List all sessions
   aiwg mc list
   

4. For lifecycle management:

   # Pause all running missions
   aiwg mc pause <session-id>
   
   # Resume paused session
   aiwg mc resume <session-id>
   
   # Stop (abort all)
   aiwg mc stop <session-id>
   
   # Stop (let running missions finish, cancel queued)
   aiwg mc stop <session-id> --drain
   

5. Report the result inline — summarize session state and mission progress.

Examples

Example 1: Parallel construction tasks

User: "Run these three features in parallel: auth fix, pagination, and test coverage"

Action:

aiwg mc start --name "Parallel Features"
aiwg mc dispatch <id> "Fix auth service" --completion "auth tests pass"
aiwg mc dispatch <id> "Add pagination to list endpoints" --completion "paginated responses"
aiwg mc dispatch <id> "Increase test coverage" --completion "coverage > 80%"

Response: "Started Mission Control session 'Parallel Features' with 3 missions queued. Use aiwg mc status to monitor progress."

Example 2: Check background progress

User: "How are the background tasks doing?"

Action:

aiwg mc status

Response: "Mission Control 'Parallel Features': 1/3 done, 2 running (auth fix complete, pagination at loop 3/10, coverage at loop 2/10)."

Example 3: Stop and clean up

User: "Stop the background tasks, let running ones finish"

Action:

aiwg mc stop <session-id> --drain

Response: "Draining session: 1 queued mission cancelled, 2 running missions will complete naturally."

Clarification Prompts

If the user's intent is ambiguous:

• "Would you like me to start a new Mission Control session, or check on an existing one?"
• "How many parallel missions should I dispatch? (detected: 3 tasks)"
• "Should I stop all missions immediately, or drain (let running ones finish)?"

References

• @$AIWG_ROOT/src/cli/handlers/mc.ts — Mission Control command handler
• @$AIWG_ROOT/docs/cli-reference.md — CLI reference
• @$AIWG_ROOT/agentic/code/frameworks/sdlc-complete/rules/self-maintenance.md — Self-maintenance rule