brainstorming

Brainstorming от obra — это workflow для превращения неоформленной идеи в согласованный дизайн или спецификацию до начала реализации. Источник задаёт жёсткое правило: агент не должен вызывать implementation skill, писать код, создавать scaffolding или менять поведение проекта, пока не представил дизайн и не получил одобрение пользователя. Поэтому карточка полезна в начале новой функции, компонента или изменения поведения, когда ещё нужно понять цель, границы и критерии успеха, а не сразу выбирать файлы и команды. Работа начинается с изучения текущего контекста проекта: файлов, документации и последних изменений. Затем агент оценивает размер задачи. Если запрос объединяет независимые подсистемы, workflow предлагает сначала разделить его на отдельные подзадачи и выбрать порядок; слишком большой проект не следует пытаться уместить в одну спецификацию. Для обычной задачи вопросы задаются по одному, чтобы последовательно уточнить назначение, ограничения и ожидаемый результат. Источник отдельно рекомендует вопросы с вариантами ответа, когда это помогает быстрее зафиксировать выбор, но не требует превращать каждое обсуждение в анкету. После понимания задачи skill требует предложить два или три подхода с компромиссами и рекомендацией. Варианты должны учитывать YAGNI: из решения удаляются необязательные функции и заранее не строится инфраструктура «на будущее». Затем дизайн представляется частями, масштабированными под сложность задачи. В описании должны быть покрыты архитектура, компоненты, поток данных, обработка ошибок и тестирование, но простой запрос не нуждается в искусственно длинной спецификации. Пользователь получает возможность одобрить каждый раздел и попросить пересмотр, если решение не соответствует цели. Когда дизайн принят, workflow требует сохранить его в docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md, выполнить короткую самопроверку и попросить пользователя просмотреть письменную спецификацию. Самопроверка ищет незаполненные места и слова вроде TBD или TODO, противоречия между архитектурой и поведением, расплывчатые требования и выход за рамки одной implementation plan. Только после пользовательского одобрения начинается переход к writing-plans skill. Это делает документ границей между обсуждением и реализацией: наличие файла само по себе не означает, что код уже написан или что план утверждён. Визуальный companion применяется условно. Его предлагают только в момент, когда макет, wireframe, схема или визуальное сравнение действительно понятнее текста; для концептуальных вопросов, ограничений и выбора подходов источник рекомендует обычный текстовый диалог. Если визуальный вопрос не возникает, браузерный companion не нужен. Такой порог ограничивает лишние артефакты и не превращает любой разговор о UI в обязательный mockup. Практический сценарий выглядит так: открыть контекст репозитория, определить scope, задать уточняющие вопросы, сравнить два или три минимальных подхода, согласовать дизайн по разделам, записать и проверить спецификацию, дождаться её review и только затем передать работу в планирование. Ограничения важны: skill не является реализацией, не обещает автоматически исправить код, не выбирает требования за пользователя и требует явного approval перед дальнейшими implementation steps. Для срочной маленькой правки этот полный gate может быть избыточен; его назначение — снизить риск незаявленных предположений в задачах, где решение ещё не определено.