habr-article

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

Habr Article Writer

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

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

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

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

Аудитория: Технические специалисты, разработчики (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+ пунктов, где половина — для красоты

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

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

Аудитория

• Демография: Разработчики, тестировщики, аналитики, DevOps, сисадмины
• Уровень: От джунов до архитекторов, но средний — мидл+
• Ожидания: Технические детали, код, практика, а не маркетинг
• Настрой: Критичный, но справедливый. Ценят глубину и честность.

Система кармы (ВАЖНО!)

Хабр — это саморегулирующееся сообщество. Карма определяет ваши возможности:

Положительная карма (5+):

• Можете минусовать статьи и комментарии
• Полные права на публикации

Отрицательная карма:

• Ограничения на комментарии
• При -31 — автоматическая блокировка

Что вызывает минусы:

• Неаргументированные утверждения
• Переходы на личности
• Маркетинговый bullshit вместо технических деталей
• Грубость и троллинг
• Безапелляционность без доказательств
• Непроверяемые цифры про компанию (размер, команда, метрики — Хабр-сообщество БУДЕТ гуглить и проверять)
• Позиция "сверху вниз" — заявление экспертности без технических доказательств
• Ссылки на CEO AI-компаний как нейтральных экспертов (Хабр видит bias)
• Скрытая реклама под видом экспертной статьи

Что вызывает плюсы:

• Технические детали и код
• Честность об ограничениях
• Практический опыт (не теория)
• Уважительный тон к сообществу
• Ответы на критику в комментариях
• Позиция WITH сообществом — валидация экспертизы разработчиков, а не угроза им
• Технические доказательства — покажи код, покажи логи, покажи diff
• Самокоррекция — "нет, подождите, я перегнул" — показывает живого человека

Тон общения

• Developer-to-developer — вы равны, а не "эксперт сверху"
• Честность — признавайте ограничения, ошибки, костыли
• Самоирония — "да, это костыль, но работает"
• Техническая точность — проверяйте факты, код должен работать

Правила доверия (КРИТИЧНО! Извлечено из реального негатива)

1. Учитывай, что Хабр БУДЕТ проверять любые заявления. Сообщество гуглит компанию, проверяет реестры, ищет LinkedIn. Специфика: компания работает по сарафанному радио, клиенты под NDA, ИП — всё это реально, но на Хабре выглядит подозрительно для незнакомых людей.

• ❌ Голые цифры без контекста: "У нас 80+ человек", "экономия 80%" — вызовут проверку и скепсис
• ✅ Цифры с контекстом: "Руковожу командой, которая активно использует AI" — не даёт повода копать
• ✅ Конкретные метрики — ТОЛЬКО с доказательствами (ссылка, open-source репозиторий, скриншот)
• ✅ Если хочешь упомянуть масштаб — добавь, почему нет публичных кейсов: "клиенты по NDA, показать не могу" (это честно и снимает вопросы)

2. Демонстрируй экспертизу кодом, а не словами.

• ❌ "Мы делаем проекты за 1-2 недели вместо 2-3 месяцев" (без доказательств)
• ✅ Код, diff, конфигурация, конкретный пример с деталями
• Если автор — руководитель, а не программист — НЕ пиши от лица программиста. Пиши от лица того, кто видит результаты команды.

3. Не ссылайся на CEO AI-компаний как на нейтральных экспертов.

• ❌ "Дарио Амодеи говорит, что..." (CEO Anthropic — заинтересованная сторона)
• ❌ "Мэтт Шумер написал, что..." (основатель AI-стартапа — заинтересованная сторона)
• ✅ Независимые исследования: NBER, GitClear, METR, академические работы
• ✅ Если ссылаешься на CEO — явно отметь: "Амодеи — CEO Anthropic, так что bias очевиден, но данные..."

4. Будь честен про человеческий труд в AI-процессах. Хабр называет это "каша из топора" — когда описывается куча ручной работы, а потом говорится "AI сделал проект".

• ❌ "AI-агенты сделали проект за 2 недели" (скрывая: 3 промпт-инженера + 2 синиора на ревью)
• ✅ "Три человека с AI-инструментами сделали за 2 недели то, что раньше делали пятеро за 2 месяца"

5. Позиционируйся WITH сообществом, не AGAINST. Хабр — это разработчики. Статья, которая говорит "программисты не нужны" — получит минусы. Статья, которая говорит "ваши навыки ценнее, чем когда-либо" — получит плюсы.

• ❌ "Не учись на программиста", "Промпт-инженер заменит кодера"
• ✅ "Инженерные навыки становятся критичнее", "Кто-то должен чинить вайб-код"

6. Различай "кодер" и "инженер". Хабр-аудитория очень чувствительна к этому. "Писать код" ≠ "инженерия". Инженер проектирует, декомпозирует, принимает архитектурные решения. Кодер набирает символы. AI заменяет второе, не первое. Путаница этих понятий — гарантированные минусы.

7. Никогда не используй AI для ответов в комментариях. Хабр-сообщество мгновенно распознаёт AI-генерированные комментарии (характерные уточняющие вопросы в конце, структурированные ответы, "спасибо за живой кейс"). Обнаружение AI-комментов уничтожает репутацию автора.

---

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

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

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

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 вопросов из списка (выбери релевантные):

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 не должен лишать смысла прочтение остального; он должен дать понять, стоит ли читать остальное.

Варианты зачинов (выбери один, чередуй между статьями):

A) Личная история: Начни с конкретной ситуации: "В пятницу вечером мы выкатили релиз и через 20 минут..."

