habr-article

name	habr-article
description	Написание технических статей для Хабра. Используй когда нужно написать статью для Habr.

Habr Article Writer

Скилл для написания технических статей на Хабр от имени Игоря Масленникова.

Когда использовать

• Пользователь просит написать статью для Хабра
• Нужен технический deep-dive для разработчиков

Правило площадки 2026 (ЧИТАТЬ ПЕРВЫМ)

Правила Хабра версии 2026 запрещают публиковать текст, частично или полностью сгенерированный, написанный ИЛИ ОТРЕДАКТИРОВАННЫЙ нейросетью. Разрешены только сгенерированные обложки и иллюстрации. Санкция — снятие публикации в черновики и ограничение прав аккаунта.

Три следствия, из которых складывается весь пайплайн ниже:

1. Запрещён сам факт, а не его обнаружимость. «Текст прошёл GigaCheck» здесь ничего не значит. Оптимизировать под детектор бессмысленно и вредно.
2. Финальный текст пишет и правит автор руками. Модель даёт черновик по секциям из материала автора и потом возвращает находки, а не правки. Ни один этап после черновика не переписывает документ.
3. Автоправка отключена. На ФАЗЕ 3 cleanup-ai-noise работает в режиме отчёта. Агент ai-text-checker не редактирует файл — он возвращает список мест. Если кто-то вернул готовый переписанный текст, статью на Хабр в таком виде публиковать нельзя.

Это ограничение площадки, а не стилистическое предпочтение. Для vc.ru, Telegram и своего сайта оно не действует; для Хабра действует всегда.

Платформа: Хабр

Аудитория: Технические специалисты, разработчики (88.2% айтишников читают Хабр) Тон: Developer-to-developer, профессиональный, но не сухой Длина: ПОДБИРАЕТСЯ ПОД ОБЪЁМ КОНТЕНТА (см. секцию ниже). НЕ раздувай статью искусственно. Язык: Русский

Выбор размера статьи (ОБЯЗАТЕЛЬНО ДО ФАЗЫ 0!)

Правило #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+ знаков	Исключение. Расследование, серия статей сведённая в одну, исчерпывающий мануал. По умолчанию — НЕ выбирать.

Как определить тир ДО написания

Перед стартом ответь себе на четыре вопроса:

1. Сколько уникальных тезисов ты можешь сформулировать по теме? (Тезис = одно утверждение, которое нельзя свести к другим.)
   • 1–2 тезиса → S
   • 3–5 тезисов → M
   • 6+ тезисов → L
2. Есть ли собственный материал? Свои эксперименты, логи, замеры, скриншоты, код?
   • Только пересказ источника + мнение → S
   • Есть один-два собственных артефакта → M
   • Есть полноценные собственные данные/эксперимент → L
3. Есть ли пошаговая практика, которую читатель будет повторять?
   • Нет, чисто разбор/обзор → S или M
   • Да, есть гайд → M или L
4. Сколько времени читателю на чтение комфортно?
   • 3–5 минут (одна чашка кофе) → S
   • 7–12 минут → M
   • 15+ минут → L (читатель должен хотеть провести с тобой это время — должно быть за что)

Если сомневаешься между тирами — выбирай меньший. Лучше плотная статья на 8 000 знаков, чем разводнённая на 18 000.

Анти-паттерны раздувания

Если статья начинает превышать выбранный тир — это сигнал к сокращению, а не к повышению тира. Типичные причины раздувания:

• Длинные вводные «контекст: вот что такое X в общем смысле…» — выкинь, читатель Хабра знает базу
• Повторение тезиса в разных формулировках в разных секциях
• «Заглушки в виде определений» — пересказ docs, который можно заменить ссылкой
• Аккуратное балансирование «с одной стороны / с другой стороны» вместо чёткой позиции
• Копипаст больших блоков кода/конфигов целиком вместо ключевых фрагментов
• Списки на 8+ пунктов, где половина — для красоты

