We stopped letting our best model write code.

---
name: mission
description: Plan a long-running multi-agent build as a Mission. Runs a structured interview, writes a validation contract, PRD, issue slices, reviews, and a fresh-session handoff. Plan-first only; execution is approval-gated.
argument-hint: "[mission goal] [--status|--resume <mission-dir>]"
---

# /mission

Plan a long-running agent Mission before any implementation starts. This command is intentionally plan-first: it builds the complete planning structure and artifacts, then stops at an approval/handoff boundary. Do not execute implementation work from this command.

**Global command.** It works in any project. The current working directory is the target repo. The deterministic gate lives in the standalone harness at `/Users/thebeast/mission-control-harness` and is called, never edited, by this command. Execution of an approved packet is a separate command: `/mission-continue`.

Arguments: `$ARGUMENTS`

## Core Doctrine

1. **Plan first, hard stop before execution.** The output is a reviewed planning packet, not code changes.
2. **Ambition is not the constraint.** A Mission may span 12 weeks or more. The constraint is context management: every stage, issue, worker task, validator pass, and handoff must fit a bounded Context Slice with enough evidence to judge it.
3. **Volume and context scope are different.**
   - Mission Volume = total duration, number of milestones, number of issues, and size of the desired outcome.
   - Context Slice = the bounded packet one agent can use for one decision, issue, implementation task, or validation pass.
   - Large Mission Volume is allowed. Oversized Context Slices are not.
4. **Use repo language.** Read the project's `CONTEXT.md` if present and challenge conflicting terms. If a term is resolved, update `CONTEXT.md` as glossary only, with no implementation details.
5. **Borrow proven planning rails.**
   - `grill-with-docs`: one-question-at-a-time interview; answer from codebase/docs instead of asking when possible.
   - `karpathy-spec`: write compact, verifiable requirements and a living spec.
   - `to-prd`: synthesize a real PRD after context is known.
   - `to-issues`: break the plan into vertical tracer-bullet issues.
   - GStack planning: decision briefs, adversarial review, engineering review, and stop points.
   - Orchestrator/worker/validator pattern: serial worker execution, validation contracts, fresh-context validators, structured handoffs, read-only internal parallelism.
   - The deterministic gate (`mission-control-harness`): packet validation plus an approval boundary; nothing executes past the gate without explicit approval.

## Model Routing Doctrine

Model versions and role mappings: /Users/thebeast/.claude/model-roster.json is the source of truth; the tables below are advisory and re-verified per docs/model-release-playbook.md.

Hide model mechanics from the user by default. The user should focus on vision, tradeoffs, interview answers, and approval gates. The Mission packet may record model/provider choices, but the interview should not require the user to understand those mechanics unless a cost, quality, privacy, or approval decision depends on them.

