version: "1.0.1" name: brainstorm description: Use for структурированного мозгового штурма при выборе подхода, поиске альтернатив или явном вызове /brainstorm. Helps развернуть пространство гипотез и свести результат к 3 различным жизнеспособным вариантам, борясь с mode collapse LLM.

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

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

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

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

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

Принцип

Шесть фаз, идущих от расширения к сужению, плюс опциональная седьмая (внешний 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

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

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 — отдельная секция в финальном выводе, не автоматически меняет рекомендацию. Решение по итогам — за пользователем.

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

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

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

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

• Постановка задачи (после 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

Эвристики

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

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

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

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

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

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

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

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

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