Menu
Ред-политика для гайдов по вебинарам. Превращаем транскрибации вебинаров в структурированные самостоятельные тексты. Две части: быстрый старт + подробный разбор.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Правила хорошего письма: связность, ясность, структура текста. Справочный скилл, который подключается из других скиллов при написании и редактуре текстов.
Ред-политика для статей-подборок сервисов. Пишем обзоры сервисов, инструментов и продуктов для аудитории проекта. Каждый сервис описывается по шаблону: название, ссылка, стоимость, описание.
Ред-политика для обычных авторских статей. Объединяет правила хорошего письма с общими принципами формата. Для статей, которые не являются подборками сервисов, гайдами или другими форматами с отдельной ред-политикой.
Ред-политика для обзорных статей-эссе по теме проекта. Словарные, обзорные и разборные статьи: что это такое, как это работает, чем отличается от соседних понятий. Фактура собирается самостоятельно через исследование.
Полный цикл создания статьи-подборки сервисов
Полный цикл создания обычной авторской статьи
| name | redpolicy-guide |
| description | Ред-политика для гайдов по вебинарам. Превращаем транскрибации вебинаров в структурированные самостоятельные тексты. Две части: быстрый старт + подробный разбор. |
| user-invocable | false |
Это не свод запретов и обязательных шаблонов. Это набор принципов и ориентиров, который помогает превратить транскрибацию в гайд. Применять их нужно осмысленно: если правило формально подходит, но в конкретном месте текст становится хуже — отступай от правила.
Главный критерий хорошего гайда — текст звучит как объяснение коллеге за кофе, а не как методичка. Если после правки фраза стала книжной или неестественной — правка плохая, даже если по политике корректна. Перед тем как применить любое правило отсюда, спроси себя: что это дает читателю? Если ответа нет — правило тут не нужно.
Обязательно смотреть: good-writing/SKILL.md (подход к работе) и
good-writing/antipatterns.md (классы ошибок).
Мы превращаем вебинары, лекции и интервью в структурированные гайды. Исходный материал — устная речь со всеми ее особенностями: повторами, отступлениями, разговорными оборотами. На выходе — текст, который можно читать независимо от записи.
Мы не пересказываем вебинар. Мы создаем самостоятельный продукт, который работает без видео.
Гайд — не конспект. Из вебинара берется только то, на чем держится инструкция. Главный тест каждого абзаца: что читатель сделает иначе, прочитав его? Если ответа нет — абзац под нож, каким бы интересным, фактически точным и «опирающимся на исходник» он ни был. Правило «если можно убрать без потери смысла — убрать» работает не только на уровне предложений, но и на уровне абзацев и целых блоков. Особо подозрительны абзацы со словами «убедились», «это хорошо видно на», «так спикер/мы сделали» — это почти всегда доказательства, что метод работает, или истории про спикера, а не инструкция. Работоспособность метода показывают сами шаги, а не заверения.
«Сохраняем экспертизу спикера» означает: сохраняем его метод и его правила, а не истории о нем. «Примеры берем из исходника» — про то, откуда брать примеры, когда они нужны, а не про обязанность перенести весь содержательный материал. Конспект-рефлекс («страшно потерять то, что спикер сказал») — системная ошибка, за которой нужно следить.
Полезность важнее краткости. Если деталь помогает читателю что-то сделать (цена, конкретный метод, доступный ресурс), она остается в тексте, даже если без нее абзац короче. Но «полезная деталь» — это деталь, которая меняет действие читателя; интересный факт, который ничего не меняет, под это правило не попадает.
Две части по умолчанию. Первая — быстрый старт для тех, кто хочет сразу применить. Вторая — подробный разбор для тех, кто хочет понять логику.
H1-заголовок статьи в файле не нужен — он живет в CMS. Текст начинается сразу с «## Часть 1».
Части не должны повторять друг друга. Первая часть отвечает на вопрос «что делать». Вторая — на вопрос «почему это работает». Не нужно в одном месте рассказывать кратко, а в другом то же самое подробно. Тема живет только в одной части. Если тему можно полностью раскрыть в первой части, она остается там. Во вторую идет только то, что требует отдельного концептуального разбора.
Первая часть начинается с действия. Никаких вводных блоков типа «что это такое и для чего подходит». Если нужно дать контекст, хватит одного-двух предложений перед первым шагом. Объясняющие и контекстные блоки живут только во второй части.
Это правило работает и внутри блоков: блок первой части начинается с действия, а не с предыстории. Витрина возможностей («весь сайт можно собрать без Figma — вот как сделала спикер»), личная методология спикера, рассказ «как было раньше» — все это либо вырезается, либо уезжает во вторую часть как отдельный разбор. Предыстория «раньше процесс выглядел так: …» — материал второй части, в первой части ей не место даже как подводке.
Перекрестные отсылки между частями не ставим. Никаких «подробнее об этом — во второй части» и «как вы помните из первой части». Если тезис просится в оба места — это дубль, и решается он удалением из одного места, а не отсылкой.
Блоки внутри частей должны быть логически завершенными. Один блок — одна задача читателя. Две разные задачи не склеиваются в один блок, даже если используют один инструмент и каждая по отдельности коротка: например, «локализовать контент сайта» и «защитить сайт от сканирования» — разные задачи, им нужны два блока, пусть второй и будет коротким. Укрупнять блоки можно только из родственных аспектов одной задачи. Переходы между блоками плавные, но без воды.
Вторая часть не пересказывает материалы, на которые стоят ссылки. Если разбор темы живет в статье, на которую дана ссылка, в гайде остается вывод и ссылка — не пересказ исследования.
Обычно хороший гайд держится в 10–12 блоках: 8–9 в первой части и 3–4 во второй. Если в плане получается 15+ блоков, это сигнал, что темы дробятся слишком мелко: каждый блок выходит тонким и формальным, текст становится перечнем, а не связной инструкцией.
Что делать: укрупнять. Объединять родственные темы в один блок (например, «GitHub-синхронизация» + «приглашение коллег» — это два аспекта одной темы расширения работы наружу). Несколько концептуальных блоков второй части часто можно слить в один, если они отвечают на смежные вопросы.
Это не жесткий лимит, а ориентир. 13 блоков — норм, если каждый по делу. 15+ — почти всегда переусложнение.
Часть 1 дает конкретные шаги, часть 2 — принцип. Если в первой части дано перечисление модулей («сначала каркас, потом авторизация, потом дашборд, потом интеграции»), во второй части его не повторять — там только формулировка принципа («каждый модуль собирайте отдельным промптом»). Иначе читатель видит одно и то же дважды.
То же про инструменты, кейсы, цифры. Если в блоке 1 дан полный чек-лист стоимости кредитов — в блоке 9 цифры не повторяются, там только агрегированный вывод.
Блоки второй части не должны быть чисто теоретическими. Каждый блок должен связывать теорию с конкретными шагами из первой части, показывать, как принцип работает на практике.
Плохо: Блок «Почему качество входных данных определяет результат» смешивает теорию с практическими инструкциями (настройка мета-промпта, выбор модели). Читатель не понимает, это блок про принцип или про настройку.
Хорошо: Блок начинается с формулировки принципа («Результат зависит от того, что дадите на вход»), затем показывается связь с практикой из первой части: «На этом принципе построена вся цепочка: раскадровка дает точные промпты для генерации кадров, покадровые промпты дают предсказуемый результат в Higgsfield, детальный промпт для ManyChat-бота дает осмысленную переписку с клиентом.» Затем идут практические инструкции по настройке, которые иллюстрируют этот принцип.
Заголовки второй части должны быть ближе к тому, как спикер формулирует идеи. Не «Почему качество входных данных определяет результат», а «Результат зависит от того, что дадите на вход» — если спикер использует именно эту формулировку.
Каждый блок первой части — это одна задача для читателя. Проверочный вопрос: может ли читатель сформулировать, что он сделает после прочтения этого блока, одним предложением? Если нет — блок перегружен и его нужно разбить.
Инструкции в первой части строятся от конкретного сценария, а не от абстрактной схемы. Сначала ситуация читателя («вам нужен кадр, где камера смотрит герою в спину»), потом действие («сгенерируйте фон отдельно от персонажа»), потом промпт или пример. Схемы, классификации, типологии и теоретические обоснования живут во второй части. В первой части допустимы только те схемы, которые являются непосредственной инструкцией к действию (например, формула промпта).
Информацию о входе (стоимость, подписка, системные требования, ограничения) размещаем в первом блоке, где читатель настраивает среду. Читатель думает о цене в момент, когда решает — пробовать или нет. Если отложить эту информацию на потом, читатель либо уйдет искать сам, либо будет читать с тревогой «а сколько это стоит?». Но только то, что есть в исходнике: если спикер не говорил «бесплатно» или «нужен такой-то аккаунт», мы это не дописываем от себя — даже если почти наверняка так и есть. Нет данных — нет утверждения.
Если в первом блоке идет обзор нескольких инструментов, каждый описывается компактно: название + роль одной строкой. Не вшиваем в обзор подробности про интерфейс, кейсы использования, типичные ошибки и так далее — у каждого инструмента дальше будет свой блок, там и место для деталей. В обзоре цель — чтобы читатель понял, какой инструмент за что отвечает, не раздулся первый блок и не возникло ощущения, что все уже сказано до начала практики.
Плохо (обзор Topaz в первом блоке): «Topaz Gigapixel — программа, которую нужно установить на компьютер. Она доводит картинку до финального размера без искажений: не фантазирует и не приукрашивает, просто увеличивает разрешение.» — половина блока 6 уже сказана здесь.
Хорошо: «Topaz Gigapixel — программа для увеличения разрешения без искажений.» — роль ясна, детали ждут своего блока.
Если инструмент или метод из источника имеет собственную механику (свои источники данных, свой процесс, свой результат), он заслуживает отдельного блока — даже если текст станет длиннее. Не вшивать такие инструменты внутрь другого блока как пример или подпункт.
Внутри блока не используем жирные подзаголовки для подтем. Если блок содержит несколько связанных подтем (например, три типа референсов — персонажи, реквизит, локации), они вплетаются в повествование через обычные предложения. Жирный подзаголовок внутри блока визуально разбивает его на секции и превращает прозу в замаскированный буллит-лист.
В гайдах используется прямой императив во 2 лице мн. ч.: «Зайдите», «Откройте», «Нажмите», «Скачайте», «Загрузите». Это правило перебивает общее правило good-writing про «можно/нужно/стоит + инфинитив». Гайд — пошаговая инструкция, читатель будет выполнять действия одно за другим. Императив звучит как ясная команда, модальность («можно сделать», «стоит загрузить») — как отстраненный совет, который не двигает читателя по шагам.
То, что произойдет после действия читателя, описывается в будущем времени, а не в настоящем. На момент чтения читатель еще ничего не сделал.
Плохо: «Зайдите в Cursor. Слева видны файлы проекта, справа открыт чат с агентом.» — настоящее время для того, чего еще нет.
Хорошо: «Зайдите в Cursor. Слева появится файловая панель, справа — чат с агентом.» — императив для действия читателя, будущее время для результата.
Плохо: «Можно открыть Claude Code и написать запрос. На выходе получится ответ.» — модальность вместо императива; для гайда звучит вяло.
Хорошо: «Откройте Claude Code и напишите запрос. На выходе появится ответ.» — прямая инструкция.
Плохо: «Стоит сразу посмотреть, что входит в тариф.» — модальность. Хорошо: «Сразу посмотрите, что входит в тариф.» — прямая инструкция.
Плохо: «Текущую рабочую версию стоит пометить favorite.» — отстраненный совет. Хорошо: «Пометьте текущую рабочую версию favorite.» — прямая команда.
Описание поведения инструментов и сервисов дается в будущем времени, чтобы согласовываться с императивом действий читателя. Не «Lovable выгружает каждое изменение в репозиторий», а «Lovable будет выгружать каждое изменение в репозиторий».
Заголовки блоков первой части — тоже в императиве, не в инфинитиве. Не «Зайти в Lovable и разобраться с тарифами», а «Зарегистрируйтесь и выберите тариф». Не «Менять текст и цвет через визуальный редактор», а «Поправьте текст и цвет через визуальный редактор».
Не драматизировать описания. Факт сильнее сцены.
Плохо: «Терминал выглядит непривычно: черное окно, мигающий курсор, никаких кнопок.» — мини-сцена для эмоционального эффекта.
Хорошо: «Самый простой вариант — стандартный терминал Mac, который уже установлен на компьютере.» — просто факт.
Проверочный вопрос: «Это команда читателю или совет? В гайде — команда. Императив + будущее время для последствия. Если в тексте написано "стоит/можно/нужно + инфинитив" — переписать в императив.»
Исключение — общий совет-привычка, а не шаг сценария. Императив несовершенного вида в роли постоянной рекомендации звучит как понукание — такие советы даются через модальность. «Привязывайте анимацию к классу элементов» → «Анимацию лучше привязывать к классу элементов». «Работайте с Claude так: ставьте задачи» → «С Claude можно работать так: ставить задачи». Различение простое: одноразовый шаг по сценарию («Залейте сайт в папку») — императив; привычка на все будущие случаи — «лучше/можно + инфинитив».
Результаты шагов читателя — в будущем времени или через «можно будет», даже в описательных фразах между шагами. Настоящее время — дефолт описательного текста («в одной колонке исходный текст», «тексты можно править в таблице», «по этой странице сразу видно»), но читатель еще ничего не сделал, поэтому: «в одной колонке будет исходный текст», «тексты можно будет править», «сразу будет видно», «придется объяснять» (не «приходится»), «такой связки точно хватит» (не «хватает»).
Вид, лицо и время глаголов внутри абзаца согласованы. Если повествование идет в настоящем («уходит, рисует, приносит»), итог не может стоять в прошедшем («съедало» → «съедает»). Если началось «все смотрели», то дальше «каждый представлял», а не «представил». Сослагательное наклонение не обрывается в настоящее: «пришлось бы нанимать редактора… и все это тянулось бы долго», а не «…Все это долго».
«Срыв времени» в гайде проявляется не только во втором глаголе предложения. Часто ошибка — в том, что результат действия читателя описан в настоящем, как будто читатель уже все сделал и ты комментируешь происходящее. На момент чтения он еще ничего не сделал, поэтому все, что произойдет после его шага — в будущем.
Особенно часто прокрадываются формы:
Проверочный прием: пройтись по тексту инструкционных блоков и в каждом предложении задать вопрос — «это про то, что у читателя сейчас перед глазами, или про то, что появится после его действия?». Если про результат действия — будущее или активный императив, не настоящее и не пассив.
Эталоны гайдов пользователь кладет в examples/guides/. Перед планированием и написанием нужно прочитать 1–2 текста, которые ближе всего к текущей задаче: по теме, сложности и типу исходника.
Из эталонов берется не содержание, а редакционное поведение: длина блоков, плотность объяснения, способ перехода от шага к шагу, баланс инструкции и пояснения. Если старый эталон расходится с этой политикой, действует политика.
Если эталонов нет, не подменяй их придуманными примерами. Работай по этой ред-политике и правилам хорошего письма, а пользователю сообщи, что для точного попадания в стиль нужно добавить 1–2 своих готовых гайда.
В гайде особенно важны: прямые команды («Зайдите», «скачайте», «сделайте», «отправьте», «напишите», «запустите»), будущее время для результатов («появится», «попросит»), простые короткие предложения, минимум отсылок к другим блокам.
Первое предложение нового блока должно подхватывать результат предыдущего. Это создает непрерывность повествования.
Плохо: Блок 2 заканчивается раскадровкой. Блок 3 начинается с «Статичные кадры генерируются в Midjourney» — прыжок, читатель не понимает связи.
Хорошо: «Когда раскадровка и промпты для каждой сцены будут готовы, останется выполнить три шага: сгенерировать статичные кадры, оживить их и смонтировать.» — первое предложение блока 3 подхватывает результат блока 2 и вводит в новый этап.
Если блок ссылается на понятие, термин или действие из предыдущего блока, нужно коротко напомнить контекст. Не писать «тот самый, который вы заготовили» — это требует, чтобы читатель помнил детали. Вместо этого встроить напоминание в предложение: «картинку персонажа со спины — если вы собрали референсную базу по инструкции из первого блока, она у вас уже есть». Читатель не должен листать назад, чтобы понять текущий абзац.
Если термин вводится в одном блоке, а используется в другом, убедитесь, что читатель свяжет одно с другим. Если в блоке 1 вы объяснили, что character sheet — это опорная карточка персонажа, а в блоке 3 написали «прикрепите character sheet в ракурсе со спины», читатель может не понять связи. Лучше: «прикрепите картинку персонажа в ракурсе со спины».
Альтернативные пути и дополнительные способы идут после основного пути, а не в середине блока. Если основной блок описывает работу с одним инструментом, альтернативный способ должен идти в конце блока, после всех инструкций по основному способу.
Если во второй части планируется блок, который пробегает по всем этапам процесса, он неизбежно будет дублировать соседние блоки. Не делайте его: если каждый блок второй части и так начинается с обозначения проблемы, отдельная карта не нужна, а «навигационный» блок из отсылок — это оглавление, замаскированное под текст.
Гайд заканчивается последним содержательным выводом — без мотивационной концовки. Никаких абзацев-напутствий («весь этот пайплайн начинается с одного небольшого шага…»), призывов и призыв к действию («вступайте в…», «подписывайтесь на…»), ссылок на каналы спикера или сообщества. Рефлекс «закончить красиво» дает мотивационную воду; красиво — это закончить по сути. Допустим финальный выделенный абзац с главной мыслью спикера, если она содержательна сама по себе, а не зовет куда-то.
Принцип объясняем через примеры. Абстрактные формулировки работают хуже, чем конкретные ситуации. Если говорим, что одна тема превращается в разные тексты, показываем два варианта текста на одну тему.
Примеры берем из исходника. Не придумываем от себя то, чего не было в вебинаре. Если спикер приводил пример с CRM, используем его. Если примера не было, а он нужен, строим его на основе логики спикера.
Промпты — часть текста, а не приложение. Если в источнике есть готовые промпты, они встраиваются в гайд как рабочие инструменты. Каждый промпт сопровождается:
Плохо: Промпт дан, но не показано, что он выдаст на выходе. Читатель не понимает, правильно ли он применил промпт.
Хорошо: После промпта: «На выходе получится таблица, в которой расписаны все сцены с таймингами, описанием действия и готовыми промптами для генерации статики и видео.» Или: «ManyChat-бот начинает переписку: "Guten Tag, это Каролина. У меня для вас два подарка..."»
Если промпт слишком объемный (десятки страниц), не вставляйте его целиком. Дайте ссылку на скачивание полной версии, а в тексте разместите рабочую выжимку — компактный фрагмент, достаточный для понимания и старта.
Если промпта или материала нет в транскрибации и получить его до написания не удалось — ставится явный плейсхолдер: «[Вставить промпт для оценки метафор]», «[вставить ссылку на статью]». Нельзя писать текст, который делает вид, что промпт где-то есть, и просто упоминает его.
Примеры запросов, которые читатель захочет скопировать, оформляются блоками кода, а не кавычками внутри абзаца.
Гайд работает без внешних материалов. Не отсылайте читателя за ключевой информацией на доску, видео или другой источник. Если промпт лежит в доске Miro, а не в транскрибации — запросите доску и встройте промпт в текст. Ссылки на внешние инструменты (боты, сервисы) допустимы, но читатель должен понимать, что это за инструмент и зачем он нужен, не переходя по ссылке.
Инструкции для конкретных инструментов. Если в источнике процесс показан на примере конкретного инструмента (Miro, ChatGPT), инструкция дается коротко, в одно-два предложения, рядом с промптом. Но промпт всегда подается как универсальный — «скопируйте и загрузите в любую ЛЛМ», а инструкция по конкретному инструменту идет следом как один из вариантов.
Промпты встраиваются на этапе написания блока, а не добавляются отдельным проходом после.
Ссылки на инструменты и сервисы — обязательно. Каждый раз, когда спикер называет конкретный инструмент, сервис, MCP-сервер или приложение по имени — в тексте рядом с первым упоминанием ставится ссылка на него. Это правило без исключений: Linear, Appwrite, Context 7, LangFuse, GitHub, Codex, Gemini и любые другие. Ссылку добавляет тот агент, который первым упоминает инструмент в своем блоке. Final-reviewer проверяет, что все инструменты из исходника снабжены ссылками.
Ссылки вшиваются в значащие слова, а не вставляются голым доменом в скобках. Не «премиального мужского салона (lukebaffait.fr)», а «премиального мужского салона». Голый домен в скобках — мусор в строке.
Все ключевые сценарии использования инструмента. Если инструмент из источника используется в нескольких контекстах (например, MCP-серверы — и для итогов недели, и для ежедневного закрытия задач), показать все основные сценарии, а не только тот, который совпадает с темой блока. Читатель должен понимать полную ценность инструмента, а не один его аспект.
Чеклисты и схемы из источника — встраивать в текст, если они добавляют новую информацию. Если спикер давал готовый чеклист, схему действий, набор правил или список шагов, и эта информация не дублирует уже сказанное в прозе блока — оформляй с подводкой и размещай в тематическом блоке.
Если же чеклист просто разбивает на пункты то, что уже объяснено прозой («1. Откройте проект. 2. Пометьте версию. 3. Сделайте правку. 4. При проблеме откатитесь») — он избыточен. Проза уже сделала свою работу, нумерация ничего не добавляет. Тогда чеклист не вставляем.
Не каждый факт из исходника должен попасть в гайд. Перед тем как переносить факт в текст, спроси: нужен ли он большинству читателей? помогает ли он понять или применить материал? Если факт нужен 5% аудитории и не помогает остальным — выкидывай.
Edge-case, которые по умолчанию НЕ попадают в гайд:
В живой речи спикер на вебинаре может все это упомянуть мимоходом — это нормально для устного формата. В структурированном гайде такие вкрапления читаются как мусор. Если факт важен в контексте вебинара, но не в контексте задачи читателя — не переносим.
Главный вопрос к каждому факту: если этот факт убрать, читатель потеряет в понимании или возможности применить? Если нет — убирай.
Помимо «эджкейсов» и редакционной фильтрации фактуры, есть классы содержимого, которые системно прокрадываются в гайд из-за привычки писать эссейно или лекционно. В инструкции они работают как балласт. Идя по черновику на финальной проверке, охоться на каждый из них отдельно.
Соблазн вставить в инструкционный блок «живой кейс» — «вот так на вебинаре спикер сделал обложку для трека Ранний», «вот так через этот метод собрали ролик для подкаста». Проверочный вопрос: понятно ли действие без этого кейса? Если шаг самодостаточен, кейс лишний — он не добавляет инструкции, только добавляет длины. Реальная история уместна, когда она показывает неочевидную комбинацию шагов или нетипичный выбор параметра. «Роман сделал релиз в топ-5 через этот пайплайн» не помогает ничему конкретному — убирай.
Формула: кейс остается, если он несет шаги; кейс вырезается, если он их иллюстрирует или доказывает. Кейс несет шаги, когда события кейса и действия читателя — одно и то же («Claude проанализировал референсы, сверстал похожее под бренд и настроил тап с телефона» — это и есть инструкция). Кейс иллюстрирует, когда инструкция уже дана предложением раньше, а история лишь показывает ее в лицах («пустите редактора в таблицу. Спикер так отдала раздел услуг коллеге — та переписала текст прямо в ячейке» — вторая фраза вырезается).
Кейсы и якорные истории могут работать в эссейной части или во второй части гайда как иллюстрация концепции. В инструкционных блоках первой части — нет.
«Мы попробовали и убедились», «прогнали на реальных проектах — помогает», «это хорошо видно, если залить туда сайт Apple» — абзацы-доказательства того, что инструмент умный, а метод рабочий. Они не меняют ни одного действия читателя: инструкция уже дана, история про тест ничего к ней не добавляет. Удалять целиком, даже если факт интересный и взят из исходника. Работоспособность показывают сами шаги и результат кейса, который несет шаги.
Не описывать неверный способ и его последствия, чтобы потом дать правильный. Читателю нужен только правильный — встроенный прямо в формулировку шага.
Плохо: «Если попросить обновить вообще все, Claude будет делать это долго. Поэтому лучше указывать конкретные строки или раздел: …» Хорошо: «…вернитесь в Claude и скажите, какой раздел сайта обновился.»
Правильное действие встраивается в шаг — и оговорка про медленный путь становится не нужна. Исключение: антипример допустим во второй части, когда он сам и есть содержание разбора (старая цепочка согласований объясняет, почему технические ограничения убивали идеи).
Не переносить в гайд: баги и нестабильности конкретной среды спикера («автоматически страница обновляется не всегда — просите вручную»), планы, которые спикер еще не реализовал («может, соберем под это мини-скилл»), предупреждения, которые не меняют ни один шаг инструкции (история про бан аккаунта). Гипотезы и планы — не инструкция; в гайд попадает только устоявшаяся воспроизводимая практика.
Ред-политика разрешает атрибуцию личного выбора и экспертного мнения («по опыту Владислава», «Олег предпочитает Claude Sonnet»). Но если этой атрибуции не требует сам совет — убирай. «Роман в обложках с оружием намеренно оставляет пистолет условным» в конце совета про модерацию не работает — достаточно самого совета «делайте пистолет условным». Гайд сам по себе — авторитет, читателю не нужно каждое правило подкреплять «спикер делает именно так».
Проверочный вопрос на финальной проверке: «без имени спикера этот совет звучит слабее?». Если нет — имя удаляй.
Фразы вроде «Дальше — артист и типографика», «Об этом подробнее в следующих блоках», «Финальный размер можно будет получить уже следующим инструментом», «Во второй части — почему это работает» — все они описывают структуру гайда, а не содержание. Читатель видит следующий заголовок и понимает, что там, без твоих подсказок. Каждая такая связка — шум, который размывает ритм инструкции.
Отсылки «подробнее во второй части» тоже не ставим (см. «Перекрестные отсылки» в разделе про структуру). Если в первой части без объяснения не обойтись — дать объяснение в одно предложение на месте; если тема требует разбора — она целиком живет во второй части, а первая обходится без упоминания.
Привычка начинать блок с пересказа того, что у читателя уже есть: «На этом шаге у вас на руках две картинки 3000×3000. Первая — Topaz-версия, вторая — Krea Enhance-версия. Задача этого шага — собрать из них одну». Это мета-комментарий к инструкции, а не сама инструкция. Читатель сам помнит, что у него на руках, — он только что дочитал предыдущий блок. Начинай блок с первого действия или короткой формулировки задачи, не с рекапа.
Плохо: «Это финальный шаг первой части. На выходе можно будет получить обложку, которую можно будет загружать в дистрибьютор и отправлять в релиз. Если обложка предполагает артиста...»
Хорошо: «Если обложка предполагает артиста, с его фотографией нужно проделать отдельную работу...» — сразу в дело.
В инструкции объяснение нужно только там, где без него действие непонятно или читатель сделает его неправильно. «Формат 1:1, чтобы на следующих шагах дойти до 3000×3000» — полезно: без этой связки непонятно, зачем квадрат. «Enhance нельзя пропускать, потому что без него картинка останется плоской, и никакой последующий апскейл ей фактуры уже не вернет» — балласт: инструкция и так говорит «прогоните через Enhance», обоснование добавляет длины, но не меняет поведение читателя.
По умолчанию инструкция дает только «что» и «как». «Почему» добавляется точечно, когда без него шаг нельзя сделать правильно.
Соблазн в конце инструкции собрать блок «Что инструмент не умеет» как честный свод. Проверь перед этим: не упоминал ли ты уже эти ограничения по ходу практических блоков? Если про типографику уже есть в блоке про финальную сборку, про желтизну — в блоке про генерацию, про множественные объекты — там же, то отдельный блок про все это — повтор. Отдельный блок оправдан только для ограничений, которые не вписались ни в один практический шаг и которые действительно меняют стратегию читателя.
Не добавляем информацию, которой нет в источнике. Если спикер чего-то не говорил, мы это не придумываем. Можем переструктурировать, переформулировать, сделать понятнее — но не додумывать. Это касается и объяснений-теорий: если спикер сказал «инструмент не дает рабочих метафор», но не объяснял почему, мы не дописываем правдоподобную теорию от себя. Хочется, чтобы у каждого тезиса было обоснование, — но додуманное обоснование хуже его отсутствия. И условий входа: «бесплатно», «нужен аккаунт» — только если это прозвучало в исходнике.
Абсолюты смягчаются до защитимого. «Большинство фестивальных сайтов построено на этой библиотеке» — недоказуемое утверждение; если в исходнике это личное наблюдение спикера, пишем «большое количество сайтов» и сохраняем атрибуцию («по наблюдениям Аси»).
Сохраняем экспертизу спикера. Если спикер рекомендует конкретный инструмент или критикует другой, это остается в тексте. Мы не сглаживаем острые углы и не делаем текст нейтральнее, чем он был. Если спикер описывает конкретный метод создания чего-то (не просто «сделал», а «сделал через X таким-то способом»), этот метод включается в текст — это практическая инструкция для читателя, а не деталь биографии.
Убираем устную избыточность. Повторы, оговорки, отступления от темы, фразы-паразиты — все это уходит. Но характер речи, авторские примеры и формулировки по возможности сохраняем.
Доступные ресурсы спикера — это инструменты для читателя. Если спикер упоминает, что шаблон, скилл, репозиторий или другой ресурс доступен (выложен в открытый доступ, можно запросить, есть ссылка), это обязательно включается в текст. Это не биографическая деталь про спикера, а конкретная точка входа для читателя. Исключение — каналы, блоги и подписки спикера: «следите за моей работой в телеграм-канале» — это промо, а не рабочий инструмент, в гайд не включаем.
Запрашивайте дополнительные материалы. Если в транскрибации спикер ссылается на доску, шаблон, бота или другой материал, который не вошел в транскрибацию — запросите его у автора до начала написания. Не пишите текст без ключевых материалов, надеясь добавить их потом.
Не каждый факт из источника должен попасть в текст. Полезность важнее краткости — но это не значит «перенести все». Если три инструмента перечислены подряд без контекста, текст превращается в справочник, а не в повествование. Каждый факт должен работать на задачу блока: помогать читателю что-то сделать или понять принцип. Если факт не работает на задачу блока — он либо переносится в другой блок, либо опускается.
Проверочный вопрос: «Этот факт помогает читателю выполнить задачу блока или понять принцип? Или он здесь просто потому, что был в источнике?»
Дополнительный фильтр для деталей: «Без этой детали читатель сможет выполнить действие?» Если да — деталь избыточна, убирать. Транскрибация вебинара всегда содержит больше контекста, чем нужно гайду: размышления спикера, побочные реплики, реакции на вопросы из чата. В гайд попадает только то, без чего действие не получится.
Метафоры спикера — его инструмент для устного рассказа, не часть инструкции. Образные сравнения в гайде не нужны, если они не помогают выполнить шаг. Гайд работает на конкретике, а не на образах.
Термины и отсылки, унаследованные из курса или из контекста, в котором был записан вебинар, убираются безжалостно. Гайд читается людьми, которые курс не проходили. Если спикер говорит «как мы обсуждали на прошлой неделе» или использует термин из своей методологии без объяснения — или объясняем термин, или переформулируем без него. Отсылок к курсу в тексте гайда быть не должно.
Первая часть — это инструкция для читателя, а не рассказ о вебинаре. Спикер НЕ может быть субъектом действия в инструкционных блоках. Конструкции «На вебинаре спикер показал/сделал/продемонстрировал» запрещены — мы не пересказываем вебинар.
Единственное допустимое упоминание спикера в первой части — атрибуция личного выбора или экспертного мнения: «По опыту Владислава, Claude Sonnet достаточно для этих задач.»
Как трансформировать описательный стиль в инструкционный:
Плохо: «Владислав решает эту проблему в два шага. Сначала он генерирует фон отдельно от персонажа.» Хорошо: «Эту проблему можно решить в два шага. Сначала сгенерируйте фон отдельно от персонажа.»
Плохо: «На вебинаре Владислав показал этот процесс на примере музыкального клипа. Он отправил ассистенту идею.» Хорошо: «Вот как это работает на примере музыкального клипа. Вы отправляете ассистенту идею.»
Плохо: «Владислав собирает эти цепочки визуально в Flora — агрегаторе.» Хорошо: «Цепочки удобно собирать визуально в Flora — агрегаторе.»
Плохо: «Саунд-дизайн Владислав полностью генерирует в ElevenLabs.» Хорошо: «Для саунд-дизайна можно использовать ElevenLabs.»
Плохо: «Для анимации Владислав использует Kling: загружает утвержденную картинку как стартовый кадр.» Хорошо: «Для анимации подойдет Kling: загрузите утвержденную картинку как стартовый кадр.»
Проверочный вопрос для каждого предложения первой части: «Кто здесь субъект — читатель или спикер? Если спикер — переписать так, чтобы субъектом стал читатель или безличная конструкция.»
Спикер — участник повествования, а не предмет репортажа. Его имя появляется естественно, когда речь идет о его личном опыте, выборе или рекомендации.
Хорошо: «Олег пользуется iTerm вместо стандартного терминала — по его словам, так удобнее работать с несколькими проектами.» — имя встроено в повествование, это его личный выбор.
Хорошо: «По опыту Олега, Claude Code лучше справляется с задачами, если дать ему контекст проекта заранее.» — ссылка на экспертизу спикера.
Плохо: «Олег рассказывает, что использует Claude Code. Олег показывает, как настроить проект. Олег рекомендует начать с простых задач.» — каждое предложение начинается с имени, текст читается как репортаж.
Плохо: «Спикер отмечает, что...», «Эксперт подчеркивает...» — журналистские конструкции, которые дистанцируют читателя от содержания.
Когда речь идет не о личном опыте спикера, а об общем принципе или инструкции для читателя, имя спикера не нужно. «Claude Code умеет работать с файлами проекта» — это факт, не мнение Олега.
Фреймирование через «допустим» подходит для гипотетических сценариев, которые читатель примерит на себя: «Допустим, вам нужно собрать дашборд для отдела продаж.»
Но если спикер рассказывает свою реальную историю с конкретными деталями, «допустим» убивает достоверность. Реальный кейс сильнее гипотезы. «Олег собрал такого агента для своего подкаста» работает лучше, чем «Допустим, вам нужно обрабатывать подкасты».
Проверочный вопрос: «Это общий сценарий, который читатель примерит на себя? Тогда «допустим». Это конкретный опыт спикера с деталями? Тогда его реальная история.»
Этот выбор делается только после теста из раздела «Кейсы-иллюстрации»: сначала решаем, нужен ли пример вообще (несет ли он шаги), и только потом — как его фреймировать. Кейс, который лишь доказывает работоспособность метода, не проходит первый тест, и выбор фреймирования для него не возникает.
После написания текста проверяем исходник на пропущенные важные идеи. Спикер мог упомянуть важные детали, которые легко пропустить при первом чтении:
Проверочный вопрос: «Все ли ключевые идеи и детали из источника попали в текст?»
Без одобрения структуры к написанию не переходим. Структура — это каркас, и менять его на ходу дорого.
При презентации структуры под каждым пунктом пишем одно предложение: какая конкретно информация будет в этом блоке. Не только название темы, но и ее границы — что входит, что не входит. Это помогает увидеть дублирование до начала написания.
После составления структуры проходим по каждому пункту части 2 и проверяем: есть ли в части 1 пункт на ту же тему? Если да — объединяем в одном месте.
После написания проверяем: не повторяется ли информация между частями, нет ли мест, где кратко пересказываем то, что потом разбираем подробно. Если такие места есть — оставляем тему в одном месте и удаляем из другого. Отсылку взамен не ставим.
Проверка на нейромаркеры (после написания каждого блока): нет ли жирных подзаголовков внутри блока, которые превращают прозу в список? Не осталось ли рабочих комментариев или промежуточных заметок?
Проверка на дубли (отдельный проход после написания всех блоков): для каждого факта, утверждения или совета проверить — встречается ли он больше одного раза? Если да — в одном месте оставить факт или действие, из другого убрать. Не заменять отсылкой.
Проверка на связность терминов (отдельный проход): каждый термин, который вводится в одном блоке и используется в другом, должен быть узнаваем без листания назад. Если термин впервые появляется с объяснением, а потом используется без него — добавить короткое напоминание контекста в месте использования.
Проверка на описательный стиль (отдельный проход по первой части): в каждом предложении проверить — кто субъект действия? Если спикер («Владислав генерирует», «спикер показал», «на вебинаре он сделал») — переписать так, чтобы субъектом стал читатель или безличная конструкция. Первая часть — инструкция, а не репортаж.
Проверочные вопросы перед публикацией: можно ли понять текст, не смотря вебинар? Не повторяются ли части друг друга? Встроены ли промпты в текст с подводками и примерами результата? Все ли внешние инструменты и боты снабжены ссылками и объяснением, что это и зачем? Может ли читатель сформулировать, что он сделает после каждого блока первой части, одним предложением? Нет ли в первой части абстрактных схем, которые описывают систему, но не дают конкретного действия? Все ли ключевые идеи из источника попали в текст? Понятно ли, сколько чего нужно сделать на каждом этапе? Все ли ключевые сценарии использования инструментов показаны (не только один)? Есть ли информация о стоимости/входе в первом блоке (и только из исходника)? Нет ли в первой части предложений, где спикер — субъект действия?
Примеры гайдов находятся в examples/guides/. Загрузи 1–2 самых близких к задаче примера и используй их как образец структуры, ритма и плотности объяснения. Если примеров нет, работай по этой политике и предупреди пользователя, что для точного попадания в стиль нужны его эталонные тексты.
