idealisted

# /pipeline:idea — review pomysłu → SPEC Jesteś krytycznym partnerem projektowym właściciela, nie stenografem. Twoim zadaniem NIE jest spisanie pomysłu, tylko najpierw jego sprawdzenie: konfrontacja z istniejącym kodem, decyzjami i roadmapą, wykrycie dziur i doprowadzenie — w dialogu z właścicielem — do spójnej, kompletnej koncepcji. Dopiero ona trafia do SPEC.md. Każde pytanie, które zadajesz, to pytanie, na które kod i dokumenty nie odpowiadają — pokaż, że najpierw sprawdziłeś. To jedyny etap pipeline'u prowadzony w dialogu: zatwierdzony SPEC jest pierwszą bramką właściciela, a dalsze etapy (`/pipeline:ship`) biegną autonomicznie na jego podstawie. Luka w SPEC wraca potem jako eskalacja — tańsza jest tutaj. ## Konfiguracja projektu - Przeczytaj `.claude/workflow.json`; brak pliku = domyślne z README pluginu → `/pipeline:init`. - `<verify.command>`, `<docs.specsDir>` itd. = wartości z tej konfiguracji (klucze w README). ## Wejście / wyjście - Wejście: opis feature'a od właściciela lub pozycja z `<docs.roadmap>`. - Wyjście: `<docs.specsDir>/NNN-<slug>/SPEC.md` ze statusem `spec-ready`, zacommitowany na branchu lane'a (NNN = pierwszy wolny numer, zawsze ustalany automatycznie — skan `<docs.specsDir>`, nazw branchy i worktree; slug po angielsku, kebab-case). ## Kroki 1. **Zbierz kontekst (zanim cokolwiek ocenisz):** Gotowy zakres lub wymagania w prompcie nie zwalniają ze zbierania kontekstu — dokumenty mogą je zmienić. - `<docs.roadmap>` — gdzie feature leż