Превращение идей в дизайн (брейнсторминг)

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

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

<HARD-GATE> НЕ вызывайте никакой скилл реализации, не пишите код, не создавайте каркас проекта и не предпринимайте никаких действий по реализации, пока не представили дизайн и пользователь его не одобрил. Это касается КАЖДОГО проекта, независимо от кажущейся простоты. </HARD-GATE>

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

Каждый проект проходит через этот процесс. Список дел, утилита из одной функции, изменение конфига — все они. «Простые» проекты — это как раз там, где непроверенные допущения приводят к наибольшему количеству напрасной работы. Дизайн может быть коротким (несколько предложений для действительно простых проектов), но вы ОБЯЗАНЫ его представить и получить одобрение.

Чек-лист

Вы ОБЯЗАНЫ создать задачу для каждого из пунктов и выполнить их по порядку:

1. Изучить контекст проекта — проверить файлы, документацию, недавние коммиты
2. Предложить визуального компаньона вовремя — НЕ заранее. В первый раз, когда вопрос будет действительно понятнее показать, чем описать, предложите его тогда (отдельным сообщением); при согласии откроется вкладка браузера. Если визуальный вопрос так и не возникнет — не предлагайте вовсе. См. раздел «Визуальный компаньон» ниже.
3. Задать уточняющие вопросы — по одному за раз, понять назначение/ограничения/критерии успеха
4. Предложить 2–3 подхода — с компромиссами и вашей рекомендацией
5. Представить дизайн — секциями, масштабированными под их сложность, получая одобрение пользователя после каждой секции
6. Написать дизайн-документ — сохранить в docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md и закоммитить
7. Самопроверка спецификации — быстрая встроенная проверка на заглушки, противоречия, неоднозначность, объём (см. ниже)
8. Пользователь проверяет письменную спецификацию — попросите пользователя просмотреть файл спецификации перед продолжением
9. Переход к реализации — вызвать скилл writing-plans для создания плана реализации

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

digraph brainstorming {
    "Explore project context" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write design doc" [shape=box];
    "Spec self-review\n(fix inline)" [shape=box];
    "User reviews spec?" [shape=diamond];
    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Spec self-review\n(fix inline)";
    "Spec self-review\n(fix inline)" -> "User reviews spec?";
    "User reviews spec?" -> "Write design doc" [label="changes requested"];
    "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
}

Терминальное состояние — это вызов writing-plans. НЕ вызывайте frontend-design, mcp-builder или любой другой скилл реализации. ЕДИНСТВЕННЫЙ скилл, который вы вызываете после брейнсторминга, — это writing-plans.

Процесс

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

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

Изучение подходов:

• Предложите 2–3 разных подхода с компромиссами
• Представьте варианты в разговорной форме с вашей рекомендацией и обоснованием
• Начинайте с рекомендуемого варианта и объясняйте, почему он

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

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

Проектируйте ради изоляции и ясности:

• Разбейте систему на меньшие единицы, каждая из которых имеет одно ясное назначение, общается через хорошо определённые интерфейсы и может быть понята и протестирована независимо
• Для каждой единицы вы должны уметь ответить: что она делает, как ею пользоваться и от чего она зависит?
• Может ли кто-то понять, что делает единица, не читая её внутренности? Можете ли вы изменить внутренности, не сломав потребителей? Если нет — границы нужно доработать.
• Меньшие, чётко ограниченные единицы и вам самим даются легче — вы лучше рассуждаете о коде, который умещается в контексте целиком, а правки надёжнее, когда файлы сфокусированы. Когда файл разрастается — это часто сигнал, что он делает слишком много.

Работа в существующих кодовых базах:

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

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

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

• Запишите проверенный дизайн (спецификацию) в docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
  • (Предпочтения пользователя по расположению спецификации переопределяют этот путь по умолчанию)
• Используйте скилл elements-of-style:writing-clearly-and-concisely, если он доступен
• Закоммитьте дизайн-документ в git

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

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

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

Гейт пользовательской проверки:
После прохождения цикла самопроверки попросите пользователя просмотреть письменную спецификацию перед продолжением:

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

Дождитесь ответа пользователя. Если он просит изменения — внесите их и повторите цикл проверки спецификации. Продолжайте только после одобрения пользователя.

Реализация:

• Вызовите скилл writing-plans для создания детального плана реализации
• НЕ вызывайте никакой другой скилл. writing-plans — это следующий шаг.

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

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

Визуальный компаньон

Браузерный компаньон для показа макетов, диаграмм и визуальных вариантов во время брейнсторминга. Доступен как инструмент — не как режим. Принятие компаньона означает, что он доступен для вопросов, выигрывающих от визуальной подачи; это НЕ значит, что каждый вопрос идёт через браузер.

Предложение компаньона (вовремя): НЕ предлагайте его заранее. Дождитесь момента, когда вопрос будет действительно понятнее показать, чем рассказать — реальный вопрос о макете/раскладке/диаграмме, а не просто тема об интерфейсе. В первый раз, когда это случится, предложите его тогда, отдельным сообщением:

«Следующую часть, возможно, будет проще, если я покажу — я могу собирать макеты, диаграммы и сравнения во вкладке браузера по ходу дела. Это всё ещё ново и может быть затратно по токенам. Включить? Я открою её для вас.»

Это предложение ДОЛЖНО быть отдельным сообщением. Только предложение — без уточняющего вопроса, резюме или другого содержимого. Дождитесь ответа пользователя. Если согласится — запустите сервер с --open, чтобы браузер открылся на первом экране автоматически. Если откажется — продолжайте только текстом и больше не предлагайте, пока он сам не поднимет тему.

Решение по каждому вопросу: Даже после согласия пользователя решайте ДЛЯ КАЖДОГО ВОПРОСА, использовать браузер или терминал. Критерий: пользователь поймёт это лучше, увидев или прочитав?

• Используйте браузер для контента, который ЯВЛЯЕТСЯ визуальным — макеты, вайрфреймы, сравнения раскладок, диаграммы архитектуры, дизайны бок о бок
• Используйте терминал для контента, который является текстом — вопросы о требованиях, концептуальный выбор, списки компромиссов, текстовые варианты A/B/C/D, решения по объёму

Вопрос на тему интерфейса не является автоматически визуальным вопросом. «Что значит „характер“ в этом контексте?» — концептуальный вопрос, используйте терминал. «Какая раскладка мастера работает лучше?» — визуальный вопрос, используйте браузер.

Если пользователь согласен на компаньона, прочтите подробное руководство перед продолжением: skills/brainstorming/visual-companion.md