| name | write-guide |
| description | Полный цикл создания гайда по вебинару из транскрибации |
| disable-model-invocation | true |
| argument-hint | ["путь-к-транскрибации"] |
Создание гайда по вебинару
Запусти полный цикл создания гайда.
Исходный материал (транскрибация): $ARGUMENTS
Что важно понимать про этот процесс
Главный инструмент качества — твоя финальная проверка в основном контексте, не агенты. Агенты пишут черновик по парам блоков, у них нет полной картины и они склонны механически применять чек-листы. Ты видишь весь текст целиком, помнишь историю разговора с пользователем, знаешь эталон и его стиль — поэтому именно ты ловишь книжные конструкции, срывы времен в описательных блоках, дубли между частями и прочее.
Раньше в цепочке были агенты plan-checker, text-checker, final-reviewer. Они вылизывали текст по чек-листам и делали его механическим. Теперь эти этапы делаешь ты — читаешь и правишь в основном контексте.
Перед тем как писать — обязательно прочитай ред-политику, правила хорошего письма и пользовательские эталоны.
Эталоны лежат в examples/guides/. Если в папке есть несколько текстов, выбери 1–2 самых близких по задаче и прочитай их целиком. Стиль формируется из эталонов, а правила нужны для проверки в моменты сомнения.
Если examples/guides/ пустая, не выдумывай чужой эталон. Сообщи пользователю, что точность попадания в стиль будет ниже, и продолжай по ред-политике и правилам хорошего письма.
Рабочая папка
- Возьми имя файла из $ARGUMENTS (без пути к директории и без расширения .md)
- Рабочая папка: output/[имя файла]/
- Создай папку командой: mkdir -p output/[имя файла]/
Параметры для всех агентов
- Тип контента: guide
- Ред-политика: skills/redpolicy-guide/SKILL.md
- Правила письма: skills/good-writing/SKILL.md и skills/good-writing/antipatterns.md
- Эталон стиля: 1–2 пользовательских текста из examples/guides/, если они есть
Шаг 1: Планирование (агент)
Используй подагента planner.
Передай ему:
- путь к исходнику ($ARGUMENTS)
- тип контента: guide
- путь к ред-политике
- рабочую папку
- ориентир по объему: 10–12 блоков (8–9 в первой части + 3–4 во второй). Один блок — одна задача читателя: разные задачи не склеивать ради счетчика.
- эталон стиля — прочитать 1–2 текста из
examples/guides/, если они есть, и держать в голове их структуру и подачу.
- ключевые запреты на уровне плана: не закладывать кейсы-доказательства («прогнали и убедились») и истории про спикера, не несущие шагов; не закладывать предыстории «как было раньше» в блоки части 1; вход/стоимость — только то, что прозвучало в исходнике; финал — последний содержательный вывод, без закольцовок-напутствий, призывов и каналов спикера; к каждому факту плана — тест «что читатель сделает иначе?»
Шаг 2: Проверка плана (ты в основном контексте)
Агент plan-checker больше не используется. Проверяешь план сам.
Что делаешь:
- Прочитай
[рабочая папка]/plan.md целиком.
- Прочитай выбранные эталоны из
examples/guides/, если еще не читал, чтобы помнить целевой стиль.
- Оцени план по ключевым критериям:
- Количество блоков. Больше 12 — значит, темы дробятся слишком мелко, объединяй родственные. Меньше 10 — возможно, чего-то важного не хватает. Но объединяй только родственные аспекты одной задачи читателя. Две разные задачи (например, «локализовать сайт» и «защитить сайт от сканирования») не склеиваются в один блок ради счетчика — пусть лучше будет лишний короткий блок. Один блок — одна задача.
- Заголовки первой части и финала в императиве. «Зарегистрируйтесь в Lovable», а не «Зайти в Lovable». Инфинитивные заголовки планера — первая правка на этом этапе.
- Заголовки второй части — повествовательные. Описание, а не команда.
- Фильтр пользы факта. Смотри на перечень ключевых фактов в плане: edge-case типа студенческих скидок, разовых акций, обходных хаков надо выкидывать — в гайде они не нужны большинству читателей. См. раздел «Фильтр пользы факта» в редполитике.
- Конспект-рефлекс в фактах плана. К каждому заложенному факту и кейсу задай вопрос: «что читатель сделает иначе?» Доказательства, что инструмент умный (тесты «мы закинули X и убедились»), истории про спикера, предупреждения-анекдоты (бан аккаунта), баги чужой среды, нереализованные планы спикера («может, сделаем скилл») — вычеркивай из плана сразу, до writer.
- Предыстории в части 1. Если в инструкционном блоке заложено «как было раньше» (старая цепочка, старый процесс) — это материал второй части или мусор. В части 1 блок начинается с действия.
- Вход/стоимость — только из исходника. Если планер заложил «бесплатно, нужен такой-то аккаунт», проверь по транскрибации, что спикер это говорил. Не говорил — вычеркивай.
- Дубли между частями. Если в блоке из части 1 и в блоке из части 2 одни и те же перечисления (модули проекта, инструменты, шаги) — развести: в части 1 конкретные шаги, в части 2 только принцип. Перекрестные отсылки «подробнее во второй части» не закладывать — дубль решается удалением.
- Жанр и форма глагола для каждого блока. Часть 1 и финал — инструкция (императив + будущее). Часть 2 — описание (модальность, безличность). Помни это при чтении будущего черновика.
- «Обзорный блок ограничений» во второй части. Если планер заложил отдельный блок типа «Что инструмент не умеет» / «Слепые зоны инструмента» / «Чего избегать», проверь: не разбросаны ли эти ограничения уже по практическим блокам части 1 (по ходу шагов с этим инструментом)? Если да — отдельный блок-обзор не нужен, он будет повтором. Удаляй его на этапе плана, не давай ему попасть в writer.
- «Якорный кейс» в инструкционных блоках. Кейс остается, только если он несет шаги (события кейса = действия читателя). Кейс-иллюстрация и кейс-доказательство («прогнали и убедились») — вычеркивай. Помечай в плане кейсы, которые нельзя тащить в текст, чтобы writer их не взял.
- Финал без промо. Если планер заложил закольцовку-напутствие, призыв или канал спикера — вычеркивай. Гайд заканчивается последним содержательным выводом.
- Недостающие материалы. Если в плане числится промпт/шаблон, которого нет в транскрибации, — запроси у пользователя на этапе согласования плана. Не получил — в тексте будет явный плейсхолдер «[Вставить …]», а не пересказ.
- При необходимости переписывай план сам — не запускай обратно агента. Ты работаешь быстрее и не ломаешь собранную фактуру.
Шаг 3: Согласование плана
Покажи пользователю [рабочая папка]/plan.md и расскажи коротко, что поменял после своей проверки. Спроси, одобряет ли план.
- Если одобряет — переходи к следующему шагу
- Если просит изменения — внеси правки в
plan.md и покажи обновленную версию
- НЕ НАЧИНАЙ писать текст, пока план не будет явно одобрен словами типа «ок», «давай», «пиши», «одобряю»
Шаг 4: Написание по блокам (агенты)
После одобрения плана переходим к написанию. Текст пишется парами блоков — не весь сразу.
Подготовка
Прочитай [рабочая папка]/plan.md. Найди все пронумерованные блоки в порядке их следования в тексте.
Разбей на пары: [1–2], [3–4], [5–6] и т.д. Если блоков нечетное число — последняя группа из одного блока. Большие объединенные блоки (например, в части 2) пиши одиночным агентом.
Итерация
Для каждой пары запускай отдельного агента writer. Выполняй строго последовательно — жди завершения одного агента, затем запускай следующего.
Каждый агент writer получает:
- Путь к исходнику ($ARGUMENTS)
- Тип контента: guide
- Ред-политика: skills/redpolicy-guide/SKILL.md (с особым вниманием к разделам «Подход к работе», «Как описывать действия читателя», «Фильтр пользы факта»)
- Правила письма: skills/good-writing/SKILL.md (манифест про подход) и skills/good-writing/antipatterns.md
- Эталон стиля в промпте: если в
examples/guides/ есть пользовательские эталоны, встроить 3–4 подходящих абзаца прямо в промпт как образец подачи. Не «прочитай файл», а готовый текст в промпте — иначе агент не проникнется стилем. Подбирай абзацы под жанр блоков агента: для части 1 — инструкционные, для части 2 — описательные.
- Полный план:
[рабочая папка]/plan.md
- Уже написанный текст: содержимое
[рабочая папка]/draft.md (пустое для первой пары; нарастает с каждой итерацией)
- Задание: «напиши блоки X и Y, добавь в конец
[рабочая папка]/draft.md»
Агент не перезаписывает draft.md — только дописывает в конец.
Обязательные требования к каждому агенту writer:
- Тест каждого абзаца: что читатель сделает иначе, прочитав его? Нет ответа — абзац не пишется, каким бы интересным ни был факт из исходника. Под запретом абзацы-доказательства («мы убедились», «это хорошо видно на примере X»), витрины возможностей и предыстории перед инструкцией, истории про спикера, не несущие шагов.
- Кейс несет шаги или вырезается. Кейс остается, если события кейса и действия читателя — одно и то же. Кейс-иллюстрация уже данной инструкции — не пишется, даже если есть в плане.
- Неправильный путь не описывается. Верное действие встраивается прямо в формулировку шага («скажите, какой раздел обновился»), без «если сделать не так — будет медленно, поэтому…».
- Ссылки на инструменты: при первом упоминании любого инструмента, сервиса, MCP-сервера или приложения — добавить ссылку в формате
[Название](ссылка), вшитую в значащие слова («премиального мужского салона»), не голым доменом в скобках. Если не знает — ищет через веб-поиск.
- Жанр определяет форму глагола:
- Часть 1 и финал (блоки-инструкции) — прямой императив для шагов + будущее время (или «можно будет») для всего, что случится после шага читателя, включая связки между шагами («тексты можно будет править», «сразу будет видно», «придется объяснять»).
- Общий совет-привычка (не шаг сценария) — через модальность: «Анимацию лучше привязывать к классу элементов», не «Привязывайте».
- Часть 2, кроме финала (блоки-описания) — модальность («можно»), безличность, инфинитивы. Императив здесь ломает жанр.
- Рассказ о прошлом кейсе — прошедшее время.
- Внутри абзаца вид, лицо и время согласованы; сослагательное не обрывается в настоящее.
- Запрещены краткие причастия в роли сказуемого («выбрана», «собрана», «задан», «сверстано») — вернуть деятеля или глагол состояния. И отглагольные существительные с прилагательными («долгая разработка», «быстрое погружение») — переписать глаголом.
- Не додумывать факты: условия входа («бесплатно», «нужен аккаунт»), объяснения-теории, детали, которых нет в исходнике. Абсолюты смягчать до защитимого с атрибуцией спикеру.
- Промпты и копируемые запросы — блоками кода. Недостающие материалы — явным плейсхолдером «[Вставить промпт …]», не текстом, который делает вид, что промпт где-то есть.
- Никакой «бойскаут-инструкции». Структура «формулировка задачи блока → инструкция → почему это работает → анонс следующего шага» — главный источник балласта в гайдах. По умолчанию пиши только «что» и «как». «Почему» добавляй точечно — только там, где без него читатель сделает шаг неправильно. «Что дальше» не пиши почти никогда — структура текста сама ведет читателя. Подробнее — в
antipatterns.md, раздел «Бойскаут-инструкция».
- Никаких кейсов-иллюстраций для красоты. Если в блоке планер прописал «якорный кейс „X"» или «живой пример из вебинара» — спроси себя: без этого кейса шаг непонятен? Если шаг и так понятен — не вставляй кейс, даже если он есть в плане. Реальные истории нужны только когда они показывают неочевидную комбинацию шагов.
- Никаких мета-анонсов и связок между блоками. Не пиши «Дальше — артист и типографика», «Об этом подробнее в следующих блоках», «Финальный размер можно будет получить следующим инструментом». Структура гайда сама ведет читателя — твои подсказки только размывают ритм.
- Никаких обзорных вступлений в начале блока. Не начинай с пересказа того, что у читателя уже есть («На этом шаге у вас две картинки», «Это финальный шаг первой части»). Сразу — первое действие или короткая формулировка задачи.
- Атрибуция спикеру — только когда совет без нее звучит слабее. «По опыту X», «X предпочитает Y» — допустимо, если без этого совет повисает в воздухе. «X в работе делает так-то» в конце готового совета — балласт, удалять.
- Финальная проверка блока: прочитать вслух. Спросить себя: «коллеге за кофе так бы объяснил?». Если фраза звучит книжно, коряво или как методичка — переписать целиком, не подправлять слово.
- Не применять antipatterns.md как чек-лист. Это инструмент для проверки в моменты сомнения, не протокол «прошел и удалил». Если формально запрещенная конструкция в контексте звучит естественно — оставить.
После всех пар
draft.md содержит полный черновик. Переходим к твоей финальной проверке.
Шаг 5: Финальная проверка (ты в основном контексте)
Агенты text-checker и final-reviewer больше не используются. Проверяешь и финализируешь сам.
Что делаешь:
- Прочитай
[рабочая папка]/draft.md целиком.
- Веди проверку по слоям:
- Содержательные пробелы. Сверь с исходником ($ARGUMENTS) — не потеряны ли важные для читателя факты, чеклисты, промпты.
- Ссылки на инструменты. Каждый конкретный инструмент/сервис/MCP-сервер из исходника должен иметь ссылку при первом упоминании, вшитую в значащие слова (не голый домен в скобках).
- Без буквы с двумя точками по всему тексту.
- Имена и факты против исходника. Имя спикера и людей из кейсов — по транскрибации, не по названию файла. Условия входа, объяснения-теории, детали — только из исходника; додуманное вычищай.
- Жанр и время глагола. В каждом блоке спроси: какой жанр (инструкция/описание/кейс)? Соответствует ли форма глагола? Особенно ловить «срывы времени» во второй части предложения (после императива авторы уходят в настоящее во втором глаголе).
- Книжные конструкции. «У X есть Y» с абстрактным Y, связочные «является/служит/представляет собой», абстрактные подлежащие («предсказуемость возвращается»), тавтологии в связках («еще одно, помимо»), зеркальные противопоставления «Y, а не X».
- Дубли. Перечисления модулей/инструментов/шагов между частью 1 и частью 2. Выводы-обобщения в конце абзацев, повторяющие уже сказанное. Сцены, разыгрывающие в лицах уже сказанный тезис.
- Связность блоков. Прочитай каждый блок целиком и спроси: «коллеге за кофе так бы объяснил?». Если нет — перепиши целиком, не подправляй слова.
- Оформление. Без H1-заголовка (текст начинается с «## Часть 1»); промпты и копируемые запросы — блоками кода; недостающие материалы — плейсхолдерами «[Вставить …]».
- Сделай пять отдельных целевых проходов — по одному паттерну за раз, не пытайся ловить все одновременно. Эти проходы критичны: даже опытный writer их пропускает в общем потоке проверки.
- Конспект-рефлекс: «что читатель сделает иначе?» Пройди по каждому абзацу. Если после абзаца читатель не сделает ничего иначе — абзац под нож, на уровне абзацев и целых блоков, не только предложений. Особо подозрительны: «убедились», «это хорошо видно на», «так Ася/спикер/мы сделали», витрины перед инструкцией, предыстории «как было раньше» в части 1, предупреждения-анекдоты, баги чужой среды, планы «потом сделаем», описания неправильного пути (сворачивай в верный шаг).
- Прогон по временам в инструкциях. Пройди по каждому инструкционному блоку (часть 1 и финал). В каждом предложении задай вопрос: «это про то, что у читателя сейчас перед глазами, или про то, что появится после его действия?». Если про результат действия — нужно будущее, «можно будет» или активный императив. Особенно ищи: безличный пассив («когда слои сведены»), глаголы состояния в настоящем («вас устраивает», «такой связки хватает», «сразу видно»), безличное «пишется/делается», настоящее в придаточных с «когда» и «если», императив несовершенного вида в общих советах («Привязывайте» → «лучше привязывать»), несогласованный вид/время внутри абзаца, оборванное сослагательное. Подробнее —
antipatterns.md, раздел «Срыв времени в инструкции через настоящее и пассив».
- Грамматический grep. Поиском по тексту: краткие причастия в роли сказуемого (
выбрана|собрана|задан|сверстано|построено|сделано|готова и похожие), отглагольные существительные с прилагательными («долгая разработка», «быстрое погружение»), счетчик «не X, а Y» (, а не |не .*, а ) — больше двух на текст не оставлять.
- Охота на балласт. Пройди по каждому абзацу и спроси: «без какого предложения смысл блока пострадает?». Если без предложения смысл не пострадает — это балласт, удаляй. Особенно охоться на: обзорные вступления в начале блока («На этом шаге у вас две картинки», «Это финальный шаг первой части»), избыточные «почему это работает» там, где инструкция и так понятна, кейсы-иллюстрации без новой информации, личные атрибуции спикеру в готовых советах, определения-наполнители.
- Удаление мета-связок и проверка финала. Пройди по началам и концам блоков. Удали все фразы, которые описывают структуру гайда вместо его содержания: «Дальше — X», «Об этом подробнее в следующем блоке», «Во второй части — почему это работает». Перекрестные отсылки между частями не ставим — дубль решается удалением. Финал: текст заканчивается последним содержательным выводом — без напутствий, призывов, призыв к действию и ссылок на каналы.
- Прогони чек-лист из ред-политики по каждому блоку.
- Вноси правки напрямую через Edit. Не делегируй агенту — он сломает стиль вылизыванием.
- Скопируй итог в
[рабочая папка]/final.md.
Подробные списки классов ошибок — в antipatterns.md (разделы «Скрытые нейромаркеры», «Бойскаут-инструкция», «Срыв времени в инструкции», «Краткие причастия», «Отглагольные существительные») и в redpolicy-guide/SKILL.md (раздел «Что НЕ пишем в гайде»).
Шаг 6: Сдача
Покажи пользователю [рабочая папка]/final.md и краткий отчет о правках, которые ты внес на шаге 5 (что именно чистил, где переписывал целиком). Спроси, устраивает ли результат или нужны доработки.
Выполняй шаги последовательно
Каждый следующий шаг начинается только после полного завершения предыдущего.
Шаги 2 и 5 — это твоя работа в основном контексте, а не вызов агента. Не пытайся делегировать их обратно агентам plan-checker/text-checker/final-reviewer — архитектура осознанно построена так, что ты делаешь эти этапы сам.
