steelmorgan/brainstorm

brainstorm — структурированный мозговой штурм

Цель — развернуть полное пространство решений задачи, а не выдать первую правдоподобную идею. Навык борется с типичной болезнью LLM: давать «гладкий ответ из моды распределения», теряя альтернативы, которые могли бы оказаться лучше.

---

Когда применять

| Триггер | Действие | |---------|----------| | Пользователь вызвал /brainstorm <тема> | Пройти все фазы 0–5, опционально 6 | | Запрос вида «как лучше сделать X», «какие есть варианты», «давай подумаем над Y» | Предложить запустить /brainstorm, при согласии — пройти фазы | | Перед написанием спецификации, когда не выбран подход | Использовать как подготовку к Considered Options/ADR | | В фазе 1 полного цикла (Analyst), задача допускает несколько подходов | Запустить как внутренний шаг анализа |

Когда НЕ применять

• Вопрос имеет один правильный ответ (факт, синтаксис, документация)
• Пользователь явно сказал «просто сделай»
• Задача — фикс конкретного бага по известной причине
• Уже есть утверждённая спецификация — это территория полного цикла, не брэйнсторма

---

Принцип

Шесть фаз, идущих от расширения к сужению, плюс опциональная седьмая (внешний red team).

0. FRAME    — какую задачу мы вообще решаем?
1. AXES     — по каким осям может различаться решение?
2. SAMPLE   — какие точки в этом пространстве рассмотрим?
3. GENERATE — формулируем гипотезу для каждой точки
4. STRESS   — что её ломает?
5. CONVERGE — три финалиста, максимально различных
6. EXT-RED  — (опционально) red team от другой модельной семьи

Что гибко: выбор техник внутри каждой фазы (5 Whys vs JTBD во FRAME, SCAMPER vs аналогии в GENERATE, экстремумы vs латинский квадрат в SAMPLE). Это руководство, не догма.

Что жёстко: порядок фаз и гейты между ними (см. следующий раздел). Их пропускать запрещено.

---

Принцип диалога — критическое требование

Брэйнсторм — это совместная работа с пользователем, а не монолог агента. Если агент сам прошёл все фазы и выдал финал — это не брэйнсторм, это презентация в обёртке. Цель навыка теряется ровно в этот момент: пользователь не успевает скорректировать оси до того, как по этим осям уже сгенерированы гипотезы.

MUST

| Требование | Описание | |-----------|----------| | Не вываливать всё одним сообщением | Запрещено пройти 2+ фазы подряд без обратной связи от пользователя | | Остановка после каждой обязательной фазы | Вывод результата → конкретный вопрос → ждать ответ перед следующей фазой | | Минимум 4 STOP за сессию | Phase 0, Phase 1, Phase 3+4, Phase 5 — обязательные гейты | | Использовать AskUserQuestion для дискретных гейтов | Выбор финалиста, добавление осей из готового набора, выбор стратегии выборки — это закрытые вопросы. Открытый ответ — обычный текстовый вопрос | | Задал вопрос — остановись | Текстовый вопрос без остановки = риторический. Не использовать как декорацию монолога |

Таблица гейтов

| После фазы | Что показать | Что спросить | STOP | |-----------|--------------|--------------|------| | 0 FRAME | Переформулировка задачи + критерии успеха + ограничения | «Фрейминг корректен? Что поправить?» | ✓ обязательно | | 1 AXES | Список осей и значений | «Все важные оси на месте? Чего не хватает?» | ✓ обязательно | | 2 SAMPLE | Стратегия выборки + список точек | (опционально) «Добавить wild point из конкретного домена?» | можно идти дальше | | 3+4 GENERATE+STRESS | Гипотезы со стресс-тестами | «Какие развить глубже? Что обрезать?» | ✓ обязательно | | 5 CONVERGE | 3 финалиста + рекомендация | «Какой выбираешь?» | ✓ обязательно |

Phase 2 — единственная необязательная остановка: если пользователь уже подтвердил оси, выборка точек — техническая работа агента, её можно показать вместе со стартом Phase 3+4 одним блоком. Фазы 0, 1, 3+4, 5 — STOP обязательно.

Самопроверка перед отправкой сообщения

Прежде чем отправить сообщение пользователю, агент проверяет:

• [ ] Сообщение содержит результат одной обязательной фазы (или одной плюс необязательная Phase 2)?
• [ ] В конце сообщения — конкретный вопрос, на который ожидается ответ?
• [ ] Не сгенерированы ли гипотезы по осям, которые пользователь ещё не подтвердил?

Если хотя бы один пункт «нет» — переписать сообщение и обрезать до текущей фазы.

---

Фазы

Phase 0 — FRAME (фрейминг)

Перед генерацией убедиться, что решаем правильную задачу.

• Переформулировать запрос своими словами и показать пользователю — пусть подтвердит или поправит
• Выяснить критерии успеха: по чему мы поймём, что решение хорошее?
• Зафиксировать ограничения: бюджет времени, технологический стек, аудитория, нефункциональные требования
• При мутном запросе — короткий 5-Whys или Jobs-to-be-Done переформулировка
• Классифицировать тип задачи: дивергентная (нужно расширение) / конвергентная (нужен выбор из известного) / смешанная

Сигнал пропустить фазу: задача чёткая, критерии явные, ограничения известны. Даже в этом случае — короткий чек-ин «понял задачу так-то, продолжаю?» перед Phase 1.

Антипаттерн: прыгнуть в генерацию идей без подтверждения, что мы решаем то, что нужно. Это самая частая причина бесполезного брэйнсторма.

[STOP] После Phase 0. Вывод: переформулировка + критерии + ограничения. Вопрос: «Фрейминг корректен? Что поправить?». Не идти к Phase 1 без ответа пользователя.

Phase 1 — AXES (оси разнообразия)

Извлечь 3–6 осей, по которым решения могут принципиально различаться. Это морфологический анализ Цвикки.

• На каждой оси — 2–4 значения
• Критично: проверить ортогональность. Оси не должны предопределять друг друга. Если выбор значения по оси A автоматически фиксирует ось B — это одна ось, а не две
• Хорошие оси для технических задач: «где живёт логика», «синхронно/асинхронно», «уровень связности», «кто инициатор», «модель данных», «timing of validation»
• Хорошие оси для продуктовых: «кто пользователь», «момент в флоу», «явное vs неявное действие», «обратимость», «уровень автоматизации»

Антипаттерн: оси-маркетинг («простое vs сложное», «лучшее vs быстрое»). Это не оси, это оценки.

[STOP] После Phase 1. Вывод: список осей и их значений. Вопрос: «Все важные оси на месте? Чего не хватает?». Не идти к Phase 2 без ответа. Сгенерировать гипотезы по неподтверждённым осям = впустую сжечь раунд.

Phase 2 — SAMPLE (выборка точек пространства)

Полный грид редко нужен (5 осей × 3 значения = 243 комбинации). Выбираем стратегию покрытия:

• Экстремумы — комбинации крайних значений по каждой оси (закрывает границы)
• Латинский квадрат — равномерное покрытие при ограниченном бюджете
• Случайные с анкорами — пара экстремумов + случайные комбинации
• Полный грид — только если осей мало и комбинаций ≤ 8

Бюджет по умолчанию: 6–9 точек. Меньше 5 — теряем покрытие, больше 10 — теряем внимание.

К отобранным точкам полезно добавить:

• 1 «дикую» точку через аналогию из чужого домена (как эту задачу решают в [биологии / военной логистике / музыке / другой индустрии])
• 1 «провокацию» — намеренно абсурдная комбинация как seed (см. references/prompt-techniques.md → Provocation)

Опциональная остановка после Phase 2. Если пользователь активен и есть смысл — спросить «добавить wild point из конкретного домена?». Если нет — переходить к Phase 3 без отдельного сообщения, объединить вывод выборки с гипотезами в Phase 3+4.

Phase 3 — GENERATE (генерация гипотез)

На каждую точку — формулировка гипотезы решения. Здесь главные риски — анкоринг и diversity theater.

• Генерировать по одной гипотезе за раз, явно ссылаясь на её координаты в осях. Не выдавать списком в одном абзаце — это анкорит на первой
• Для каждой гипотезы: суть в 2–3 предложениях + один ключевой механизм + на чём держится
• Не оценивать на этой фазе — оценка убивает дивергентность
• Если две гипотезы из разных точек получились семантически одинаковыми — одна из осей была не настоящая, вернуться к Phase 1
• Опционально: 1 worst-idea для полноты (часто инверсия плохой даёт неожиданно хорошее)