**Subscription-first, API-last.** Full backend cost order, capability table, GLM model family tiering (which GLM variant for which job), free-model scouting, and the escalation ladder all live in the shared doctrine at `/Users/thebeast/.claude/rules-on-demand/subscription-backend-routing.md` — read it before Phase 6 (path updated 2026-07-05: the old `rules/` location silently 404'd and a planning run fell back to Claude-only rosters — if this file is missing, STOP and find the doctrine, never write a roster without it). `long-running-harness` uses the identical file, so a credential or pricing update never has to be made twice. Record backend availability honestly in `AGENT_ROSTER.md` (Phase 6); never claim automatic routing without evidence (a live test call), per the required-tools stop rule.

The standing goal: **Fable 5 orchestrates; almost nothing else runs on Fable — and Claude tiers are not the default workers either.** Per `model-roster.json` `standing_policy`: the orchestrator (interview, spec, sharding, adversarial synthesis, final judgment) stays on the session model; **execution work routes to GLM by default** (GLM-5.2 validator-guarded implementation, GLM-4.7 lighter slices, GLM-4.7-Flash free bulk), Codex/GPT-5.5 reviews, Gemini handles all visual input. Claude Sonnet/Opus are the *escalation* tiers (validator failed twice, or architectural/high-stakes/one-way), not the starting assignment. A roster that puts a Claude tier on a worker slice must record why GLM was rejected for that slice. Mark `HITL` and stop for Desmond when the orchestrator can't resolve a stuck slice itself.

### Model tier + effort routing (token efficiency)

The table above picks the *backend* (vendor/product). This layer picks the *Claude tier + reasoning effort* for any Claude-backed role (orchestrator, reviewers, escalations — remember workers default to GLM, Layer A above), per `/Users/thebeast/.claude/rules-on-demand/agent-model-routing.md`. The objective is token efficiency, not speed: assign the cheapest model whose output will not need rework, because rework is double spend.

Casting call -- **Fable 5** is the architect (interview design, glossary pressure, validation-contract and spec authoring, sharding, adversarial synthesis, taste calls); **Opus** is the smart engineer (one hard *bounded* problem or deep single-problem research, no architectural taste); **Sonnet** is the journeyman builder (worker slices against a clear Context Slice + validation contract); **Haiku** is the eager apprentice (mechanical, specified, low-judgment auxiliary work -- fixtures, summaries, draft alternatives).

**Fable 5 usage boundary (from community cost testing, 2026-07):** Fable runs ~$10/$50 per million tokens -- 2x Opus, 5x Sonnet -- and independent task-level testing shows it earns that premium ONLY on long-horizon work: multi-day/multi-milestone planning, large cross-cutting refactors, frontier-difficulty bugs, and runs where one failed attempt costs more than the token delta. It does NOT pay off on routine agentic coding throughput -- Opus 4.8 at xhigh (or GPT 5.5 xhigh via the Codex subscription, which costs zero marginal tokens) matches it there at a fraction of the cost, and validator-guarded slices don't need it at all. Concretely in a Mission: Fable is justified for the interview/spec/sharding/adversarial-synthesis passes and nothing else; workers never get Fable; escalate a slice to Fable only after a stronger-engineer retry (GPT 5.5 or Opus) has already failed the validator. Where Fable is tempting but the problem is bounded, use Opus or GPT 5.5 instead; where it's mechanical, use Haiku or GLM 5.2.

Decision, in order: (1) if the slice is guarded by a mechanical validator/eval (the norm here, since every issue maps to a `VAL` assertion), route the worker **down and off-vendor** -- GLM-5.2 by default (GLM-4.7/GLM-4.7-Flash for well-specified low-judgment slices); Sonnet/Haiku only when GLM is unavailable or has failed the validator twice -- and escalate to Fable only where the slice needs design or architectural taste the `VAL` cannot express. Wiring tests-first (`/tdd`) into a slice is a cost lever: it lets a journeyman build correctly without an architect. (2) No eval -> rework double-spend test: high redo-risk (ambiguous, novel, design, cross-cutting) uses the stronger model once; low redo-risk uses the cheaper one. (3) Otherwise route by judgment-vs-mechanics. Effort is a second dial -- sometimes Fable-low beats Opus-max for a taste call, and mechanical work drops to low effort even on a small model.

Mechanism: the planning orchestrator stays on the session model (a strong architect is correct for the interview, spec, and reviews) and dispatches worker/validator slices **down** via the spawn `model` param. A session left on Fable 5 high is a ceiling, not a per-worker setting -- spend Fable only on architect-grade slices. Record the chosen tier + effort + a one-line justification (which branch fired) per role in `AGENT_ROSTER.md` alongside the backend capability table, so the Context Slice's cost profile is auditable.

## Artifact Layout

Classify Mission size before choosing artifact depth:

| Tier | Use When | Artifact Rule |
|---|---|---|
| Compact Mission | One small outcome, no execution backend changes, low risk | May combine `INTERVIEW.md`, `MISSION_CONTEXT.md`, `PRD.md`, and `EXECUTION_PLAN.md` into `MISSION.md`, but must still write `mission-state.json`, `VALIDATION_CONTRACT.md`, `ISSUES.md`, and `HANDOFF.md`. |
| Standard Mission | Multi-issue work or any future worker handoff | Use the full artifact layout. |
| Long Mission | Multi-week / multi-milestone / multi-backend work | Use the full artifact layout plus milestone sections and stricter Context Slice boundaries. |

Default to Standard Mission when unsure. Do not use Compact Mission for live business actions, data migrations, public UI launches, ads/CMS/social/customer communication, or backend dispatcher work.

Create artifacts under the target repo:

```text
docs/missions/YYYY-MM-DD-<mission-slug>/
  mission-state.json
  INTERVIEW.md
  MISSION_CONTEXT.md
  VALIDATION_CONTRACT.md
  PRD.md
  ISSUES.md
  EXECUTION_PLAN.md
  AGENT_ROSTER.md
  reviews/
    ADVERSARIAL_REVIEW.md
    ISSUES_VALIDATION.md
    ENG_REVIEW.md
  HANDOFF.md
```

If the directory already exists, resume from `mission-state.json`. Write `mission-state.json` before each phase starts ("write state before execute").

### `mission-state.json` Schema

Every `/mission` run must maintain this minimal state file:

```json
{
  "schema": "mission-state-v1",
  "mission_id": "YYYY-MM-DD-<mission-slug>",
  "created_at": "ISO-8601",
  "updated_at": "ISO-8601",
  "phase": "load_inputs|interview|context_gate|spec_prd|issues|execution_plan|adversarial_review|eng_review|handoff|awaiting_approval|blocked",
  "status": "active|context_needed|reviewing|awaiting_approval|complete|blocked",
  "mission_volume": { "duration_estimate": "string", "milestone_count": 0, "issue_count": 0 },
  "context_slices": [],
  "artifact_paths": {
    "interview": "INTERVIEW.md",
    "context": "MISSION_CONTEXT.md",
    "validation_contract": "VALIDATION_CONTRACT.md",
    "prd": "PRD.md",
    "issues": "ISSUES.md",
    "execution_plan": "EXECUTION_PLAN.md",
    "agent_roster": "AGENT_ROSTER.md",
    "handoff": "HANDOFF.md"
  },
  "reviews": { "adversarial": "pending|pass|blocked", "issues": "pending|pass|blocked", "eng": "pending|pass|blocked" },
  "open_questions": [],
  "blocked_reason": null
}
```

Resume behavior:

- `context_needed` resumes at Phase 1 interview.
- `reviewing` resumes at the first review with `blocked` or `pending`.
- `awaiting_approval` reports the handoff path and stops.
- `blocked` reports `blocked_reason` and asks whether to revise scope or stop.

Formal transition contract (the deterministic gate enforces this):

```text
load_inputs(active) -> interview(active|context_needed|blocked)
interview(active|context_needed) -> context_gate(active|context_needed|blocked)
context_gate(active) -> spec_prd(active|blocked)
spec_prd(active) -> adversarial_review(reviewing|blocked)
adversarial_review(reviewing) -> eng_review(reviewing|blocked)
eng_review(reviewing) -> issues(active|blocked)
issues(active) -> execution_plan(active|blocked)
execution_plan(active) -> handoff(active|blocked)
handoff(active) -> awaiting_approval(awaiting_approval)
awaiting_approval(awaiting_approval) -> terminal planning stop
blocked(blocked) -> interview(active) OR terminal stop after user decision
```

State-write rules:

- Write `mission-state.json` before every phase transition.
- Prefer atomic writes: write `mission-state.json.tmp`, then rename it to `mission-state.json`.
- If a temp state file exists on resume, read both files, prefer the newest valid JSON, and record the recovery decision in `MISSION_CONTEXT.md`.
- Do not use `status: "complete"` while approval is still pending. Planning packet completion is `phase: "awaiting_approval"` and `status: "awaiting_approval"`.

## Phase 0 -- Load Mission Inputs

1. Parse the goal from `$ARGUMENTS`.
2. If `$ARGUMENTS` is `--status` or `--resume`, read the target `mission-state.json` and report/resume from the current phase.
3. Read available context from the target repo (read each only if present): `CONTEXT.md`, `CLAUDE.md`, `AGENTS.md`, `README.md`, and any active spec or plan files the goal points at.
4. The deterministic gate is the standalone harness at `/Users/thebeast/mission-control-harness`. You do not edit it; you call it for validation (see Mission Packet Verification).
5. Preferred global planning skills (use if available): `grill-with-docs`, `karpathy-spec`, `to-prd`, `to-issues`.
6. Record assumptions, known constraints, and source files in `MISSION_CONTEXT.md`.

Missing-source behavior:

- Project-local sources are read **if present**; none are hard required except a writable `docs/` for output. Record which existed and which were absent.
- Global skill files are preferred references, not hard dependencies. If one is missing, use the embedded phase contract in this command and record the missing source.
- Never claim a source was read if it was missing, inaccessible, or skipped.

## Phase 1 -- Structured Interview

Use `grill-with-docs` rules:

- Ask one decision at a time.
- Include your recommended answer with every question.
- If the answer can be discovered from the repo, inspect the repo instead of asking.
- If the user uses a fuzzy term, propose a precise canonical term.
- If a user statement contradicts code/docs, surface the contradiction immediately.

Interview stages:

1. **Outcome:** What should exist when the Mission is done?
2. **Status quo:** What exists now, what hurts, and what must not break?
3. **Desperate specificity:** Who uses this, in what exact scenario, and what failure is unacceptable?
4. **Mission Volume:** How large can the calendar/task ambition be?
5. **Context Slices:** What are the safe bounded packets for planning, issues, worker tasks, validators, and handoffs?
6. **Validation contract:** What must be true before any code can be called done?
7. **Guardrails:** What is always allowed, ask-first, held, or never allowed?
8. **Fresh-session handoff:** What must a future execution agent know without reading the full chat?

Write each resolved answer to `INTERVIEW.md` and keep `MISSION_CONTEXT.md` updated.

## Phase 2 -- Context Sufficiency Gate

Before writing implementation issues, score the Mission for context readiness:

| Dimension | Points | Pass Signal |
|---|---:|---|
| Intent | 0-2 | The desired outcome and user-visible value are concrete. |
| Boundaries | 0-2 | Non-goals, held actions, and never-do actions are explicit. |
| Existing system | 0-2 | Relevant code/docs/data sources have been inspected. |
| Validation | 0-2 | Correctness is defined before implementation. |
| Context slices | 0-2 | Each planned worker/validator packet is bounded and reviewable. |
| Handoff | 0-2 | A fresh agent can resume from disk artifacts without chat history. |

Readiness threshold:

- 10-12: proceed to spec/PRD.
- 7-9: ask targeted follow-up questions before writing issues.
- 0-6: do not fake a plan. Keep interviewing and mark the Mission `context_needed`.

Record the score, evidence, and missing context in `MISSION_CONTEXT.md`.

## Phase 3 -- Write the Mission Spec and PRD

Use `karpathy-spec` posture: distinguish intent, requirements, tasks, and verification; use stable requirement IDs (`REQ-001`, ...); keep requirements verifiable; include stop-and-ask conditions; define baseline/metric/verify/guard/results-log for any optimization loop.

Then synthesize `PRD.md` using the `/to-prd` structure: Problem Statement, Solution, User Stories, Implementation Decisions, Testing Decisions, Out of Scope, Further Notes. Local artifact only — do not publish to an issue tracker from this command.

## Phase 4 -- Adversarial Review and Engineering Review (before issues)

> Reviews gate the **spec/PRD**, before issues are written, because issues are expensive to edit. (Reorder per `mission-control-harness` ADR-0002.)

**Adversarial review** -> `reviews/ADVERSARIAL_REVIEW.md`. Prefer a fresh-context reviewer; if unavailable record `independence: unavailable` and keep it advisory. Attack for: scope illusion (high Volume masquerading as a small Slice), missing validation assertions, hidden side effects/approvals/deploys/customer/ads/CMS/db risk, context loss over long execution, overlapping issue slices, missing rollback/evidence/handoff, and any violation of the gate's fail-closed boundary.

**Engineering review** -> `reviews/ENG_REVIEW.md`. Prefer Codex or a fresh subagent that did not write the packet. Inspect architecture, data flow, tool/lane permissions, state/resume model, edge cases, test strategy, browser/user-testing strategy when UI is involved, performance/cost budget, and serial-execution/parallelism model. If no fresh-context reviewer is available, mark `reviews.eng = "blocked"` and stop; do not call the packet approved.

Revise the spec until both reviews have no blocking findings. Review audit-trail rule: do not delete findings; each ends with `status: accepted|rejected|deferred|superseded` and a one-line rationale.

## Phase 5 -- Build Issues and Validate Issues (after reviews pass)

Build `ISSUES.md` using `/to-issues` tracer-bullet rules: each issue is a vertical slice; label `HITL` or `AFK`; record dependencies; attach covered `REQ` IDs and `VAL` assertions; include acceptance criteria.

Pre-flight clean-tree issues (the ISSUE-000 pattern) must never instruct a blanket commit of the dirty tree. The issue text must require: classify each dirty file's provenance per `~/.claude/rules-on-demand/clean-tree-before-work.md`, stage owned paths only, STOP on foreign WIP from parallel sessions, and record per-file provenance in the commit message plus a work-ledger entry. (Origin: Ranger 2026-06-08 ISSUE-000 re-baseline froze parallel-session WIP onto production — `9be163bc`/`2f3f8673`.)

Then run a mechanical issues check (formatting + link integrity) and write `reviews/ISSUES_VALIDATION.md`. This is a mechanical check, not a human review (per ADR-0003). It asserts: no vague-bucket issues; no unbounded repo scan to start; no hidden chat dependency; every issue maps to a real `REQ` and `VAL`; every AFK issue is self-sufficient; HITL issues name the exact decision needed.

## Phase 6 -- Draft Execution Plan and Agent Roster

Write `EXECUTION_PLAN.md` and `AGENT_ROSTER.md`. Execution roles: Mission Orchestrator (owns plan state, prevents drift), Worker Agent (one Context Slice -> one issue -> structured handoff), Scrutiny Validator (fresh context: spec compliance, tests, typecheck, guardrails), User Testing Validator (fresh context: live behavior when relevant), Handoff Validator (blocks if the handoff is insufficient).

Execution rules: serial by default; parallelize only read-only research/search/static-review/independent validators; structured worker handoffs (completed, undone, files touched, commands+exit codes, issues found, next slice); validators never share worker context; every milestone ends with validation. `AGENT_ROSTER.md` must include the backend capability table:

```text
| Backend | Pricing basis | Intended role | Available now? | Evidence checked | Fallback |
|---|---|---|---|---|---|
| Claude (session) | Subscription | Interviewer / plan writer | yes/no | <how checked> | <fallback> |
| Codex (GPT 5.5) | Subscription (ChatGPT) | Engineering reviewer / validator / hard bounded problems | yes/no | <how checked, e.g. `~/.codex/auth.json` auth_mode> | <fallback> |
| GLM-5.2 + GLM-4.7 (Z.ai Coding Plan) — the two workhorses, see `subscription-backend-routing.md` | Subscription | Worker (GLM-5.2 default) / cheap auxiliary (GLM-4.7, GLM-4.7-Flash) | yes/no | <how checked, e.g. `ZAI_API_KEY` present + test call against api.z.ai/api/anthropic/v1/models> | Cursor Composer, then Sonnet |
| Gemini (`gemini` MCP) | Subscription/API, connected | All visual/multimodal work — GLM-5.2 tested blind on images 2026-07-04, never route vision to it | yes/no | `claude mcp list` shows `gemini ... Connected` | <fallback> |
| Cursor Cloud Composer | Subscription | Worker fallback | yes/no | <how checked> | <fallback> |
| Hermes / OpenRouter (paid) | Metered API (last resort) | Cheap auxiliary / worker trial only when nothing above fits | yes/no | <how checked, e.g. `OPENROUTER_API_KEY` present> | <fallback> |
| mission-control-harness | n/a | Safety / gate | yes/no | <how checked> | <fallback> |
```

Do not claim automatic routing unless `Available now? = yes` with evidence. If unknown, write procedural fallback instructions in `HANDOFF.md`.

## Phase 7 -- Write Fresh-Session Handoff

Write `HANDOFF.md` a fresh agent can use directly: mission goal + approval state; artifact index; requirements summary; validation contract summary; issue list + dependency order; agent roster + execution rules; exact next command or next human approval; what not to do; known blockers and open questions.

End with a clear stop:

```text
STOP: Planning packet complete. Do not execute implementation until the user approves this Mission packet and starts a fresh execution session with HANDOFF.md.
```

## Mission Packet Verification

Run the deterministic validator from the global harness against the packet you just wrote:

```sh
pnpm --dir "/Users/thebeast/mission-control-harness" mission:validate --mission <absolute-path-to-docs/missions/YYYY-MM-DD-slug>
```

Exit `0` = the packet is complete and clean. Non-zero = fix the reported issues and re-run. The validator asserts: `mission-state.json` parses and uses `schema: "mission-state-v1"` with a valid phase/status pair; required artifacts exist; `VALIDATION_CONTRACT.md` defines stable `VAL` IDs; every issue maps to a real `REQ` + `VAL`; `AGENT_ROSTER.md` has the backend capability table; `HANDOFF.md` has the STOP line + a fresh-session next step; redaction classes hold (verified public business facts marked as such are allowed; customer PII, secrets, credentials, SQL/tool params, and outbound message bodies are blocked); late phases are rejected if any review gate is not `pass`.

## Completion Report

Report: Mission folder path; artifact list; context sufficiency verdict; blocking findings if any; whether `CONTEXT.md` was updated with glossary-only terms; next recommended action (normally: review the packet, then run `/mission-continue <mission-dir>` after approval).

Do not commit, push, publish issues, deploy, run ads/CMS/customer/social actions, or start implementation from `/mission`.

## Continuation

`/mission` plans only. Approved execution runs through **`/mission-continue <mission-dir>`** (a separate global command).

Boundary rule:

- `/mission --resume <mission-dir>` resumes planning only.
- `/mission-continue <mission-dir>` resumes approved execution only.
- If a Mission is `awaiting_approval`, `/mission --resume` reports the approval boundary and stops. It must not execute the handoff.

---
name: mission-continue
description: Execute an approved Mission packet one Context Slice at a time, gated. Reads HANDOFF.md, runs the next issue, requires a structured handoff, validates, then stops at the next boundary. Approved execution only.
argument-hint: "<mission-dir> [--approve] [--issue ISSUE-###]"
---

# /mission-continue

Execute an **already-approved** Mission packet, one issue at a time, with a hard gate between slices. This is the execution half of the Mission workflow; `/mission` is the planning half. Plan -> approve -> `/mission-continue` builds it piece by piece, checking each piece, until done.

**Global command.** Works in any project. The deterministic gate lives at `/Users/thebeast/mission-control-harness` and is called, never edited.

Arguments: `$ARGUMENTS` — the Mission directory (e.g. `docs/missions/2026-06-05-foo`), plus optional `--approve` and `--issue ISSUE-###`.

## Hard boundaries (never cross without explicit approval)

- Do not run a single implementation step until approval is confirmed (see Step 1).
- Do not commit, push, deploy, publish issues, send customer/CMS/social/ads actions, spend money, rotate credentials, or touch any path outside the target repo without a separate explicit approval in the current turn.
- One issue per slice. Never load the whole Mission into a worker. Never skip the gate between slices.
- If anything is ambiguous or a gate fails twice, STOP and report. Do not improvise past a failed gate.
- **Never blanket-commit a dirty shared worktree as a pre-flight "re-baseline".** A dirty tree at slice start is other sessions' in-flight work. Classify every dirty file per `~/.claude/rules-on-demand/clean-tree-before-work.md`, stage ONLY paths the issue owns, and STOP on foreign WIP (check `docs/long-running-harness/*/handoff.md` and `docs/missions/*/mission-state.json` mtimes for the owning session). Any re-baseline commit must list per-file provenance in its message and get a work-ledger entry. (Origin: Ranger 2026-06-08 ISSUE-000 froze a parallel session's WIP onto prod — `9be163bc`/`2f3f8673`; see the repo rule `.claude/rules/no-blanket-rebaseline-commits.md` where one exists.)

