Decide

Skill Generous-Corp/pulp/.agents/skills/decide

Ask Daniel a blocking decision as options with a recommendation and honest pros/cons, rather than prose. Use whenever work is blocked on a judgment call, a product decision, an approval, or a choice between approaches — instead of writing "let me know which you prefer" at the end of a message.From its SKILL.md

Install

npx -y skills add Generous-Corp/pulp --skill decide

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.6 KB, as published. Nobody here has run it

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:

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.
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.
Keep labels short (1–5 words) — they are chips, not sentences.
header ≤ 12 chars — it renders as a tag.
Batch related decisions into one call (up to 4 questions) so the user answers a set rather than being interrupted repeatedly.
Use multiSelect: true when the choices genuinely compose, e.g. "which of these should ship in the next build".
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.