---
name: decision-prompt-three-lines
title: Decision prompt — trzy ścieżki (propozycja / opcje A-C / zawęź)
description: "Trzy ścieżki podejmowania decyzji: (1) jedna sensowna opcja → propozycja + \"widzisz luki?\", (2) 2-3 realne opcje → klasyczny format 3-liniowy + TL;DR, (3) > 3 opcje → zawęź. Eliminuje sztuczne A/B/C i mnożenie wariantów ponad potrzebę, ale zachowuje dyscyplinę dla prawdziwych decyzji."
category: writing
tags:
  - decyzja
  - komunikacja
  - harness
  - steering
  - klarowność
model: Claude Sonnet 4.6 / Opus 4.7
source: https://madejski.ai/pl/promptoteka/decision-prompt-three-lines
locale: pl
license: MIT
---

# Decision prompt — trzy ścieżki

## Problem

Gdy agent musi podjąć decyzję, są dwa anty-wzorce:

1. **Mnożenie sztucznych opcji** — A/B/C gdy B i C są oczywiście gorsze, żeby "było demokratycznie". Użytkownik traci czas.
2. **Esej decyzyjny** — 5 akapitów kontekstu, a na końcu "co wybierasz?". Użytkownik nie wie co klika.

Obie sytuacje wynikają z jednego błędu: agent nie zdiagnozował najpierw, **ile realnych opcji istnieje**.

## Diagnoza najpierw — ile jest realnych opcji?

- **1 opcja** → propozycja + pytanie o luki (ścieżka 1)
- **2–3 realne opcje** → klasyczny A/B/C z 3-liniowym formatem (ścieżka 2)
- **> 3 opcje** → zawęź najpierw (ścieżka 3)

---

## Ścieżka 1 — jedna sensowna opcja (proposal + luki?)

Jeśli widzisz **jedną ścieżkę**, która wynika z kontekstu (inne są oczywiście gorsze, nieadekwatne, lub nie istnieją), **nie mnożysz sztucznych opcji**. Zamiast A/B/C:

```
**Propozycja**: zrobię X (1 linia — co fizycznie).
Wpływ: Y (1 linia — prod/test/DB/cost).
Ryzyko: Z (1 linia — co może pójść nie tak, ile trwa).

Widzisz luki? Jeśli nie — GO.
```

Domyślnie czekasz na NO-GO. Brak odpowiedzi ≠ GO. Użytkownik odpowiada: `GO` / `luka: ...` / `inaczej: ...`.

### Kiedy ścieżka 1 jest właściwa

- Pipeline ma jeden idiomatyczny krok (następna migracja w serii, kolejny commit w logicznej sekwencji)
- Użytkownik poprosił o konkret (np. "dodaj endpoint /api/health") — nie wymyślaj wariantów
- Inne opcje wymagałyby zmiany architektury / scope — to osobna decyzja, nie alternatywa
- Niska irreversibility + niski koszt (zmiana odwracalna `git revert`)

### Przykład (dobra ścieżka 1)

```
Propozycja: dodam `config.ts` z `ROUTING_V2_ENABLED` — `z.string().default('false')
.transform(v => v==='true'||v==='1')` (edge-case safe boolean parsing).
Wpływ: test env + prod env przyjmie nową env var; domyślnie off.
Ryzyko: żadne (default off, zero touch v1 routing).

Widzisz luki? Jeśli nie — GO.
```

**Dlaczego dobry**: jedna sensowna ścieżka (parsing boolean z zodem to idiomatyczny sposób), mały blast radius, pełna odwracalność. Pytanie o A/B/C byłoby marnowaniem czasu.

---

## Ścieżka 2 — 2–3 realne opcje (klasyczny format)

Gdy są **realne** opcje z różnymi implikacjami, każda musi mieć dokładnie 3 linie:

1. **Co fizycznie zrobię** (1 linia — akcja, nie cel)
2. **Na co wpływa** (1 linia — prod? test? UI? baza? koszt? irreversible?)
3. **Trade-off / ryzyko** (1 linia — co zyskujemy / co tracimy / jak długo trwa)

### Format

```
**A** `label` — co zrobię (zmiana Railway env var, backend redeploy).
Wpływ: tylko test env, bez ruszenia prod.
Trade-off: ~3 min, odwracalne.

**B** `label` — co zrobię (merge feature/X do main, prod auto-deploy).
Wpływ: **PROD live**, migracja 031_edges uruchomi się na prod Supabase.
Trade-off: rollback przez `git revert` + redeploy, additive migracja więc safe.

**C** `pauza` — nic nie robię.
Wpływ: zero.
Trade-off: wracasz kiedy chcesz.
```

Po liście opcji — **1 linia TL;DR rekomendacji** (jeśli masz zdanie):

> *Rekomenduję A — B jest reversible ale chce mieć test verify pierwsze.*

### Kiedy ścieżka 2 jest właściwa

- Różna odwracalność (jedna irreversible, inna nie)
- Różny blast radius (test vs prod)
- Różny koszt (wolne + tanie vs szybkie + drogie)
- Różne trade-offy poznawcze (agent nie może zdecydować bez wiedzy użytkownika)

---

## Ścieżka 3 — > 3 opcje, żadna nie dominuje

Decyzja zbyt gruba. **Najpierw zawęź** do 2–3 wariantów.

Pierwszy krok: decision prompt o kryterium wyboru, nie o konkretną opcję:

```
**Decision narrowing**:
Mamy 5 bibliotek do rozważenia (A, B, C, D, E).
Pytanie wstępne: jakie kryterium najważniejsze — (1) bundle size, (2) API ergonomics,
(3) maintenance activity, (4) TypeScript support?

Po wskazaniu kryterium wybiorę 2 najlepsze do pełnego decision prompta.
```

---

## Zawsze pytaj (niezależnie od ścieżki)

- **Irreversible**: `DROP TABLE`, `rm -rf`, force push na main, delete branch zdalnie
- **High-cost**: operacja > $X, API call w pętli, long-running compute
- **Prod-impact**: deploy, migracja produkcyjna, zmiana w main
- **Scope expansion**: użytkownik poprosił o X, widzisz że należy też Y — pytaj zanim rozszerzysz

## Nie pytaj o kosmetykę

Nazwa commit message, kolor badge, formatowanie JSON → **decydujesz sam** zgodnie z konwencjami repo.

## Anty-wzorce

- **Sztuczne A/B/C** — gdy B i C są oczywiście gorsze, nie mnóż. Ścieżka 1.
- **"Co ty na to?"** bez propozycji — użytkownik nie zna pełnego kontekstu narzędzi, ty znasz
- **Decyzja na końcu po 5 akapitach** — propozycja / opcje od razu, nie po długim wstępie
- **Pytanie o oczywiste** — "czy mam dodać `if (!user) throw`?" Nie pytaj o idiomatyczne fragmenty

## Efekt

- Użytkownik w 10 sekund wie co klika (gdy są opcje)
- Agent nie blokuje się na godzinach deliberacji
- Pytania są celowe, nie rytualne
- Przestrzeń decyzyjna zachowana dla **realnych** wyborów