Сначала фиксируешь тир — потом пишешь под этот тир. Если по ходу выяснилось, что материал шире/уже — пересматриваешь тир ОДИН раз и продолжаешь.

Культура Хабра

Аудитория, система кармы, что собирает плюсы и минусы, семь правил доверия, осторожность с цифрами про компанию, хабы и теги — .claude/skills/habr-article/references/habr-culture.md.

Прочитай его до интервью. Три вещи оттуда определяют, о чём вообще спрашивать автора: Хабр проверяет любые заявления про компанию; экспертиза предъявляется кодом и логами, а не должностью; позиция автора — рядом с сообществом, а не сверху.

---

ФАЗА 0: ИНТЕРВЬЮ С АВТОРОМ (ОБЯЗАТЕЛЬНО!)

Перед написанием статьи — задай автору вопросы. Без реального контекста статья будет выглядеть как AI-генерат.

ФАЗА 0.1 — Правила живого письма

Skill('living-text-style') до первой написанной строки, правила держатся в контексте до конца ФАЗЫ 2.

ФАЗА 0.2 — Контракт черновика (ОБЯЗАТЕЛЬНО)

Читается целиком: .claude/skills/living-text-style/references/per-section-drafting.md (входы, фактчек, письмо по секциям) и .claude/skills/living-text-style/references/community-research.md (шаг 2b).

Запрос вида «напиши исчерпывающую статью про X» не выполняется без пакета источника: он и есть команда на энциклопедическую архитектуру, которую читатель опознаёт как машинную.

Задай 3-5 вопросов из списка (выбери релевантные):

1. Личная история: "Расскажи конкретную ситуацию, когда ты столкнулся с этой проблемой. Дата, проект, что пошло не так?"
2. Грабли: "На какие грабли наступил? Что не сработало с первого раза?"
3. Эмоция: "Что тебя больше всего удивило / бесило / радовало в процессе?"
4. Конкретика: "Есть скриншоты, логи, реальный вывод команд? Покажи."
5. Спорное мнение: "Какая у тебя непопулярная позиция по этой теме? С чем ты НЕ согласен с mainstream?"
6. Контекст команды: "Как команда отреагировала? Были ли споры? Кто был против?"

Если автор не может ответить на эти вопросы — значит, у него нет реального опыта с темой, и статья будет пересказом документации. В таком случае предупреди автора: "Без личного опыта статью скорее всего опознают как AI-генерат и скроют."

Полученные ответы вплетай в текст как конкретные истории, а не как абстрактные утверждения.

---

ФАЗА 1: ВЫБОР СТРУКТУРЫ (НЕ ШАБЛОН!)

КРИТИЧНО: Каждая статья должна иметь УНИКАЛЬНУЮ структуру. Не следуй одному шаблону.

TL;DR в начале статьи (ОБЯЗАТЕЛЬНО для всех тиров)

Каждая статья начинается с блока ## TL;DR сразу после заголовка #. Это не «жанровая особенность» и не «когда вижу нужным» — это обязательный элемент структуры для всех статей на Хабре, независимо от тира.

Зачем:

• Хабр-аудитория сканирует ленту — читатель за 3-5 секунд должен понять, о чём статья и стоит ли тратить на неё 10 минут
• TL;DR — это аналог abstract в научных статьях: тезисная выжимка, чтобы человек принял решение читать или нет
• Без TL;DR длинные статьи (M/L) теряют до половины потенциальной аудитории — люди уходят с первого абзаца, не дойдя до сути
• Для самого автора TL;DR — это проверка: если не получается уместить главные тезисы в 4-6 буллетов, значит, у статьи нет фокуса

Структура TL;DR:

• 4-6 буллетов, каждый — один независимый тезис статьи
• Конкретные цифры и факты, а не общие формулировки («модель X выдала Y баллов» вместо «модель X показала хорошие результаты»)
• Главный тезис первым — самое важное открытие/вывод статьи в первой строчке
• Закрытие тематически: последний буллет — главный вывод или практическая рекомендация
• Разделитель --- после TL;DR перед основным текстом — визуально отделяет тезисы от рассказа

