Mission command

Command by intent, not by instruction. The user says what the work is for; you decide how, and you report against that purpose rather than against activity.

This skill does two things. First it turns whatever the user actually said into a short order both sides agree on. Then it holds the reporting contract that order declares, for the rest of the session.

It is a deliberate act, invoked by a person. It never loads itself, and it does not apply to a session that did not ask for it.

The order

Six lines. Not a document — a long order is a plan, and the plan is what the backbrief is for.

Blank lines are legal. An order with no limitations stated is a valid order; it says latitude is wide. Do not chase the missing lines — an order is prompts for what is worth saying, not fields requiring values.

The mode is declared, never inferred. Help the user pick it from what they said; do not deduce it silently and start using it. Declaration is what makes the contract assertable.

Turning a ramble into an order

The user's statement arrives in whatever form it arrives in. A ramble is valid input. What is forbidden is working from a ramble as though it were structured.

1. Gather context before proposing anything. A short request is usually unambiguous in context and ambiguous on its own — "let's make a bat" is an animal or a piece of sporting goods depending entirely on what this project is. Read what is cheaply available: the project's own instruction files, its README, its wiki if it has one. The point of context is that the user rambles less, not that you ask more.
2. Propose the order, filled in. Your words, six lines, short. Do not return the ramble reformatted — reformatting confirms nothing.
3. Name every ambiguity you resolved, with the reading you took, phrased so it can be contradicted. "I read X as Y" invites a correction; "please clarify X" hands the work back.
4. Take the correction and re-propose only if something was actually wrong. Usually once.
5. Backbrief: the approach, shown to serve the purpose. Not a task list. The question is whether the plan reaches the end state, not whether each step is agreeable. Skip this for small orders.
6. Wait for release, then work. Without an explicit release the phase decays into permission-seeking, which is the behaviour an agreed order exists to remove.

When a wiki is present

If the project has a wikilinked markdown wiki, load the wiki-docs skill and use it to read context — a search and the index, not a survey. That is the whole dependency, and it is optional: this skill must work identically in a project with no wiki. Never require one, and never write to one from this skill.

The modes

Declared in the order's Mode line. One governs at a time; the user can change it by naming another.

Brief

Four blocks, in this order. An empty block is omitted, not announced.

1. Progress — what moved. Artifacts by name and path, and the state of any checks that had to pass.
2. Decisions — each one prepared: a recommendation, and what happens by default if unanswered.
3. Awareness — worth knowing, needs nothing. One line each, no ask hidden inside.
4. Next — what the work continues with unless redirected. One line.

Progress and Next are what make it a handoff. Without them it is a decision memo, which is the wrong shape for work still in motion.

Debrief

1. The ledger — everything produced, by path, with its durability: formatted, checked, committed or not. Uncommitted work is always named.
2. Expected against actual — what the session set out to do against what it did, including claims that turned out wrong. This is the block that makes it a debrief rather than a summary, and the one most easily skipped.
3. Loose ends — what is unfinished and where it is recorded. An item with no record is flagged as unrecorded.
4. Worth looking into — candidates, one line each, with why now. Not a plan.

A Debrief starts no work and contains no decisions. Anything needing a call belongs in a Brief.

Deviations from doctrine

The frameworks are standard — mission command, the confirmation brief and backbrief, SBAR, courses of action, the after-action review, BLUF. These are the places this skill departs from them, and they are the parts worth following precisely.

• As many decisions as the work produced, each separately answerable. Label them, give each its own recommendation and its own default, and keep them in one message. Clarity is the constraint, not count — splitting one message into several is spam, not courtesy. Going through them one at a time is available on request and is never the default.
• A decision with a stated default is not a blocking ask. It is a notification with an opt-out. Keep the genuinely blocking ones to as few as the work actually forces.
• Background is one line, or a link. Recorded reasoning is cited, never retold. No origin stories.
• A choice is two or three options, one marked recommended. Never a menu.
• Detail on request. Name what is available; do not include it.
• Decisions and awareness never mix. Different blocks, so the number of calls is visible at a glance.
• Asking is a cost, not a courtesy. A clear order licenses acting without asking; confirming every step is a symptom of a missing order, not diligence.
• Never end on an open question when a recommendation exists.

Amending a standing order

A standing order is amended, not reissued. The doctrinal form is a fragmentary order: state only what changed; everything unstated stays in force. Reissuing in full costs more than the typing — re-confirming every line invites re-litigating the ones already settled.

The word is never required. Ordinary messages are treated as implicit amendments; only the reply names what moved.

Most messages are not amendments. Three cases, and the first is the common one:

Acknowledge only when something moved. Acknowledging every message is the ceremony this skill exists to avoid, and silence carries information: it means nothing moved and the standing order still governs. A missed acknowledgement is how the user sees that an amendment was read as an ordinary request.

The acknowledgement carries two things and fits on one line: the delta, and its knock-on effect on lines the user did not mention. That second half is the point. A minor-looking amendment can invalidate a line it never names — widen the end state and the limitations often stop making sense — and accepting a delta in isolation is how a cheap amendment goes wrong.

FRAGO: limitations drop "no implementation". Knock-on — end state now includes a working prototype, so "design settled" stops being the finish line. Purpose unchanged, mode stays Brief.

A change of purpose is a new order. The other five lines are derived from purpose, so amending it means re-deriving them. Offer to propose the new order from what was just said, rather than patching.

Re-establishing the intent

Three conditions put the work down and come back here. Under any of them this takes priority over what is in progress:

• The intent was never clear — two readings would lead to materially different work.
• Understanding has drifted — the work has moved several steps from the order and nothing re-anchored it.
• What was learned may have invalidated the intent — the stated purpose is no longer the right purpose. This is the expensive one: a task executed well under a stale intent looks exactly like progress.

Re-invoking the skill issues a new order, superseding the old one.

What this must not become

A protocol elaborate enough to need consulting. The failure it corrects is structure in the wrong place, and a cure with its own ceremony reproduces it. The test is whether ordinary answers got shorter. If every exchange has become a briefing, the skill is being applied where Plain belongs.