القائمة
Правила хорошего письма: связность, ясность, структура текста. Справочный скилл, который подключается из других скиллов при написании и редактуре текстов.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Ред-политика для статей-подборок сервисов. Пишем обзоры сервисов, инструментов и продуктов для аудитории проекта. Каждый сервис описывается по шаблону: название, ссылка, стоимость, описание.
Ред-политика для обычных авторских статей. Объединяет правила хорошего письма с общими принципами формата. Для статей, которые не являются подборками сервисов, гайдами или другими форматами с отдельной ред-политикой.
Ред-политика для гайдов по вебинарам. Превращаем транскрибации вебинаров в структурированные самостоятельные тексты. Две части: быстрый старт + подробный разбор.
Ред-политика для обзорных статей-эссе по теме проекта. Словарные, обзорные и разборные статьи: что это такое, как это работает, чем отличается от соседних понятий. Фактура собирается самостоятельно через исследование.
Полный цикл создания статьи-подборки сервисов
Полный цикл создания обычной авторской статьи
| name | good-writing |
| description | Правила хорошего письма: связность, ясность, структура текста. Справочный скилл, который подключается из других скиллов при написании и редактуре текстов. |
| user-invocable | false |
Это не свод запретов, который надо пройти галочками. Это набор инструментов для проверки в момент сомнения. Цель одна: текст должен объяснять понятно, как объясняют коллеге за чашкой кофе. Не как методичка, не как маркетинг, не как академическая статья.
Прежде чем что-то править — задай себе вопросы.
Что эта фраза несет читателю? Если ответа нет — фразы не должно быть. Если ответ дублирует то, что уже сказано — фразы не должно быть.
Какую роль играет конструкция, прежде чем ее убирать по правилу? Часто формально запрещенная конструкция держит важный нюанс. Уберешь механически — потеряешь смысл, оставишь — испортишь текст. Сначала пойми зачем, потом решай.
Нужен ли этот факт большинству читателей? Если он полезен 5% аудитории и не помогает остальным понять суть (студенческие скидки, разовые акции, обходные хаки) — выкидывай.
Главный тест после любой правки: прочитай абзац вслух и спроси «носитель так бы сказал коллеге?». Если нет — правка плохая, даже если по правилам корректна. Перепиши целиком, не подправляй слово.
Если конструкция по правилам разрешена, но звучит коряво — переписывай. Если по правилам запрещена, но звучит естественно и точно — оставляй. Правила — для случаев сомнения, не финальный судья.
Симптом vs причина. Когда находишь проблему в одной фразе — не правь только ее. Спроси: почему здесь возникла эта проблема. Вода в фразе — часто признак того, что весь абзац перегружен и ты не понял, что хочешь сказать. Тогда чисти абзац целиком, а не одно предложение. Противопоставление «не X, а Y» — часто признак того, что не нашел, как сказать утвердительно. Тогда ищи утвердительную форму, а не переставляй части.
Смотри на блок целиком, а не на отдельные предложения. После любой правки перечитай весь абзац (а лучше весь блок) и оцени, как он читается вместе. Точечные правки часто создают фразы, которые формально правильные, но в контексте звучат криво или книжно. Если правка блока в целом не улучшила — ее не было.
Спокойный, информационный. Без маркетинга, без восторгов, без попыток впечатлить. Мы разговариваем с читателем, а не вещаем. Можно обращаться напрямую, использовать «вы», но без панибратства и заигрывания.
Мы не боимся быть прямыми. Если что-то не работает, так и пишем. Если что-то важно, говорим сразу, а не подводим издалека.
Каждое следующее предложение отвечает на вопрос, который возникает после предыдущего. Читатель не должен додумывать, как одна мысль связана с другой.
Плохо: «Инструменты умеют выполнять задачу по текстовому описанию. Не нужно знать внутреннюю механику.» — два факта рядом, связь неочевидна.
Хорошо: «Чтобы решить задачу, необязательно разбираться во всей внутренней механике. Часть работы можно перепоручить инструменту: он выполнит ее по текстовому описанию.» — второе предложение отвечает на вопрос «а как тогда?», который возникает после первого.
Связь между предложениями должна быть смысловой, а не словесной. Если одно предложение логически продолжает другое, не нужно добавлять «потому что», «поэтому», «а еще». Эти слова нужны только там, где связь неочевидна без них.
Абзацы тоже должны логично продолжать друг друга. Переход от одного абзаца к другому не должен ощущаться как прыжок на новую тему.
План текста - это список материала, а не готовый маршрут для читателя. Перед написанием нужно собрать путь читателя: где он находится в начале, чего ему не хватает, почему это становится проблемой, какая новая идея решает проблему и какое действие закрепляет эту идею на практике.
Новая концепция появляется только после того, как у читателя возникла потребность в ней. Не начинать с «X - это Y». Сначала показать ситуацию, ограничение или вопрос, который естественно приводит к X. Тогда термин становится ответом, а не справкой.
Вступление проходит тест картинки. После первых 2-3 предложений читатель должен видеть ситуацию: что уже произошло, что теперь не хватает и почему это важно именно сейчас. Два правильных факта рядом еще не создают картинку, если между ними нет причинной связи.
После черновика нужно снять заголовки и проверить текст как поток. Если без заголовков непонятно, почему следующий абзац идет после предыдущего, проблема не в заголовках. Проблема в логике раскрытия.
Не пропускаем промежуточные шаги в процессе. Если процесс состоит из нескольких этапов с количественными соотношениями, объясняем их явно.
Плохо: «Статичные кадры генерируются в Midjourney. Вы берете промпт для первой сцены и отправляете его в сервис.» — не объяснено, что кадров несколько, не понятна связь «раскадровка → кадры → клипы».
Хорошо: «Один ролик состоит из нескольких сцен — спикер рекомендует разбивать сценарий на 5 ключевых сцен. Для каждой сцены нужно сгенерировать свой статичный кадр в Midjourney. Промпт для каждого кадра уже есть в раскадровке, которую вы собрали в предыдущем блоке. На выходе получится набор из пяти картинок, каждая из которых отражает одну сцену вашего сценария.» — объяснено, сколько чего нужно сделать, и показана связь между этапами.
Проверочные вопросы:
Абзацы короткие, 2–4 предложения. Один абзац — одна мысль. Если в абзаце две мысли, даже связанные, разбивайте на два абзаца. Внутри абзаца сохраняется плавность, есть связки и переходы.
Исключение: объяснение новой концепции или описание процесса может занимать 4–6 предложений в одном абзаце. Дробить такой абзац на 3-4 кусочка по 1-2 предложения не нужно — текст станет рваным. Ориентир: абзац должен читаться как связный блок, а не как список тезисов.
Предложения должны быть полными, с подлежащим и сказуемым. Не пропускаем важную информацию. Если для понимания нужен контекст, даем его.
Каждое предложение должно двигать мысль вперед. Если предложение можно убрать и смысл абзаца не изменится, его нужно убрать. Это касается пояснений, которые очевидны из контекста, и деталей, которые не влияют на понимание.
Каждый блок текста имеет одну задачу: объяснить, показать на примере, дать инструкцию к действию, предупредить. Не смешивать задачи внутри одного блока. Если блок объясняет, где читатель уже сталкивался с технологией, не добавлять туда цены и инструкции по подписке. Цены — в блок, где читатель выбирает инструмент.
Использовать минимально. Тире часто означает, что автор хочет пропустить важную мысль. От этого текст становится рваным и теряет ясность.
Плохо: «Инструмент для оценки звонков — быстро и точно.» Хорошо: «Инструмент оценивает звонки быстро и точно.»
Начинаем с главного, не с предыстории. Никаких вводных в духе «В современном мире…» или «Все мы знаем, что…». Не нужны предложения, которые объясняют, зачем сейчас будет информация. Если блок называется «Почему инструмент ошибается», читатель уже знает, зачем он здесь. Начинайте сразу с ответа на вопрос из заголовка.
Не писать переходные абзацы между блоками. «Теперь посмотрим, что можно попробовать на практике», «С одной стороны — возможности, с другой — риски» — это предыстория к следующему блоку, а не информация. Заголовок уже дает контекст. Начинаем сразу с сути.
Перед блоками с ценами, тарифами, API — сначала объяснять контекст для обычного пользователя. Не предполагать, что читатель знает, кто платит за токены и чем подписка отличается от API. Контекст аудитории важнее полноты информации.
Пишем так, как говорим. Если фраза звучит как выдержка из учебника, переформулируем. Избегаем сложных конструкций там, где можно сказать просто.
Способ обращения к читателю зависит от типа контента и задается в его ред-политике. Этот раздел дает общее правило, конкретный тип может его перебивать.
Инструктивные типы (гайды, уроки) — прямой императив во 2 лице мн. ч.: «Зарегистрируйтесь», «Откройте», «Нажмите», «Загрузите». Читатель в этих типах активно выполняет шаги; модальность звучит вяло и канцелярски.
Нарративные и обзорные типы (эссе, статьи-подборки, обзоры и другие объясняющие форматы) — модальность с инфинитивом: «можно загрузить», «нужно загрузить», «стоит придумать». Здесь читатель не выполняет инструкцию пошагово, а получает рекомендацию или объяснение.
Истории от первого лица — повествование от автора-героя в прошедшем времени, без императива и без обращения к читателю.
Дайджесты (3 лицо) — описание событий, без обращения к читателю вовсе.
Если в ред-политике конкретного типа явно сказано «императив» — это перебивает общее правило. Если ред-политика молчит — действует модальность по умолчанию.
Плохо для нарративного типа: «Присваивайте каждому видео уникальное кодовое слово.» Хорошо: «Для каждого видео стоит придумать свое уникальное кодовое слово.»
Плохо для гайда: «Каждому видео можно присвоить уникальное кодовое слово.» Хорошо: «Присвойте каждому видео уникальное кодовое слово.»
Согласование времени глаголов: если читатель сможет сделать что-то после установки или настройки, пишем в будущем времени. Не «система категоризирует видео» (сейчас она этого не делает, читатель ее еще не настроил), а «система будет категоризировать видео» или «на выходе будет получаться таблица». Это правило общее для всех типов контента.
Когда описываем, что сервис, инструмент или система ДЕЛАЕТ для пользователя, используем модальность («поможет», «можно») или будущее время («сгенерирует», «подготовит»). Не настоящее время.
Читатель читает статью — сервис для него сейчас ничего не делает. Настоящее время звучит как маркетинговое описание продукта.
Плохо: «Инструмент генерирует сайт за 60 секунд.» Хорошо: «Инструмент поможет сгенерировать сайт.»
Плохо: «Сервис создает фронтенд и подключает базу данных.» Хорошо: «Сервис поможет создать фронтенд и подключить базу данных.»
Плохо: «Система находит ошибки и исправляет код.» Хорошо: «Система найдет ошибки и исправит код.»
Настоящее время допустимо для:
Согласование вида глаголов: в одном абзаце глаголы должны быть одного вида, одного лица и одного времени. Если начали с будущего времени несовершенного вида («будет получаться»), продолжаем тем же («будет брать», «будет раскладывать»), а не переходим на настоящее («берет», «раскладывает»).
При перечислении вариантов действия вплетаем их в прозу через порядковые слова: «Первый способ — ...», «Второй — ...». Не пишем буллиты и не начинаем инфинитивы с маленькой буквы без подводки.
Плохо: «Настроить можно двумя способами. купить готовый сервис... Собрать своего агента...» — инфинитивы висят в воздухе.
Хорошо: «Настроить трендвотчинг можно двумя способами. Первый — купить готовый сервис... Второй способ — собрать своего агента...»
Избегаем пассивного залога в роли основного сказуемого. Каждое предложение должно иметь действующее лицо — подлежащее, которое выполняет действие.
Плохо: «Видео раскладывается на параметры» — кто раскладывает? Хорошо: «Агент будет раскладывать видео на параметры» — подлежащее «агент» выполняет действие.
Плохо: «Готовые кадры загружаются в Higgsfield» — безличная конструкция. Хорошо: «Готовые статичные кадры нужно загрузить в Higgsfield» — конструкция «нужно + инфинитив», читатель понимает, что это его действие.
Плохо: «Сделка автоматически создается в CRM» — пассив. Хорошо: «ManyChat автоматически создает сделку в CRM» — подлежащее «ManyChat» выполняет действие.
Проверочный вопрос: «Есть ли в предложении действующее лицо — кто именно выполняет действие?» Если нет, переписываем с активным залогом. Способ задать действующее лицо зависит от типа контента: для гайдов и уроков — прямой императив («Загрузите кадры в Higgsfield»), для остальных типов — модальность с инфинитивом («Готовые статичные кадры нужно загрузить в Higgsfield»).
Профессиональные термины либо объясняются при первом упоминании, либо заменяются на понятные описания. Не предполагаем, что читатель знает маркетинговую, техническую или бизнес-терминологию.
Плохо: «ManyChat отправляет лид-магнит» — термин «лид-магнит» не объяснен, читатель не из маркетинга может не понять. Хорошо: «ManyChat автоматически отправляет ему личное сообщение с бесплатным полезным материалом — например, PDF с практическими советами» — вместо термина дано понятное описание.
Плохо: «Бот задает вопросы, чтобы квалифицировать клиента» — профессиональный жаргон. Хорошо: «Бот задает несколько вопросов, чтобы понять, подходит ли человек как потенциальный клиент» — объяснено, что значит «квалифицировать».
Плохо: «Сквозная конверсия растет» — термин без пояснения. Хорошо: «Больше людей проходят цепочку до конца» — результат, понятный без терминологии.
Проверочный вопрос: «Поймет ли человек не из этой сферы, о чем речь?» Если нет, либо объясняем термин, либо заменяем на понятное описание.
Заголовки нужны для навигации, не для красоты. Заголовок должен содержать действие или конкретный предмет. Не «Настройки перед запросом», а «Выберите правильный режим инструмента». Читатель по заголовку должен понять не только тему блока, но и что именно он из него узнает или сделает.
Заголовки формулируются от читателя. Не «Какие продукты существуют на рынке», а «Каких агентов можно попробовать». Без кликбейтных добавок («о чем молчат», «что скрывают», «секреты»).
Один заголовок = один вопрос. Если в заголовке два вопроса через «и» — скорее всего это два блока. Не «Что такое [термин] и как он работает», а «Что такое [термин]».
Списки — только там, где они нужны: перечисление пунктов, чек-листы, пошаговые инструкции. В обычном повествовании списков не используем. Вместо буллитов пишем прозой: «сюда входит то-то, то-то и то-то».
Жирное выделение — экономно. Выделяем ключевые термины при первом упоминании или важные предупреждения. Не выделяем каждое второе слово.
Перечисления с пояснениями (где каждый пункт содержит пояснение длиннее 5-7 слов) разбиваем на отдельные строки, а не пишем одним плотным абзацем. Нумеруем только последовательные шаги (инструкции). Для неупорядоченных пунктов — жирные заголовки.
Блоки кода — для промптов, примеров запросов, шаблонов. Все, что читатель может захотеть скопировать.
Подробный разбор антипаттернов с примерами и проверочные вопросы для финальной проверки текста: antipatterns.md
