brainstorming

name	brainstorming
description	Используй ПЕРЕД любой работой по созданию или изменению функциональности. Исследует намерения пользователя, требования и дизайн до начала реализации.

Брейнсторминг: от идеи к дизайну

Помоги превратить идею в проработанный дизайн через диалог.

Начни с изучения текущего состояния проекта, затем задавай уточняющие вопросы по одному. Когда поймёшь что строим — представь дизайн и получи одобрение пользователя.

НЕ вызывай никакие скиллы реализации, не пиши код, не трогай конфиги до тех пор, пока не представил дизайн и пользователь его не одобрил. Это правило действует для ЛЮБОГО проекта, независимо от кажущейся простоты.

Антипаттерн: «Это слишком просто, чтобы нужен был дизайн»

Через этот процесс проходит каждый проект. Небольшое изменение шаблона, новый скрипт, правка конфига — всё. «Простые» проекты — это где невысказанные допущения приводят к наибольшим потерям. Дизайн может быть коротким (пара предложений для совсем простых задач), но НУЖНО его представить и получить одобрение.

Чеклист

Создай задачу для каждого пункта и выполняй по порядку:

1. Изучить контекст проекта — файлы, документы, последние коммиты
2. Задать уточняющие вопросы — по одному, понять цель/ограничения/критерии успеха
3. Предложить 2-3 подхода — с компромиссами и рекомендацией
4. Представить дизайн — по разделам, соразмерно сложности, получить одобрение после каждого
5. Написать дизайн-документ — сохранить в docs/specs/YYYY-MM-DD-<тема>-design.md
6. Само-ревью спека — быстрая проверка на плейсхолдеры, противоречия, двусмысленности
7. Пользователь проверяет спек — попросить проверить файл перед переходом к плану
8. Спросить пользователя о следующем шаге — writing-plans сейчас или next-stage-prompt для нового контекста

Схема процесса

См. references/process-diagram.md

Конечное состояние — выбор пользователя между writing-plans и next-stage-prompt. Никакой другой скилл из брейнсторминга не вызывается.

Процесс

Понимание идеи:

• Сначала изучи текущее состояние проекта (файлы, документы, последние изменения)
• До детальных вопросов оцени масштаб: если запрос описывает несколько независимых подсистем — скажи об этом сразу. Не трать вопросы на детали проекта, который нужно сначала декомпозировать.
• Если проект слишком большой для одного спека — помоги декомпозировать на подпроекты. Затем проведи брейнсторминг первого подпроекта. Каждый подпроект получает свой цикл спек → план → реализация.
• Для проектов подходящего масштаба задавай вопросы по одному
• Предпочитай вопросы с вариантами ответов, но открытые тоже допустимы
• Только один вопрос в сообщении — если тема требует нескольких вопросов, разбей их
• Фокус: цель, ограничения, критерии успеха

Исследование подходов:

• Предложи 2-3 разных подхода с компромиссами
• Веди с рекомендованным вариантом и объясни почему
• Изложи варианты разговорно, не сухо

Представление дизайна:

• Когда понял что строим — представь дизайн
• Масштабируй каждый раздел к его сложности: пара предложений для простого, больше для сложного
• Спрашивай после каждого раздела, всё ли правильно
• Охвати: архитектуру, компоненты, поток данных, обработку ошибок, тестирование
• Будь готов вернуться и уточнить, если что-то не так

Работа в существующей кодовой базе:

• Изучи текущую структуру до предложения изменений. Следуй существующим паттернам.
• Если в существующем коде есть проблемы, влияющие на работу — включи точечные улучшения в дизайн.
• Не предлагай несвязанный рефакторинг. Фокусируйся на текущей цели.

После дизайна

Документация:

• Запиши утверждённый дизайн (спек) в docs/specs/YYYY-MM-DD-<тема>-design.md
  • (Предпочтения пользователя по расположению переопределяют дефолт)
• Создай директорию docs/specs/, если её нет

Само-ревью спека: После записи документа посмотри на него свежим взглядом:

1. Проверка плейсхолдеров: Есть «TBD», «TODO», неполные разделы или расплывчатые требования? Исправь.
2. Внутренняя согласованность: Противоречат ли разделы друг другу? Совпадает ли архитектура с описанием функций?
3. Проверка масштаба: Достаточно ли сфокусировано для одного плана реализации или нужна декомпозиция?
4. Проверка на двусмысленность: Можно ли любое требование интерпретировать двояко? Выбери одну интерпретацию и сделай её явной.

Исправляй на месте. Нет нужды перепроверять — просто исправь и двигайся дальше.

Гейт проверки пользователем: После само-ревью попроси пользователя проверить спек:

«Спек записан в <путь>. Пожалуйста, проверь его и скажи, если хочешь что-то изменить, прежде чем переходить к плану реализации.»

Жди ответа пользователя. Если нужны правки — внеси и повтори само-ревью. Переходи дальше только после одобрения.

Переход к следующему этапу:

После одобрения спека спроси пользователя, как продолжить:

«Спек одобрен. Как продолжим?

1. writing-plans сейчас — создам план реализации в текущем контекстном окне.
2. next-stage-prompt — сгенерирую готовый промпт со ссылкой на спек, чтобы ты вставил его в новый чистый контекст.»

Жди ответа и вызови выбранный скилл:

• Вариант 1 → вызови writing-plans
• Вариант 2 → вызови next-stage-prompt

НЕ вызывай никакой другой скилл и не выбирай за пользователя.

Ключевые принципы

• Один вопрос за раз — не перегружай несколькими вопросами
• Предпочитай вопросы с вариантами — легче отвечать, чем на открытые
• YAGNI безжалостно — убирай лишние функции из всех дизайнов
• Исследуй альтернативы — всегда предлагай 2-3 подхода до выбора
• Инкрементальная валидация — представляй дизайн, получай одобрение перед движением вперёд
• Будь гибким — возвращайся и уточняй, если что-то не так