## Step 1 — Confirm approval

1. Read `<mission-dir>/mission-state.json`.
2. Proceed only if **either** `status: "awaiting_approval"` **and** the user passed `--approve` (or gave explicit approval this turn), **or** the Mission is already mid-execution (`phase: "execution"`, see below) and resuming.
3. If `status` is anything else (e.g. still planning, `blocked`, or `awaiting_approval` with no `--approve`), report the approval boundary and **stop**. Do not execute. This mirrors the harness rule: a fresh run never auto-executes; approval is a deliberate, separate act.

## Step 2 — Load the approved packet

Read, in this order: `HANDOFF.md`, `EXECUTION_PLAN.md`, `ISSUES.md`, `VALIDATION_CONTRACT.md`, `AGENT_ROSTER.md`, and the project's `CONTEXT.md`/`CLAUDE.md`/`AGENTS.md` if present. Do not read the original planning chat — the packet is the source of truth.

## Step 3 — Pick the next issue (dependency order)

- If `--issue ISSUE-###` was given, use it (but refuse if its dependencies are not yet complete).
- Otherwise select the first issue whose dependencies are all complete and whose status is not done, in the dependency order from `EXECUTION_PLAN.md`.
- If every issue is complete, jump to Step 8 (milestone/Mission completion).

## Step 4 — Build exactly one Worker Context Slice