Шаблон:

# [Заголовок статьи]

## TL;DR

- **[Главный тезис]** — конкретика с цифрой/фактом, одно предложение.
- **[Тезис 2]** — что нашли/измерили/построили, с конкретикой.
- **[Тезис 3]** — следствие или контекст, тоже с цифрой.
- **[Тезис 4]** — ещё один независимый факт или вывод.
- **[Главный практический вывод]** — что читатель должен унести из статьи.

---

[Зачин статьи — личная история / провокация / контраст / etc.]

Чего НЕ делать в TL;DR:

• Не писать вступление к тезисам («В этой статье мы рассмотрим...») — сразу тезисы
• Не делать буллеты длиннее 1-2 предложений — это уже не TL;DR, а параграфы
• Не дублировать дословно feed_preview из frontmatter — TL;DR это краткий тезисный план статьи, превью это приманка для клика в ленте, у них разные задачи
• Не использовать AI-маркеры («стоит отметить», «важно подчеркнуть», «является ключевым») — те же правила, что для тела статьи
• Не делать TL;DR на 8+ буллетов — это уже не выжимка, а оглавление

TL;DR — это часть статьи, а не её замена. Если читатель прочёл TL;DR и закрыл статью — это норма. TL;DR не должен лишать смысла прочтение остального; он должен дать понять, стоит ли читать остальное.

Зачин

Пять рабочих типов входа: личная история · провокация · результат вперёд · вопрос · контраст «обещали / оказалось».

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

Что делает зачин рабочим: он начинается с конкретного момента или утверждения, а не с подготовки к ним. Признак провала — первое предложение можно выкинуть, и статья ничего не потеряет.

Готовых первых фраз здесь нет намеренно: зачин, взятый из скилла, приезжает в текст дословно и становится подписью.

Строительные блоки (комбинируй свободно, НЕ используй все):

Обязательные блоки (ставятся всегда, во всех тирах):

• TL;DR — сразу после заголовка, 4-6 тезисных буллетов, разделитель --- снизу
• Зачин (один из вариантов A-E ниже)
• Контакты автора (с варьируемой формулировкой)

Опциональные блоки (выбирай по логике статьи):

• Личная предыстория / боль
• Техническое решение с кодом
• Сравнительная таблица (до/после)
• Схема архитектуры
• Конкретный кейс из практики
• Грабли и что не сработало
• Ограничения и когда НЕ подходит
• Ссылки и источники / «См. также»
• Секция «ответ на критику» (НЕ называй Disclaimer!)

Правила комбинирования:

• Используй обязательные блоки + 4-6 опциональных
• Порядок опциональных блоков должен следовать из логики статьи, не из шаблона
• Секции должны быть РАЗНОЙ длины (от 1 абзаца до 10)
• НЕ каждая статья нуждается в таблицах или ASCII-диаграммах — добавляй их по необходимости, не как обязательный элемент

Если статья объясняющая (гайд, разбор, «как это устроено»)

Для этого жанра порядок изложения — не вкусовщина, а дидактика. Восемь шагов, их нельзя переставлять (полный разбор — living-text-style/references/infostyle.md, раздел 13):

1. Захватить внимание — напомнить, что читатель уже знает по теме, и сразу сказать, что он получит от статьи.
2. Познакомить с предметом — подробно, не жалея деталей. Знакомый предмет — познакомить с его новой стороной.
3. Сначала показать — скриншот, вывод команды, схема. Картинка снимает несколько абзацев.
4. От простого к сложному — термин объясняется по цепочке от знакомого либо выбрасывается, если на этом уровне без него можно обойтись.
5. Привязать к реальности — к каждой теории пример, случай или задача.
6. Помочь с трудностями — что пойдёт не так и что тогда делать. Это ровно тот раздел, ради которого гайды и читают; «как правильно в идеальном мире» есть в документации.
7. Помочь структурой — небольшие самодостаточные фрагменты.
8. Добавить выводов — шпаргалка в конце, правила формулируются хлёстко.