См. references/prompt-techniques.md для конкретных приёмов генерации (SCAMPER, аналогии, reversal, first-principles).

Phase 4 — STRESS-TEST (проверка на прочность)

Короткий проход по всем гипотезам.

• Pre-mortem на каждую: «представь, что мы это сделали и через год оно провалилось — почему?»
• Скрытые допущения: «что должно быть истинным, чтобы это работало?»
• Отсев заведомо нежизнеспособных — с явным обоснованием, не молча
• Опционально (тяжёлый случай) — отдельный вызов в роли критика/red-team по shortlist

Антипаттерн: проводить стресс-тест в той же роли/контексте, что и генерацию. Внутренний критик ленив. Лучше — явный сдвиг рамки («теперь я инвестор-скептик»).

[STOP] После Phase 3+4. Вывод: гипотезы со стресс-тестами (можно объединить с выборкой из Phase 2). Вопрос: «Какие гипотезы стоит развить глубже? Что обрезать сразу?». Не идти к Phase 5 без ответа. Конвергенция по неотфильтрованному пользователем списку = выбор за пользователя, что нарушает суть навыка.

Phase 5 — CONVERGE (схождение к 3)

Финал — три варианта. Не пять, не один.

• Явные критерии с весами, зафиксированные ДО оценки (иначе подгонка под фаворита)
• Правило выбора: «качество ≥ порог И максимально различны по осям». Не «топ-3 по сумме баллов» — это даст три варианта одной точки
• Для каждого финалиста: суть, координаты в осях, риски из Phase 4, falsifier, оценка усилий
• Короткий список «отвергнутых ветвей» (1–2 строки на каждую) — почему НЕ они

Финальный вывод MUST соответствовать шаблону references/output-template.md — он совместим с разделом Considered Options в спецификациях по spec-standard.

[STOP] После Phase 5. Вывод: 3 финалиста + рекомендация + отвергнутые ветви. Вопрос: «Какой выбираешь?» — через AskUserQuestion с тремя опциями. Не действовать на основе своей рекомендации, пока пользователь не выбрал.

Phase 6 — EXT-RED (опциональная внешняя red team)

Для тяжёлых задач (архитектурный выбор, продуктовая стратегия, дорогая ошибка) — финалисты прогоняются через cross-provider-review в режиме advisory как идею-критику.

Когда применять:

• Архитектурное решение с долгосрочными последствиями
• Выбор внешней зависимости / vendor lock-in
• Решение, которое будет тяжело откатить
• Пользователь явно попросил «второе мнение»

Когда НЕ применять:

• Лёгкий брэйнсторм по UX-микрорешению
• Решение в обратимой области (можно переделать за день)
• Время дороже качества

Что подавать:

• Финал из Phase 5 в формате output-template.md
• БЕЗ контекста генерации (axes, отвергнутые, рассуждения) — чтобы получить независимую оценку
• Явная инструкция: «red team роль, найти слабые места каждого из 3 вариантов, не балансировать с плюсами»

Результат red team — отдельная секция в финальном выводе, не автоматически меняет рекомендацию. Решение по итогам — за пользователем.

---

Память между сессиями

Брэйнсторм по одной задаче часто идёт в несколько проходов. Чтобы не повторять отвергнутые ветви и не терять оси, навык ведёт лёгкий контекст.

Где сохранять

| Контекст | Путь | |----------|------| | Брэйнсторм привязан к задаче из tasks/<id>/ | tasks/<id>/.context/brainstorm.md | | Брэйнсторм без задачи (свободное обсуждение) | .context/brainstorm-<topic-slug>.md в текущем рабочем каталоге | | Универсальные паттерны брэйнсторма по проекту | MEMORY.md через стандартный механизм памяти (если есть) |

Что сохранять

• Постановка задачи (после Phase 0) — как пользователь подтвердил
• Оси и значения (Phase 1) — чтобы при возобновлении не извлекать заново
• Отвергнутые ветви (Phase 5) — список с обоснованием «почему НЕ»
• Финалисты — 3 варианта в формате output-template
• Дата и итерация — для понимания актуальности

Что НЕ сохранять

• Полный лог рассуждений по каждой гипотезе (раздувает контекст)
• Промежуточные оценки до weighted criteria
• Прямые цитаты из ответов LLM