Assemble the bounded packet for this one issue and nothing more:

- the issue text + its acceptance criteria,
- its covered `REQ-###` and `VAL-###` (pull the exact text from `PRD.md` / `VALIDATION_CONTRACT.md`),
- the allowed files/surfaces and the validation command(s),
- the structured-handoff template (Step 6).

Routing: dispatch to the worker backend named in `AGENT_ROSTER.md` **if its capability row says `Available now? = yes`**. Backends dispatchable today without an adapter: (a) **Codex / GPT 5.5** (ChatGPT subscription) via the `codex` MCP or CLI — engineering-review/validator slices and hard bounded problems, kept independent from the GLM worker deliberately (see `subscription-backend-routing.md` § Why Codex stays the reviewer); (b) **Claude tier down-routing** via the Agent-spawn `model` param (Sonnet for validator-guarded worker slices, Haiku for mechanical ones) — never run a worker slice on the session model just because it's set; (c) **GLM-5.2 + GLM-4.7 (Z.ai Coding Plan)**, the two workhorses, dispatchable by spawning `claude` with `ANTHROPIC_BASE_URL=https://api.z.ai/api/anthropic` + `ANTHROPIC_AUTH_TOKEN=$ZAI_API_KEY`; pick the tier per `/Users/thebeast/.claude/rules-on-demand/subscription-backend-routing.md` (GLM-5.2 default worker, GLM-4.7/GLM-4.7-Flash for mechanical/bulk slices) and confirm the credential with a test call first, recording honestly if absent; (d) **Gemini** (`gemini` MCP, already connected) — the ONLY backend for visual/multimodal input in a slice (screenshots, mockups, design review); never route an image to GLM-5.2, which was tested blind on solid-color images 2026-07-04. Order: subscription and free backends always before metered API. On stuck/unexpected (not a plain validator miss): escalate to the orchestrator to re-scope, and to a `HITL` stop for Desmond if it needs a human decision — never silently work around a surprise. Otherwise execute the slice in-session (single-backend) and record that fallback. (Remaining dispatch adapters — Cursor/Hermes — are a later slice; do not fake automatic routing.)

