prompt-engineering.si
Decisions

Decision-making prompts: compare options without outsourcing judgment

A decision prompt should help you inspect options and assumptions. It should not manufacture certainty or imply that a model knows your priorities better than you do. Define the decision, the feasible alternatives, and what would make the recommendation change.

Frame the actual decision

“Should we launch?” hides several possibilities: launch to everyone, pilot with a small group, reduce scope, or wait for a specific condition. State the alternatives and the deadline. Include “do nothing for now” when it is a real option.

Separate hard constraints from preferences. A legal restriction or an unavailable dependency is not just another score in a weighted average. If an option violates a hard constraint, the model should flag it before comparing benefits.

A decision brief you can reuse

Decision: [what must be decided, by whom, and by when]
Options: [feasible alternatives, including waiting if appropriate]
Hard constraints: [non-negotiable conditions]
Criteria: [what matters, with priorities if known]
Evidence: [verified facts and estimates, clearly separated]

Compare options in a table: expected benefit, downside, reversibility, evidence gaps, and dependency. Do not invent numerical probabilities or weights.
Recommend a provisional next step, give the strongest objection, and state what new evidence would reverse the recommendation. Separate facts, assumptions, and value judgments.

“Provisional” matters because a sensible choice can change when a critical assumption changes. The reversal condition makes that dependency explicit rather than treating consistency as a virtue in itself.

Worked case: a product rollout

In a fictional rollout, the team can support 20 pilot customers, has not tested one payment path, and can roll back within an hour. A full launch and a pilot do not carry the same downside or learning value. Ask the model to surface those distinctions instead of generating a generic pros-and-cons list.

A useful answer might recommend a pilot conditional on excluding the untested path. But that answer is only acceptable if the exclusion is technically possible and the team can monitor failures. The human reviewer must verify those prerequisites.

A reversal condition could be: “If the pilot cannot isolate the payment path, postpone until the path is tested.” This converts a vague preference for caution into an actionable rule.

Ask for a challenge that could actually matter

“Play devil’s advocate” often produces generic objections. Ask instead: “Which assumption is both uncertain and important enough to change this decision?” Then identify a cheap way to test it.

Another useful prompt is: “Describe one plausible failure that our current plan would detect too late.” This focuses attention on monitoring and feedback. It should lead to a concrete safeguard, owner, or stop condition, not merely a longer risk list.

Keep accountability with the decision maker

Before accepting a recommendation, check whether the options were genuinely feasible, the criteria reflected your priorities, and the evidence was current. Review any invented scores or unjustified confidence language. A beautifully formatted matrix can still encode a poor decision frame.

Record the decision and the evidence available at the time. Later, compare the process with the outcome without assuming that a lucky result proves sound reasoning. Use the evaluation guide to improve the prompt itself across repeated decisions.

Keep going