---
name: plan-before-code-discipline
title: Plan-before-code — dyscyplina implementacji
description: "Skill wymuszający plan-first: 3–5 bullet plan wystawiany użytkownikowi przed każdą zmianą w kodzie. Czekasz na GO, dopiero wtedy piszesz. Wyjątek: batch approval (\"zrób X i commit\"). Eliminuje \"już zacząłem\" i nieautoryzowane commitowanie."
category: workflow
tags:
  - plan-first
  - dyscyplina
  - harness
  - workflow
  - kontrola
requires:
  - Claude Code
source: https://madejski.ai/pl/skilloteka/plan-before-code-discipline
locale: pl
license: MIT
---

# Plan-before-code — dyscyplina implementacji

## Zasada

**Plan przed kodem.** Wystawiasz plan użytkownikowi → czekasz na GO → piszesz kod.

Bez GO = brak edytów. Bez wyjątków "to proste".

## Dwa formaty planu

### Format A — single path (jedna sensowna ścieżka)

Gdy ścieżka jest jedna (pipeline pokazuje oczywisty następny krok, kontekst nie pozostawia realnych alternatyw):

```
Plan (single path):
- Co zrobię: <1-2 linie — konkretne pliki + akcja>
- Weryfikacja: <build/test/run command>
- Commit: <message>

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

Użytkownik odpowiada `GO` / `luka: ...` / `inaczej: ...`. To jest **właściwy domyślny format** dla większości kroków w molekularnym harness.

### Format B — plan z wariantami (gdy są realne opcje)

Gdy widzisz 2–3 sensowne podejścia z różnymi trade-offami:

```
Plan:
1. <akcja konkretna — plik + co w nim zrobić>
2. <akcja konkretna>
3. <akcja konkretna>
4. <weryfikacja — build / test / run>
5. <commit strategy — ile commitów, jakie>

Dwie opcje implementacji kroku 2:
- A: <podejście + trade-off>
- B: <podejście + trade-off>
Rekomenduję A.

Pytanie: GO (z A)?
```

## Trzy tryby pracy (stery użytkownika)

| Steer | Co to znaczy | Co robisz |
|---|---|---|
| `plan only` / `koncepcyjnie` | Tylko plan, bez kodu | Wystawiasz plan, czekasz na feedback, **nie edytujesz** |
| `kodem` / `implementuj` | Kod, ale plan przed | Wystawiasz plan → GO → piszesz kod |
| `zrób X i commit` | Batch approval | Wykonujesz X + commitujesz, nie pytasz na każdym kroku |
| `review` | Tryb code review | Agent code-reviewer, **zero edytów** |
| `zatrzymaj` / `wait` | STOP | Pełen stop, nie kontynuujesz do odwołania |
| `GO` | Zatwierdzenie single-path propozycji | Implementujesz wg propozycji |
| `luka: ...` | Wskazanie gap w propozycji | Wracasz do planu z uwzględnieniem luki |

## Kiedy single-path, kiedy warianty?

### Single-path (Format A) — użyj, gdy:

- Pipeline ma jeden idiomatyczny krok (np. następna migracja w numerowanej serii)
- Użytkownik poprosił o konkret — nie wymyślaj wariantów
- Inne podejścia wymagałyby zmiany architektury / scope
- Niska irreversibility + niski koszt

### Warianty (Format B) — użyj, gdy:

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

## Granularność planu

- **Zbyt gruby**: "Dodaj feature X" → nie da się sterować
- **Zbyt drobny**: "Dodaj linię 42 w pliku Y" → za dużo frykcji
- **Dobry**: 3–5 bulletów per krok logiczny

**Reguła kciuka**: jeśli plan ma > 7 bulletów, **podziel na dwie fazy**.

## Batch approval

Gdy użytkownik pisze **"zrób X i commit"**:

- NIE pytasz o GO przed commitem
- NIE pytasz o decision prompts dla kosmetyki
- Wykonujesz batch do końca
- Raportujesz jedną wiadomością na końcu

**Wyjątek w batch**: jeśli napotkasz **irreversible / high-risk** decyzję — zatrzymujesz się i pytasz mimo batch approval.

## Co robić, gdy agent łamie regułę

1. **STOP natychmiast.** Nie commituj.
2. Cofnij edytowane pliki (`git restore <file>`).
3. Wystaw plan post-factum: "Właśnie edytowałem X, Y — chciałem zrobić Z. Cofnąłem. Plan + GO?"
4. Czekaj na decyzję użytkownika.

Lepiej zrestartować niż ukryć.

## Red flag: "już zacząłem"

Jeśli pomyślisz "już zacząłem, to mały krok, dokończę i pokażę": **STOP**. Pokaż plan (single-path lub warianty). Czekaj na GO.

"Już zacząłem" = agent wymusza decyzję ex-post. Antyteza harness'u.

## Red flag: sztuczne warianty

Jeśli masz ochotę "żeby było demokratycznie" wystawić A/B/C, gdzie B i C są oczywiście gorsze — **nie rób**. Użyj Format A (single path). Marnowanie czasu na sztuczne opcje jest takim samym odejściem od harness'u, jak brak planu w ogóle.

## Efekt

- Użytkownik widzi, co się stanie **przed** tym jak się stanie
- Agent nie robi "niespodzianek" w commit history
- Plany są audit trail — łatwo zrekonstruować "dlaczego to tak"
- Odwracalność zachowana do ostatniego możliwego momentu
- **Przestrzeń decyzyjna agenta** wykorzystana — agent decyduje sam gdy jest jedna ścieżka, pyta gdy są realne warianty