# Umiejętność agenta: Przekształcanie pomysłów z burzy mózgów w projekty

> Przekształć niejasne pomysły w klarowne, zweryfikowane projekty i specyfikacje poprzez ustrukturyzowany dialog i zdyscyplinowane rozumowanie, zapobiegając przedwczesnej implementacji i nietrafionym rozwiązaniom. Rozpocznij projektowanie z jasnością w kilka sekund.

- Canonical: https://nanoskill.ai/pl/skills/brainstorming-ideas-to-designs
- Markdown: https://nanoskill.ai/pl/skills/brainstorming-ideas-to-designs.md
- Author: sickn33
- Published: 2026-05-23T00:10:47.865Z
- Updated: 2026-07-15T13:36:27.068Z
- Language: pl
- Source type: github
- Popularity signal: 38396

## Sources

- https://github.com/sickn33/antigravity-awesome-skills

## Install

```shell
npx skills add https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/brainstorming
```

## About

Umiejętność agenta przekształcania pomysłów w projekty pomaga przekształcić niejasne koncepcje w klarowne, zweryfikowane projekty i specyfikacje poprzez ustrukturyzowany, oparty na współpracy proces. Działając jako facylitator projektowy i starszy recenzent, prowadzi użytkowników przez zdyscyplinowany proces rozumowania, zapewniając, że pomysły są dokładnie sprawdzone i zrozumiane przed rozpoczęciem implementacji. Zapobiega to typowym pułapkom, takim jak przedwczesne kodowanie, ukryte założenia, nietrafione rozwiązania i niestabilne systemy, prowadząc ostatecznie do bardziej solidnych i skutecznych rezultatów.

Umiejętność ta wymusza metodyczne podejście, zaczynając od obowiązkowego kroku zrozumienia bieżącego kontekstu projektu, w tym istniejącej dokumentacji i wcześniejszych decyzji. Następnie przechodzi do fazy skoncentrowanego zadawania pytań i odpowiedzi, aby ustalić wspólną jasność co do celu, użytkowników, ograniczeń i wymagań niefunkcjonalnych. Kluczowy krok 'Blokady Zrozumienia' zapewnia jednoznaczne potwierdzenie intencji przed zbadaniem podejść projektowych, które są prezentowane stopniowo z wyraźnymi kompromisami.

Przez cały proces umiejętność ta prowadzi obowiązkowy Dziennik Decyzji, dokumentując wybory, alternatywy i uzasadnienia, aby zapewnić przejrzystość i dostarczyć historyczny zapis. Po walidacji ostateczny projekt jest dokumentowany, a opcjonalnie może nastąpić przekazanie implementacji. Ten ustrukturyzowany przepływ pracy jest idealny do walidacji nowych funkcji, projektowania architektur systemów i udoskonalania przebiegów zachowań użytkowników, zapewniając, że wszystkie główne założenia są udokumentowane, a kluczowe ryzyka są rozpoznane przed przejściem dalej.

## Key features

- **Ustrukturyzowane Facylitowanie Projektowania**: Działa jako facylitator projektowy i starszy recenzent, kierując procesem przekształcania surowych pomysłów w jasne, zweryfikowane projekty i specyfikacje przed rozpoczęciem implementacji.
- **Zapobiega Przedwczesnej Implementacji**: Zapewnia zdyscyplinowane podejście, nie zezwalając na implementację, kodowanie ani modyfikację zachowania podczas aktywności, skupiając się wyłącznie na walidacji projektu.
- **Obowiązkowe Zrozumienie Kontekstu**: Wymaga dokładnego przeglądu bieżącego stanu projektu, w tym plików, dokumentacji i wcześniejszych decyzji, w celu zidentyfikowania istniejących elementów i proponowanych zmian.
- **Prezentacja Projektu Przyrostowego**: Dzieli propozycje projektowe na łatwe do zarządzania sekcje (maksymalnie 200-300 słów), prosząc o potwierdzenie po każdej z nich, aby zapewnić ciągłe dopasowanie i walidację.
- **Kompleksowe Rejestrowanie Decyzji**: Prowadzi bieżący dziennik wszystkich decyzji, w tym rozważanych alternatyw i powodów wyborów, zapewniając przejrzystość i zachowując dokumentację do wykorzystania w przyszłości.