## Step 5 — Execute the slice

Implement only this issue. Make the smallest coherent change that satisfies its acceptance criteria. Do not touch other issues' surfaces. Do not expand scope.

## Step 6 — Require a structured worker handoff (before any validation)

The worker must produce, in writing, before a validator runs:

```text
- Completed work:
- Unresolved work:
- Files touched:
- Commands run (with exit codes):
- Issues / surprises discovered:
- Next Context Slice:
```

If the handoff is missing any field, treat the slice as incomplete and stop.

## Step 7 — Gate the slice (fresh context where possible)

Run, in order, and record results:

1. **Scrutiny validation** — spec compliance, tests, typecheck, project guardrails. Use the project's own commands (e.g. `tsc --noEmit`, the test runner, `git diff --check`). Prefer a fresh-context validator that did not write the slice.
2. **User-testing validation** when UI/behavior is involved (browser flow, form, screenshot, API smoke).
3. **Packet re-validation** — confirm the Mission packet is still internally consistent:
   ```sh
   pnpm --dir "/Users/thebeast/mission-control-harness" mission:validate --mission <absolute-mission-dir>
   ```

Gate rule: if any check fails, mark the issue blocked, write the reason into the Mission state, and **stop** with the failure. Do not advance. If a fix is obvious and in-scope, apply it and re-run the gate once; a second failure stops the run for the user.

