Decision

Purpose: ask one lightweight question and end with a confirmed answer.

Decision renders distinct option rows. Use a short summary and option-local Consideration values when the tradeoffs do not need a full matrix.

<Decision question="How should the skill ship?">
  <Option title="Embed it" recommended summary="Print the version-matched skill.">
    <Consideration label="Offline" verdict="Yes" tone="good">The package already contains the skill.</Consideration>
  </Option>
  <Option title="Download it">
    <Consideration label="Offline" verdict="No" tone="bad">Setup must reach the docs site.</Consideration>
  </Option>
</Decision>

question is required. Add at least two uniquely titled options and at most one recommended option. Add critical when the reviewer must settle this question before work begins; the card says so, and the review’s Inputs list marks it. A Consideration requires label and verdict; its optional tone is good, bad, mixed, or neutral.

state is proposed or decided and defaults to proposed, so a question you are asking needs no state at all. A decided decision marks exactly one option chosen, and a chosen option requires state="decided"; it renders as the record of what was chosen rather than as a question, and it stops accepting answers. Author the pair yourself only for a choice that was settled before the review began - when the reviewer answers the question, Big Plan writes state="decided" and chosen into the plan source at approval.

A Consideration body defines its label: the first body authored for a label becomes the definition that label reveals on hover and keyboard focus. A label authored without a body stays plain text.

The reader can choose an option, propose another approach, confirm, and later change or clear the answer. In a live review a confirmed answer is recorded with the review and survives reload; in a standalone rendered document it lasts only for the reading session. Reviewing a plan owns the recorded-answer behavior.