/mission-brief

name: mission-brief
description: Use when a mission brief must become verified work end to end — brief, then specify, clarify, plan, implement, verify, converge in one lane-carrying DAG with Default plus Speckit, Superpowers, Matt, and Addy lanes.

mission-brief

> **Scope rule**: scripts stay skill-local — never source a script from another skill. For another skill's operations, invoke that skill (e.g. `architect-clarify`, `product-clarify`, `team-boot`) via the Skill tool; for its documents, follow the `Requires` line. `scripts/` and `references/` below are relative to this skill. `{REPO_ROOT}` denotes the project root (where `.adlc/` lives).

**Requires:** the `factory-runbook` skill (provides the publish procedure and run contracts): `adlc-cli skills add tikalk/adlc-team-skills --skill factory-runbook`.

In a local session — you answer the gates

When `ADLC_RUN_ID` is not set, a person is in this session, and nothing else will answer a gate. The agentic-container runtime that relays gates to Slack exists only in a runner pod.

1. **A paused run is your turn, not the end of the mission.** When `adlc-cli workflow run` or `resume` exits with the run paused at a gate (`run_paused`, `status: paused` in `adlc-cli workflow state show <run_id>`), ask the person the gate's question and options. Then run `adlc-cli workflow resume <run_id> --input <verdict_input>=<answer>` and keep going. Never end your turn on a paused run that nobody was asked about. 2. **Every gate that approves MRs is followed by a step that opens them.** A `gate` whose message promises MRs/PRs is followed by a `publish` step: `run-branch.sh` and `open-mr.sh` for each repository the change touches, writing `mr_url` (`mr_urls` for more than one). Only then comes the write-back step, so the completion comment links real MRs. A gate with nothing after it to act on its answer is a plan defect; fix the plan before you start the run. 3. Before ending your turn, the run is `completed`, `failed` or aborted, or it is paused at a gate the person has been asked about.

What this skill does

`mission-brief` owns the mission lifecycle end to end as one DAG: it turns the mission's brief into a spec whose acceptance criteria each answer yes or no, into an ordered plan, into tested code, into a converge verdict — judged against the brief, never against the implementer's claims. It works under the shared executor contract (invoke the `factory-runbook` skill; contract at `references/executor.md` in that skill): the `brief` step emits the Mission Brief draft per `references/mission-brief-template.md`; `specify` reads `brief.md` and emits a draft; `clarify` reads `spec.md` and emits a decision; `plan` reads `spec.md` plus the clarify decision and emits `plan.md`; `test` reads `spec.md` and emits an `artifact-ref`; `code` reads that `test` artifact plus `spec.md` and `plan.md`; `verify` reads the `test` and `code` artifacts and emits severity-ranked findings; `converge` reads `brief.md` and emits one verdict of `DONE`, `CONTINUE`, or `SPEC_CORRECTION_NEEDED`. A `SPEC_CORRECTION_NEEDED` verdict routes to the owning clarify gate, never to code.

The lane-carrying sections below keep one pointer per framework lane; the lane prose lives in its own home and is linked, never duplicated here. Lane resolution is a session instruction (Phase 0), never a script or table lookup.

Lane routing

The single lane table is `references/lane-routing.yml` (data, not prose): the five resolvable lanes (`embedded`, `speckit`, `superpowers`, `matt`, `addy`) and the seven lifecycle steps with their `output_type`/`reads_from` contract. Every resolvable lane has a section below; a lane without a section here can never be resolved.

Framework lane detection (Phase 0 — session-LLM instruction)

There is no detector script and no precedence table to run. In the brief step, inspect the well-known install paths yourself and disclose what you found in the brief:

1. Inspect the installed skill packs via the Skill tool (distinctive names: `*speckit*`, `*superpowers*`, `*addy*`, `*matt*`, `*pocock*`). 2. Inspect the plugin entries (the agent registry's plugin list — superpowers-style plugin installs live outside the skills dirs). 3. Check `specify` CLI availability (`specify --help` on PATH). 4. Look at repo usage hints (framework-native artifacts: specs dirs, plans dirs, spec-linked issues) — but a hint is never selection evidence on its own.

Resolution: the installed framework wins; usage hints among installed frameworks break ties only. Usage hints with no installed framework disclose and fall back to Default. Write the outcome into the brief exactly as:

`Framework lane: <lane> (<evidence>)`

where `<lane>` is one of `embedded`, `speckit`, `superpowers`, `matt`, `addy`, and `<evidence>` names what was inspected (`installed:<pack>`, `plugin:<entry>`, `specify-cli`, `usage hints <paths>, not installed`, or `default`).

Default lane (embedded)

Default lane built into this skill.

1. Read the intake: in a factory run the issue ref, otherwise the spec description from arguments. Write the Mission Brief per `references/mission-brief-template.md`: Goal, Constraints, Non-Goals, Success Criteria with a measurement method each, plus the `Framework lane` disclosure. 2. Restate every success criterion as a binary, measurable outcome — each one answers a yes/no question through a command that exits, an artifact that exists, or a diff that shows the change. 3. Write `spec.md`: outcome, constraints, non-goals, acceptance criteria, and out of scope. Each acceptance criterion stays traceable to the success criterion it restates. Specify never selects technologies and never plans files; those belong to the plan and code steps. 4. Surface any criterion that cannot be measured and any constraint that conflicts with another; do not paper over either in prose. 5. Resolve each surfaced item at the clarify phase — ask the person in a gated run, or in autonomous mode rec