---
name: decision-prompt-three-lines
title: Decision prompt — three paths (proposal / A-B-C options / narrow first)
description: "Three paths for making decisions: (1) one sensible option → proposal + \"see any gaps?\", (2) 2-3 real options → classic 3-line format + TL;DR, (3) > 3 options → narrow first. Eliminates fake A/B/C and option multiplication beyond need, while preserving discipline for real decisions."
category: writing
tags:
  - decyzja
  - komunikacja
  - harness
  - steering
  - klarowność
model: Claude Sonnet 4.6 / Opus 4.7
source: https://madejski.ai/promptoteka/decision-prompt-three-lines
locale: en
license: MIT
---

# Decision prompt — three paths

## Problem

When an agent needs to make a decision, there are two anti-patterns:

1. **Multiplying fake options** — A/B/C when B and C are obviously worse, just to "seem democratic". Wastes the user's time.
2. **Decision essay** — 5 paragraphs of context, then "what do you choose?". User doesn't know what they're clicking.

Both stem from one mistake: the agent didn't diagnose first **how many real options exist**.

## Diagnose first — how many real options?

- **1 option** → proposal + gap check (path 1)
- **2–3 real options** → classic A/B/C with 3-line format (path 2)
- **> 3 options** → narrow first (path 3)

---

## Path 1 — one sensible option (proposal + gaps?)

If you see **one path** that follows from context (others are obviously worse, inadequate, or don't exist), **don't multiply fake options**. Instead of A/B/C:

```
**Proposal**: will do X (1 line — what physically).
Impact: Y (1 line — prod/test/DB/cost).
Risk: Z (1 line — what could go wrong, how long).

See any gaps? If not — GO.
```

You wait for NO-GO by default. No response ≠ GO. User answers: `GO` / `gap: ...` / `different: ...`.

### When path 1 is right

- Pipeline has one idiomatic next step (next migration in a series, next commit in a logical sequence)
- User asked for something concrete (e.g. "add /api/health endpoint") — don't invent variants
- Other options would require architecture/scope change — that's a separate decision
- Low irreversibility + low cost (change reversible via `git revert`)

### Example (good path 1)

```
Proposal: add `config.ts` with `ROUTING_V2_ENABLED` — `z.string().default('false')
.transform(v => v==='true'||v==='1')` (edge-case safe boolean parsing).
Impact: test env + prod env accept new env var; default off.
Risk: none (default off, zero touch v1 routing).

See any gaps? If not — GO.
```

**Why good**: one sensible path, small blast radius, full reversibility. Asking for A/B/C would waste time.

---

## Path 2 — 2–3 real options (classic format)

When there are **real** options with different implications, each must have exactly 3 lines:

1. **What I will do physically** (1 line — action, not goal)
2. **What it affects** (1 line — prod? test? UI? DB? cost? irreversible?)
3. **Trade-off / risk** (1 line — what we gain / lose / how long it takes)

### Format

```
**A** `label` — what I'll do (change Railway env var, backend redeploy).
Impact: test env only, prod untouched.
Trade-off: ~3 min, reversible.

**B** `label` — what I'll do (merge feature/X to main, prod auto-deploy).
Impact: **PROD live**, migration 031_edges runs on prod Supabase.
Trade-off: rollback via `git revert` + redeploy; additive migration so safe.

**C** `pause` — I do nothing.
Impact: zero.
Trade-off: come back when you want.
```

After listing options — **1 line TL;DR recommendation** (if you have one):

> *Recommend A — B is reversible but I want test verification first.*

### When path 2 is right

- Different reversibility (one irreversible, one not)
- Different blast radius (test vs prod)
- Different cost (slow + cheap vs fast + expensive)
- Different cognitive trade-offs (agent can't decide without user's knowledge)

---

## Path 3 — > 3 options, none dominates

Decision too coarse. **Narrow first** to 2–3 variants.

First step: decision prompt about the selection criterion, not the specific option:

```
**Decision narrowing**:
We have 5 libraries to consider (A, B, C, D, E).
Preliminary question: which criterion matters most — (1) bundle size, (2) API ergonomics,
(3) maintenance activity, (4) TypeScript support?

After you point at the criterion, I'll pick the 2 best for a full decision prompt.
```

---

## Always ask (regardless of path)

- **Irreversible**: `DROP TABLE`, `rm -rf`, force push to main, delete remote branch
- **High-cost**: operation > $X, API call in a loop, long-running compute
- **Prod-impact**: deploy, production migration, change on main
- **Scope expansion**: user asked for X, you see Y also needs doing — ask before expanding

## Don't ask about cosmetics

Commit message, badge color, JSON formatting → **you decide yourself** per repo conventions.

## Anti-patterns

- **Fake A/B/C** — when B and C are obviously worse, don't multiply. Path 1.
- **"What do you think?"** without a proposal — user doesn't know full tool context; you do
- **Decision at the end after 5 paragraphs** — proposal / options upfront, not after a long preamble
- **Asking about the obvious** — "should I add `if (!user) throw`?" Don't ask about idiomatic fragments

## Effect

- User knows what they're clicking in 10 seconds (when there are options)
- Agent doesn't block for hours of deliberation
- Questions are purposeful, not ritualistic
- Decision-making space preserved for **real** choices