Поведение при возобновлении

1. На старте /brainstorm — проверить, есть ли релевантный файл по контексту задачи
2. Если есть — прочитать, показать пользователю краткую сводку («в прошлый раз обсуждали такие оси, отвергли X и Y, остановились на 3 финалистах»)
3. Спросить: продолжаем с того же / расширяем оси / начинаем заново?
4. Если «заново» — старый файл переименовать в brainstorm.<дата>.md для архива, не удалять

Шаблон файла памяти

См. references/output-template.md — он же используется и как формат финального вывода, и как формат файла памяти. Дополнительно в начале файла:

# Brainstorm: <тема>

**Задача:** <ID или slug>
**Итерация:** <N>
**Дата:** <ISO>
**Статус:** in_progress | finalized | archived

---

Эвристики

| Сигнал | Действие | |--------|----------| | Все три финалиста похожи | Оси не были ортогональны — вернуться к Phase 1 | | Не получается извлечь 3 оси | Задача либо тривиальная (брэйнсторм не нужен), либо плохо отфреймлена (вернуться к Phase 0) | | Гипотезы получаются «правильными и скучными» | Добавить аналогию из чужого домена или provocation в Phase 3 | | Пользователь говорит «но я хотел не это» | Phase 0 была пропущена/некачественна — переделать фрейминг | | Финалисты все — варианты одного и того же | Конвергенция шла по сумме баллов, а не по diversity-aware правилу | | Решение тяжёлое и долгосрочное | Включить Phase 6 (external red team) | | Брэйнсторм возобновляется по той же теме | Сначала прочитать файл памяти, потом расширять, не повторять | | Агент прошёл 2+ обязательные фазы в одном сообщении | Нарушен принцип диалога. Откатиться к точке последней реальной сверки с пользователем, извиниться, продолжить с гейтами | | Агент задал вопрос, но в том же сообщении уже выдал ответ за следующую фазу | Вопрос риторический — не считается. Переписать сообщение, оборвать на вопросе, ждать ответ | | Финал из 3 финалистов получен без участия пользователя на гейтах 0/1/3+4 | Это не брэйнсторм, это презентация. Признать ошибку, спросить, на каком гейте откатываться, переиграть |

---

Коммуникация с пользователем

Базовое правило диалога описано в разделе «Принцип диалога» выше (таблица гейтов + самопроверка). Здесь — дополнения по формату:

• На каждом гейте — короткое сообщение, не лекция. 3–10 строк вывода + 1 вопрос
• Для дискретного выбора (финалист, стратегия выборки) — AskUserQuestion вместо текстового вопроса
• Финал — компактно: 3 варианта в едином формате (см. references/output-template.md), отвергнутые ветви списком, рекомендация с обоснованием
• При включении Phase 6 — явно предупредить: «отправлю финалистов на внешнюю критику, это займёт N минут»
• Если пользователь явно говорит «не нужно гейтов, давай всё сразу» — это его осознанный отказ, фиксируй и продолжай. Но не подразумевай такой отказ молча

---

Опционально: разделение ролей

Для тяжёлых задач можно делегировать фазы разным агентам:

• Генератор (Phase 3) — высокая температура, фокус на разнообразии
• Критик (Phase 4) — отдельный вызов в роли скептика, без видимости генерации
• Синтезатор (Phase 5) — независимая оценка по критериям

Это дороже, но даёт меньше «диверсити-театра». В лёгких задачах — один агент проходит все фазы сам.

---

Связь с другими навыками и правилами

| Навык/правило | Связь | |---------------|-------| | spec-standard | Финал брэйнсторма ложится в Considered Options/ADR спецификации в формате output-template.md | | cross-provider-review | Используется в Phase 6 (опционально) для внешней red team финалистов | | framework/workflows/full-cycle.md | В фазе 1 (Analyst) брэйнсторм — внутренний шаг анализа | | agent-context-protocol | Файл памяти brainstorm.md лежит рядом с {role}-context.md в .context/ |

---

depends_on:

• framework/skills/spec-writing/spec-standard/SKILL.md
• framework/skills/tool-usage/review/cross-provider-review/SKILL.md
• framework/rules/agent-context-protocol.md references:
• references/prompt-techniques.md
• references/output-template.md

---