write-guide

name	write-guide
description	Полный цикл создания гайда по вебинару из транскрибации
disable-model-invocation	true
argument-hint	["путь-к-транскрибации"]

Создание гайда по вебинару

Запусти полный цикл создания гайда.

Исходный материал (транскрибация): $ARGUMENTS

Что важно понимать про этот процесс

Главный инструмент качества — твоя финальная проверка в основном контексте, не агенты. Агенты пишут черновик по парам блоков, у них нет полной картины и они склонны механически применять чек-листы. Ты видишь весь текст целиком, помнишь историю разговора с пользователем, знаешь эталон и его стиль — поэтому именно ты ловишь книжные конструкции, срывы времен в описательных блоках, дубли между частями и прочее.

Раньше в цепочке были агенты plan-checker, text-checker, final-reviewer. Они вылизывали текст по чек-листам и делали его механическим. Теперь эти этапы делаешь ты — читаешь и правишь в основном контексте.

Перед тем как писать — обязательно прочитай ред-политику, правила хорошего письма и пользовательские эталоны.

Эталоны лежат в examples/guides/. Если в папке есть несколько текстов, выбери 1–2 самых близких по задаче и прочитай их целиком. Стиль формируется из эталонов, а правила нужны для проверки в моменты сомнения.

Если examples/guides/ пустая, не выдумывай чужой эталон. Сообщи пользователю, что точность попадания в стиль будет ниже, и продолжай по ред-политике и правилам хорошего письма.

Рабочая папка

1. Возьми имя файла из $ARGUMENTS (без пути к директории и без расширения .md)
2. Рабочая папка: output/[имя файла]/
3. Создай папку командой: 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 больше не используется. Проверяешь план сам.

Что делаешь:

1. Прочитай [рабочая папка]/plan.md целиком.
2. Прочитай выбранные эталоны из examples/guides/, если еще не читал, чтобы помнить целевой стиль.
3. Оцени план по ключевым критериям:
   • Количество блоков. Больше 12 — значит, темы дробятся слишком мелко, объединяй родственные. Меньше 10 — возможно, чего-то важного не хватает. Но объединяй только родственные аспекты одной задачи читателя. Две разные задачи (например, «локализовать сайт» и «защитить сайт от сканирования») не склеиваются в один блок ради счетчика — пусть лучше будет лишний короткий блок. Один блок — одна задача.
   • Заголовки первой части и финала в императиве. «Зарегистрируйтесь в Lovable», а не «Зайти в Lovable». Инфинитивные заголовки планера — первая правка на этом этапе.
   • Заголовки второй части — повествовательные. Описание, а не команда.
   • Фильтр пользы факта. Смотри на перечень ключевых фактов в плане: edge-case типа студенческих скидок, разовых акций, обходных хаков надо выкидывать — в гайде они не нужны большинству читателей. См. раздел «Фильтр пользы факта» в редполитике.
   • Конспект-рефлекс в фактах плана. К каждому заложенному факту и кейсу задай вопрос: «что читатель сделает иначе?» Доказательства, что инструмент умный (тесты «мы закинули X и убедились»), истории про спикера, предупреждения-анекдоты (бан аккаунта), баги чужой среды, нереализованные планы спикера («может, сделаем скилл») — вычеркивай из плана сразу, до writer.
   • Предыстории в части 1. Если в инструкционном блоке заложено «как было раньше» (старая цепочка, старый процесс) — это материал второй части или мусор. В части 1 блок начинается с действия.
   • Вход/стоимость — только из исходника. Если планер заложил «бесплатно, нужен такой-то аккаунт», проверь по транскрибации, что спикер это говорил. Не говорил — вычеркивай.
   • Дубли между частями. Если в блоке из части 1 и в блоке из части 2 одни и те же перечисления (модули проекта, инструменты, шаги) — развести: в части 1 конкретные шаги, в части 2 только принцип. Перекрестные отсылки «подробнее во второй части» не закладывать — дубль решается удалением.
   • Жанр и форма глагола для каждого блока. Часть 1 и финал — инструкция (императив + будущее). Часть 2 — описание (модальность, безличность). Помни это при чтении будущего черновика.
   • «Обзорный блок ограничений» во второй части. Если планер заложил отдельный блок типа «Что инструмент не умеет» / «Слепые зоны инструмента» / «Чего избегать», проверь: не разбросаны ли эти ограничения уже по практическим блокам части 1 (по ходу шагов с этим инструментом)? Если да — отдельный блок-обзор не нужен, он будет повтором. Удаляй его на этапе плана, не давай ему попасть в writer.
   • «Якорный кейс» в инструкционных блоках. Кейс остается, только если он несет шаги (события кейса = действия читателя). Кейс-иллюстрация и кейс-доказательство («прогнали и убедились») — вычеркивай. Помечай в плане кейсы, которые нельзя тащить в текст, чтобы writer их не взял.
   • Финал без промо. Если планер заложил закольцовку-напутствие, призыв или канал спикера — вычеркивай. Гайд заканчивается последним содержательным выводом.
   • Недостающие материалы. Если в плане числится промпт/шаблон, которого нет в транскрибации, — запроси у пользователя на этапе согласования плана. Не получил — в тексте будет явный плейсхолдер «[Вставить …]», а не пересказ.
