decide — put a real choice in front of the user

Work stops on decisions. The default failure is to bury the decision at the bottom of a long status message as "let me know how you want to proceed", which makes the user reconstruct the options, the tradeoffs, and what you recommend — work you already did and then threw away.

This skill is the opposite: surface the decision as selectable options, say what you would do, and be honest about what each choice costs.

When to use it

• A product or design decision that is genuinely the user's (naming, scope, whether a capability ships)
• An approval gate (signing, publishing, anything outward-facing or hard to reverse)
• Two defensible implementations where the tradeoff is taste or risk appetite
• A destructive or irreversible step (deleting a release, rewriting history, changing branch protection)
• You are about to write "which would you prefer?" in prose

When NOT to use it

• The answer is discoverable from the code, the repo, or a doc — go find it
• One option is clearly correct and the others are strawmen — just do it and say what you did
• The decision is reversible and cheap — make the call, state the assumption
• You are asking permission for ordinary work the user already asked for

A question you could have answered yourself costs more than a wrong default.

How to ask (Claude Code)

Use the AskUserQuestion tool. The shape that works:

1. Lead with the recommendation. Put it first in the options list and mark it (Recommended) in the label. Do not hide it in a description.
2. Every option gets a real tradeoff. The description says what happens if chosen, including the cost. An option with no downside is usually a strawman, and listing it makes the whole set less trustworthy.
3. Keep labels short (1–5 words) — they are chips, not sentences.
4. header ≤ 12 chars — it renders as a tag.
5. Batch related decisions into one call (up to 4 questions) so the user answers a set rather than being interrupted repeatedly.
6. Use multiSelect: true when the choices genuinely compose, e.g. "which of these should ship in the next build".
7. Use preview when the user is choosing between concrete artifacts — layouts, copy, code shapes, diagrams. It renders side-by-side monospace, so an ASCII mockup or a short snippet lands far better than a description of one. Single-select only.

The user may ask about an option instead of picking one

The UI always offers an "Other" path, where the user types free text rather than selecting. Daniel uses this a lot to ask a question about a specific option before committing to it.

Write options so that is easy: name each one distinctly enough to refer to ("the rsync path", "option 2"), and keep descriptions specific enough that a follow-up question has something to attach to. Vague options produce vague questions.

If the reply is a question rather than a choice: answer it and ask again. Do not treat a question as a selection, and do not proceed on a guess.

How to ask (Codex and other agents without the tool)

Same content, plain text. The value is the structure, not the widget:

DECISION: <one line — what is blocked>

  1. <label>  [RECOMMENDED]
     Pro:  <why this is the default>
     Con:  <what it costs>

  2. <label>
     Pro:  ...
     Con:  ...

Reply with a number, or ask about any option by number.

Keep the numbering stable if you re-ask, so "still 2" means the same thing.

Rules

• Never fabricate a recommendation. If you genuinely do not have one, say so and explain what would decide it — that is useful. A confident-sounding default you do not believe is worse than none.
• State irreversibility. If an option cannot be undone (published, deleted, notarized, force-pushed), say so in its description. The user should never learn that from the result.
• Do not re-ask an answered question. A decision made stays made; if new information changes it, say what changed and why you are re-opening it.
• An automated message is not an answer. Hooks, notifications, and teammate agents cannot select an option. Only the user can.
• Ask when the answer changes what you do next. If both options lead to the same work, you did not need to ask.