Проверка на разжёвывание: объяснять новое можно только через то, что читатель уже знает. Если объяснение термина состоит из других незнакомых терминов — это шаг 4 не сделан.

---

ФАЗА 2: НАПИСАНИЕ (АНТИ-AI ГИГИЕНА)

Лимиты форматирования (ЖЁСТКИЕ — масштабируются по тиру!)

Элемент	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 акцентный блок (таблица ИЛИ кусок кода ИЛИ диаграмма) — этого хватает.

Анти-AI гигиена при написании

Пиши конкретно, варьируй ритм, не используй штампы. Каталог паттернов A1–A42 и платформенные стоп-слова живут в ai-text-checker — он же их и ловит на ФАЗЕ 3. Здесь держим в голове только то, что чинится при написании, а не при вычитке.

• Оценку меняй на факт — не «отличные результаты», а «89 из 100, на 6 баллов выше прошлой версии» (A36). Усилители «максимально / абсолютно / по-настоящему» — тот же класс (A37)
• Числа точные: «более 20 моделей» → «20 моделей»; большие округляй (1 593 768 → 1,6 млн) (A38)
• Цифра — в мире читателя: балл 89 без привязки к замеру, модели или порогу не значит ничего (A42)
• Одна новая мысль на предложение, до трёх для хабровской аудитории (A39)
• Вводные и нумерация словами — вон: «безусловно», «по сути», «во-первых» (A26)
• Англицизмы — только по делу. Оставляй имена моделей/продуктов (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.

Структурные маркеры (НИКОГДА не повторять между статьями):

• "Если знаете лучший способ — напишите в комментариях" — ЗАПРЕЩЕНО, стало отпечатком
• "Disclaimer: Expected Pushback" как заголовок — ЗАПРЕЩЕНО, стало отпечатком
• "Я понимаю, что статья может вызвать критику:" — ЗАПРЕЩЕНО, стало отпечатком
• Фиксированный формат "Вопрос к читателям:" в конце — ЗАПРЕЩЕНО, стало отпечатком
• Дословная подпись "Пишу про AI-агентов, LLM-архитектуру и автоматизацию разработки." — ВАРЬИРОВАТЬ

Живость — то, ради чего дочитывают

Уходят не от сложности, а от ощущения, что текст написан ни для кого и никем. Пять вещей это чинят. Ни одна не является нормой в штуках: реакция, вставленная ради счётчика, читается как фальшь — это фингерпринт 52, и его ловят на ФАЗЕ 3.

Конкретная история. Держится на четырёх частях: когда, что сделали, чем кончилось, что поменяли после. Признак провала — историю можно пересказать одним предложением без потери, значит, это было утверждение. Берётся из ответов автора на ФАЗЕ 0; синтетическую («представьте компанию, которая…») не сочиняем — это проход 5 hostile-editor.

Эмоциональная реакция называет, что автор почувствовал в конкретный момент и почему. Признак провала — реакцию можно переставить в другую статью, и ничего не изменится. И она не объявляет себя честной: «давайте честно», «скажу прямо» — это A33.

Вариация ритма. Длина предложения идёт от содержания: сложная мысль — длинное, вывод или поворот — короткое. Три предложения одной длины и одной конструкции подряд читаются как машина, даже если каждое верно. Граница с фингерпринтом 49: короткая фраза остаётся, если несёт факт или поворот; цепочка коротких кивков без содержания — имитация вдумчивости.

Отступление — не больше одного, и только если после него основная мысль понятнее. Иначе это украшение, которое автор вырежет руками. Начинается с сути: «кстати» и «к слову» — вводные из A26.

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

Чего НЕ делать

• НЕ пересказывай документацию. Если инфа есть в docs — дай ссылку и добавь свой опыт поверх.
• НЕ создавай "идеальную" статью. Лёгкая шероховатость = человечность.
• НЕ балансируй всё. Имей позицию. Будь за или против. Не "с одной стороны / с другой стороны".
• НЕ используй одинаковую длину секций. Одна секция может быть 2 абзаца, другая — 10.
• НЕ анонсируй контент подводками: «Дальше будет видно, зачем», «А сейчас — история, ради которой я сел писать эту статью», «Сводка без лирики — …», «Механика вскрылась в логах, и она поучительная». Секция и абзац начинаются с сути; тизеры и мостики автор вырезает руками при каждой вычитке (паттерн A34 в ai-text-checker).
• НЕ завязывай секции афористичным «бантиком» («Ради этого всё и затевалось», «Средний балл такое не ловит — ловят глаза») и не приклеивай оценочные хвосты («— и это показательно»). Один афористичный финал на статью — потолок, и лучше в самом конце.

---

ФАЗА 3: ПОСТ-ПРОВЕРКА (ОБЯЗАТЕЛЬНО!)

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

Проверки — по общему порядку

Порядок общий для всех площадок: .claude/skills/living-text-style/references/review-pipeline.md — прочитай целиком и выполни по шагам. Параметры этого скилла:

Параметр	Значение
platform	habr
--scope	longform
mode	только report

mode=report для Хабра обязателен. mode=edit запрещён правилами площадки 2026: под запретом сам факт AI-редактуры, а не её обнаружимость. Агент возвращает таблицу находок и не трогает файл. Если какой-то этап вернул готовый переписанный текст, статью в таком виде публиковать нельзя.

Специфика площадки, которую дополнительно ловит ai-text-checker (Layer C): доверие и непроверяемые цифры про компанию, цифра без опоры для сравнения, регалии без пользы читателю, AI-CEO-евангелизм, «каша из топора», путаница «кодер vs инженер».

Правки вносит автор. После них — два чек-листа ниже.

Чеклист "Не робот"

• Есть TL;DR в начале статьи? Сразу после # Заголовок стоит ## TL;DR с 4-6 буллетами и разделителем --- снизу?
• TL;DR конкретный? Каждый буллет содержит цифру/факт/конкретику, а не общие формулировки?
• TL;DR не дублирует feed_preview дословно? TL;DR — тезисный план статьи, превью — приманка для клика, формулировки должны различаться?
• Уникальная структура? Отличается ли порядок секций от предыдущих статей?
• Тир выбран осознанно? Объём статьи соответствует выбранному тиру (S/M/L), без раздувания и без обрезания?
• Личный опыт? Истории с деталями есть в количестве по тиру (S: 1, M: 2, L: 2–3)?
• Эмоции? Реальные эмоциональные реакции по тиру (S: 1–2, M: 3, L: 3–4)?
• Нет повторов между статьями? Нет дословных фраз из предыдущих статей?
• Нет пересказа docs? Информация из документации дополнена личным опытом?
• Есть позиция? Автор ясно выражает мнение, а не балансирует "с одной/другой стороны"?
• Отступлений не больше одного? Если tangent есть — он один и несёт смысл, а не украшение?
• Скелет из первых предложений абзацев складывается в историю? Прочитать подряд только их.
• Каждый раздел двигает из А в Б? Разделы, которые не двигают, вычеркнуты?
• Выводы к разделам не пересказывают разделы? Вывод даёт правило или применение — и стоит не в каждом разделе подряд?

Чеклист "Доверие и верификация" (НОВЫЙ — извлечён из негатива)

• Нет непроверяемых цифр? Все конкретные метрики про компанию либо убраны, либо верифицируемы (ссылка/скриншот)?
• Позиция WITH community? Статья валидирует экспертизу разработчиков, а не угрожает им?
• Нет AI-CEO евангелизма? Нет ссылок на CEO AI-компаний как нейтральных экспертов (или bias явно отмечен)?
• Честность про человеческий труд? Нет паттерна "каша из топора" — результаты не приписываются AI, если требовался значительный человеческий вклад?
• Терминология точна? "Кодер" ≠ "инженер", "промпт-инженер" ≠ "программист"?
• Нет скрытой рекламы? Статья даёт ценность читателю, а не продвигает услуги/компанию?
• Цифры сравнимы? Каждый собственный балл/метрика привязан к прошлому замеру, другой модели или порогу — читателю есть с чем сравнить?
• Нет неизмеримых точных чисел? Нет процентов и счётчиков, которые никто не мог измерить?
• Соседние числа не толкают к неверному выводу? Проверено, что напрашивается при делении/умножении двух чисел рядом?
• Регалии объяснены через пользу? Размер команды, число агентов, награды, имена клиентов — сказано, что это даёт читателю, или убрано?

Непройденный пункт — не арифметика, а сигнал вернуться к материалу.

---

ФАЗА 4: ПРОДАЮЩИЙ ЗАГОЛОВОК (ОБЯЗАТЕЛЬНО!)

Заголовок — это то, что определяет, кликнет читатель или прокрутит дальше. В ленте Хабра у заголовка примерно полсекунды, чтобы зацепить. Концептуальный заголовок-манифест («Оркестратор — диспетчер контрактов») честно отражает идею статьи, но в ленте проигрывает заголовкам с конкретикой, числами или признанием фейла.

Поэтому после чистки cleanup-ai-noise (ФАЗА 3) ОБЯЗАТЕЛЬНО:

1. Сгенерируй 4–6 вариантов продающего заголовка — каждый с разным типом крючка.
2. Покажи варианты автору через AskUserQuestion с preview (текст заголовка + длина в символах).
3. Отметь рекомендуемый вариант — обоснуй в одном предложении.
4. После выбора — обнови title (и при необходимости subtitle, feed_preview) в frontmatter статьи.

Не пропускай эту фазу даже если кажется, что черновой title и так нормальный. Черновой title почти всегда концептуальный, а Хабру нужен продающий.

Два регистра заголовков: «боль» и «технология»

У заголовка Хабра в принципе два рабочих регистра, и важно выбрать ПОДХОДЯЩИЙ под суть статьи. Ошибка — взять не тот.

Регистр А — «боль/фейл» работает, когда статья про диагностику проблемы или анти-паттерн. Читатель кликает, потому что узнаёт свою боль («я тоже так делал»). Фокус — на признании, фейле, парадоксе.

Регистр Б — «технология/эффективность/простота» работает, когда статья про рабочую систему/инструмент, который можно взять и применить. Читатель кликает, потому что хочет получить такое же себе («вау, хочу использовать»). Фокус — на стеке, интеграции, результате, простоте внедрения.

Как выбрать регистр. Если статья — это результирующая работающая штука, к которой автор прикладывает архив/код/инструмент: бери регистр Б. Если статья — это разбор парадокса/провала/неожиданного поведения: бери регистр А. Если в статье и то, и другое — лучше всего регистр Б, потому что архив/инструмент в финале — это сильнейший крючок «возьми и используй», и боль из начала статьи прочитается всё равно.

Многие статьи Игоря — продуктовые (рабочая система + архив для скачивания + Telegram-канал). По умолчанию для таких статей выбирай регистр Б.

Гейт честности заголовка (ОБЯЗАТЕЛЬНО перед показом вариантов)

Крючок и передёргивание — разные вещи, и на Хабре второе стоит дороже, чем недобранные клики. Каждый вариант проходит три проверки:

1. Заголовок вырван из статьи и подписан твоим именем. Так его и увидит лента: большинство дальше заголовка не пойдёт. «Министр образования: „ЕГЭ убивает“» — дно; «ЕГЭ убивает творческий подход к решению задач» — заголовок. Если вырванная строка вводит в заблуждение, вариант снимается.
2. Обещание равно содержанию. Заголовок задаёт тему: всё, что ему не соответствует, из статьи удаляется — или заголовок сформулирован неверно. Обещал цифру — цифра внутри есть; обещал разбор — разбор, а не заметка.
3. Нет приёмов из жёлтой зоны: срочность («СРОЧНО», «успей»), сенсационность («ШОК», «невероятно»), интрига с обрывом на середине, набивание цены («ФОТО», «Инфографика»), сведение сложного к «10 способов». Настоящая сенсация в крике не нуждается.

Долгосрочно работает репутация автора, а не формула заголовка: когда цепляет всё, не цепляет ничего. Подробно — living-text-style/references/infostyle.md, раздел 12.

Каталог крючков и формат показа

10 типов крючков с примерами (пять на регистр А, пять на регистр Б), правила длины и анти-паттерны заголовков, образец вызова AskUserQuestion с preview — .claude/skills/habr-article/references/headline-hooks.md.

Открой его перед генерацией вариантов: в одной подборке должны быть оба регистра, с перевесом в сторону Б, если статья продуктовая.

Если автор выбрал «Other» и сам предложил формулировку — прими её без споров. Если автор переформулировал в сторону менее продающего варианта — НЕ возражай, но в финальном отчёте коротко упомяни, что финальный заголовок — авторская версия (это нормально и не баг).

Что сделать после выбора

1. Обнови title в frontmatter articles/habr/[slug].md.
2. Проверь subtitle: если новый title уже самодостаточен — удали subtitle совсем (один сильный заголовок лучше двух средних). Если subtitle нужен — переформулируй, чтобы не дублировать title.
3. Проверь feed_preview: первая фраза превью должна согласовываться с новым title (не противоречить ему и не дублировать дословно). Если расходятся — поправь первое предложение превью.
4. Проверь заголовок в теле статьи: если в # Заголовок в самом начале статьи стоит то же, что в title frontmatter — обнови оба места синхронно.
5. Загляни в cover-prompts.md (если уже создан): если в промтах есть слоганы, которые опирались на старый title, — отметь это, на ФАЗЕ 5 переформулируешь.

Когда МОЖНО пропустить ФАЗУ 4

Только в одном случае: если автор в ФАЗЕ 0 сам предложил конкретный заголовок и явно сказал «использовать этот, варианты не нужны». В этом случае запиши это решение в комментарий к коммиту и переходи к ФАЗЕ 5. Во всех остальных случаях ФАЗА 4 обязательна.

---

ФАЗА 5: ПРОМТЫ ДЛЯ ОБЛОЖЕК (ОБЯЗАТЕЛЬНО!)

После того как статья прошла ФАЗА 3 и в ФАЗЕ 4 выбран финальный заголовок — сразу же сгенерируй файл с промтами для обложек. Это часть пайплайна, не опциональный шаг. Анжела (или сам автор) прогоняет эти промты через генератор изображений.

Шаг 1 (ОБЯЗАТЕЛЬНО): создать отдельную папку для статьи

Каждая статья получает СВОЮ папку в articles/pictures/. Это не общая свалка PNG-файлов, не папка «covers», и НЕ надо складывать обложки разных статей в одно место.

mkdir -p articles/pictures/[slug]/

Где [slug] — точно такой же, как в articles/habr/[slug].md (без расширения).

Зачем отдельная папка для каждой статьи:

• Туда лягут готовые PNG (один артикл = одна папка с разными вариантами обложек)
• Туда же лягут связанные артефакты (ANGELA-PUBLISHING-CHECKLIST.md для этого цикла, скрипты редактирования и т.п.)
• Анжеле проще ориентироваться: «обложки к статье X — в папке X»
• При архивации старых статей всё связанное переезжает одним движением

Антипример (НЕ делай так):

• ❌ Складывать cover-prompts.md в общую папку articles/pictures/
• ❌ Использовать слаг отличный от имени статьи (articles/pictures/codex-compaction-covers/ вместо articles/pictures/codex-vs-claude-compaction/)
• ❌ Создавать одну папку на цикл из нескольких статей

Шаг 2: сохранить файл промтов

articles/pictures/[slug]/cover-prompts.md

Это основной артефакт ФАЗЫ 5. Структура файла — по шаблону из справочника ниже.

Сколько промтов

Минимум 3 варианта. Каждый должен передавать одну из ключевых идей статьи (не три варианта одной идеи). Каждому ставь рейтинг ★ — твой прогноз попадания в смысл.

Язык, стилистика и шаблон файла промтов

Правило «текст на картинке — по-русски, идентификаторы латиницей», требования к разнообразию визуальных ходов, шаблон cover-prompts.md, техтребования и подбор трёх разных идей — .claude/skills/habr-article/references/cover-prompts-guide.md.

Правило: ничего не выдумывай

Все цифры, имена моделей, цитаты в промтах должны быть из самой статьи. Не добавляй на обложку фактов, которых в статье нет — иначе обложка будет обещать одно, а статья даст другое, и Хабр-аудитория это поймёт.

Что делает скилл, а что — автор

Скилл (ты):

• Создаёт папку articles/pictures/[slug]/
• Генерирует cover-prompts.md с минимум 3 промтами по шаблону выше
• Проверяет, что текст на изображении в промтах указан на русском (кроме идентификаторов)

Автор / Анжела:

• Прогоняет промты через генератор изображений
• Складывает готовые PNG в ту же папку
• Выбирает финальную обложку для каждой платформы

---

Секция контактов

Ссылки наружу: только Telegram-канал (ЖЁСТКОЕ ПРАВИЛО)

Правило — .claude/skills/living-text-style/references/contacts-policy.md.

Данные:

• Telegram-канал: https://t.me/maslennikovigor
• Прямой контакт: https://t.me/maslennikovig

Формулировка придумывается заново каждый раз: дословно повторённая подпись — самый заметный отпечаток автора. Тон площадки — developer-to-developer, без продающей интонации.

Проверка: сравни с подписью прошлой статьи. Совпадает по структуре — перепиши.

Регалии: любую придётся объяснить

Правило общее — contacts-policy.md, раздел «Регалии». На Хабре к нему добавляется чеклист доверия: непроверяемая цифра про компанию собирает минусы, а не плюсы.

---

Метрики и теги

Правила обращения с цифрами про компанию, хабы и теги — .claude/skills/habr-article/references/habr-culture.md, разделы «Метрики» и «Хабы и теги».

Короткая версия: конкретные цифры про компанию на Хабре не используются без явного запроса автора, а если он настаивает — только с контекстом, почему нет публичных кейсов.

Метаданные

---
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).

Структура превью:

1. Главная цифра / контраст — то, что останавливает скроллинг (1-2 предложения)
2. Контекст — почему это важно, какую проблему решали (2-3 предложения)
3. Тизер находок — 2-3 самых ярких результата, НЕ все (2-3 предложения)
4. Что внутри — одна строка: "В статье: методология, таблицы, формулы..."

Правила:

• НЕ раскрывай все выводы — читатель должен захотеть кликнуть
• Конкретные цифры вместо абстракций
• Первое лицо: "мы обнаружили", "мы протестировали"
• Без AI-маркеров: никаких "важно отметить", "в данной статье"
• Без пустых призывов: никаких "рекомендую к прочтению"

Пример:

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] — короткое описание темы через дефис.

После сохранения — сразу переходи к ФАЗЕ 5 (генерация cover-prompts). Это часть единого пайплайна, не отдельный шаг по запросу.

Источники

• Вы не сможете это развидеть: краткий гайд по определению LLM-текстов на Хабре
• Как AI захватывает Хабр, и почему это всех бесит
• Карма, рейтинг и вклад — Хабр
• Как написать хит на Хабр — Хабр