## Use cases

- **Walidacja Nowych Funkcji**: Użyj tej umiejętności, aby dokładnie przeprowadzić burzę mózgów i zweryfikować pomysły na nowe funkcje, upewniając się, że są one zgodne z celami projektu i potrzebami użytkowników przed rozpoczęciem jakichkolwiek prac programistycznych.
- **Projektowanie Architektury Systemu**: Zastosuj ustrukturyzowany proces burzy mózgów do projektowania solidnych architektur systemów, wyjaśniając wymagania niefunkcjonalne i badając wiele podejść.
- **Udoskonalanie Przepływów Zachowań Użytkowników**: Ułatwiaj dyskusje w celu udoskonalenia przepływów zachowań użytkowników, identyfikując przypadki skrajne i zapewniając jasne zrozumienie interakcji użytkownika i odpowiedzi systemu.

## Result preview

Zobacz rzeczywisty projekt prototypu interfejsu użytkownika wygenerowany przez tę umiejętność agenta.

![brainstorming-demo-01](https://file.nanoskill.ai/brainstorming-demo-01.jpg)

![brainstorming-demo-02](https://file.nanoskill.ai/brainstorming-demo-02.jpg)

![brainstorming-demo-03](https://file.nanoskill.ai/brainstorming-demo-03.jpg)

![brainstorming-demo-04](https://file.nanoskill.ai/brainstorming-demo-04.jpg)

## Result walkthrough

### Krok 1：Zainstaluj

Dodaj umiejętność do swojego agenta

![brainstorming-step-1](https://file.nanoskill.ai/brainstorming-step-1.jpg)

### Krok 2：Opisz swoją koncepcję

Zacznij od swojego pomysłu lub wyzwania, które chcesz zgłębić.

![brainstorming-step-2](https://file.nanoskill.ai/brainstorming-step-2.jpg)

### Krok 3：Udoskonal projekt

Otrzymaj rekomendacje projektowe i dobrze zdefiniowaną propozycję.

![brainstorming-step-3](https://file.nanoskill.ai/brainstorming-step-3.jpg)

## Skill definition

# Przekształcanie pomysłów w projekty

## Cel

Przekształcanie surowych pomysłów w **jasne, zweryfikowane projekty i specyfikacje**
poprzez ustrukturyzowany dialog **przed rozpoczęciem jakiejkolwiek implementacji**.

Umiejętność ta ma zapobiegać:
- przedwczesnej implementacji
- ukrytym założeniom
- niedopasowanym rozwiązaniom
- kruchym systemom

**Nie wolno** Ci implementować, kodować ani modyfikować zachowania, gdy ta umiejętność jest aktywna.

---

## Tryb działania

Działasz jako **facylitator projektowy i starszy recenzent**, a nie budowniczy.

- Żadnej kreatywnej implementacji  
- Żadnych spekulacyjnych funkcji  
- Żadnych milczących założeń  
- Żadnego wyprzedzania  

Twoim zadaniem jest **spowolnienie procesu na tyle, aby zrobić to dobrze**.

---

## Proces

### 1️⃣ Zrozum bieżący kontekst (Obowiązkowy pierwszy krok)

Przed zadaniem jakichkolwiek pytań:

- Przejrzyj bieżący stan projektu (jeśli dostępny):
  - pliki
  - dokumentacja
  - plany
  - wcześniejsze decyzje
- Zidentyfikuj, co już istnieje, a co jest proponowane
- Zanotuj ograniczenia, które wydają się dorozumiane, ale niepotwierdzone

**Jeszcze nie projektuj.**

---

### 2️⃣ Zrozumienie pomysłu (Jedno pytanie naraz)

Twoim celem jest **wspólna jasność**, a nie szybkość.

**Zasady:**

- Zadawaj **jedno pytanie na wiadomość**
- Preferuj **pytania wielokrotnego wyboru**, gdy to możliwe
- Używaj pytań otwartych tylko wtedy, gdy jest to konieczne
- Jeśli temat wymaga głębszego omówienia, podziel go na wiele pytań

Skoncentruj się na zrozumieniu:

- celu  
- grupy docelowej  
- ograniczeń  
- kryteriów sukcesu  
- jawnych nie-celów  

---

### 3️⃣ Wymagania niefunkcjonalne (Obowiązkowe)

MUSISZ wyraźnie wyjaśnić lub zaproponować założenia dotyczące:

- oczekiwań wydajnościowych  
- skali (użytkownicy, dane, ruch)  
- ograniczeń bezpieczeństwa lub prywatności  
- wymagań dotyczących niezawodności / dostępności  
- oczekiwań dotyczących utrzymania i odpowiedzialności  

Jeśli użytkownik nie jest pewien:

- Zaproponuj rozsądne wartości domyślne  
- Wyraźnie oznacz je jako **założenia**

---

### 4️⃣ Blokada zrozumienia (Twarda brama)

Przed zaproponowaniem **jakiegokolwiek projektu** MUSISZ się zatrzymać i wykonać następujące czynności:

#### Podsumowanie zrozumienia
Przedstaw zwięzłe podsumowanie (5–7 punktów) obejmujące:
- Co jest budowane  
- Dlaczego istnieje  
- Dla kogo jest przeznaczone  
- Kluczowe ograniczenia  
- Jawne nie-cele  

#### Założenia
Wypisz wszystkie założenia jawnie.

#### Otwarte pytania
Wypisz nierozwiązane pytania, jeśli występują.

Następnie zapytaj:

> „Czy to dokładnie odzwierciedla Twój zamiar?  
> Proszę potwierdź lub popraw cokolwiek, zanim przejdziemy do projektowania.”

**NIE kontynuuj, dopóki nie otrzymasz jawnego potwierdzenia.**

---

### 5️⃣ Zbadaj podejścia projektowe

Po potwierdzeniu zrozumienia:

- Zaproponuj **2–3 realne podejścia**
- Rozpocznij od **opcji zalecanej**
- Wyjaśnij kompromisy w sposób jasny:
  - złożoność
  - rozszerzalność
  - ryzyko
  - utrzymanie
- Unikaj przedwczesnej optymalizacji (**bezlitosne YAGNI**)

To wciąż **nie jest** ostateczny projekt.

---

### 6️⃣ Przedstaw projekt (Stopniowo)

Prezentując projekt:

- Podziel go na sekcje o długości **maksymalnie 200–300 słów**
- Po każdej sekcji zapytaj:

  > „Czy to na razie wygląda dobrze?”

Uwzględnij, jeśli dotyczy:

- Architekturę  
- Komponenty  
- Przepływ danych  
- Obsługę błędów  
- Przypadki brzegowe  
- Strategię testowania  

---

### 7️⃣ Dziennik decyzji (Obowiązkowy)

Prowadź bieżący **dziennik decyzji** przez całą dyskusję projektową.

Dla każdej decyzji:
- Co zostało postanowione  
- Jakie alternatywy rozważano  
- Dlaczego wybrano tę opcję  

Dziennik ten powinien zostać zachowany do dokumentacji.

---

## Po zakończeniu projektu

### 📄 Dokumentacja

Po zweryfikowaniu projektu:

- Zapisz ostateczny projekt w trwałym, współdzielonym formacie (np. Markdown)
- Uwzględnij:
  - Podsumowanie zrozumienia
  - Założenia
  - Dziennik decyzji
  - Ostateczny projekt

Zachowaj dokument zgodnie ze standardowym przepływem pracy w projekcie.

---

### 🛠️ Przekazanie do implementacji (Opcjonalnie)

Dopiero po ukończeniu dokumentacji zapytaj:

> „Gotowy do przygotowania do implementacji?”

Jeśli tak:
- Stwórz jawny plan implementacji
- Wydziel pracę, jeśli przepływ pracy na to pozwala
- Postępuj stopniowo

---

## Kryteria wyjścia (Warunki twardego zatrzymania)

Możesz wyjść z trybu burzy mózgów **tylko wtedy, gdy wszystkie poniższe są prawdziwe**:

- Blokada zrozumienia została potwierdzona  
- Co najmniej jedno podejście projektowe jest jawnie zaakceptowane  
- Główne założenia są udokumentowane  
- Kluczowe ryzyka są uznane  
- Dziennik decyzji jest kompletny  

Jeśli którekolwiek kryterium nie jest spełnione:
- Kontynuuj udoskonalanie  
- **NIE przechodź do implementacji**

---

## Kluczowe zasady (Nienegocjowalne)

- Jedno pytanie naraz  
- Założenia muszą być jawne  
- Badaj alternatywy  
- Waliduj stopniowo  
- Przedkładaj jasność nad spryt  
- Bądź gotów cofnąć się i wyjaśnić  
- **Bezlitosne YAGNI**

---
Jeśli projekt ma duży wpływ, wysokie ryzyko lub wymaga podwyższonego poziomu pewności, MUSISZ przekazać ostateczny projekt i dziennik decyzji do umiejętności `multi-agent-brainstorming` przed implementacją.

## Kiedy używać
Ta umiejętność ma zastosowanie do wykonania przepływu pracy lub działań opisanych w przeglądzie.

## Ograniczenia
- Używaj tej umiejętności tylko wtedy, gdy zadanie wyraźnie pasuje do zakresu opisanego powyżej.
- Nie traktuj wyniku jako substytutu walidacji specyficznej dla środowiska, testowania lub recenzji eksperckiej.
- Zatrzymaj się i poproś o wyjaśnienie, jeśli brakuje wymaganych danych wejściowych, uprawnień, granic bezpieczeństwa lub kryteriów sukcesu.

## FAQ

### Jaki jest główny cel umiejętności Burzy mózgów?

Głównym celem umiejętności Burzy mózgów jest przekształcanie surowych pomysłów w jasne, zweryfikowane projekty i specyfikacje poprzez ustrukturyzowany dialog przed rozpoczęciem jakiejkolwiek implementacji. Działa jako facylitator projektowy i starszy recenzent.

### Czy mogę użyć tej umiejętności do pisania kodu lub implementowania funkcji?

Nie, podczas gdy ta umiejętność jest aktywna, wyraźnie nie wolno Ci implementować, kodować ani modyfikować zachowania. Jej jedynym celem jest projektowanie i walidacja, aby zapobiec przedwczesnej implementacji.

### W jaki sposób umiejętność zapewnia wspólną jasność podczas burzy mózgów?

Umiejętność zapewnia wspólną jasność, wymagając jednego pytania na wiadomość, preferując pytania wielokrotnego wyboru i koncentrując się na zrozumieniu celu, docelowych użytkowników, ograniczeń i kryteriów sukcesu przed przejściem do projektowania.

### Czym są 'Wymagania Niefunkcjonalne' i dlaczego są obowiązkowe?

Wymagania Niefunkcjonalne (NFR) obejmują oczekiwania dotyczące wydajności, skalowalności, bezpieczeństwa, niezawodności i konserwacji. Są one obowiązkowe w celu wyjaśnienia lub zaproponowania założeń, zapewniając kompleksowy projekt, który uwzględnia krytyczne atrybuty systemu.

### Czym jest 'Blokada Zrozumienia' i kiedy występuje?

Blokada Zrozumienia to twarda brama, w której musisz się zatrzymać i przedstawić zwięzłe podsumowanie pomysłu, wymienić założenia i otwarte pytania. Nie możesz przejść do projektowania, dopóki nie otrzymasz wyraźnego potwierdzenia, że podsumowanie dokładnie odzwierciedla intencje użytkownika.

### Co się dzieje po zweryfikowaniu projektu?

Po zweryfikowaniu projektu umiejętność wymaga udokumentowania ostatecznego projektu w trwałym formacie, w tym podsumowania zrozumienia, założeń i dziennika decyzji. Następnie może nastąpić opcjonalne przekazanie do implementacji.
