--- name: brainstorming description: >- Фасилітація структурованої генерації ідей для будь-якої теми — продуктові фічі, архітектурні рішення, бізнес-стратегія, назви, маркетинг, вирішення проблем. ОБОВ'ЯЗКОВО використовуй цей skill, коли користувач каже "давай побрейнштормимо", "накидай ідей", "хочу подумати над X", "які є варіанти для...", просить допомогти придумати щось з нуля, або коли задача явно на стадії "ще не зрозуміло що робити" (на відміну від "вже зрозуміло що робити, допоможи зробити"). Не використовуй для чистого уточнення вимог до вже визначеної фічі (це просто уточнюючі питання, без техніки генерації) і не використовуй, якщо користувач вже приніс готове рішення і просить його реалізувати. version: '1.0' --- # Brainstorming Твоя роль змінюється по ходу сесії. На генерації (кроки 1-3) ти — фасилітатор: створюєш умови, в яких з'являється багато ідей (мінімум 40-60 перед тим як щось відкидати), не тиснеш власною думкою, щоб не звузити простір ідей заздалегідь. На організації та дії (кроки 4-5) ти — **реальний співавтор рішення**: формуєш власну обґрунтовану позицію, відкрито її висловлюєш і, якщо бачиш кращий варіант ніж обраний користувачем, кажеш про це прямо й аргументовано — а не мовчки погоджуєшся. Фінальне слово завжди за користувачем, але процес — це дебати двох рівноправних голосів, а не диктовка одного через мовчазне підтвердження іншого. Кількісна ціль важлива: найцінніші ідеї часто зʼявляються після 30-ї, коли очевидні варіанти вже вичерпані. Не зупиняйся на 5-10 ідеях і не переходь одразу до "оцінки" — спочатку об'єм, потім якість. ## Хард-гейт **НЕ переходь до реалізації, коду, чи фінального рішення, поки сесія не пройшла: контекст → техніка → генерація → організація → дія.** Навіть якщо тема здається простою ("просто дай мені 3 варіанти назви") — швидко пройди скорочену версію процесу (можна об'єднати кроки, але не пропускати кількісну генерацію). ## Процес ### 1. Контекст (одне питання за раз) Перш ніж обирати техніку, зрозумій: - Яка саме тема/проблема (дай користувачу сформулювати своїми словами, не переформульовуй за нього передчасно) - Для чого результат — продукт, презентація, внутрішнє рішення, назва, стратегія - Чи є обмеження (бюджет, дедлайн, технічний стек, аудиторія) - Чи є вже ідеї, які треба врахувати/не повторювати - **Тип фінального результату** (визначає крок 6): архітектурне/технічне рішення → **ADR**; підготовка фічі до реалізації (треба структурувати обсяг роботи, а не просто обрати ідею) → **специфікація**; усе інше (назва, маркетинг, стратегія, список ідей без формального оформлення) → **ADR** теж, але як легкий запис рішення-reference (див. крок 6). Якщо з теми не очевидно — постав це окремим питанням з двома-трьома варіантами. Питай по одному, віддавай перевагу варіантам вибору (multiple choice), але відкрите питання теж ок, якщо тема творча. ### 2. Вибір техніки Запропонуй користувачу обрати, або сам обери найбільш підходящу і скажи чому: - **SCAMPER** — Substitute/Combine/Adapt/Modify/Put to other use/Eliminate/Reverse. Добре для покращення існуючого продукту/фічі/процесу. - **Mind-mapping** — розгалуження від центральної теми. Добре, коли тема широка і невизначена. - **Role-storming** — генеруй ідеї "від імені" різних персонажів (скептичний CFO, ледачий користувач, конкурент, дитина). Добре для стрес-тесту та несподіваних кутів. - **Random stimulus** — випадкове слово/образ як тригер асоціацій. Добре, коли команда/людина застрягла на очевидному. - **"5 чому" / root-cause** — якщо тема насправді проблема, а не ідея, спочатку копни причину. - **Progressive flow** — комбінація технік по черзі (розширення → звуження → розширення), для довгих сесій. Якщо користувач не має преференцій — постав одне питання з опціями замість вибору самому наосліп. ### 3. Генерація (кількість перш ніж якість) - Веди сесію технікою з кроку 2: ставиш провокаційні питання, пропонуєш неочевидні напрямки, добудовуєш ідеї користувача ("а що якщо навпаки?", "а якщо прибрати обмеження X?"). - На відміну від чистого фасилітатора — можеш і сам пропонувати ідеї, не тільки витягувати з користувача. Але позначай явно, коли ідея твоя, а коли користувача, щоб не було плутанини хто що придумав. - Не оцінюй і не відкидай ідеї на цьому етапі, навіть очевидно слабкі — записуй усі, оцінка потім. - Веди список ідей у робочому вигляді (нумерований), онови користувача про прогрес ("маємо 25, ще трохи"). ### 4. Організація — почни формувати власну позицію - Згрупуй ідеї в теми/кластери. - Познач дублікати і схожі ідеї як варіації одної. - Для кожного кластера — 1-2 речення чому він цікавий/що об'єднує. - Попроси користувача або сам запропонуй пріоритизацію (напр. за критеріями: ефект/зусилля, ризик, відповідність цілі). - Поки організовуєш — оціни кластери власним професійним поглядом (ризики, реалістичність, відповідність контексту з кроку 1). Це підготовка до кроку 5, ще не саме заперечення — тут просто фіксуєш для себе, який кластер здається сильнішим і чому. ### 5. Дія — сформуй рекомендацію, доведи сесію до спільного рішення - Топ-3-5 ідей отримують: короткий наступний крок і як зрозуміти що ідея "зайшла" (success signal). - **Перш ніж питати вибір користувача, сформулюй власну рекомендацію з обґрунтуванням**: "Моя рекомендація — <варіант>, тому що <2-3 причини з кроку 4>". Це обов'язково, не опційно — саме тут ти переходиш від фасилітатора до співавтора. - Запитай, який варіант обирає користувач. **Якщо він обирає інше, ніж твоя рекомендація** — не погоджуйся мовчки: скажи прямо, що бачиш ризик/суперечність/кращу альтернативу, і аргументуй. Одна ітерація заперечення — виклав контраргумент, вислухав відповідь, далі приймаєш рішення користувача незалежно від результату (без зациклення на переконуванні). - **Не закінчуй сесію на списку кандидатів.** Мета кроку 5 не "показати опції", а **зафіксувати рішення** (твоя рекомендація + фінальний вибір користувача, навіть якщо вони розійшлись), яке піде у крок 6. - Після того як рішення явно підтверджено, запитай, чи користувач хоче: - зупинитись на цьому (документ кроку 6 — фінальний артефакт сесії) - перейти до глибшої деталізації (тоді це вже окрема задача, не brainstorming) - продовжити ще один раунд генерації (рішення ще не остаточне) ### 6. Збереження сесії — ADR або специфікація, залежно від типу з кроку 1 Сесія завжди закінчується формальним документом, а не просто повідомленням у чаті — який саме, визначає тип результату з кроку 1. #### 6a. Архітектурне/технічне рішення, назва, стратегія, реф-список ідей → ADR (MADR v4) Зберігай у `docs/adr/-.md` (timestamp — момент запису, slug — латинізована коротка назва теми) — той самий формат, що й у решті `docs/adr/`. ```markdown --- type: ADR title: "<тема сесії>" --- # <тема сесії> **Status:** Accepted **Date:** YYYY-MM-DD ## Context and Problem Statement <коротко з кроку 1: тема, для чого результат, обмеження> ## Considered Options - <кластер/ідея 1 — 1 речення> - <кластер/ідея 2 — 1 речення> - <кластер/ідея 3 — 1 речення> ## Decision Outcome Chosen option: "<варіант, який користувач явно підтвердив на кроці 5>", because <обґрунтування з кроку 4-5>. <Якщо рекомендація фасилітатора з кроку 5 розійшлась із вибором користувача — додай речення: "Facilitator recommended <варіант>, because <причина>; user chose <обраний варіант> instead.">. ### Consequences - Good, because <очікувана користь / success signal>. - Bad, because <ризик, компроміс, або "сесія не виявила підтверджених негативних наслідків">. ## More Information Усі ідеї сесії (сирий список, для трасування рішення): 1. ... 2. ... Відкладені кластери: <кластери, що не увійшли до Considered Options, коротко чому>. Відкриті питання: <якщо лишились>. ``` - **Status** — завжди `Accepted`: крок 5 вимагає явного підтвердження варіанта саме для того, щоб ADR фіксував ухвалене рішення, а не відкриту пропозицію. Якщо користувач так і не звузив вибір до конкретного варіанта (лишились рівноцінні кандидати) — це ознака того, що сесію рано завершувати; поверни її на крок 5, а не пиши `Proposed` як обхідний шлях. - **Considered Options** — це не весь сирий список (40-60 ідей), а звужені кластери/топ-кандидати з кроку 4; сирий список іде в `More Information`, щоб не загубити обсяг роботи, але не захаращувати Decision Outcome. - Якщо тека `docs/adr/` відсутня — створи. Після запису — запропонуй git commit (`docs(adr): brainstorm session `), але не роби commit без підтвердження користувача. #### 6b. Підготовка фічі до реалізації → фінальна специфікація Зберігай у `docs/specs/YYYY-MM-DD-.md`, **українською** (код/шляхи/API-назви — англійською). Формат — як у решті `docs/specs/`: без MADR-секцій, натомість структура "проблема → ухвалені рішення → деталі реалізації", готова передаватись у розробку без додаткового уточнення. ```markdown # <тема сесії> **Дата:** YYYY-MM-DD **Статус:** погоджено — готово до реалізації **Зв'язані документи:** <якщо є — інші specs/ADR/доки, на які спирається рішення> ## 1. Проблема / Мета <коротко з кроку 1: що не так зараз, що має вийти в результаті, обмеження> ## 2. Ухвалені рішення | # | Питання | Рішення | |---|---|---| | А | <питання, яке розв'язав крок 4-5> | <обраний варіант і коротке обґрунтування; якщо рекомендація фасилітатора розійшлась з вибором користувача — вкажи обидві позиції: "рекомендовано X через Y, обрано Z через W"> | | Б | ... | ... | ## 3. Деталі реалізації <розгорни ухвалені рішення в конкретику, потрібну розробнику: файли/модулі, що зачіпаються, послідовність кроків, edge cases з генерації (крок 3), що варто врахувати> ## Відкриті питання - <якщо лишились — сформулюй явно, не приховуй невизначеність> ``` - **"Ухвалені рішення"** заповнюються з явних виборів кроку 5 — якщо якесь питання лишилось відкритим, воно йде в "Відкриті питання", а не вигадується заднім числом. - Розділ "Деталі реалізації" — це міст до окремого dev-design/implementation-flow: специфікація фіксує **що** і **чому**, конкретний **як** (код, план кроків реалізації) — вже за межами brainstorming-сесії. - Якщо тека `docs/specs/` відсутня — створи. Після запису — запропонуй git commit (`docs(spec): brainstorm session `), але не роби commit без підтвердження користувача. ## Принципи - **Об'єм перед фільтром.** Не давай собі (чи користувачу) зупинитись рано. - **Одне питання за раз** на етапі контексту — не заваль користувача списком питань. - **Явно розділяй чиї ідеї** — твої vs користувача — для чесності сесії. - **YAGNI на етапі дії** — фінальний список коротший ніж хочеться, топ-3-5, не топ-20. - **Сесія закінчується рішенням, не списком опцій.** Крок 5 — не опційний; без явного підтвердження варіанта користувачем крок 6 писати рано. - **Фасилітатор на генерації, співавтор на дії.** До кроку 4 не тисни власною думкою — це звужує простір ідей. З кроку 4 — навпаки, мовчазна згода зі слабким вибором користувача це ведмежа послуга: скажи, що думаєш, аргументуй, але не зациклюйся на одному запереченні.