aiwg-mission

What this skill does

# AIWG Mission

You are launching (or participating in) an **AIWG Mission** — AIWG's dynamic, durable, audited agent orchestration. A Mission decomposes a goal into worker cycles, runs them toward a measurable completion criterion, and aggregates the result, while AIWG owns the bookkeeping and gates regardless of which agent stack each worker runs on.

This is an **AIWG-specific kernel capability**. On Codex it surfaces as `/aiwg-mission`, deployed by AIWG to `~/.codex/prompts/` — it is **AIWG-owned**, not the plugin-provided `/workflow` an arbitrary Codex install may or may not have (`/workflow` is not a core Codex primitive — see `.aiwg/research/provider-workflow-integration.md`).

## Mission vs Flow vs in-stack primitive

- **Mission** (this skill) = *dynamic* orchestration. The shape emerges at run time from the goal. Cross-stack capable.
- **Flow** = a *pre-established* declarative YAML sequence (`flow.aiwg.io/v1`); use `aiwg discover` to find a matching Flow before improvising a Mission.
- **In-stack primitive** (Codex `/goal`, Claude's Workflow tool) = orchestrates *within one stack's process/turn*. A Mission may dispatch workers **to** these; they do not replace the Mission conductor.

## When this fires

Natural-language triggers:

- "launch a mission" / "start an AIWG mission"
- "orchestrate this across agents"
- "fan this out to several agents and aggregate"
- "spawn workers to do X until Y"
- "run a long unattended orchestration"
- "coordinate Codex and Claude agents on this" (cross-stack — see #1546)

Non-triggers (route elsewhere):

- A single focused task → just do it (no orchestration overhead; see `god-session` / `subagent-scoping`).
- A pre-established repeatable sequence → find the **Flow** via `aiwg discover` (e.g. `flow-release`, `flow-deploy-to-production`).
- An in-session "iterate until condition" on one stack → the provider-native `/goal` (Codex, Claude Code) already routes for that (#1451/#1469).
- "Address open issues" → the `address-issues` skill (which may itself run as a Mission).

## How to run a Mission

1. **State the completion criterion measurably** (per the `vague-discretion` rule). "good enough" is not a criterion; "all tests pass and CI green", "score ≥ 85", "every flagged finding verified" are. If the user's goal is vague, extract a checkable criterion first.

2. **Right-size + decompose.** Break the goal into independently-verifiable worker cycles (`subagent-scoping`). Decide single-stack vs cross-stack:
   - **Single-stack** (default): workers run on the current stack. Use this stack's native primitive for in-session fan-out where available; otherwise AIWG's external loop.
   - **Cross-stack** (#1546): when the operator wants heterogeneous stacks (e.g. Claude conductor → Codex workers), dispatch worker cycles to executors advertising the target `stack:<name>` capability via AIWG's `serve` executor-registry. The conductor stays AIWG-owned.

3. **Dispatch.** For durable/detached/unattended Missions use AIWG's external route (`aiwg mc dispatch` / `ralph-external`) so the Mission survives the session ending. For in-session orchestration, the native primitive may drive the *mechanism* — but AIWG still owns everything in step 4.

4. **Retain ownership (non-negotiable, identical across stacks).** Whatever drives the worker mechanism, AIWG owns:
   - activity-log entries (per the `activity-log` rule)
   - issue-thread comments / progress
   - human-authorization + threat gates (per `human-authorization`)
   - best-output selection across cycles
   - crash-resilient checkpoint/resume (durability)
   - reproducibility + cost tracking

5. **Converge + report.** Run cycles until the completion criterion is met (with a `max-cycles` escape hatch), select the best output, and report what each worker did and the aggregated result. Apply the anti-laziness recovery protocol (PAUSE→DIAGNOSE→ADAPT→RETRY→ESCALATE) rather than abandoning on failure.

## Discover before improvising

Before hand-rolling a Mission, run `aiwg discover "<the goal>"` — a curated Flow or skill may already exist (the `skill-discovery` rule). A Mission is for genuinely *dynamic* orchestration where no pre-established Flow fits.

## References

- `.aiwg/architecture/adr-workflow-routing.md` — routing + cross-stack amendment
- `.aiwg/research/provider-workflow-integration.md` — why Codex `/workflow` is not core (#1535)
- #1534 (epic), #1544 (this command), #1546 (cross-stack Missions), #1536 (Missions/Flows naming)
- `aiwg mc` (mission-control) — the durable dispatch surface