B) Провокация / спорный тезис: "90% разработчиков используют AI-инструменты неправильно. Я знаю, потому что сам так делал полгода."

C) Результат вперёд: "Было: 3 дня на деплой. Стало: 15 минут. Вот что мы сделали."

D) Вопрос: "Что будет, если дать 5 AI-агентам спорить друг с другом о баге? Мы проверили."

E) Контрастный вход: "Документация обещала X. Реальность оказалась Y."

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

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

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

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

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

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

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

---

ФАЗА 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 гигиена при написании

Базовая дисциплина: пиши конкретно, варьируй ритм, не используй штампы. Полный каталог запрещённых паттернов (28 категорий) и автоматическая чистка — в агенте ai-text-checker, который запускается в ФАЗА 3 через skill cleanup-ai-noise. Здесь — только напоминания:

• Никаких «В современном мире...», «стоит отметить», «является ключевым»
• Никаких деепричастных хвостов «подчёркивая X» / «демонстрируя Y»
• Не пиши «может похвастаться» — давай конкретные цифры или убирай хвалу
• Англицизмы — только по делу. Оставляй имена моделей/продуктов (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.

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

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

Обязательные элементы "живости" (масштабируются по тиру)

Элемент	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 используют одну модель."

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

• НЕ пересказывай документацию. Если инфа есть в docs — дай ссылку и добавь свой опыт поверх.
• НЕ создавай "идеальную" статью. Лёгкая шероховатость = человечность.
• НЕ балансируй всё. Имей позицию. Будь за или против. Не "с одной стороны / с другой стороны".
• НЕ используй одинаковую длину секций. Одна секция может быть 2 абзаца, другая — 10.

---

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

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

Шаг 1: Автоматическая чистка AI-шума (ОБЯЗАТЕЛЬНО)

Запусти skill cleanup-ai-noise с параметром platform=habr. Скилл сохранит черновик в .tmp/current/articles/, прогонит агента ai-text-checker (27 паттернов + штампы проекта + платформо-специфика Хабра — доверие, непроверяемые цифры, AI-CEO-евангелизм, «каша из топора», «кодер vs инженер») и вернёт отчёт с правками + спорные места для ручного решения.

Только после автоправки и проверки спорных мест — переходи к ручным чек-листам ниже.

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

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

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

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

Если 2+ пунктов из второго чеклиста не пройдены — статья получит минусы. Перепиши.

---

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

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

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

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

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

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

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

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

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

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

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

10 типов крючков для заголовка (используй РАЗНЫЕ для вариантов!)

Эти типы перекликаются с крючками для Telegram-анонсов, но заголовок Хабра короче и должен работать без вступительного контекста. Первые 5 — регистр А (боль), следующие 5 — регистр Б (технология). Старайся в одной подборке вариантов давать обе подачи, с явным перевесом в сторону регистра Б, если статья продуктовая.

Регистр А — боль / фейл

1. Цифра + контраст (число в начале — мощный стопор)

• «30 КБ AGENTS.md не помогли. 4 skill помогли»
• «3 дня деплоя стали 15 минутами. Вот что мы сделали»
• «GPT-5.4 пишет на 97 из 100. Но стоит $0.10 за вызов»

2. Личный фейл / признание

• «Полгода писал один большой AGENTS.md. Codex всё равно срезал углы»
• «Я думал, что покрытие тестов 80% — это нормально. Сломали prod дважды»

3. Парадокс / перевёрнутое ожидание («Я думал X — оказалось Y»)

• «Думал, проблема в моделях. Оказалось — в моём контракте»
• «Поставили AI-агентов, чтобы ускориться. Получили на 30% медленнее»

4. Жёсткая позиция / спорный тезис

• «Оркестратор не должен быть умным промптом. Он должен быть тупым диспетчером»
• «1M токенов в Claude Opus — это маркетинг. Реально полезных — 300K»

5. Вопрос-крючок (только если он действительно цепляет)

• «Почему Codex делает по-своему, даже когда расписал всё в AGENTS.md?»

Регистр Б — технология / эффективность / простота

6. Стек / интеграция нескольких решений

• «Codex + Beads + Superpowers + 4 локальных skill: что объединил в свою систему оркестрации»
• «Моя рабочая связка для Codex: 4 skill, Parallel Decomposition Matrix, видимые spawned subagents»
• Принцип: показать, что в одной системе сошлись N независимых сильных элементов. Это интригует — «как это всё работает вместе».

7. Результат / эффективность (что технология даёт)

• «Параллельная разработка с Codex-агентами без хаоса: 4 skill, одна матрица, нулевой silent debt»
• «Как 4 skill научили Codex реально параллелить задачи, проверять себя и не забывать verification»
• Принцип: обещание конкретного полезного поведения, которого у читателя сейчас нет. Не «как сделать X», а «X стал делать Y».

8. «Возьми и работает» / простота применения

• «Распаковал, дал одну фразу в промте — Codex перестал срезать углы. 4 skill для оркестрации»
• «4 skill, README, одна команда unzip — и Codex работает как диспетчер контрактов»
• Принцип: подчеркнуть, что барьер входа низкий. Это работает, когда к статье прилагается архив, репозиторий, плагин.

9. «Было / стало» (трансформация)

• «Раньше Codex срезал углы, теперь работает как диспетчер контрактов: 4 skill, которые это сделали»
• «Был один монолитный AGENTS.md. Стало 4 связанных skill, и оркестратор перестал тихо лениться»

10. Конкретный артефакт + цена внедрения

• «4 skill, 1 фраза в промте, 0 silent debt: моя текущая система для Codex»
• «47 промптов, 3 модели, 12 000 вызовов: что показал наш battle test»
• Принцип: цифры-маркеры, которые сразу обещают конкретику внутри.

Правила хорошего заголовка для Хабра

• Длина 50–130 символов (оптимально 70–100). Слишком длинный обрезается в ленте.
• Крючок в первой трети — не «как», не «о», не «зачем» в начале. Конкретное слово, число или утверждение.
• Никаких маркетинговых штампов: «полный гайд», «всё, что нужно знать», «глубокий разбор», «практическое руководство». Хабр это не любит.
• Никакой академичности: «Анализ применения X для Y», «К вопросу о Z» — гарантированный скроллинг мимо.
• Подзаголовок (subtitle) — это второй шанс. В нём можно дать контекст, который не влез в title. Но subtitle ОПЦИОНАЛЕН — если основной title уже самодостаточен, subtitle лучше убрать вообще, чем разводить водой.
• Проверка «представь себя в ленте»: листаю Хабр, у меня 0.5 секунды на решение. Я бы кликнул на этот заголовок? Если сомневаешься — крючок недостаточно сильный.

Анти-паттерны заголовков (НЕ делай так)

• ❌ «Как я сделал X для Y» — стерильный шаблон, без крючка
• ❌ «Обзор системы X» — звучит как пресс-релиз
• ❌ «X: что это и зачем нужно» — школьное сочинение
• ❌ «Опыт внедрения X» — корпоративный язык
• ❌ «X — это про Y» — пустая формулировка без обещания
• ❌ Длинный заголовок-аннотация на 200+ символов с тремя двоеточиями
• ❌ Заголовок-вопрос без сильного крючка («Что такое X?», «Зачем нужен Y?»)

Как показать варианты автору

Используй 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 коротко упомяни, что финальный заголовок — авторская версия (это нормально и не баг).

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

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 выбран финальный заголовок — сразу же сгенерируй файл с промтами для обложек. Это часть пайплайна, не опциональный шаг. Анжела (или сам автор) использует эти промты для генерации обложек через Whisk / Midjourney / Imagen / другой генератор.

Шаг 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

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

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

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

КРИТИЧНО: язык текста НА самой картинке

Промт пишется на английском (это технический язык генераторов изображений, на русском Whisk и Midjourney работают хуже).

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

Исключения, которые остаются на английском (или латинице):

1. Имена моделей и продуктов — Opus 4.7, Codex-Max, GPT-5.5, Claude Code, MRCR v2
2. Технические идентификаторы — compact_20260112, prompt.md, <summary>, AES blob, имена API-методов
3. Числа и единицы — 300K tokens, 78% → 32%, $28 440/year
4. Конкретные термины-кальки, которые в русском IT-сообществе устоялись на английском — compaction, 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 — универсальный] | Любой, главное — читается на мобильном |

