authoring-acceptance-probelisted

# Authoring an Acceptance Probe **Render before asking.** Before any AskUserQuestion, render the decision context as assistant chat text. Content that exists only in a Read result, a subagent/Agent return, or the question/option strings **does not count as rendered** (the UI shows a compact card) — restate it in chat first. A probe is the smoke-test contract that proves wiring works end-to-end. Without one, a task cannot be dispatched in 2.0 — `dispatching-task-loop` refuses to run a task whose `acceptance_probe:` is missing or empty. So **authoring the probe is part of authoring the task**, not an optional polish step. ## When This Applies - During `/ship-sprint` Step 3 (task decomposition), as you write each task file. - During `/ship-quick` scoping, before dispatching the change. - During `/ship-bug` fix authoring — the probe is the regression scenario. - During `/ship-discuss` *only* if the discussion produces a task spec ready to enter the backlog with a probe. If a task is genuinely too speculative to author a probe for, that task isn't ready for execution. Either refine until it is, or mark it `kind: research` (no probe needed; deliverable is a findings doc). ## The Authoring Question Ask exactly this: > **"What single shell command, run from a clean state against the merged change, would print observable evidence that the wiring works?"** If you cannot answer that question in one sentence, the acceptance criteria are too vague. Refine the criteria first, then