Все 30 промптов
Полный комплект для копирования: 20 шагов основного маршрута, 4 дополнительных модуля и 6 служебных промптов. Текст каждого промпта приведён слово в слово по рабочему комплекту.
- основной маршрут
- 20
- модули
- 4
- служебные
- 6
Основной маршрут
20 шагов от брифа до разбора результатов. Идут по порядку.
Начать с нуля: собрать бриф
- когда брать
- Первое сообщение в рабочем диалоге. Подходит, даже когда игровой идеи еще нет.
- что подготовить
- Материалы о продукте и аудитории, если они уже есть. Отсутствие идеи не мешает начать.
Ты — продюсер игровых прогревающих воронок и гейм-дизайнер. Помоги мне по шагам создать воронку к моему продукту. Пока не пиши готовый сценарий, тексты сообщений или код.
Мои исходные материалы: [приложить или описать].
Что уже известно: [продукт / аудитория / желаемое действие / площадка].
Что пока не определено: [можно написать «игровой идеи нет»].
Сначала изучи материалы и отдели подтвержденную информацию от предположений. Не переноси сведения из других проектов без моего подтверждения. Не придумывай за меня цены, обещания, методику и характеристики аудитории.
Помоги определить: что продаем и за сколько; кто и с какой ситуацией приходит; насколько человек знаком с экспертом и продуктом; откуда он попадает в воронку; в какой стране находится аудитория; какое целевое действие нужно в финале; какую реальную пользу участник получит до предложения купить; какие есть ограничения по сложности, длительности и ресурсам.
Работай в диалоге. Задавай по одному содержательному вопросу и не спрашивай повторно то, что уже есть в материалах. Когда я затрудняюсь, предложи варианты как гипотезы, а не как решенные за меня условия.
Порядок работы: бриф → данные и аналитика → игровая идея → скелет → тексты и визуал → проверка → сборка и тестирование. Не переходи на следующий этап без согласования результата текущего.
После каждого этапа кратко фиксируй принятое решение, открытые вопросы и наше место в маршруте. Согласованные результаты сохраняй в Markdown-файлы; если инструментов сохранения нет, выдай их полный текст и не утверждай, что файл создан.
Сейчас покажи, что уже понятно из моих материалов, и задай первый недостающий вопрос.Что получится: Согласованный бриф 00_brief.md; игровая концепция пока не выбрана.
Основание в вебинаре: 00:40:28–00:46:32; 00:51:20–00:52:06; 01:06:34–01:08:02.
Оговорка: Восстановлено по подходу вебинара. По одному вопросу, карта текущего этапа и правила фиксации решений — добавленная организация работы.
Определить данные и аналитику
- когда брать
- После брифа, до игровых вопросов и написания сценария.
- что подготовить
- Согласованный бриф 00_brief.md.
Используй согласованный бриф. Пока не придумывай игровые вопросы, диалоги и тексты. Сначала определи, какую информацию мы должны получать из воронки.
Раздели ее на три группы:
1. Маркетинг: источник входа, площадка, прохождение этапов, остановки, время между шагами, возвраты, переходы к предложению и конверсии.
2. Продажи: какой продукт интересен, какой следующий шаг нужен человеку, его предпочтения по формату помощи, готовность обсуждать покупку и причины отказа, если это уместно для нашей задачи.
3. Кастдев: ситуация на входе, основной запрос, предыдущие попытки, желаемое изменение и обратная связь о полученной пользе.
Для каждого поля укажи: что узнаем; зачем нам это; какое решение на основе этого примем; откуда получим данные — из действия, технического события или ответа; обязательно ли поле; как обозначаем отсутствие ответа.
Не превращай примерный список в обязательную анкету. Удали поля без понятного применения. Отдельно покажи, что собирается без вопросов, что должно появиться внутри сюжета, а что можно спросить только по желанию.
Добавь события, которые должен записывать бот, и формулы ключевых конверсий с понятными числителем и знаменателем. Раздели показ предложения, нажатие кнопки оплаты и подтвержденную оплату. Если событие нельзя достоверно наблюдать, не называй его измеренным.
Результат оформи как спецификацию 01_data_and_analytics.md. В конце перечисли решения, которые надо согласовать. Формулировки вопросов для игрока пока не пиши.Что получится: Первый основной артефакт: 01_data_and_analytics.md.
Основание в вебинаре: 00:46:14–00:46:52; 00:53:57–00:56:36; 01:02:57–01:11:57.
Оговорка: Структура трех групп — из вебинара; разделение клика и подтвержденной оплаты и проверка наблюдаемости — добавленные уточнения.
Проверить полезность собираемых данных
- когда брать
- Когда список данных уже составлен, но еще не встроен в игру.
- что подготовить
- Бриф и 01_data_and_analytics.md.
Оцени нашу спецификацию данных от 1 до 100 в двух ролях: маркетолог и руководитель отдела продаж. Это экспертная оценка проекта, а не прогноз конверсии.
Как маркетолог проверь: поймем ли мы, кто пришел, откуда пришел, на каком шаге остановился, получил ли результат и вернулся ли после напоминания? Сможем ли сравнить прохождение и покупки у разных сегментов и источников?
Как руководитель отдела продаж проверь: поможет ли собранное понять запрос клиента, подходящий продукт, предпочтительный формат помощи и препятствие перед следующим шагом? Какие сведения сотрудник сможет использовать в разговоре, а какие будут лишь догадкой?
Для каждого замечания укажи: чего не хватает или что лишнее; почему это важно; какое поле или событие нужно изменить. Не расширяй список ради полноты. Не делай вывод о реальной платежеспособности только по одному игровому выбору.
Отдельно проверь нагрузку на участника: что можно понять без вопроса, что оставить в сюжете, что убрать или сделать необязательным. Нам нужна игра с полезной обратной связью, а не длинное интервью.
Сначала выдай оценки с обоснованием и предложенные изменения. Не пиши формулировки вопросов для игрока. После моего согласования обнови 01_data_and_analytics.md и покажи, что именно изменилось.Что получится: Уточненный первый артефакт без лишних вопросов и пропущенных измерений.
Основание в вебинаре: 00:56:43–01:01:45; 01:04:34–01:07:48; 01:08:22–01:10:45.
Оговорка: Оценка в двух ролях — по вебинару. Ограничения интерпретации оценок и ответов добавлены для ясности.
Придумать несколько игровых идей
- когда брать
- Когда понятны продукт, аудитория, полезный результат и данные для сбора.
- что подготовить
- Бриф и согласованная спецификация данных.
Ты — сценарист игровых воронок и гейм-дизайнер. Предложи 4 разные идеи прогревающей игровой воронки на основе нашего брифа и спецификации данных. Если у меня уже есть набросок, включи его в рассмотрение: [набросок или «нет»].
Не ограничивайся переименованием одной анкеты. Это должны быть разные способы прожить полезный опыт: например, квест, расследование, путешествие, мастерская или другой сюжет, который естественно связан с нашей нишей. Не копируй примеры вебинара автоматически.
Для каждой идеи опиши:
— понятное рабочее название и завязку;
— кто участник в этой истории и зачем ему продолжать;
— первое полезное открытие или действие;
— что он выбирает и как выбор меняет дальнейший опыт;
— какой результат получает к финалу;
— почему следующий платный шаг логично продолжает этот результат;
— как внутри сюжета можно собрать нужные сведения без отдельного интервью;
— что может сделать идею слишком сложной или скучной.
Учитывай согласованную длительность. Если ее еще нет, предложи варианты продолжительности, но не назначай один сам. Делай воронку интересной и поддерживающей, без запугивания, унижения и обещаний невозможного.
Сравни идеи по связи с продуктом, понятности для нашей аудитории, силе бесплатного результата и сложности реализации. Объясни, какие две стоит обсуждать дальше. Финальный выбор оставь мне. Тексты сообщений и код пока не пиши.Что получится: Несколько действительно разных концепций для выбора, не готовая воронка.
Основание в вебинаре: 01:17:13–01:26:49; 01:27:34–01:29:21.
Оговорка: Четыре варианта и критерии сравнения — редакторская форма; поиск разных сюжетов и связь с нишей — подход вебинара.
Усилить выбранную идею и результат
- когда брать
- После выбора направления. Используй, чтобы идея не осталась красивой оболочкой.
- что подготовить
- Выбранная идея, бриф, список данных, комментарии к концепции.
Развиваем выбранную идею: [название]. В ней мне нравится [что именно], а не нравится или непонятно [что именно]. Остальные согласованные условия сохраняем.
Проверь, что участник получает не только игровой титул или красивую характеристику, а полезный результат, связанный с нашей темой. Построй движение по логике «результат → вопрос или выбор → следующий результат».
Покажи, что человек сможет понять, сделать, собрать или применить уже в начале, что добавится по пути и что останется у него в финале. Опиши будущий итоговый материал, если он нужен: например, личная карта, план, подборка или созданный участником объект. Не назначай формат без связи с задачей.
Затем свяжи этот результат с нашим целевым действием. Что полностью закрывает бесплатная часть? С какой более глубокой задачей помогает платный продукт? Почему уместно предложить именно его? Не обрывай обещанный бесплатный результат ради давления на покупку.
Если обсуждаем несколько продуктов, разложи их по последовательности и развилкам. Заявка, консультация, недорогой платный продукт или вебинар — возможные пути, но не обязательные ступени. Не добавляй новый продукт без согласования.
Уточни длительность, число этапов и место первого ощутимого результата. Дай компактное описание концепции простым русским языком. Сначала покажи спорные решения, после согласования зафиксируй 02_game_concept.md. Не переходи к полным текстам.Что получится: Согласованная концепция 02_game_concept.md.
Основание в вебинаре: 00:16:13–00:17:23; 01:17:13–01:21:33; 01:26:25–01:26:49.
Оговорка: Связка результата и следующего продукта — из вебинара; запрет искусственно обрывать обещанную пользу — добавленный контроль.
Построить полный скелет воронки
- когда брать
- После согласования концепции, до написания сообщений.
- что подготовить
- Бриф, данные и 02_game_concept.md.
Построй полный скелет нашей воронки от входа до финала. Пока не пиши художественные тексты сообщений и код бота.
Покажи: источник входа → старт и объяснение правил → необходимые согласия → знакомство и калибровка → игровые этапы → промежуточные результаты → итоговая польза → предложение следующего шага → возможные завершения.
Для каждого узла дай короткий ID, понятное название, назначение, действие участника, условие перехода, следующий узел и данные или события, которые фиксируются. Если ответ меняет маршрут, покажи каждую ветку и место ее возвращения в общий путь. Не создавай развилки только для вида.
Отдельно от основного маршрута покажи: отказ продолжать, паузу, возврат после паузы, напоминание, повторный старт, неподходящий ввод и отказ от предложения. Если есть несколько дней, укажи условия открытия следующего, а не просто надпись «завтра».
У каждой ветки должен быть понятный исход. Участник должен понимать, где он находится, что уже получил и что будет дальше. Не перегружай его меню и одновременными кнопками.
Представь результат как наглядную схему и таблицу переходов. Если в среде нельзя построить визуальную схему, дай точное текстовое дерево или Mermaid-код, не утверждая, что изображение создано.
Сверь маршрут со спецификацией данных. Неопределенные переходы отметь как открытые решения. После согласования сохрани 03_funnel_map.md. Тексты будем писать отдельно.Что получится: Схема и таблица переходов 03_funnel_map.md.
Основание в вебинаре: 00:28:46–00:30:20; 00:36:02–00:36:34; 01:11:57–01:17:46; 01:35:44–01:37:02; 02:00:52–02:01:33.
Оговорка: ID, таблица переходов и формат Mermaid — добавленная упаковка схемы для последующей сборки.
Спроектировать геймификацию
- когда брать
- На основе скелета; затем можно повторить после прохождения первого прототипа.
- что подготовить
- Концепция и 03_funnel_map.md.
Посмотри на наш скелет как гейм-дизайнер. Нам нужна не анкета с декоративными названиями, а понятный игровой опыт с ощущением движения и полезным результатом.
Предложи подходящую систему геймификации: роль участника; проводник, если он действительно нужен; видимый путь; реакция на выбор; промежуточные достижения; финальная сборка полученного. Монеты, рюкзак, ключи, артефакты и награды используй только там, где они имеют смысл в нашем сюжете.
Для каждой механики объясни: какое действие ее запускает; что видит участник; зачем ему это; что сохраняет бот; что происходит при повторном нажатии или возвращении. Не подменяй полезный результат баллами.
Сравни минимальный набор для первой версии и расширения на потом. Не добавляй сложность ради эффектности. Проверь, не стало ли слишком много кнопок, правил, счетчиков и обязательных действий.
Отдельно предложи чередование форматов: текст, изображение, короткое видео, выбор, маленькое действие. Обозначь, где они поддерживают смысл и где только тормозят прохождение.
В вебинаре это названо «дофаминовой геймификацией». В нашей задаче опиши наблюдаемый опыт: интерес, ясную обратную связь, достижение и желание продолжить, а не обещание физиологического эффекта.
После согласования зафиксируй 04_gamification.md и перечисли точечные изменения в скелете. Полностью не переписывай маршрут и пока не переходи к коду.Что получится: Правила игры 04_gamification.md и уточнения к схеме.
Основание в вебинаре: 00:18:48–00:20:38; 00:24:44–00:27:11; 02:18:05–02:18:50; 02:21:25–02:21:36.
Оговорка: Игровые механики — из примеров эфира. Формальные правила повторных действий и уточнение термина «дофаминовая» добавлены.
Описать персонализацию и результаты
- когда брать
- До окончательных текстов и сборки, если результат зависит от ответов участника.
- что подготовить
- Скелет, поля данных, материалы эксперта и утвержденная методика, если она нужна.
Опиши, как наша воронка выбирает персонализированный маршрут и результат. Используй только предоставленные материалы и согласованные правила: [материалы / методика / таблица результатов].
Раздели три вещи: сведения, которые вводит участник; правила выбора или расчета; подготовленные тексты, которые бот выдает. Не подменяй правило красивым примером одного результата.
Составь таблицу: входные данные → проверка и подтверждение ввода → условие или расчет → вариант результата → текст → следующий шаг. Покрой все допустимые варианты, включая пропуск, неверный ввод и ответ «не узнаю себя», если такой вариант предусмотрен.
Если участники отличаются по опыту, покажи, кому нужен вводный путь, а кто может его пропустить. Если на следующих этапах подставляются предыдущие ответы, укажи точные поля и способ подстановки.
Не придумывай экспертную методику, значения шкал или расчет по дате рождения за автора. При отсутствии утвержденного алгоритма покажи, чего не хватает. Для проверки интерфейса можно предложить явно помеченные демонстрационные данные, но не выдавать их за достоверную диагностику.
Персональный вывод должен опираться на реальные ответы или согласованное правило. Не создавай впечатление, что мы знаем о человеке больше, чем он сообщил.
Подготовь примеры проверки каждого правила и сохрани 05_personalization.md после согласования. Если персонализация не нужна, обоснуй пропуск этого шага, не усложняя воронку.Что получится: Правила результатов 05_personalization.md; при отсутствии данных — список пробелов.
Основание в вебинаре: 00:21:38–00:22:52; 00:28:46–00:30:20; 00:31:34–00:32:18; 01:44:18–01:45:14; 02:40:31–02:41:24.
Оговорка: Важно: в учебном примере расчет был придуман ИИ. Требование утвержденной методики здесь добавлено редактором и не приписывается ведущей.
Написать первый день или блок
- когда брать
- Только после согласования схемы. Не обязательно делать многодневную воронку.
- что подготовить
- Скелет, концепция, данные, правила игры и персонализации.
Напиши только первый согласованный день или смысловой блок нашей воронки. Если она рассчитана на одну короткую сессию, используй первый законченный фрагмент, а не придумывай дополнительные дни.
Строго следуй утвержденному скелету. Не меняй продукты, обещания, последовательность, правила персонализации и количество веток без отдельного предложения.
Начни с понятного входа: где человек оказался, что будет происходить, какую пользу он получит, что от него потребуется, где правила и необходимые документы. Затем веди по сюжету к первому результату.
Исследовательские вопросы встрой в действия и выборы персонажа. Для холодной аудитории в этом подходе используем преимущественно понятные варианты ответа на кнопках, а не обязательные развернутые интервью. Варианты должны точно передавать смысл поля, которое мы собираем.
Для каждого экрана укажи: ID из схемы; текст сообщения; формат медиа; подписи кнопок; какой ответ сохраняется; куда ведет каждая кнопка; событие аналитики; условие отправки следующего сообщения. Отдельно опиши возврат и напоминание, если они относятся к этому блоку.
Пиши живым русским языком, без шаблонных маркетинговых фраз. Текст должен объяснять происходящее, а не быть коротким любой ценой. Сохраняй поддерживающий тон и показывай полезный прогресс.
В конце сверь готовые экраны со схемой. После согласования сохрани 06_block_01.md. Остальные блоки и код пока не пиши.Что получится: Полный текст первого блока 06_block_01.md.
Основание в вебинаре: 00:34:46–00:36:26; 01:00:35–01:00:59; 01:08:22–01:09:45; 01:35:44–01:38:38; 01:59:05–01:59:41.
Оговорка: Форма карточки экрана добавлена для копирования в разработку. Закрытые вопросы для холодной аудитории — подход ведущей, не универсальный закон.
Отредактировать русский язык
- когда брать
- После черновика первого блока; можно использовать в отдельном диалоге.
- что подготовить
- Тексты блока, описание аудитории и образец голоса эксперта, если есть.
Ты — редактор и сценарист. Я делаю игровую воронку для аудитории: [описание]. Вот согласованные тексты: [вставить или приложить]. Образец подходящего мне голоса: [пример, если есть].
Сделай тексты естественными, интересными и стилистически правильными на русском языке. Убери неудачные метафоры, канцелярит, искусственные обороты и маркетинговые клише. Сохрани понятный сюжет, теплый тон и конкретную пользу.
Не сокращай все до обрывков: участник должен понимать, где находится, что делает и зачем. Если сообщение перегружено, предложи его разделение, но не вводи новые шаги без явной пометки.
Не меняй ID экранов, смысл ответов, переходы, условия, продукт, цену, обещания и правила расчета. Не добавляй несуществующие кейсы, достижения эксперта или гарантии. Юридические формулировки не переписывай как художественный текст; отметь их отдельно для профильной проверки.
Выдай отредактированные сообщения в той же структуре. После текста коротко перечисли смысловые места, которые требуют решения автора, и предложенные изменения кнопок или разбиения экранов. Все, что затрагивает логику, согласовываем отдельно.
Не называй редактуру проверкой работоспособности: техническая проверка маршрута будет следующим отдельным действием. Пока не пиши код и не меняй остальные блоки.Что получится: Отредактированные тексты с сохраненными ID, кнопками и переходами.
Основание в вебинаре: 01:02:19–01:03:13; 01:29:04–01:29:46; 01:39:16–01:41:17; 01:43:43–01:44:18.
Оговорка: В эфире для редакторской работы использовали Gemini. Этот промпт не привязан к сервису; ограничения неизменности добавлены.
Подготовить визуальную концепцию
- когда брать
- Когда тексты первого блока достаточно стабильны.
- что подготовить
- Концепция, тексты экранов, референсы и фирменный стиль, если есть.
Мы подготовили тексты первого блока. Теперь предложи визуал, который поддержит сюжет и поможет воспринимать сообщения, а не просто украсит их.
Наши материалы: [тексты, концепция, референсы]. Предложи три действительно разных стилевых направления. Для каждого объясни настроение, цветовую логику, характер изображения, роль героя или проводника и соответствие нашей аудитории.
После выбора одного направления составь список изображений по ID экранов. Для каждой сцены опиши: ее назначение; что происходит; кто изображен; композицию; что должно оставаться одинаковым во всей серии; нужен ли текст на картинке; что лучше оставить текстом сообщения.
Если в сюжете есть героиня, герой или проводник, проверь, что они действительно присутствуют в нужных сценах. Не создавай серию пустых декораций вместо истории с участником.
Отдельно укажи, где уместны другие форматы — например, короткое видео или видеокружок. Они не обязательны для каждого экрана и не должны становиться условием сборки первого прототипа без необходимости.
Требования к формату для выбранной площадки нужно проверить перед подготовкой финальных изображений. Не считай пропорции из примера вебинара обязательным стандартом. Отдели технические ограничения от наших композиционных предпочтений.
Сейчас выдай варианты стиля, затем после моего выбора — 07_visual_brief.md. Изображения пока не генерируй: сначала согласуем направление и список сцен.Что получится: Согласованное техническое задание на визуал 07_visual_brief.md.
Основание в вебинаре: 00:18:33–00:19:11; 00:24:44–00:25:09; 01:41:25–01:42:47; 01:45:18–01:46:47; 02:00:18–02:00:49.
Оговорка: Три направления и список по ID — редакторская форма. Проверка актуальных требований вынесена на этап реализации.
Написать промпты для серии изображений
- когда брать
- После согласования стиля и списка сцен. Это запрос на тексты промптов, не на генерацию.
- что подготовить
- 07_visual_brief.md, список сцен и доступные референсы.
На основе утвержденного визуального задания подготовь полный комплект промптов для изображений нашей игровой воронки. Сейчас нужны только тексты промптов, не сами изображения.
Сначала зафиксируй общий блок серии: единый стиль, палитра, свет, атмосфера, внешний вид героя или проводника, повторяющиеся предметы и правила композиции. Не меняй эти параметры от сцены к сцене без сюжетной причины.
Затем для каждого изображения дай отдельный самодостаточный промпт. Включи в него общий стиль, описание конкретного действия, положение персонажей, композицию и согласованный формат. Каждый промпт должен быть пригоден для копирования отдельно, без фразы «как выше».
Укажи ID изображения, связанный экран, предлагаемое имя файла и нужный референс, если он реально приложен. Не ссылайся на несуществующий или недоступный референс. При необходимости сначала попроси подготовить исходное изображение героя.
Добавь отдельный общий промпт для последовательной генерации серии: каждое изображение — отдельный результат, не коллаж, если коллаж не был согласован. Количество изображений за один запрос адаптируется к возможностям выбранного инструмента; не фиксируй лимит из вебинара как действующий.
В конце проверь: все ли сцены покрыты; есть ли нужный персонаж; выдержан ли единый стиль; не потерялось ли смысловое различие между изображениями. Сохрани 08_visual_prompts.md. Визуальную генерацию запускаем отдельно.Что получится: Копируемые промпты и таблица «экран → изображение» в 08_visual_prompts.md.
Основание в вебинаре: 01:45:37–01:47:07; 01:53:16–01:54:04; 02:00:18–02:00:49; 02:23:28–02:25:01.
Оговорка: Серия и единый образ — по вебинару; самодостаточность каждого промпта и правила референсов — добавленная организация.
Проверить весь путь до сборки
- когда брать
- После редакторской доработки, до команды писать код.
- что подготовить
- Итоговые тексты, скелет, первый артефакт данных, правила результатов и медиа.
Проверь итоговый первый блок нашей воронки вместе со скелетом всего пути. Не переписывай тексты автоматически.
Сначала пройди его мысленно как игрок: понятно ли, где я нахожусь, что мне обещают, что нужно сделать, зачем отвечать и какой результат я получил? Нет ли необъясненных терминов, провала в негатив, скучных анкетных фрагментов или путаницы из-за кнопок?
Затем проверь как разработчик: куда ведет каждая кнопка; нет ли обрывов и недостижимых экранов; доступны ли все результаты; есть ли обработка неверного ввода, подтверждение важных данных, повторный старт, возврат и свободный текст вместо кнопки; что произойдет после двойного нажатия?
Проверь согласия и остановку сообщений: можно ли обойти требуемый шаг; когда допустимо отправлять напоминание; что происходит после отказа или стоп-команды. Для следующих дней проверь условия открытия и обещания в тексте.
Отдельно сверь с 01_data_and_analytics.md: где собирается каждое обязательное поле, где записывается каждое событие и какие показатели мы сможем посчитать. Отметь то, чего в первом блоке еще нет, но что предусмотрено позднее.
Оцени также воронку от 1 до 100 с точки зрения продаж: понятно ли предложение, связан ли платный шаг с полученным результатом, достаточно ли оснований продолжить и нет ли давления вместо прогрева. Обоснуй оценку; это не прогноз конверсии.
Выдай таблицу: ID экрана или перехода → проблема → влияние → предлагаемое исправление. Раздели блокирующие, важные и косметические замечания. Если смотришь только документы, назови это проверкой спецификации, а не реальным тестом бота.
Сохрани 09_audit.md и дождись согласования правок. Не переходи к сборке с неразрешенными блокирующими проблемами.Что получится: Отчет 09_audit.md с конкретными дефектами и предложениями исправлений.
Основание в вебинаре: 00:36:02–00:36:34; 01:57:23–01:58:11; 02:00:52–02:01:33; 02:08:55–02:09:15; 02:50:26–02:52:46.
Оговорка: Виды ошибок взяты из проверки на эфире; уровни критичности и различение проверки документов и реального теста добавлены.
Зафиксировать пакет для сборки
- когда брать
- После согласования замечаний проверки.
- что подготовить
- Все согласованные документы и список одобренных исправлений.
Внеси только согласованные исправления из проверки: [список или ссылка на отчет]. Остальную логику и тексты сохрани.
Затем собери единый пакет для разработки первого работающего блока. В нем должны быть: цель воронки и границы текущей версии; карта экранов и переходов; финальные тексты и кнопки; правила персонализации; геймификация; условия отправки и напоминаний; данные и события; список медиа; известные ограничения и отсутствующие материалы.
Дай понятные ссылки на файлы проекта. Укажи, какой документ является основным при противоречии. Если противоречия остались, не выбирай версию молча: вынеси их на решение.
Отдельно раздели готовое к реализации, временные заглушки и то, что появится в следующих блоках. У заглушки должно быть видно, что это тестовый элемент, а не уже работающая функция. Не показывай игроку действующую кнопку, которая ведет в никуда.
Составь краткий перечень действий для приемки: что мы должны увидеть при нормальном прохождении и при нестандартном вводе. Не объявляй эти проверки пройденными заранее.
Сохрани 10_build_spec.md и обнови только затронутые исходные документы. В конце покажи список измененных файлов, суть изменений и оставшиеся блокеры. Код начнем отдельной командой.Что получится: Обновленные документы и единое задание 10_build_spec.md.
Основание в вебинаре: 01:06:34–01:08:02; 01:57:23–01:58:11; 02:01:39–02:02:27.
Оговорка: Отдельный промпт передачи в разработку, имена файлов и правила заглушек — редакторское дополнение к показанному переходу от проверки к сборке.
Собрать первую работающую версию
- когда брать
- После готового задания. Применяется в среде, где действительно можно создавать и запускать код.
- что подготовить
- Папка проекта, 10_build_spec.md, выбранная платформа и безопасно настроенные доступы.
Реализуй первую версию сценарного бота по 10_build_spec.md и указанным в нем согласованным материалам. Площадка: [площадка]. Папка проекта: [путь].
Сначала проверь, доступны ли тебе файлы, терминал, запуск кода и нужные подключения. Если доступа нет, выдай проект и инструкции запуска; не утверждай, что бот уже работает.
Это запрограммированная воронка, а не свободно отвечающий ИИ-агент. По умолчанию используй согласованные тексты, правила, результаты и переходы. Не добавляй генерацию ответов через языковую модель без отдельной задачи.
Реализуй только согласованный объем: состояния участника, кнопки, сохранение ответов, персонализацию, игровые механики, события аналитики и предусмотренные напоминания. Учти нестандартные действия из отчета проверки. Не переписывай сценарий во время кодирования.
Если среда или площадка требует дополнительных действий владельца, объясни их простыми шагами. Для Telegram при необходимости проведи через создание бота в BotFather. Перед конкретными техническими настройками проверь актуальную официальную документацию.
Секреты используй через согласованный защищенный способ настройки. Не проси вставить реальный токен в публичный текст, не выводи его в отчет, не записывай в сценарий или репозиторий. Если конфигурации не хватает, перечисли только названия нужных параметров.
Создай и запусти доступные проверки. Заверши отчетом: что реализовано; что запускалось; что проверено; чего не хватает; как открыть тестовую версию. Не размещай рабочую версию на сервере без отдельной команды.Что получится: Первый исполняемый блок бота и отчет о фактически сделанном.
Основание в вебинаре: 01:48:25–01:52:46; 02:01:39–02:02:27; 02:10:44–02:11:43; 02:19:02–02:19:42.
Оговорка: Тип бота и этап сборки — из вебинара. Проверка доступных инструментов, безопасная передача секретов и границы публикации добавлены; в эфире ключ передавали в чат.
Добавить медиа и улучшить подачу
- когда брать
- Когда первый блок уже можно пройти и подготовлены реальные файлы медиа.
- что подготовить
- Код прототипа, папка изображений, карта медиа и согласованные тексты.
Подключи подготовленные медиа к прототипу нашей воронки. Реальные файлы находятся здесь: [путь или вложения]. Используй соответствие «ID экрана → ID изображения» из визуального задания.
Сначала проверь, что файлы доступны и подходят нужным сценам. Если изображения нет или оно не соответствует заданию, отметь это, а не подставляй случайное. Не меняй согласованный текст ради картинки.
Доработай представление: отдели смысловые части текста, выдели важное там, где это поддерживается площадкой, проверь длину подписей и удобство кнопок. Изображение и текст должны восприниматься как один шаг.
Проверь темп: сообщения не должны вываливаться сразу большой стеной, но и искусственное ожидание не должно мешать движению. Предложи точечные настройки темпа и способ продолжения; не добавляй лишние нажатия на каждый абзац.
Сохрани согласованную геймификацию: видимый прогресс, реакции на выбор и заработанные результаты. Если при прохождении чего-то не хватает, сначала обозначь улучшение и его влияние на сценарий.
Не удаляй предыдущие сообщения только ради снятия кнопок без согласованного правила. Проверь старые и повторные нажатия, чтобы они не запускали ветку второй раз.
Протестируй доступные варианты отображения. Где проверка на телефоне или другом клиенте недоступна, выдай конкретный список для ручной проверки. В отчете раздели реальные результаты теста и непроверенные предположения.Что получится: Прототип с медиа и отчет о проверке подачи сообщений.
Основание в вебинаре: 02:15:46–02:16:39; 02:18:05–02:19:42; 02:24:33–02:25:01; 02:28:21–02:30:50; 02:49:37–02:52:46; 02:57:41–03:02:18.
Оговорка: Подача, темп и ошибки кнопок — из эфира. Разделение доступных и ручных проверок добавлено.
Протестировать и исправить ошибки
- когда брать
- После сборки первого прототипа и после существенных изменений.
- что подготовить
- Работающий тестовый бот, задание, журнал ошибок, скриншоты или запись прохождения.
Проверь реальную работу бота по согласованному заданию. Сначала укажи, к чему у тебя есть доступ: код, запуск тестов, логи, интерфейс или только мои описания.
Проверь основной путь и каждую альтернативную ветку. Включи новый вход, повторный старт, продолжение после паузы, неправильный ввод, текст вместо кнопки, двойное нажатие, старую кнопку, остановку сообщений, возврат, напоминания и разные результаты персонализации — если эти случаи применимы к нашей воронке.
Отдельно проверь: не теряются ли ответы; не начисляются ли награды повторно; совпадает ли путь с согласованной схемой; записываются ли нужные события; нет ли зависшего перехода; соответствуют ли текст и медиа экрану. Для оплаты не считай нажатие кнопки подтверждением платежа.
Для каждого дефекта зафиксируй: шаги воспроизведения; ожидаемое поведение; фактическое поведение; затронутый участок; предлагаемое исправление. Не называй догадку найденной причиной без проверки.
Исправляй подтвержденные ошибки в пределах согласованной логики. Изменение продукта, обещания, сценария или условий доступа выноси отдельно. После исправления повтори соответствующий тест и проверь соседние переходы.
В 11_test_report.md раздели результаты на «проверено и работает», «исправлено и перепроверено», «ошибка остается», «не проверено». Если не можешь сам пройти интерфейс, подготовь пошаговый сценарий ручного тестирования вместо заявления об успешном прохождении.Что получится: Исправления и проверяемый отчет 11_test_report.md.
Основание в вебинаре: 02:15:46–02:19:42; 02:26:56–02:27:12; 02:46:55–02:49:25; 02:50:26–02:52:46; 02:54:25–03:03:52.
Оговорка: Принцип «пройти → дать обратную связь → исправить» — из вебинара. Формат тестового отчета и дополнительные проверки сохранности добавлены.
Продолжить следующие блоки
- когда брать
- Когда первый блок согласован по стилю и логике и проверен в прототипе.
- что подготовить
- Полный скелет, готовый первый блок, отчет о тестировании и правила игры.
Первый блок нашей воронки согласован. Продолжаем следующий блок: [номер или название]. Используй полный скелет и реально проверенный стиль первого блока.
Не начинай проект заново и не переименовывай согласованные сущности. Сохрани голос, проводника, визуальную логику, правила персонализации, данные, игровые механики и условия доступа.
Сначала покажи краткий план: с чем участник входит; какой новый результат получает; какие ответы или действия нужны; как завершается блок; куда он ведет дальше. Проверь, что это продолжение уже выданных обещаний, а не новая несвязанная история.
Затем после согласования напиши экраны, вопросы, кнопки, варианты ответов, условия переходов, медиа и события по той же структуре, что в первом блоке. Не добавляй обязательную анкету в середину игры.
Если блок относится к следующему дню, уточни точные условия открытия и напоминаний по нашему решению. Если это финал, выдай обещанную пользу полностью и свяжи ее с согласованным предложением следующего шага. Предусмотри понятный исход и для человека, который не покупает.
Проверь стык предыдущего и нового блока, все ответвления, персонализацию и соответствие первому артефакту данных. Сохрани отдельный файл блока и перечисли необходимые обновления схемы и визуального задания.
Сборку и тестирование выполняй после согласования текстов. Не переписывай уже утвержденную часть без конкретного основания.Что получится: Один следующий законченный блок, не автоматическая генерация всей оставшейся воронки.
Основание в вебинаре: 00:34:46–00:36:26; 01:35:44–01:37:02; 01:41:53–01:42:04; 02:19:02–02:19:42; 03:05:59–03:06:21.
Оговорка: В эфире подробно создавали первый день; полный процесс для следующих дней не показан. Этот шаблон переносит показанный подход на продолжение.
Подготовить размещение на сервере
- когда брать
- Когда согласован нужный для запуска объем и пройдены тесты.
- что подготовить
- Код, отчет тестов, сведения об окружении и подтвержденные владельцем условия запуска.
Подготовь размещение нашей воронки на сервере. Сначала изучи код, текущее окружение и отчет тестирования. Не меняй работающие сервисы и не публикуй бота, пока не согласован план.
Покажи, что уже готово и чего не хватает: среда исполнения, постоянное хранение данных, настройки бота, медиа, планировщик напоминаний, необходимые ссылки и документы. Отличай локально запущенный прототип от опубликованной версии.
Проверь актуальные технические требования по официальной документации выбранных сервисов. Не считай утверждения из вебинара про платформы, тарифы, лимиты и размещение данных действующей инструкцией.
Отдельно перечисли вопросы, которые должен подтвердить владелец: где можно обрабатывать данные нашей аудитории, какие документы нужны и какие условия сообщений и платежей применимы. При отсутствии проверенных правовых оснований не объявляй проект юридически готовым.
Предложи план развертывания без нарушения других проектов: конфигурация секретов без их раскрытия, запуск процесса, сохранность данных, логи, восстановление после сбоя, резервная копия и возврат к предыдущей версии. Отметь дополнительные расходы до их возникновения.
После явного согласования плана выполни только доступные и разрешенные действия. Проверь старт, переходы, сохранение состояния и предусмотренные фоновые задачи на опубликованной версии.
Сохрани 12_deployment.md: где и какая версия запущена; что фактически проверено; что осталось вручную; как остановить или восстановить работу. Если доступа к серверу нет, подготовь инструкции и не называй размещение выполненным.Что получится: План размещения, затем фактический отчет 12_deployment.md.
Основание в вебинаре: 00:03:32–00:03:57; 02:09:33–02:10:06; 02:14:20–02:15:00; 02:19:27–02:20:23.
Оговорка: На вебинаре размещение обсуждалось, но полного регламента нет. План, секреты, резервирование и проверка актуальных требований — дополнения, не готовое правовое заключение.
Разобрать результаты и улучшить воронку
- когда брать
- Когда есть реальные данные прохождения, заявок и покупок.
- что подготовить
- Выгрузка событий и результатов, спецификация данных, версия сценария и период наблюдения.
Проанализируй тестовый запуск нашей игровой воронки. Используй только приложенные данные: [выгрузки, период, версия]. Если их нет, предложи формат выгрузки и не придумывай показатели.
Сначала проверь качество данных и соответствие 01_data_and_analytics.md. Укажи пропуски, дубли, неясные события и показатели, которые нельзя надежно посчитать.
Затем покажи прохождение основных этапов и конверсии с исходными количествами и понятными знаменателями. Раздели получение результата, переход к предложению, заявку, нажатие оплаты и подтвержденную покупку.
Сравни пути по источникам и реально собранным характеристикам аудитории. Какие люди чаще доходят до результата? Кто покупает? Где останавливаются? Есть ли возвраты после напоминаний? Что говорят ответы о запросах и ожиданиях?
Раздели наблюдения и гипотезы. Остановка на шаге сама по себе не доказывает причину: это может быть текст, сложность задания, техническая проблема или другое обстоятельство. Не объявляй небольшую выборку подтверждением универсального вывода.
Предложи приоритетные изменения: какую проблему проверяем; что меняем; какой показатель смотрим; что должно остаться неизменным; как поймем, помогло ли изменение. Не переписывай все одновременно.
Сохрани 13_results_review.md. Отдельно покажи, какие знания об аудитории мы получили, даже если план по продажам пока не выполнен. Изменения в сценарий и код вносим после согласования.Что получится: Разбор 13_results_review.md и приоритетный план изменений.
Основание в вебинаре: 00:20:20–00:22:52; 00:46:14–00:46:52; 00:53:57–00:55:48; 01:04:34–01:07:48.
Оговорка: Назначение аналитики и доработка по данным — из вебинара. Полный разбор запуска в эфире не проводился; этот промпт — рабочая реконструкция с добавленными правилами интерпретации.
Дополнительные модули
Подключаются по необходимости: подписка, ВК, WhatsApp, шпаргалка.
Добавить проверку подписки
- когда брать
- Только если подписка на канал или сообщество действительно нужна в этой воронке.
- что подготовить
- Согласованный маршрут, цель подписки, площадка и канал или сообщество.
Хочу рассмотреть проверку подписки на [канал или сообщество] в нашей игровой воронке. Не вставляй ее автоматически на входе.
Сначала предложи два возможных места в существующем маршруте. Для каждого объясни, какую пользу человек к этому моменту уже получил, что получит дальше и как дополнительное действие повлияет на понятность пути.
Учти, что в вебинаре обсуждались разные места: после уже выданного результата и, в конкретном примере, перед открытием первой двери. Это не одно и то же правило. Выбери аргументы для нашей ситуации, а окончательное место согласуй со мной.
После выбора опиши сценарий: предложение подписаться → переход → кнопка проверки → подтверждение → продолжение. Отдельно покажи, что будет, если человек уже подписан, пока не подписался, не хочет подписываться, нажал повторно или техническая проверка недоступна.
Проверь актуальные возможности площадки и необходимые права по официальной документации. Не выдавай техническую ошибку за отсутствие подписки. Не обещай проверить статус, который используемый способ подключения не позволяет достоверно получить.
Сохрани прогресс, результаты и ответы участника. Не забирай уже обещанную бесплатную пользу без заранее понятного условия. Допиши события аналитики, чтобы увидеть, сколько людей доходит до проверки и продолжает после нее.
Сначала покажи изменения в схеме и текстах. После согласования внеси их в реализацию и проверь все предусмотренные исходы. Остальную воронку не меняй.Что получится: Согласованное место проверки и описание всех исходов.
Основание в вебинаре: 02:34:04–02:35:09; 02:37:41–02:38:40.
Оговорка: Два разных места проверки сохранены как разные решения из эфира. Обработка технических ошибок и ограничение доступа к уже обещанной пользе добавлены.
Адаптировать воронку для ВК
- когда брать
- Когда уже есть согласованный сценарий и решение использовать ВК.
- что подготовить
- Исходная воронка, документы, код при наличии и сведения о сообществе.
Помоги адаптировать нашу согласованную воронку для ВК. Исходные материалы: [папка или файлы]. Сведения о сообществе: [без секретных ключей].
Не предполагай, что перенос делается один в один. Сначала по актуальной официальной документации проверь возможности сообщений, кнопок, вложений, форматирования, запуска диалога, событий и напоминаний, которые нужны именно нашему сценарию.
Составь таблицу: элемент исходной воронки → возможность ВК → необходимая адаптация → влияние на опыт участника → способ проверки. Не переписывай продукт и сюжет из-за смены платформы, если можно сохранить их смысл.
Проведи меня по необходимым настройкам сообщества простым языком. Уточни, какие сообщения и возможности бота нужно включить, как получить минимально необходимые права и как участник запустит игру. Секреты не помещай в документы или открытый чат.
Особое внимание удели проблемам, встречавшимся на вебинаре: кнопке начала, повторному старту, исчезновению предыдущих сообщений, зависанию переходов, форматированию и тексту, который не помещается на кнопках.
После согласования реализуй адаптацию в доступной среде, не ломая исходную версию. Различай участников и события по площадке; не объединяй разных людей только по одинаковому имени.
Проверь весь первый блок, все ветки и сохранение данных. Отдельно покажи выполненное, непроверенное и то, что требует моего доступа. Обнови документ адаптации и тестовый отчет. Не называй перенос завершенным только потому, что первое сообщение отправилось.Что получится: План адаптации и протестированная версия в пределах доступных инструментов.
Основание в вебинаре: 02:32:52–02:33:24; 02:36:31–02:38:55; 02:40:54–02:43:13; 02:52:48–03:03:52.
Оговорка: ВК демонстрировался с последовательными исправлениями. Проверка текущих возможностей, разделение площадок и минимальные права — дополнения.
Оценить перенос в WhatsApp
- когда брать
- До решения о переносе, а не после обещания запустить воронку на всех площадках.
- что подготовить
- Согласованный маршрут, страны аудитории и владельца, сведения о подключении без секретов.
Оцени, можно ли перенести нашу игровую воронку в WhatsApp и что для этого потребуется. Сейчас не начинай кодирование.
Исходная воронка: [материалы]. Аудитория и ее страны: [данные]. Что уже подключено у владельца: [описание без секретов].
Сначала проверь актуальные официальные требования для используемого способа подключения. Разберись, какие учетные записи и подтверждения нужны, какие типы сообщений доступны, что происходит с напоминаниями, шаблонами и отправкой за пределами разрешенного окна общения.
Затем сопоставь с нашей воронкой количество и типы кнопок, редактирование сообщений, медиа, ветки, длительность, повторный вход и условия следующего дня. Проверь текущие правила и стоимость сообщений, не используя цифры и ограничения вебинара как автоматически действующие.
Дай таблицу: наша механика → ограничение или требование → возможная замена → что теряем или сохраняем → что придется сделать вручную. Отдельно обозначь расходы, этапы согласования и действия, которые нельзя выполнить имеющимися инструментами.
Сохрани полезный результат, логику сюжета и честные условия сообщений. Не предлагай обход правил площадки.
Заверши выводом: что можно переносить без изменения смысла; что нужно переработать; какие данные или разрешения еще нужны; какой объем разумно тестировать первым. При отсутствии доступа к актуальным источникам перечисли непроверенное, а не заявляй о совместимости.
Реализацию начнем только после согласования этого плана.Что получится: Обоснованный план адаптации либо список препятствий; не обещание готового запуска.
Основание в вебинаре: 00:42:04–00:42:44; 00:48:28–00:48:58; 02:32:52–02:33:24; 02:35:11–02:36:29; 02:59:24–03:00:08.
Оговорка: В эфире обсуждали ограничения и будущую попытку переноса; работающий запуск WhatsApp не показан. Шаблон намеренно начинается с проверки, а не обещания переноса.
Собрать шпаргалку готового проекта
- когда брать
- После сборки и тестирования либо перед передачей проекта в другой рабочий диалог.
- что подготовить
- Актуальные документы, код, журнал изменений и результаты проверок.
Собери рабочую шпаргалку по нашей воронке из актуальных документов и реально выполненных действий. Не превращай это в общий учебник по ботам.
Зафиксируй: цель и продукт; выбранную аудиторию; игровую концепцию; маршрут; первый и финальный результаты; правила персонализации и геймификации; структуру данных и аналитики; медиа; площадки; готовый объем и то, что еще не реализовано.
Перечисли основные файлы проекта и их назначение. Покажи, где менять текст, кнопку, результат, изображение и условие напоминания. Отдельно отметь изменения, которые требуют повторного тестирования маршрута.
Добавь ошибки, с которыми мы реально столкнулись: проявление → проверенная причина, если найдена → исправление → проверка, защищающая от повторения. Не придумывай истории отладки, которых не было.
Составь краткую последовательность запуска, проверки, остановки и восстановления только в пределах фактически настроенного окружения. Секретные значения, токены и пароли в шпаргалку не включай.
Создай PROJECT_STATE.md: текущая версия; что согласовано; что реализовано; что проверено; открытые решения; следующий конкретный шаг; какие файлы нужно передать следующему исполнителю. Если документы противоречат друг другу, укажи это вместо молчаливого выбора.
В конце предложи, какие из наших проверенных правил можно использовать в следующем проекте, а какие относятся только к этой воронке. Не объявляй весь процесс универсальным или полностью автоматическим, если часть работы осталась ручной.Что получится: PROJECT_STATE.md и инструкция по дальнейшей работе с воронкой.
Основание в вебинаре: 01:06:34–01:08:02; 01:15:34–01:15:58; 03:06:46–03:07:56.
Оговорка: Идея шпаргалки по этапам и найденным ошибкам — из вебинара. Формат PROJECT_STATE.md и передача контекста добавлены.
Служебные промпты
Для ситуаций, когда нейросеть перескочила этап, написала скучно или запутала кнопки.
Сначала составь промпт
Помоги мне написать сильный промпт для следующей задачи: [задача]. Контекст и согласованные материалы: [контекст]. Нужный результат: [формат и критерии].
Пока не выполняй саму задачу. Сначала составь готовый промпт: роль, входные данные, порядок действий, ограничения, формат результата и условия завершения. Учти уже принятые решения. Не добавляй за меня длительность, продукты, аудиторию или обещания.
После промпта коротко покажи, какие предположения в него вошли и что надо уточнить. Выполнение начнем отдельным сообщением.Основание в вебинаре: 00:41:22–00:41:42; 01:17:13–01:18:00; 01:23:39–01:24:00; 02:22:24–02:22:57.
Оговорка: Рабочая реконструкция повторяющегося приема ведущей.
Стоп: ты перескочил этап
Стоп. Мы сейчас на этапе [данные / идея / скелет / тексты], а ты уже начал [что именно]. Этот переход я не согласовывала.
Вернись к текущей задаче. Используй принятые решения, не начинай проект заново. Сейчас нужно только [конкретный результат]. Пока не пиши [тексты / вопросы / код].
Покажи исправленный результат в нужных границах и отдельно — открытые вопросы. Не переходи дальше, пока я не согласую этот этап.Основание в вебинаре: 01:02:57–01:04:32; 01:10:23–01:10:45; 01:27:25–01:29:21.
Оговорка: По замечаниям ведущей, когда ИИ начинал писать тексты до согласования логики.
Идея скучная или результат слабый
Мне не подходит текущая версия: [что конкретно не работает]. Сохрани [что нравится и уже согласовано].
Сейчас участник получает слишком мало понятной пользы или проходит обычную анкету под игровыми названиями. Предложи три изменения самой механики и результата, а не только новые названия и украшения.
Для каждого покажи: что делает человек; что получает; почему хочет продолжить; как это связано с продуктом. Не удлиняй воронку автоматически. Сначала выберем направление, потом будем писать тексты.Основание в вебинаре: 01:17:13–01:18:00; 01:19:20–01:21:33; 01:23:07–01:26:49.
Оговорка: По итерациям выбора и усиления игрового сюжета.
Верни понятный язык и поддерживающий тон
В этом фрагменте слишком много [негатива / клише / непонятных метафор]: [фрагмент]. Перепиши его ясным, естественным русским языком для нашей аудитории.
Не обесценивай ситуацию человека, но покажи доступный следующий шаг и опору на уже полученный результат. Не используй запугивание, стыд и обещания гарантированного изменения.
Сохрани смысл, действие участника, кнопки и переходы. Если проблема не в стиле, а в самой логике, назови ее отдельно. Не переписывай всю воронку.Основание в вебинаре: 01:02:19–01:03:13; 01:27:25–01:29:46; 01:39:16–01:41:17.
Оговорка: По обратной связи о негативе, неясных метафорах и маркетинговых клише.
Упрости кнопки и темп
На участке [ID или описание] я теряюсь: слишком много кнопок, непонятен следующий шаг или неудачно идут сообщения. Вот наблюдение: [что происходит].
Покажи, какое действие сейчас главное. Предложи более ясный порядок выбора и короткие подписи без потери смысла ответов. Сохрани нужные данные и все согласованные исходы.
Проверь старые кнопки, возврат, последовательность сообщений и состояние участника. Сначала покажи изменения «было → станет», затем после согласования внеси их и повтори проверку этого участка.Основание в вебинаре: 00:30:43–00:31:28; 02:29:56–02:30:50; 02:50:26–02:52:46; 03:01:43–03:01:56.
Оговорка: По замечаниям ведущей при прохождении прототипов.
Продолжить без лишних изменений
Продолжаем уже начатый проект. Прочитай PROJECT_STATE.md и перечисленные в нем актуальные материалы. Если файла нет, используй приложенные согласованные результаты.
Не запускай заново бриф и выбор идеи. Кратко восстанови текущий этап, готовое и открытые вопросы. Следующая задача: [задача]. Не меняй остальные части без конкретного основания.
После работы покажи, что сделано, какие файлы изменены, что действительно проверено и что остается. Обнови состояние проекта. Если нужных материалов нет, прямо укажи пробел, а не восстанавливай согласованные решения по догадке.Основание в вебинаре: Редакторское дополнение к работе с артефактами проекта; принцип фиксации — 01:06:34–01:08:02.
Оговорка: Не дословный прием из вебинара; добавлен для сохранения контекста между рабочими сессиями.