4. При необходимости переписывай план сам — не запускай обратно агента. Ты работаешь быстрее и не ломаешь собранную фактуру.

Шаг 3: Согласование плана

Покажи пользователю [рабочая папка]/plan.md и расскажи коротко, что поменял после своей проверки. Спроси, одобряет ли план.

• Если одобряет — переходи к следующему шагу
• Если просит изменения — внеси правки в plan.md и покажи обновленную версию
• НЕ НАЧИНАЙ писать текст, пока план не будет явно одобрен словами типа «ок», «давай», «пиши», «одобряю»

Шаг 4: Написание по блокам (агенты)

После одобрения плана переходим к написанию. Текст пишется парами блоков — не весь сразу.

Подготовка

Прочитай [рабочая папка]/plan.md. Найди все пронумерованные блоки в порядке их следования в тексте. Разбей на пары: [1–2], [3–4], [5–6] и т.д. Если блоков нечетное число — последняя группа из одного блока. Большие объединенные блоки (например, в части 2) пиши одиночным агентом.

Итерация

Для каждой пары запускай отдельного агента writer. Выполняй строго последовательно — жди завершения одного агента, затем запускай следующего.

Каждый агент writer получает:

1. Путь к исходнику ($ARGUMENTS)
2. Тип контента: guide
3. Ред-политика: skills/redpolicy-guide/SKILL.md (с особым вниманием к разделам «Подход к работе», «Как описывать действия читателя», «Фильтр пользы факта»)
4. Правила письма: skills/good-writing/SKILL.md (манифест про подход) и skills/good-writing/antipatterns.md
5. Эталон стиля в промпте: если в examples/guides/ есть пользовательские эталоны, встроить 3–4 подходящих абзаца прямо в промпт как образец подачи. Не «прочитай файл», а готовый текст в промпте — иначе агент не проникнется стилем. Подбирай абзацы под жанр блоков агента: для части 1 — инструкционные, для части 2 — описательные.
6. Полный план: [рабочая папка]/plan.md
7. Уже написанный текст: содержимое [рабочая папка]/draft.md (пустое для первой пары; нарастает с каждой итерацией)
8. Задание: «напиши блоки 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 больше не используются. Проверяешь и финализируешь сам.

Что делаешь:

