メニュー
Ред-политика для обычных авторских статей. Объединяет правила хорошего письма с общими принципами формата. Для статей, которые не являются подборками сервисов, гайдами или другими форматами с отдельной ред-политикой.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Правила хорошего письма: связность, ясность, структура текста. Справочный скилл, который подключается из других скиллов при написании и редактуре текстов.
Ред-политика для статей-подборок сервисов. Пишем обзоры сервисов, инструментов и продуктов для аудитории проекта. Каждый сервис описывается по шаблону: название, ссылка, стоимость, описание.
Ред-политика для гайдов по вебинарам. Превращаем транскрибации вебинаров в структурированные самостоятельные тексты. Две части: быстрый старт + подробный разбор.
Ред-политика для обзорных статей-эссе по теме проекта. Словарные, обзорные и разборные статьи: что это такое, как это работает, чем отличается от соседних понятий. Фактура собирается самостоятельно через исследование.
Полный цикл создания статьи-подборки сервисов
Полный цикл создания обычной авторской статьи
| name | redpolicy-essay |
| description | Ред-политика для обычных авторских статей. Объединяет правила хорошего письма с общими принципами формата. Для статей, которые не являются подборками сервисов, гайдами или другими форматами с отдельной ред-политикой. |
| user-invocable | false |
Общие правила хорошего письма описаны в скилле good-writing и antipatterns.md. Ниже — только правила, специфичные для обычных статей.
Обычные статьи — это авторские тексты по теме проекта, которые не являются подборками сервисов, гайдами или другим форматом с отдельной ред-политикой. Это могут быть аналитические материалы, разборы тем, обзоры трендов, мнения.
Целевая аудитория берется из профиля проекта. Не подставляй аудиторию из старого проекта и не пиши «для всех». В каждом тексте должно быть понятно, для кого он написан, что этому человеку уже ясно, где он обычно путается и зачем ему эта тема.
Первые 2-3 предложения определяют, прочитают ли статью до конца.
Разрешенные типы открывашки — ровно один из пяти:
Запрещено:
Открывашка не объясняет, что будет в статье. Она вовлекает.
Абстрактные утверждения не работают. Каждый ключевой тезис нужно подкреплять конкретным сценарием, примером или деталью.
В статье должно быть 1-2 конкретных мини-сценария с реальными деталями:
Плохо: «Новый инструмент помогает ускорить работу.» Хорошо: «Редактор, которая раньше тратила утро на первичный разбор материалов, стала собирать черновую структуру за полчаса. Время освободилось, но появилась новая задача: проверять факты и не пропускать слабые обобщения.»
Конкретика не обязательно про реального человека — подойдет узнаваемая ситуация из жизни читателя.
Структура зависит от темы. Фиксированного шаблона нет, но есть принцип: структура строится от вопросов читателя, а не от логики предмета.
Не «как предмет устроен изнутри», а «что читателю нужно знать, чтобы применить это в своей работе или жизни».
Обязательные принципы:
Не добавляем информацию, которой нет в источнике. Если ее нет, не придумываем. Можем переструктурировать и переформулировать.
Используем конструкции «можно сделать» вместо прямого обращения, где это уместно. Не «загружаете фото и получаете результат», а «можно загрузить фото и получить результат».
Обращаться к читателю на «вы» можно в практических блоках, но без панибратства.
Примеры статей находятся в examples/essays/. Загрузи 1–3 примера, если они есть. Если примеров нет, работай по этой ред-политике и профилю проекта.