## Step 8 — Update state and stop at the next boundary

- Write `mission-state.json` before and after each slice (atomic temp-write-then-rename). Track per-issue completion (e.g. in `EXECUTION_PLAN.md` or an execution log under the mission dir).
- After a passing slice, **stop at the next boundary**: end of a milestone, a `HITL` issue needing a user decision, a blocked gate, or all-issues-complete. Report what was done, what's next, and the exact command to continue.
- On full completion: report the Mission complete, list every issue + its gate evidence, and state the final verified outcome. Do not auto-commit/push/deploy — surface that as the user's explicit next action.

## What this command does not do yet (deferred slices)

- Automatic dispatch adapters for Cursor Composer and Hermes / OpenRouter workers — until those exist, such slices run single-backend in-session with the fallback recorded. (Codex, Claude tier down-routing, and GLM-family-via-env are dispatchable now; see Step 4.)
- Per-slice cost/turn budget enforcement.
- A control-plane dashboard.

These are tracked as the Mission Control Plane "later waves"; see `/Users/thebeast/mission-control-harness/docs/reference/mission-control-plane-design.md`.

# The /mission skill — planning + gated execution for Claude Code

These are the two real command files we run in production, unedited. `/mission` plans a
long-running multi-agent build into a reviewed, approval-gated packet; `/mission-continue`
executes it one bounded Context Slice at a time with validators between slices.

