메뉴
Написание технических статей для Хабра. Используй когда нужно написать статью для Habr.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | habr-article |
| description | Написание технических статей для Хабра. Используй когда нужно написать статью для Habr. |
Скилл для написания технических статей на Хабр от имени Игоря Масленникова.
Аудитория: Технические специалисты, разработчики (88.2% айтишников читают Хабр) Тон: Developer-to-developer, профессиональный, но не сухой Длина: ПОДБИРАЕТСЯ ПОД ОБЪЁМ КОНТЕНТА (см. секцию ниже). НЕ раздувай статью искусственно. Язык: Русский
Правило #1: размер статьи определяется содержанием, а не амбициями. Если по теме реально есть только на 6 000 знаков — пиши 6 000. Раздутый «фундаментальный материал» из тонкой темы Хабр распознаёт мгновенно: вода, повторы, банальные определения.
| Тир | Объём | Когда использовать |
|---|---|---|
| S — заметка/зарисовка | 3 000 – 7 000 знаков | Один инструмент / один бенчмарк / одна находка / разбор одной фичи. Свежий релиз, который надо просто описать: что это, как работает, почему интересно. Краткий разбор чужого исследования с собственным мнением. |
| M — фокусный материал | 7 000 – 15 000 знаков | Одна тема, разобранная нормально: что это, как реализовано, почему важно, ограничения, где применять. Обзор инструмента с практикой. Разбор бенчмарка с интерпретацией. Дефолт для большинства тем. |
| L — deep-dive | 15 000 – 25 000 знаков | Архитектурный разбор, многомерное сравнение, серия экспериментов с собственными данными, гайд с пошаговой реализацией от и до. Только если есть реальный материал такого объёма. |
| XL — лонгрид | 25 000+ знаков | Исключение. Расследование, серия статей сведённая в одну, исчерпывающий мануал. По умолчанию — НЕ выбирать. |
Перед стартом ответь себе на четыре вопроса:
Если сомневаешься между тирами — выбирай меньший. Лучше плотная статья на 8 000 знаков, чем разводнённая на 18 000.
Если статья начинает превышать выбранный тир — это сигнал к сокращению, а не к повышению тира. Типичные причины раздувания:
Сначала фиксируешь тир — потом пишешь под этот тир. Если по ходу выяснилось, что материал шире/уже — пересматриваешь тир ОДИН раз и продолжаешь.
Хабр — это саморегулирующееся сообщество. Карма определяет ваши возможности:
Положительная карма (5+):
Отрицательная карма:
Что вызывает минусы:
Что вызывает плюсы:
1. Учитывай, что Хабр БУДЕТ проверять любые заявления. Сообщество гуглит компанию, проверяет реестры, ищет LinkedIn. Специфика: компания работает по сарафанному радио, клиенты под NDA, ИП — всё это реально, но на Хабре выглядит подозрительно для незнакомых людей.
2. Демонстрируй экспертизу кодом, а не словами.
3. Не ссылайся на CEO AI-компаний как на нейтральных экспертов.
4. Будь честен про человеческий труд в AI-процессах. Хабр называет это "каша из топора" — когда описывается куча ручной работы, а потом говорится "AI сделал проект".
5. Позиционируйся WITH сообществом, не AGAINST. Хабр — это разработчики. Статья, которая говорит "программисты не нужны" — получит минусы. Статья, которая говорит "ваши навыки ценнее, чем когда-либо" — получит плюсы.
6. Различай "кодер" и "инженер". Хабр-аудитория очень чувствительна к этому. "Писать код" ≠ "инженерия". Инженер проектирует, декомпозирует, принимает архитектурные решения. Кодер набирает символы. AI заменяет второе, не первое. Путаница этих понятий — гарантированные минусы.
7. Никогда не используй AI для ответов в комментариях. Хабр-сообщество мгновенно распознаёт AI-генерированные комментарии (характерные уточняющие вопросы в конце, структурированные ответы, "спасибо за живой кейс"). Обнаружение AI-комментов уничтожает репутацию автора.
Перед написанием статьи — задай автору вопросы. Без реального контекста статья будет выглядеть как AI-генерат.
Before any drafting, invoke Skill('living-text-style') and keep its rules in
context for ФАЗА 1–2. This is the preventive layer — write right the first time;
the detective layer (cleanup-ai-noise in ФАЗА 3) catches what slipped through.
Do not skip this step. Skipping degrades draft quality and inflates ФАЗА 3 cleanup cost.
Задай 3-5 вопросов из списка (выбери релевантные):
Если автор не может ответить на эти вопросы — значит, у него нет реального опыта с темой, и статья будет пересказом документации. В таком случае предупреди автора: "Без личного опыта статью скорее всего опознают как AI-генерат и скроют."
Полученные ответы вплетай в текст как конкретные истории, а не как абстрактные утверждения.
КРИТИЧНО: Каждая статья должна иметь УНИКАЛЬНУЮ структуру. Не следуй одному шаблону.
Каждая статья начинается с блока ## TL;DR сразу после заголовка #. Это не «жанровая особенность» и не «когда вижу нужным» — это обязательный элемент структуры для всех статей на Хабре, независимо от тира.
Зачем:
Структура TL;DR:
--- после TL;DR перед основным текстом — визуально отделяет тезисы от рассказаШаблон:
# [Заголовок статьи]
## TL;DR
- **[Главный тезис]** — конкретика с цифрой/фактом, одно предложение.
- **[Тезис 2]** — что нашли/измерили/построили, с конкретикой.
- **[Тезис 3]** — следствие или контекст, тоже с цифрой.
- **[Тезис 4]** — ещё один независимый факт или вывод.
- **[Главный практический вывод]** — что читатель должен унести из статьи.
---
[Зачин статьи — личная история / провокация / контраст / etc.]
Чего НЕ делать в TL;DR:
feed_preview из frontmatter — TL;DR это краткий тезисный план статьи, превью это приманка для клика в ленте, у них разные задачиTL;DR — это часть статьи, а не её замена. Если читатель прочёл TL;DR и закрыл статью — это норма. TL;DR не должен лишать смысла прочтение остального; он должен дать понять, стоит ли читать остальное.
A) Личная история: Начни с конкретной ситуации: "В пятницу вечером мы выкатили релиз и через 20 минут..."
B) Провокация / спорный тезис: "90% разработчиков используют AI-инструменты неправильно. Я знаю, потому что сам так делал полгода."
C) Результат вперёд: "Было: 3 дня на деплой. Стало: 15 минут. Вот что мы сделали."
D) Вопрос: "Что будет, если дать 5 AI-агентам спорить друг с другом о баге? Мы проверили."
E) Контрастный вход: "Документация обещала X. Реальность оказалась Y."
Обязательные блоки (ставятся всегда, во всех тирах):
--- снизуОпциональные блоки (выбирай по логике статьи):
Правила комбинирования:
| Элемент | S (3–7K) | M (7–15K) | L (15–25K) |
|---|---|---|---|
| ASCII-диаграммы | 0–1 | 1 | 2 |
| Таблицы | 0–1 | 1–2 | 3 |
| Блоки кода | 1–2 | 3–5 | 7 |
| Bullet-листы | 1 | 2–3 | 4 |
Правило 60/40: Минимум 60% текста — связная проза. Максимум 40% — форматированные блоки (код, таблицы, списки, диаграммы). Если получается больше — перепиши блоки в текст.
Особое правило для тира S: в коротких заметках соблазн сделать «всё списком» особенно велик — статья превращается в bullet-сводку. Не делай так. Связная проза + 1 акцентный блок (таблица ИЛИ кусок кода ИЛИ диаграмма) — этого хватает.
Базовая дисциплина: пиши конкретно, варьируй ритм, не используй штампы. Полный каталог запрещённых паттернов (28 категорий) и автоматическая чистка — в агенте ai-text-checker, который запускается в ФАЗА 3 через skill cleanup-ai-noise. Здесь — только напоминания:
GPT-5.5, Gemini), идентификаторы кода (response.usage, model_id), устоявшиеся аббревиатуры (API, LLM, SQL) и калькированные термины, реально принятые у разработчиков (production, токен, промпт, fallback). Но переводи перебор, у которого есть нормальный русский эквивалент: executive deep-dive → «подробный разбор для руководителей», use-case → «задача», training mix → «обучающий набор данных», narrative → «связный текст». Хабр терпит технический английский больше, чем Pikabu/TenChat, но «английская инфографика для русской статьи» отталкивает и здесь. Подробное правило — паттерн A28 в ai-text-checker.См. ФАЗА 3 → автоматическая чистка через cleanup-ai-noise.
Структурные маркеры (НИКОГДА не повторять между статьями):
| Элемент | S | M | L |
|---|---|---|---|
| Конкретные истории (с деталями) | 1 | 2 | 2–3 |
| Эмоциональные реакции | 1–2 | 3 | 3–4 |
| Tangents/отступления | 0–1 | 1 | 1–2 |
| Самопоправки | 0–1 | 1 | 1–2 |
В тире S «живость» не означает «впихнуть всё что положено в L». Одной точной истории + одной эмоциональной реакции достаточно, чтобы заметка читалась как живой текст, а не AI-генерат.
1. Конкретные истории:
Не "Мы используем этот подход" — а:
"В ноябре на проекте для [клиент/описание] мы попробовали X.
Первый запуск — агент сожрал 400k токенов и не нашёл ни одного бага.
Оказалось, я забыл передать ему правильный контекст."
2. Эмоциональные реакции (минимум 3-4 на статью): Варианты:
3. Вариация ритма предложений: Чередуй длинные и короткие. После сложного абзаца — короткая фраза.
Плохо:
"Agent Teams позволяют координировать несколько экземпляров Claude Code.
Один агент становится team lead, а остальные — teammates.
Они общаются между собой через mailbox."
(Все предложения одинаковой длины)
Хорошо:
"Agent Teams — это координация нескольких Claude Code.
Звучит просто. На практике — куча нюансов.
Один становится lead, остальные — рабочие лошадки, каждый со своим контекстом.
И вот тут начинается интересное: они могут спорить друг с другом."
(Короткая. Короткая. Длинная. Длинная с поворотом.)
4. Отступления и tangents: Добавляй 1-2 небольших отступления от темы — боковые мысли, ассоциации:
"(Кстати, это напоминает проблему с микросервисами: распределённая система
всегда сложнее монолита. Те же грабли, только AI-шные.)"
5. Поправки самого себя: Иногда начинай мысль, потом корректируй:
"Нет, подождите. Это работает не так, как я описал. Точнее, работает, но
только если все teammates используют одну модель."
После написания статьи — пройди три этапа: автоматическую чистку и два ручных чек-листа.
Запусти skill cleanup-ai-noise с параметром platform=habr. Скилл сохранит черновик в .tmp/current/articles/, прогонит агента ai-text-checker (27 паттернов + штампы проекта + платформо-специфика Хабра — доверие, непроверяемые цифры, AI-CEO-евангелизм, «каша из топора», «кодер vs инженер») и вернёт отчёт с правками + спорные места для ручного решения.
Только после автоправки и проверки спорных мест — переходи к ручным чек-листам ниже.
# Заголовок стоит ## TL;DR с 4-6 буллетами и разделителем --- снизу?Если 2+ пунктов из второго чеклиста не пройдены — статья получит минусы. Перепиши.
Заголовок — это то, что определяет, кликнет читатель или прокрутит дальше. В ленте Хабра у заголовка примерно полсекунды, чтобы зацепить. Концептуальный заголовок-манифест («Оркестратор — диспетчер контрактов») честно отражает идею статьи, но в ленте проигрывает заголовкам с конкретикой, числами или признанием фейла.
Поэтому после чистки cleanup-ai-noise (ФАЗА 3) ОБЯЗАТЕЛЬНО:
AskUserQuestion с preview (текст заголовка + длина в символах).title (и при необходимости subtitle, feed_preview) в frontmatter статьи.Не пропускай эту фазу даже если кажется, что черновой title и так нормальный. Черновой title почти всегда концептуальный, а Хабру нужен продающий.
У заголовка Хабра в принципе два рабочих регистра, и важно выбрать ПОДХОДЯЩИЙ под суть статьи. Ошибка — взять не тот.
Регистр А — «боль/фейл» работает, когда статья про диагностику проблемы или анти-паттерн. Читатель кликает, потому что узнаёт свою боль («я тоже так делал»). Фокус — на признании, фейле, парадоксе.
Регистр Б — «технология/эффективность/простота» работает, когда статья про рабочую систему/инструмент, который можно взять и применить. Читатель кликает, потому что хочет получить такое же себе («вау, хочу использовать»). Фокус — на стеке, интеграции, результате, простоте внедрения.
Как выбрать регистр. Если статья — это результирующая работающая штука, к которой автор прикладывает архив/код/инструмент: бери регистр Б. Если статья — это разбор парадокса/провала/неожиданного поведения: бери регистр А. Если в статье и то, и другое — лучше всего регистр Б, потому что архив/инструмент в финале — это сильнейший крючок «возьми и используй», и боль из начала статьи прочитается всё равно.
Многие статьи Игоря — продуктовые (рабочая система + архив для скачивания + Telegram-канал). По умолчанию для таких статей выбирай регистр Б.
Эти типы перекликаются с крючками для Telegram-анонсов, но заголовок Хабра короче и должен работать без вступительного контекста. Первые 5 — регистр А (боль), следующие 5 — регистр Б (технология). Старайся в одной подборке вариантов давать обе подачи, с явным перевесом в сторону регистра Б, если статья продуктовая.
1. Цифра + контраст (число в начале — мощный стопор)
2. Личный фейл / признание
3. Парадокс / перевёрнутое ожидание («Я думал X — оказалось Y»)
4. Жёсткая позиция / спорный тезис
5. Вопрос-крючок (только если он действительно цепляет)
6. Стек / интеграция нескольких решений
7. Результат / эффективность (что технология даёт)
8. «Возьми и работает» / простота применения
9. «Было / стало» (трансформация)
10. Конкретный артефакт + цена внедрения
Используй AskUserQuestion с типом single-select, обязательно с preview для каждой опции — превью должно содержать сам текст заголовка + количество символов в скобках. Для продуктовой статьи (с приложенным архивом/инструментом) рекомендуемый вариант — из регистра Б. Пример формулировки:
Вопрос: «Какой заголовок для Хабра берём?»
Header: «Title»
Опция 1 (рекомендуемая — регистр Б, стек):
label: "Стек / интеграция (Рекомендую)"
description: "Подчёркивает связку из нескольких сильных компонентов — провоцирует 'хочу повторить'."
preview: "Моя рабочая связка для Codex: 4 skill, Parallel Decomposition Matrix и видимые spawned subagents\n(108 знаков)"
Опция 2 (регистр Б, результат):
label: "Эффективность / результат"
description: "Обещание конкретного полезного поведения, которое статья даёт читателю."
preview: "Параллельная разработка с Codex-агентами без хаоса: 4 skill, одна матрица, нулевой silent debt\n(98 знаков)"
Опция 3 (регистр Б, простота):
label: "Возьми и работает"
description: "Низкий барьер входа — особенно сильно, если к статье прикреплён архив."
preview: "Распаковал, дал одну фразу в промте — Codex перестал срезать углы. 4 skill для оркестрации\n(94 знака)"
Опция 4 (регистр А, контраст):
label: "Цифра + контраст"
description: "Альтернатива через боль — для тех, кто кликает на признание фейла, а не на технологию."
preview: "30 КБ AGENTS.md не помогли. 4 skill помогли. Разбор системы оркестрации Codex\n(78 знаков)"
Если автор выбрал «Other» и сам предложил формулировку — прими её без споров. Если автор переформулировал в сторону менее продающего варианта — НЕ возражай, но в отчёте после ФАЗЫ 5 коротко упомяни, что финальный заголовок — авторская версия (это нормально и не баг).
title в frontmatter articles/habr/[slug].md.subtitle: если новый title уже самодостаточен — удали subtitle совсем (один сильный заголовок лучше двух средних). Если subtitle нужен — переформулируй, чтобы не дублировать title.feed_preview: первая фраза превью должна согласовываться с новым title (не противоречить ему и не дублировать дословно). Если расходятся — поправь первое предложение превью.# Заголовок в самом начале статьи стоит то же, что в title frontmatter — обнови оба места синхронно.cover-prompts.md (если уже создан): если в промтах есть слоганы, которые опирались на старый title, — отметь это, на ФАЗЕ 5 переформулируешь.Только в одном случае: если автор в ФАЗЕ 0 сам предложил конкретный заголовок и явно сказал «использовать этот, варианты не нужны». В этом случае запиши это решение в комментарий к коммиту и переходи к ФАЗЕ 5. Во всех остальных случаях ФАЗА 4 обязательна.
После того как статья прошла ФАЗА 3 и в ФАЗЕ 4 выбран финальный заголовок — сразу же сгенерируй файл с промтами для обложек. Это часть пайплайна, не опциональный шаг. Анжела (или сам автор) использует эти промты для генерации обложек через Whisk / Midjourney / Imagen / другой генератор.
Каждая статья получает СВОЮ папку в articles/pictures/. Это не общая свалка PNG-файлов, не папка «covers», и НЕ надо складывать обложки разных статей в одно место.
mkdir -p articles/pictures/[slug]/
Где [slug] — точно такой же, как в articles/habr/[slug].md (без расширения).
Зачем отдельная папка для каждой статьи:
ANGELA-PUBLISHING-CHECKLIST.md для этого цикла, скрипты редактирования и т.п.)Антипример (НЕ делай так):
cover-prompts.md в общую папку articles/pictures/articles/pictures/codex-compaction-covers/ вместо articles/pictures/codex-vs-claude-compaction/)articles/pictures/[slug]/cover-prompts.md
Это основной артефакт ФАЗЫ 4. Структура файла — по шаблону ниже.
Минимум 3 варианта. Каждый должен передавать одну из ключевых идей статьи (не три варианта одной идеи). Каждому ставь рейтинг ★ — твой прогноз попадания в смысл.
Промт пишется на английском (это технический язык генераторов изображений, на русском Whisk и Midjourney работают хуже).
Но текст, который должен появиться НА самой картинке — заголовки, метки на графиках, подписи, названия осей, цитаты — указывай на русском языке. Аудитория Хабра русскоязычная, статья русская, обложка должна читаться без перевода.
Исключения, которые остаются на английском (или латинице):
Opus 4.7, Codex-Max, GPT-5.5, Claude Code, MRCR v2compact_20260112, prompt.md, <summary>, AES blob, имена API-методов300K tokens, 78% → 32%, $28 440/yearcompaction, handoff, context window, ZDRВсё остальное — по-русски:
Качество, Длина контекста, Деградация начинается тут)Пример правильной формулировки в промте (выделено жирным — что попадает на картинку):
A horizontal bar chart titled "Score per Dollar — кто реально эффективен?"
Bars represent: DeepSeek V4 Flash (longest, glowing gold, "43,684"),
DeepSeek V4 Pro (much shorter, gray, "3,477")...
В этом примере: технические идентификаторы и цифры остались как есть (43,684, DeepSeek V4 Flash), а человекочитаемый заголовок — на русском (Score per Dollar — кто реально эффективен?).
Антипример (не делай так):
A bar chart titled "Score per Dollar — who is really efficient?"
Labels: "Quality", "Cost per call", "Models compared"
Здесь весь читаемый текст на английском — Хабр-аудитория увидит «английскую инфографику для русской статьи», и это смотрится как машинный перевод.
cover-prompts.md# Промпты для обложек: [Тема статьи]
[1-2 предложения — что генерируем, для какой статьи, ссылка на сам файл статьи. Какие генераторы поддерживаются.]
После генерации — складываем готовые PNG в эту же папку (`articles/pictures/[slug]/`). Анжела возьмёт оттуда нужную для каждой платформы.
---
## Prompt 1: [Краткое название идеи на английском] ★★★★★
```
[Полный английский промт. Текст на изображении — на русском (кроме идентификаторов).
Размер: 16:9. Стиль: editorial illustration / data viz / etc.]
```
**Когда использовать:** [Универсал / Habr+TenChat / Pikabu / Telegram анонс — какой платформе подойдёт лучше всего и почему.]
---
## Prompt 2: [Другая ключевая идея] ★★★★★
```
[Полный промт]
```
**Когда использовать:** [...]
---
## Prompt 3: [Третья ключевая идея] ★★★★☆
```
[Полный промт]
```
**Когда использовать:** [...]
---
## Технические требования
- **Размер:** минимум 1280×720 (16:9), оптимально 1920×1080
- **Формат:** PNG или JPG
- **Стиль:** без фотореализма людей, без лиц с распознаваемой внешностью
- **Цветовая палитра:** [специфика темы — например, тёмный фон + неоновые акценты]
- **Текст на изображении:** **на русском**, кроме имён моделей/продуктов и технических идентификаторов
## Что НЕ нужно генерировать
- Логотипы реальных компаний — только generic robot/AI characters / abstract designs
- Фото реальных людей (даже упомянутых в статье — не визуализируем)
- Confused / sad faces у моделей — мы анализируем, не критикуем
- Маркетинговые баннеры с кучей текста
- Текст на английском там, где русский был бы естественнее
## Адаптация под платформы
| Платформа | Лучший промпт | Кроп |
|---|---|---|
| Habr | [Prompt N] | 16:9 (превью в ленте) |
| Pikabu | [Prompt N] | Квадрат или 16:9 |
| TenChat | [Prompt N — обычно инфографика] | 4:3 или 16:9 |
| Telegram анонс | [Prompt N — универсальный] | Любой, главное — читается на мобильном |
Не «три варианта одной картинки». Три разные ключевые идеи статьи:
Если статья о сравнении двух систем — Prompt 1 показывает обе рядом, Prompt 2 — график их различия, Prompt 3 — драматическую сцену взаимодействия.
Если статья о провале / парадоксе — Prompt 1 показывает сам парадокс, Prompt 2 — цифры, Prompt 3 — личный момент автора («думал X, оказалось Y»).
Все цифры, имена моделей, цитаты в промтах должны быть из самой статьи. Не добавляй на обложку фактов, которых в статье нет — иначе обложка будет обещать одно, а статья даст другое, и Хабр-аудитория это поймёт.
Скилл (ты):
articles/pictures/[slug]/cover-prompts.md с минимум 3 промтами по шаблону вышеАвтор / Анжела:
Включай в конце, но ВАРЬИРУЙ формулировку. Не используй одинаковый блок.
Данные:
Примеры разных формулировок:
Вариант 1: "Пишите в Telegram @maslennikovig, если хотите обсудить."
Вариант 2: "Инструменты — на GitHub, разговоры — в Telegram."
Вариант 3: Просто ссылки в конце без отдельного заголовка "Контакты".
Вариант 4: Вплести в текст: "Исходники — в репозитории, а если что — пишите в @maslennikovig."
Метрики доступны в CLAUDE.local.md, но на Хабре их нужно использовать крайне аккуратно:
Контекст: Компания реально существует, сотрудники реальные, заказы идут по сарафанке, клиенты под NDA. Но Хабр этого не знает — и проверяет. ИП без публичных кейсов выглядит для Хабра подозрительно, даже если всё честно.
Правило: Конкретные цифры про компанию — НЕ использовать на Хабре без явного запроса автора. Если автор хочет их включить — обязательно добавить контекст:
Вместо голых цифр — цифры с контекстом:
Если автор настаивает на конкретных цифрах — спроси: "Хабр будет проверять. Добавим контекст, почему нет публичных кейсов (NDA, сарафанка), или уберём цифры?"
Выбирайте релевантные хабы:
Теги: 5-7 релевантных, конкретных (не "программирование", а "docker-compose").
---
platform: habr
title: "[Заголовок]"
subtitle: "[Подзаголовок]"
author: Igor Maslennikov
date: [YYYY-MM-DD]
length: ~[N] characters
tags: [DevOps, Docker, CI/CD, Blue-Green, ...]
hubs: [DevOps, Системное администрирование]
language: ru
feed_preview: |
[Превью для ленты Хабра, 100-3000 символов]
---
Хабр показывает превью статьи в ленте до клика. Это не пересказ статьи — это приманка. 100-3000 символов (оптимально 500-900).
Структура превью:
Правила:
Пример:
GPT-5.4 пишет лучше всех — 97 баллов из 100. Но $0.10 за вызов.
При 10 000 генераций в месяц — $1000. А мы нашли модель, которая
справляется на 91% и стоит $0.0008. Разница — $992 каждый месяц.
Мы построили собственный battle test и прогнали через него 18 моделей.
Что обнаружили: 7 из 18 вставляют китайские иероглифы в русский текст.
Одна копирует промпт в заголовки. А LLM-судья поставил сам себе 127/100.
В статье: полная методология, таблицы, формула value score и лидерборд.
articles/habr/[slug].md
Где [slug] — короткое описание темы через дефис.
После сохранения — сразу переходи к ФАЗЕ 4 (генерация cover-prompts). Это часть единого пайплайна, не отдельный шаг по запросу.
Invoke at ФАЗА 0 of any article-skill BEFORE drafting (habr-article, vcru-article, dzen-article, pikabu-article, tenchat-article, telegraph-article, telegram-article, telegram-announcement). Injects 13 hard don'ts + Voice & Soul techniques + канцелярит replacement table into the author's context so the draft comes out living instead of AI-stamped. Mirror of `ai-text-checker` detective rules, cross-referenced via ↔ A{X} tags.
Use when enabling, auditing, refreshing, or using Graphify as a local project knowledge graph, especially when setup must be skill-driven and must not use external model/API-backed Graphify extraction unless explicitly authorized.
Написание деловых статей для TenChat. Используй когда нужно написать статью для TenChat.
Написание анонсов статей для Telegram-канала. Используй когда нужно анонсировать статью с другой платформы (Habr, VC.ru, TenChat, Pikabu, Telegraph).
Написание коротких постов для Telegram-канала. Используй когда нужно написать пост для Telegram.
Написание статей для Яндекс Дзен. Используй когда нужно написать статью для Dzen.ru.