| name | brainstorming |
| description | Используй ПЕРЕД любой работой по созданию или изменению функциональности. Исследует намерения пользователя, требования и дизайн до начала реализации. |
Брейнсторминг: от идеи к дизайну
Помоги превратить идею в проработанный дизайн через диалог.
Начни с изучения текущего состояния проекта, затем задавай уточняющие вопросы по одному. Когда поймёшь что строим — представь дизайн и получи одобрение пользователя.
НЕ вызывай никакие скиллы реализации, не пиши код, не трогай конфиги до тех пор, пока не представил дизайн и пользователь его не одобрил. Это правило действует для ЛЮБОГО проекта, независимо от кажущейся простоты.
Антипаттерн: «Это слишком просто, чтобы нужен был дизайн»
Через этот процесс проходит каждый проект. Небольшое изменение шаблона, новый скрипт, правка конфига — всё. «Простые» проекты — это где невысказанные допущения приводят к наибольшим потерям. Дизайн может быть коротким (пара предложений для совсем простых задач), но НУЖНО его представить и получить одобрение.
Чеклист
Создай задачу для каждого пункта и выполняй по порядку:
- Изучить контекст проекта — файлы, документы, последние коммиты
- Задать уточняющие вопросы — по одному, понять цель/ограничения/критерии успеха
- Предложить 2-3 подхода — с компромиссами и рекомендацией
- Представить дизайн — по разделам, соразмерно сложности, получить одобрение после каждого
- Написать дизайн-документ — сохранить в
docs/specs/YYYY-MM-DD-<тема>-design.md
- Само-ревью спека — быстрая проверка на плейсхолдеры, противоречия, двусмысленности
- Пользователь проверяет спек — попросить проверить файл перед переходом к плану
- Спросить пользователя о следующем шаге — 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/, если её нет
Само-ревью спека:
После записи документа посмотри на него свежим взглядом:
- Проверка плейсхолдеров: Есть «TBD», «TODO», неполные разделы или расплывчатые требования? Исправь.
- Внутренняя согласованность: Противоречат ли разделы друг другу? Совпадает ли архитектура с описанием функций?
- Проверка масштаба: Достаточно ли сфокусировано для одного плана реализации или нужна декомпозиция?
- Проверка на двусмысленность: Можно ли любое требование интерпретировать двояко? Выбери одну интерпретацию и сделай её явной.
Исправляй на месте. Нет нужды перепроверять — просто исправь и двигайся дальше.
Гейт проверки пользователем:
После само-ревью попроси пользователя проверить спек:
«Спек записан в <путь>. Пожалуйста, проверь его и скажи, если хочешь что-то изменить, прежде чем переходить к плану реализации.»
Жди ответа пользователя. Если нужны правки — внеси и повтори само-ревью. Переходи дальше только после одобрения.
Переход к следующему этапу:
После одобрения спека спроси пользователя, как продолжить:
«Спек одобрен. Как продолжим?
- writing-plans сейчас — создам план реализации в текущем контекстном окне.
- next-stage-prompt — сгенерирую готовый промпт со ссылкой на спек, чтобы ты вставил его в новый чистый контекст.»
Жди ответа и вызови выбранный скилл:
- Вариант 1 → вызови
writing-plans
- Вариант 2 → вызови
next-stage-prompt
НЕ вызывай никакой другой скилл и не выбирай за пользователя.
Ключевые принципы
- Один вопрос за раз — не перегружай несколькими вопросами
- Предпочитай вопросы с вариантами — легче отвечать, чем на открытые
- YAGNI безжалостно — убирай лишние функции из всех дизайнов
- Исследуй альтернативы — всегда предлагай 2-3 подхода до выбора
- Инкрементальная валидация — представляй дизайн, получай одобрение перед движением вперёд
- Будь гибким — возвращайся и уточняй, если что-то не так
