# Навык агента «Мозговой штурм: от идей к дизайну» > Превратите туманные идеи в чёткие, проверенные проекты и спецификации с помощью структурированного диалога и дисциплинированного мышления. Это предотвращает преждевременную реализацию и несогласованные решения. Начните проектирование с ясности за секунды. - Canonical: https://nanoskill.ai/ru/skills/brainstorming-ideas-to-designs - Markdown: https://nanoskill.ai/ru/skills/brainstorming-ideas-to-designs.md - Author: sickn33 - Published: 2026-05-23T00:10:47.865Z - Updated: 2026-07-15T13:36:27.068Z - Language: ru - Source type: github - Popularity signal: 38396 ## Sources - https://github.com/sickn33/antigravity-awesome-skills ## Install ```shell npx skills add https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/brainstorming ``` ## About Навык агента «Мозговой штурм: от идей к дизайну» помогает преобразовывать туманные концепции в чёткие, проверенные проекты и спецификации с помощью структурированного, совместного процесса. Выступая в роли фасилитатора дизайна и старшего рецензента, он ведёт пользователей через дисциплинированный процесс рассуждений, гарантируя, что идеи тщательно проверены и поняты до начала любой реализации. Это предотвращает распространённые ошибки, такие как преждевременное кодирование, скрытые предположения, несогласованные решения и хрупкие системы, что в итоге приводит к более надёжным и эффективным результатам. Этот навык требует методичного подхода, начиная с обязательного шага по изучению текущего контекста проекта, включая существующую документацию и предыдущие решения. Затем следует этап целенаправленных вопросов и ответов для установления общей ясности относительно цели, пользователей, ограничений и нефункциональных требований. Критически важный шаг «Фиксация понимания» обеспечивает явное подтверждение намерений перед изучением подходов к дизайну, которые представляются пошагово с чёткими компромиссами. На протяжении всего процесса навык ведёт обязательный журнал решений, документируя выборы, альтернативы и обоснования для обеспечения прозрачности и создания истории изменений. После валидации финальный дизайн документируется, и может произойти опциональная передача реализации. Этот структурированный рабочий процесс идеально подходит для проверки новых функций, проектирования системных архитектур и уточнения потоков поведения пользователей, гарантируя, что все основные предположения задокументированы, а ключевые риски признаны до начала работы. ## Key features - **Структурированная фасилитация проектирования**: Работает как фасилитатор проектирования и старший рецензент, направляя процесс превращения сырых идей в четкие, проверенные проекты и спецификации до начала реализации. - **Предотвращает преждевременную реализацию**: Обеспечивает дисциплинированный подход, запрещая реализацию, написание кода или изменение поведения во время активности, фокусируясь исключительно на проверке проекта. - **Обязательное понимание контекста**: Требует тщательного анализа текущего состояния проекта, включая файлы, документацию и предыдущие решения, для выявления существующих элементов и предлагаемых изменений. - **Поэтапное представление проекта**: Разбивает проектные предложения на удобные разделы (максимум 200-300 слов), запрашивая подтверждение после каждого, чтобы обеспечить постоянное соответствие и проверку. - **Комплексное протоколирование решений**: Ведет текущий журнал всех решений, включая рассмотренные альтернативы и причины выбора, обеспечивая прозрачность и сохранение документации для будущего использования. ## Use cases - **Проверка новых функций**: Используйте этот навык для тщательного мозгового штурма и проверки идей новых функций, гарантируя их соответствие целям проекта и потребностям пользователей до начала любой разработки. - **Проектирование архитектуры системы**: Применяйте структурированный процесс мозгового штурма для проектирования надежных архитектур системы, уточняя нефункциональные требования и изучая различные подходы. - **Уточнение потоков поведения пользователей**: Содействуйте обсуждениям для уточнения потоков поведения пользователей, выявляя крайние случаи и обеспечивая четкое понимание взаимодействия пользователей и реакции системы. ## Result preview Посмотрите реальный прототип UI-дизайна, созданный этим навыком агента. ![brainstorming-demo-01](https://file.nanoskill.ai/brainstorming-demo-01.jpg) ![brainstorming-demo-02](https://file.nanoskill.ai/brainstorming-demo-02.jpg) ![brainstorming-demo-03](https://file.nanoskill.ai/brainstorming-demo-03.jpg) ![brainstorming-demo-04](https://file.nanoskill.ai/brainstorming-demo-04.jpg) ## Result walkthrough ### Шаг 1：Установка Добавьте навык в своего агента ![brainstorming-step-1](https://file.nanoskill.ai/brainstorming-step-1.jpg) ### Шаг 2：Опишите свою концепцию Начните с идеи или задачи, которую хотите исследовать. ![brainstorming-step-2](https://file.nanoskill.ai/brainstorming-step-2.jpg) ### Шаг 3：Уточните дизайн Получите рекомендации по дизайну и чётко сформулированное предложение. ![brainstorming-step-3](https://file.nanoskill.ai/brainstorming-step-3.jpg) ## Skill definition # Мозговой штурм: от идей к проектированию ## Цель Превращать сырые идеи в **чёткие, проверенные проектные решения и спецификации** через структурированный диалог **до начала любой реализации**. Эта способность существует для предотвращения: - преждевременной реализации - скрытых предположений - несогласованных решений - хрупких систем Вам **не разрешено** реализовывать, программировать или изменять поведение, пока эта способность активна. --- ## Режим работы Вы действуете как **фасилитатор проектирования и старший рецензент**, а не как разработчик. - Никакой творческой реализации - Никаких спекулятивных функций - Никаких молчаливых предположений - Никакого пропуска вперёд Ваша задача — **замедлить процесс ровно настолько, чтобы сделать его правильно**. --- ## Процесс ### 1️⃣ Понять текущий контекст (обязательный первый шаг) Прежде чем задавать вопросы: - Ознакомьтесь с текущим состоянием проекта (если доступно): - файлы - документация - планы - предыдущие решения - Определите, что уже существует, а что предлагается - Отметьте ограничения, которые кажутся неявными, но неподтверждёнными **Пока не проектируйте.** --- ### 2️⃣ Понимание идеи (один вопрос за раз) Ваша цель здесь — **общая ясность**, а не скорость. **Правила:** - Задавайте **по одному вопросу за сообщение** - Предпочитайте **вопросы с выбором ответа**, когда это возможно - Используйте открытые вопросы только при необходимости - Если тема требует глубины, разбейте её на несколько вопросов Сосредоточьтесь на понимании: - цели - целевых пользователей - ограничений - критериев успеха - явных нецелей --- ### 3️⃣ Нефункциональные требования (обязательно) Вы ДОЛЖНЫ явно прояснить или предложить предположения для: - Ожиданий по производительности - Масштаба (пользователи, данные, трафик) - Ограничений безопасности или конфиденциальности - Требований к надёжности / доступности - Ожиданий по обслуживанию и владению Если пользователь не уверен: - Предложите разумные значения по умолчанию - Чётко пометьте их как **предположения** --- ### 4️⃣ Фиксация понимания (жёсткий шлюз) Прежде чем предлагать **любой дизайн**, вы ДОЛЖНЫ сделать паузу и выполнить следующее: #### Резюме понимания Предоставьте краткое резюме (5–7 пунктов), охватывающее: - Что создаётся - Зачем это нужно - Для кого - Ключевые ограничения - Явные нецели #### Предположения Явно перечислите все предположения. #### Открытые вопросы Перечислите нерешённые вопросы, если таковые имеются. Затем спросите: > «Это точно отражает ваши намерения? > Пожалуйста, подтвердите или исправьте что-либо, прежде чем мы перейдём к проектированию.» **НЕ продолжайте до получения явного подтверждения.** --- ### 5️⃣ Изучите подходы к проектированию Как только понимание подтверждено: - Предложите **2–3 жизнеспособных подхода** - Начните с **рекомендуемого варианта** - Чётко объясните компромиссы: - сложность - расширяемость - риск - обслуживание - Избегайте преждевременной оптимизации (**YAGNI безжалостно**) Это всё ещё **не** окончательный дизайн. --- ### 6️⃣ Представьте дизайн (постепенно) При представлении дизайна: - Разбейте его на разделы не более **200–300 слов** - После каждого раздела спрашивайте: > «Пока всё верно?» Охватите, по мере необходимости: - Архитектуру - Компоненты - Поток данных - Обработку ошибок - Пограничные случаи - Стратегию тестирования --- ### 7️⃣ Журнал решений (обязательно) Ведите текущий **журнал решений** на протяжении всего обсуждения дизайна. Для каждого решения: - Что было решено - Рассмотренные альтернативы - Почему был выбран этот вариант Этот журнал должен быть сохранён для документирования. --- ## После проектирования ### 📄 Документация Как только дизайн утверждён: - Запишите окончательный дизайн в долговечном, общедоступном формате (например, Markdown) - Включите: - Резюме понимания - Предположения - Журнал решений - Окончательный дизайн Сохраните документ в соответствии со стандартным рабочим процессом проекта. --- ### 🛠️ Передача на реализацию (опционально) Только после завершения документации спросите: > «Готовы приступить к реализации?» Если да: - Создайте явный план реализации - Изолируйте работу, если рабочий процесс это поддерживает - Действуйте постепенно --- ## Критерии выхода (условия жёсткой остановки) Вы можете выйти из режима мозгового штурма **только когда всё нижеперечисленное верно**: - Фиксация понимания подтверждена - По крайней мере один подход к проектированию явно принят - Основные предположения задокументированы - Ключевые риски признаны - Журнал решений завершён Если какой-либо критерий не выполнен: - Продолжайте доработку - **НЕ переходите к реализации** --- ## Ключевые принципы (не подлежат обсуждению) - Один вопрос за раз - Предположения должны быть явными - Изучайте альтернативы - Проверяйте постепенно - Предпочитайте ясность хитроумию - Будьте готовы вернуться и уточнить - **YAGNI безжалостно** --- Если дизайн имеет высокое влияние, высокий риск или требует повышенной уверенности, вы ДОЛЖНЫ передать окончательный дизайн и Журнал решений навыку `multi-agent-brainstorming` перед реализацией. ## Когда использовать Этот навык применим для выполнения рабочего процесса или действий, описанных в обзоре. ## Ограничения - Используйте этот навык только когда задача чётко соответствует описанному выше объёму. - Не рассматривайте вывод как замену валидации, тестирования или экспертной оценки, специфичных для окружения. - Остановитесь и запросите разъяснения, если отсутствуют необходимые входные данные, разрешения, границы безопасности или критерии успеха. ## FAQ ### Какова основная цель навыка мозгового штурма? Основная цель навыка мозгового штурма — преобразовывать сырые идеи в четкие, проверенные проекты и спецификации посредством структурированного диалога до начала любой реализации. Он действует как фасилитатор проектирования и старший рецензент. ### Можно ли использовать этот навык для написания кода или реализации функций? Нет, вам явно запрещено реализовывать, писать код или изменять поведение, пока этот навык активен. Его единственная цель — проектирование и проверка, чтобы предотвратить преждевременную реализацию. ### Как навык обеспечивает общую ясность во время мозгового штурма? Навык обеспечивает общую ясность, требуя задавать по одному вопросу за сообщение, предпочитая вопросы с несколькими вариантами ответов и фокусируясь на понимании цели, целевых пользователей, ограничений и критериев успеха перед переходом к проектированию. ### Что такое «нефункциональные требования» и почему они обязательны? Нефункциональные требования (НФТ) включают ожидания по производительности, масштабируемости, безопасности, надежности и обслуживаемости. Они обязательны для уточнения или предложения допущений, обеспечивая всесторонний проект, учитывающий критические атрибуты системы. ### Что такое «блокировка понимания» и когда она происходит? Блокировка понимания — это жесткий этап, на котором необходимо остановиться и предоставить краткое изложение идеи, перечислить допущения и открытые вопросы. Нельзя переходить к проектированию, пока не будет получено явное подтверждение того, что изложение точно отражает намерения пользователя. ### Что происходит после проверки проекта? После проверки проекта навык требует документирования окончательного проекта в долговременном формате, включая резюме понимания, допущения и журнал решений. Затем может быть выполнена необязательная передача реализации.