1. Прочитай [рабочая папка]/draft.md целиком.
2. Веди проверку по слоям:
   • Содержательные пробелы. Сверь с исходником ($ARGUMENTS) — не потеряны ли важные для читателя факты, чеклисты, промпты.
   • Ссылки на инструменты. Каждый конкретный инструмент/сервис/MCP-сервер из исходника должен иметь ссылку при первом упоминании, вшитую в значащие слова (не голый домен в скобках).
   • Без буквы с двумя точками по всему тексту.
   • Имена и факты против исходника. Имя спикера и людей из кейсов — по транскрибации, не по названию файла. Условия входа, объяснения-теории, детали — только из исходника; додуманное вычищай.
   • Жанр и время глагола. В каждом блоке спроси: какой жанр (инструкция/описание/кейс)? Соответствует ли форма глагола? Особенно ловить «срывы времени» во второй части предложения (после императива авторы уходят в настоящее во втором глаголе).
   • Книжные конструкции. «У X есть Y» с абстрактным Y, связочные «является/служит/представляет собой», абстрактные подлежащие («предсказуемость возвращается»), тавтологии в связках («еще одно, помимо»), зеркальные противопоставления «Y, а не X».
   • Дубли. Перечисления модулей/инструментов/шагов между частью 1 и частью 2. Выводы-обобщения в конце абзацев, повторяющие уже сказанное. Сцены, разыгрывающие в лицах уже сказанный тезис.
   • Связность блоков. Прочитай каждый блок целиком и спроси: «коллеге за кофе так бы объяснил?». Если нет — перепиши целиком, не подправляй слова.
   • Оформление. Без H1-заголовка (текст начинается с «## Часть 1»); промпты и копируемые запросы — блоками кода; недостающие материалы — плейсхолдерами «[Вставить …]».
3. Сделай пять отдельных целевых проходов — по одному паттерну за раз, не пытайся ловить все одновременно. Эти проходы критичны: даже опытный writer их пропускает в общем потоке проверки.
   • Конспект-рефлекс: «что читатель сделает иначе?» Пройди по каждому абзацу. Если после абзаца читатель не сделает ничего иначе — абзац под нож, на уровне абзацев и целых блоков, не только предложений. Особо подозрительны: «убедились», «это хорошо видно на», «так Ася/спикер/мы сделали», витрины перед инструкцией, предыстории «как было раньше» в части 1, предупреждения-анекдоты, баги чужой среды, планы «потом сделаем», описания неправильного пути (сворачивай в верный шаг).
   • Прогон по временам в инструкциях. Пройди по каждому инструкционному блоку (часть 1 и финал). В каждом предложении задай вопрос: «это про то, что у читателя сейчас перед глазами, или про то, что появится после его действия?». Если про результат действия — нужно будущее, «можно будет» или активный императив. Особенно ищи: безличный пассив («когда слои сведены»), глаголы состояния в настоящем («вас устраивает», «такой связки хватает», «сразу видно»), безличное «пишется/делается», настоящее в придаточных с «когда» и «если», императив несовершенного вида в общих советах («Привязывайте» → «лучше привязывать»), несогласованный вид/время внутри абзаца, оборванное сослагательное. Подробнее — antipatterns.md, раздел «Срыв времени в инструкции через настоящее и пассив».
   • Грамматический grep. Поиском по тексту: краткие причастия в роли сказуемого (выбрана|собрана|задан|сверстано|построено|сделано|готова и похожие), отглагольные существительные с прилагательными («долгая разработка», «быстрое погружение»), счетчик «не X, а Y» (, а не |не .*, а ) — больше двух на текст не оставлять.
   • Охота на балласт. Пройди по каждому абзацу и спроси: «без какого предложения смысл блока пострадает?». Если без предложения смысл не пострадает — это балласт, удаляй. Особенно охоться на: обзорные вступления в начале блока («На этом шаге у вас две картинки», «Это финальный шаг первой части»), избыточные «почему это работает» там, где инструкция и так понятна, кейсы-иллюстрации без новой информации, личные атрибуции спикеру в готовых советах, определения-наполнители.
   • Удаление мета-связок и проверка финала. Пройди по началам и концам блоков. Удали все фразы, которые описывают структуру гайда вместо его содержания: «Дальше — X», «Об этом подробнее в следующем блоке», «Во второй части — почему это работает». Перекрестные отсылки между частями не ставим — дубль решается удалением. Финал: текст заканчивается последним содержательным выводом — без напутствий, призывов, призыв к действию и ссылок на каналы.
4. Прогони чек-лист из ред-политики по каждому блоку.
5. Вноси правки напрямую через Edit. Не делегируй агенту — он сломает стиль вылизыванием.
6. Скопируй итог в [рабочая папка]/final.md.

Подробные списки классов ошибок — в antipatterns.md (разделы «Скрытые нейромаркеры», «Бойскаут-инструкция», «Срыв времени в инструкции», «Краткие причастия», «Отглагольные существительные») и в redpolicy-guide/SKILL.md (раздел «Что НЕ пишем в гайде»).

Шаг 6: Сдача

Покажи пользователю [рабочая папка]/final.md и краткий отчет о правках, которые ты внес на шаге 5 (что именно чистил, где переписывал целиком). Спроси, устраивает ли результат или нужны доработки.

---

Выполняй шаги последовательно

Каждый следующий шаг начинается только после полного завершения предыдущего.

Шаги 2 и 5 — это твоя работа в основном контексте, а не вызов агента. Не пытайся делегировать их обратно агентам plan-checker/text-checker/final-reviewer — архитектура осознанно построена так, что ты делаешь эти этапы сам.