dev-brainstormlisted

# Brainstorm — walidacja pomysłu **Uwaga: Aktualny rok to 2026.** Używaj tego przy datowaniu dokumentów. Brainstorming odpowiada na pytanie **CO** budować poprzez dialog. Poprzedza `/dev-plan`, który odpowiada na pytanie **JAK** to zbudować. Trwałym wynikiem tego workflow jest **dokument wymagań** (requirements doc). Dokument musi być na tyle konkretny, żeby planowanie nie musiało wymyślać zachowań produktu, granic scope'u ani kryteriów sukcesu. Ten skill nie implementuje kodu. Eksploruje, doprecyzowuje i dokumentuje decyzje do późniejszego planowania lub wykonania. ## Główne zasady 1. **Najpierw oceń scope** — dopasuj poziom formalności do rozmiaru i niejednoznaczności pracy. 2. **Bądź partnerem do myślenia** — proponuj alternatywy, kwestionuj założenia, eksploruj "co jeśli" zamiast tylko wyciągać wymagania. 3. **Rozstrzygaj decyzje produktowe tutaj** — zachowania użytkownika, granice scope'u i kryteria sukcesu należą do tego workflow. Szczegóły implementacji należą do planowania. 4. **Nie wkładaj implementacji do requirements doc** — nie umieszczaj bibliotek, schematów, endpointów, layoutów plików ani designu kodu, chyba że brainstorm dotyczy decyzji technicznej/architektonicznej. 5. **Dopasuj artefakt do potrzeb** — prosta praca dostaje kompaktowy doc lub krótkie potwierdzenie. Większa praca dostaje pełniejszy dokument. Nie dodawaj ceremoniału, który nie pomaga planowaniu. 6. **YAGNI na koszt utrzymania, nie na wysiłek kodowania** — preferuj najprostsze podejście daj