القائمة
Ред-политика для обзорных статей-эссе по теме проекта. Словарные, обзорные и разборные статьи: что это такое, как это работает, чем отличается от соседних понятий. Фактура собирается самостоятельно через исследование.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Правила хорошего письма: связность, ясность, структура текста. Справочный скилл, который подключается из других скиллов при написании и редактуре текстов.
Ред-политика для статей-подборок сервисов. Пишем обзоры сервисов, инструментов и продуктов для аудитории проекта. Каждый сервис описывается по шаблону: название, ссылка, стоимость, описание.
Ред-политика для обычных авторских статей. Объединяет правила хорошего письма с общими принципами формата. Для статей, которые не являются подборками сервисов, гайдами или другими форматами с отдельной ред-политикой.
Ред-политика для гайдов по вебинарам. Превращаем транскрибации вебинаров в структурированные самостоятельные тексты. Две части: быстрый старт + подробный разбор.
Полный цикл создания статьи-подборки сервисов
Полный цикл создания обычной авторской статьи
| name | redpolicy-overview |
| description | Ред-политика для обзорных статей-эссе по теме проекта. Словарные, обзорные и разборные статьи: что это такое, как это работает, чем отличается от соседних понятий. Фактура собирается самостоятельно через исследование. |
| user-invocable | false |
Общие правила хорошего письма описаны в скилле good-writing и antipatterns.md. Ниже — только правила, специфичные для обзорных статей.
Обзорные статьи — это словарные, разборные и обзорные тексты по теме проекта. Они объясняют понятие, явление, подход, рынок, категорию инструментов или спорный вопрос, когда готового исходника нет и фактуру нужно собрать самостоятельно.
Главное отличие от других типов контента: у нас нет готового исходника. Фактуру нужно собрать самостоятельно через исследование темы в интернете, а потом на ее основе построить текст.
Целевая аудитория берется из профиля проекта. Не подставляй аудиторию из старого проекта и не пиши «для всех».
Для них важно:
Текст не должен уходить в глубину, которая не нужна аудитории проекта. Если читатель из профиля проекта — специалист, допустима профессиональная глубина. Если нет — сложные детали объясняются только настолько, насколько они помогают принять решение или действовать.
Структура зависит от темы. Фиксированного шаблона нет. Но есть принципы:
Структура строится от вопросов читателя, а не от логики предмета. Не «как предмет устроен изнутри», а «что читателю нужно знать, чтобы применить это в работе или жизни».
Типичная логика обзорной статьи:
Не все блоки обязательны. Для некоторых тем нужны сравнения, для других — подборка инструментов, для третьих — хронология развития. Структура подстраивается под тему.
Обязательные принципы структуры:
Фактура собирается агентом-исследователем ДО написания плана. Результат исследования лежит в файле research.md.
Правила работы с фактурой:
Обзорные статьи часто объясняют технические концепции. Правила:
Обзорные статьи часто начинаются с определения («X — это...»). Это самый слабый способ открыть текст.
Разрешенные типы открывашки — ровно один из пяти:
Запрещено:
Открывашка не объясняет, что будет в статье. Она вовлекает.
Используем конструкции «можно сделать» вместо прямого обращения через глаголы, где это уместно. Не «загружаете фото и получаете результат», а «можно загрузить фото и получить результат».
Можно обращаться к читателю на «вы» в практических блоках, но без панибратства.
Там, где уместно, учим правильно называть вещи. Блок «как правильно говорить» с примерами через галочки и крестики — хороший прием для терминологических статей.
Не начинать блок с переходного абзаца. Заголовок уже дает контекст — начинаем сразу с сути. Не «Теперь посмотрим, что можно попробовать на практике», а сразу про практику.
Заголовки простые, от читателя. Не «Какие продукты уже работают и сколько стоят», а «Какие инструменты можно попробовать». Без кликбейтных добавок («о чем молчат в рекламе», «что скрывают вендоры»).
Перед блоками про стоимость, тарифы, API — объяснять контекст для обычного пользователя. Не предполагать, что читатель знает разницу между подпиской и оплатой по API, между бесплатным и платным использованием. Сначала контекст (кто платит, за что, когда это актуально) — потом цифры и таблицы.
В рекомендательных блоках (что попробовать, какой инструмент выбрать) писать естественным языком, а не структурировать как каталог. Не «Для знакомства с технологией:» / «Для продвинутого использования:», а «Самый простой вариант — ...», «Если нужно что-то серьезнее — ...». Текст должен читаться как совет знакомого, а не как карточка товара.
Горизонтальные разделители (—) внутри статьи не используются. Разделение через заголовки.
Изображения и схемы приветствуются. Для каждого изображения предусмотрен alt-текст, описывающий содержание.
Если в статье есть блок с обзором конкретных сервисов или инструментов, описание каждого сервиса пишется по принципам из ред-политики для статей-подборок (skills/redpolicy-article/SKILL.md): название, ссылка, стоимость, описание на 2-3 абзаца (что за инструмент, для чего нужен, что можно делать, какие фишки). Информация о сервисах проверяется через поиск, а не берется из знаний модели. При этом стиль подачи остается как в обзорной статье — естественным языком, а не как каталог.
Примеры обзорных статей находятся в examples/essays/. Загрузи 1–3 примера, если они есть. Если примеров нет, работай по этой ред-политике и профилю проекта.
