---
name: decision-ask
description: Format any message that asks your principal for an action, approval, choice, ruling, or decision. Load before composing the ask, even when it does not look like a formal decision.
---

# Decision Ask

<trigger>
Load this skill BEFORE composing any message in the REAL bucket below. The five-part ask format and fail-closed pre-send check apply only to: spend (quota resets, paid renders, purchases); external sends (anything posted, emailed, or messaged outside the machine other than the standing digest channels); security-control edits (hooks, guards, sandbox, credentials); restarts and service acts the agent may not perform; and your principal's reserved categories (consent, taste, identity surfaces). For everything else, use the Decide and notify contract below. Do not draft first and retrofit the format afterward.
</trigger>

<real_bucket>
The REAL bucket is: spend (quota resets, paid renders, purchases); external sends (anything posted, emailed, or messaged outside the machine other than the standing digest channels); security-control edits (hooks, guards, sandbox, credentials); restarts and service acts the agent may not perform; and your principal's reserved categories (consent, taste, identity surfaces).
</real_bucket>

<source_rule>
The owner's own words, on the form she wants asks delivered in:

> "When decisions are needed, I need context (3-5 sentences of what is happening and what I would observe, in plain english), question (in plain english), options (in plain english, describing how I would experience the given option, and also the pros and cons of each options), your recommendation, and, if needed, anything else you need from me."
</source_rule>

<format>
Use these parts in this order for each ask:

1. `CONTEXT`: three to five plain sentences explaining what is happening, defining unfamiliar names, and saying what your principal would observe.
2. `QUESTION`: one direct plain-English question.
3. `OPTIONS`: every real option, including defer or do nothing when real. For EACH option state how your principal would experience it, then its pros and cons.
4. `RECOMMENDATION`: one recommendation with the decisive reason. Do not hide the recommendation in context.
5. `NEEDED FROM YOU`: the exact answer, action, or input needed. This part is required for every ask.

One message may contain multiple asks, but each item independently carries all five parts. A title, card number, file path, command, or internal label never substitutes for an explanation.
</format>

<pre_send_gate>
For a REAL-bucket ask, before sending, check the actual message against every line below:

- Is the premise verified, and is the item still unanswered?
- Are all five parts present and in order?
- Is `CONTEXT` three to five sentences and understandable to a reader joining cold?
- Is `QUESTION` an actual question sentence?
- Does EACH option say what your principal would experience plus its pros and cons?
- Is there a clear recommendation?
- Does `NEEDED FROM YOU` state the exact response or action?

Any `NO` means FAIL: do not send, post, publish, or relay the ask. Rewrite it and run the complete check again. Passing a template or mentioning all five labels is insufficient if any part lacks its required substance.
</pre_send_gate>

<decide_and_notify>
## Decide and notify

For EVERYTHING ELSE, the agent decides, executes when ready, and sends ONE line naming what was delivered, in your principal's plain-language style, with a revert line naming the command or commit to undo it.

The bar: deliver real parity and real functionality, not the conservative or hedged version of what was asked for.

Before sending the notify line, check:

- Does the delivered thing match the sources at full parity?
- Does it actually work end to end, observed rather than represented by a flag?

If either answer is `NO`, do not send the line. Continue the work until the delivered thing passes both checks. An ask drafted on work that is already built or already decided is a defect; do the work instead of re-asking.
</decide_and_notify>

<boundaries>
Preserve your principal's words verbatim when quoting a ruling. Keep evidence strength attached to claims. This skill formats an ask; it does not create authority, make the decision, authorize a live action, or revive an already answered question.
</boundaries>

<record_rule>
When your principal answers an ask with a letter, number, or single word, the record of that ruling (scratch note, log, handoff doc, or status file) carries the enumerated options she chose among, verbatim as presented, in the same line or row, so the ruling is auditable without needing the original conversation transcript.
</record_rule>

<commit_ask_rule>
Any ask that would authorize a commit (to code, to a published document, to a live configuration) carries three things, never a change count and an assumed pass: (1) the actual diff at a named path on disk, byte-identical to what would be committed; (2) a plain-language reading of that diff, hunk by hunk, saying what each change does and what your principal would notice; (3) the verifier-fail branch, stating what happens if an independent check fails after the approval is given. An approval given on a description whose artifact later changes is not an approval on the new artifact; re-ask with the new diff.
</commit_ask_rule>