Как подбирать идеи для трёх промтов

Не «три варианта одной картинки». Три разные ключевые идеи статьи:

1. Главный insight — то, ради чего статья написана. Должен быть передан буквально в одном кадре.
2. Главная цифра / контраст — если в статье есть бенчмарк, разрыв «было/стало», парадокс — оформи это инфографикой.
3. Метафора или сценка — что-то для эмоционально-вовлекающей версии (Pikabu любит такое).

Если статья о сравнении двух систем — Prompt 1 показывает обе рядом, Prompt 2 — график их различия, Prompt 3 — драматическую сцену взаимодействия.

Если статья о провале / парадоксе — Prompt 1 показывает сам парадокс, Prompt 2 — цифры, Prompt 3 — личный момент автора («думал X, оказалось Y»).

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

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

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

Скилл (ты):

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

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

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

---

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

Включай в конце, но ВАРЬИРУЙ формулировку. Не используй одинаковый блок.

Данные:

• Telegram-канал: https://t.me/maslennikovigor
• Прямой контакт: https://t.me/maslennikovig
• GitHub: https://github.com/maslennikov-ig/claude-code-orchestrator-kit

Примеры разных формулировок:

Вариант 1: "Пишите в Telegram @maslennikovig, если хотите обсудить."
Вариант 2: "Инструменты — на GitHub, разговоры — в Telegram."
Вариант 3: Просто ссылки в конце без отдельного заголовка "Контакты".
Вариант 4: Вплести в текст: "Исходники — в репозитории, а если что — пишите в @maslennikovig."

---

Метрики (ОСТОРОЖНО!)

Метрики доступны в CLAUDE.local.md, но на Хабре их нужно использовать крайне аккуратно:

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

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

Вместо голых цифр — цифры с контекстом:

• ✅ "Руковожу командой, которая активно использует AI в разработке"
• ✅ "На наших проектах мы видим, что..." / "По нашему опыту..."
• ✅ Если метрики нужны: "Показать клиентские кейсы не могу — NDA. Но инструменты, которые мы используем, лежат на GitHub — можете составить впечатление сами."
• ❌ Голые числа без контекста: "54 специалиста + 44 AI-агента" (провоцирует проверку)
• ❌ "Экономия 80%" без методологии расчёта

Если автор настаивает на конкретных цифрах — спроси: "Хабр будет проверять. Добавим контекст, почему нет публичных кейсов (NDA, сарафанка), или уберём цифры?"

Хабы и теги

Выбирайте релевантные хабы:

• DevOps — для CI/CD, деплоя, инфраструктуры
• Python, JavaScript, Go — для языковых статей
• Машинное обучение — для AI/ML
• Управление разработкой — для процессов
• Системное администрирование — для серверов

Теги: 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).

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

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

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

Источники

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