This is the system behind the eval in the launch post: Fable 5 orchestrates, cheap
validator-guarded workers execute (GLM-4.7 tied GLM-5.2 3/3 first-pass at ~18× less than
a flagship worker seat, measured 2026-07-05).

## Install (~2 minutes)

1. Copy both files into your Claude Code commands directory:
   ```
   mkdir -p ~/.claude/commands
   cp mission.md mission-continue.md ~/.claude/commands/
   ```
2. In any repo: `/mission <what you want built>` → answer the interview → review the packet.
3. After you approve: `/mission-continue <mission-dir> --approved`.

## What you WILL need to adapt (~15 minutes, honest notes)

These files reference infrastructure from our machine. Each is optional — the workflow
degrades gracefully — but you should know what's ours:

- **`/Users/thebeast/mission-control-harness`** — our deterministic packet validator
  (`mission:validate`). Without it, skip the validator step or replace it with your own
  checks; the artifact structure is fully described in `mission.md` Phase 7.
- **`/Users/thebeast/.claude/rules-on-demand/subscription-backend-routing.md`** and
  **`model-roster.json`** — our model-routing doctrine (which backend runs worker slices).
  Replace with your own table in `AGENT_ROSTER.md`, or just use Claude tiers via the
  Task/Agent tool's `model` param.
- **GLM workers** — we dispatch cheap workers through z.ai's Anthropic-compatible endpoint
  (needs their Coding Plan + `ZAI_API_KEY`). Entirely optional: Sonnet workers work fine,
  they just cost more.
- **`~/.claude/rules-on-demand/clean-tree-before-work.md`** — our dirty-git-tree triage
  rule. The principle it encodes: never blanket-commit a dirty tree at mission start;
  classify every file first.

Names/paths aside, the core is portable: interview → validation contract → PRD →
tracer-bullet issues → adversarial + eng review → HANDOFF with a hard approval boundary →
sliced execution with fresh-context validators.

## License / provenance

Shared free by Truline (Desmond Landry) as part of a build-in-public campaign, 2026-07-05.
Use it, adapt it, ship with it. Attribution appreciated, not required.