site-article

name	site-article
description	Написание статей под собственный сайт aidevteam.ru с прицелом на коммерческий поисковый трафик. Используй когда нужна статья для раздела «Статьи» на своём сайте, а также для адаптации готовой статьи с другой площадки под сайт.

Site Article Writer

Пишет статьи для раздела «Статьи» на aidevteam.ru и публикует их целиком: от интервью с автором до задеплоенной страницы.

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

• Нужна статья под свой сайт с прицелом на поисковый трафик.
• Нужно адаптировать готовую статью с Хабра, VC или Дзена под сайт.
• Нужно обновить уже опубликованную статью на сайте.

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

• Статья для Хабра → habr-article
• Для Дзена → dzen-article, для VC → vcru-article, для Пикабу → pikabu-article
• Пост для Telegram-канала → telegram-announcement

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

Чем отличается от habr-article

	habr-article	site-article
Аудитория	разработчики	коммерческий B2B-заказчик
Цель	репутация, обсуждение	поисковый трафик и экспертиза
Семантика	не собирается	ядро запросов обязательно
Иллюстрации	только обложка	обложка + 3–6 внутри статьи
Публикация	автор вручную	агент целиком
Подсказка Анжеле	генерируется	не генерируется

Два входа

Режим «новая статья» — полный цикл ФАЗА 0 → 7.

Режим «адаптация» — берём готовую статью с другой площадки и делаем версию под сайт.

Правило канонизации (обязательно). Версия на сайте и версия на исходной площадке раскрывают разные углы одной темы. Полное совпадение текста недопустимо: две одинаковые страницы конкурируют между собой, и поисковик выбирает одну, обычно чужую.

Ссылку с сайта на исходную площадку не ставим. Версия на сайте работает на поисковый трафик, уводить читателя на чужую площадку незачем. Упоминать, что есть техническая версия для разработчиков, тоже не нужно.

Единственная внешняя площадка, куда статья ведёт, — наш Telegram-канал @maslennikovigor. Повод должен быть конкретным: что человек там найдёт по теме этой статьи. Приглашение «подписывайтесь» поводом не считается.

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

Зеркальная копия. Вторая копия лежит в /home/me/code/aidevteam/.claude/skills/site-article/SKILL.md, чтобы скилл был доступен из сессии в репозитории сайта. Правки вносить в оба файла.

Раскладка файлов

Черновик:         articles/site/{slug}.md
Промты картинок:  articles/pictures/{slug}/image-prompts.md
Публикация:       aidevteam/frontend/content/blog/{slug}.md
                  aidevteam/frontend/public/blog/{slug}/

---

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

Шаг 1. Интервью с автором

Спросить и дождаться ответов:

1. Тема статьи.
2. Какую боль заказчика закрываем.
3. Есть ли реальный кейс, цифры, скриншоты.

Про услугу и целевое действие не спрашивать: статья работает мягкой силой, продающего блока в ней нет. Подробности — в разделе «Про „коммерческую страницу“» ниже.

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

Сохранить ответы дословно в .claude/skills/voice-check/references/corpus-igor/interview/{slug}.md — до написания черновика, без приглаживания. Это собственный текст автора, из которого растёт его профиль голоса.

Шаг 2. Сбор семантического ядра

Собрать главный запрос + 5–15 сопутствующих. Источники:

• анализ поисковой выдачи по теме;
• блок «люди также спрашивают» / «вместе с этим ищут»;
• формулировки, которыми говорят сами заказчики в переписке.

Платные инструменты не используются.

Главный запрос — это то, что набирает заказчик, а не название статьи. «Архитектура AI-агента» — запрос. «Анатомия AI-агента: что внутри этой штуки» — заголовок.

Шаг 3. Проверка каннибализации (ОБЯЗАТЕЛЬНО)

cd /home/me/code/aidevteam/frontend && pnpm articles:seo

Посмотреть на правило duplicate-keyword. Если под выбранный главный запрос уже есть статья — обновляем существующую, а не плодим вторую. Две страницы под один запрос конкурируют друг с другом, и обе проседают.

Шаг 4. Роль в кластере

Определить: это опорная статья (isPillar: true) или поддерживающая (pillar: "{slug-опорной}")?

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

---

ФАЗА 0.1: ПРАВИЛА ЖИВОГО ПИСЬМА

Skill('living-text-style') до первой написанной строки.

ФАЗА 0.2: КОНТРАКТ ЧЕРНОВИКА (ОБЯЗАТЕЛЬНО)

Читается целиком: .claude/skills/living-text-style/references/per-section-drafting.md и .claude/skills/living-text-style/references/community-research.md.

Что специфично для сайта

• Пакет источника при адаптации. Если статья переносится с другой площадки, пакетом служит исходный текст плюс ответы автора про коммерческий интент — повторное интервью не нужно.
• Цель А → Б работает как фильтр против SEO-раздувания. Раздел, который не двигает читателя из А в Б, не спасается ключевым запросом. Поисковый интент определяет структуру, но не отменяет запрет на выдумку: если под интент просится блок, которого нечем наполнить, блок не пишется.
• Объём секции диктует материал, а не симметрия и не SEO-разметка.
• Выдуманный кейс здесь дороже, чем где-либо. В разделе «Статьи» на своём сайте это обещание клиенту, а не стилистическая помарка.

---

ФАЗА 1: СТРУКТУРА ПОД ИНТЕНТ

Тип интента

Определить, что человек хочет, когда вводит главный запрос:

Интент	Что ждёт читатель	Чем закрываем
Информационный	понять, как это устроено	разбор с примерами
Коммерческий	понять, сколько стоит и что получит	состав работ, сроки, вилка
Сравнение	выбрать между вариантами	таблица различий, границы применимости
Кейс	увидеть, что у кого-то сработало	задача → что делали → результат

Структура статьи следует за интентом, а не за привычным шаблоном.

Скелет

H1 (= title)

«Коротко»  прямой ответ на главный запрос, 2–4 предложения.
           Живёт в поле `tldr` frontmatter, НЕ в теле статьи.

H2 …    каждый закрывает свой подзапрос
        и НАЧИНАЕТСЯ с прямого ответа, а не с подводки

FAQ     3–6 вопросов из «также спрашивают»

CTA

Аббревиатуру «TL;DR» в тексте не писать. Она из хабровской культуры, а аудитория сайта нетехническая и её не расшифровывает. На странице блок и так подписан «Коротко» — заголовок зашит в components/blog/article-tldr.tsx, менять его в статье не нужно и нельзя. Дублировать этот текст в теле статьи тоже не надо: он отрисуется дважды.

Правило «H2 начинается с прямого ответа» — главный рычаг цитируемости. ИИ-поисковики забирают самодостаточные куски. Абзац, который начинается с «Чтобы понять это, давайте сначала разберёмся…», процитировать нельзя.

Требования к читаемости

Аудитория — нетехнический B2B. Поэтому:

• абзац 2–4 предложения;
• средняя длина предложения до 20 слов;
• никакого жаргона без расшифровки при первом употреблении;
• цифры, таблицы и примеры вместо оценочных прилагательных («быстро», «эффективно», «современно»).

Разметка точек под иллюстрации

Здесь же наметить 3–6 мест под изображения и записать для каждого:

• после какого H2 стоит;
• что именно должно быть видно;
• зачем оно тут — что читатель поймёт быстрее, чем из текста.

Иллюстрация без ответа на третий вопрос не нужна.

---

ФАЗА 2: НАПИСАНИЕ

Голос авторский, от первого лица. Это отличие от офферов, где говорит компания: в блоге личная экспертиза работает на E-E-A-T, а обезличенный текст — нет.

Действующие запреты:

• никаких юридических и регуляторных гарантий («обеспечим соответствие 152-ФЗ», «гарантируем прохождение проверки»);
• никаких упоминаний конкретных конкурентов;
• никаких выдуманных цифр, кейсов и источников.

Инфостиль при написании (полностью — в living-text-style, словари в references/infostyle.md):

• Оценка меняется на факт, сценарий или случай. «Эффективный подход», «удобно», «надёжно» — это выводы, к которым читатель должен прийти сам. На коммерческой странице оценка без факта читается как реклама, и следующий абзац уже не верят (A36). Усилители — «максимально», «абсолютно», «по-настоящему» — тот же класс (A37).
• Числа точные, крупные — округлённые до полезного уровня. «Более 20» → «20» или «20 на 1 августа»; 1 593 768 → 1,6 млн (A38).
• Цифра привязана к тому, с чем читатель может сравнить — к прошлому замеру, к другой модели, к порогу (A42).
• Одна новая мысль на предложение. Перегруз ловится числом новых сущностей, а не длиной (A39).
• Регалии объясняются через пользу. Размер команды и имена клиентов сами по себе не отвечают ни на один вопрос читателя (infostyle.md, раздел 16).

---

ФАЗА 3: АУДИТ (не чистка)

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

Параметр	Значение
platform	site
--scope	longform
mode	report
файл	articles/site/[slug].md (не .tmp/)

Ни один этап не переписывает документ — правки вносит автор.

Что здесь строже, чем на других площадках

Статья лежит на коммерческом сайте, поэтому три прохода hostile-editor критичны:

• проход 2 (утверждение без источника) — цифра на своей витрине читается как оферта;
• проход 5 (синтетический пример) — выдуманный кейс в разделе «Статьи» это обещание клиенту, а не стилистическая помарка;
• проход 8 (оценка вместо факта) — «мы эффективно решаем задачи» на коммерческой странице стоит ровно столько же, сколько у всех остальных.

---

ФАЗА 4: SEO-ЧЕКЛИСТ

Каждый пункт блокирующий. Не прошёл — правим, а не публикуем.

• title 50–60 символов, главный запрос в первой половине
• metaDescription 120–160 символов
• главный запрос присутствует в H1, первом абзаце, минимум одном H2 и минимум одном alt
• главный запрос точной фразой в теле 3–6 раз, плюс вариации по смыслу
• у всех изображений осмысленный alt (не повтор заголовка)
• внутренних ссылок на другие статьи 1–5, плюс одна на содержательную страницу сайта. Ноль — скрипт даёт no-outgoing («тупик обхода»), больше пяти — link-overload. Считаются только ссылки вида /blog/{slug}
• внешних ссылок 2–5 на 1000 слов, каждая открывается и отдаёт 200. В no-outgoing они не засчитываются — это отдельный счётчик
• на новую статью ссылается хотя бы одна старая, иначе orphan («для поиска она второстепенная»). Закрывается на ФАЗЕ 6 шаг 7, но проверять надо здесь
• updatedDate проставлен, если правим уже опубликованную статью. Для новостных тем это влияет на выдачу сильнее, чем правка текста
• tldr и faq заполнены
• в тексте есть конкретный повод перейти в Telegram-канал, и нет ссылок на исходную площадку
• проходит pnpm articles:validate
• pnpm articles:seo не выдаёт ошибок уровня error

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

Считать надо абсолютное число вхождений в теле, а не плотность на объём: для лонгрида в 20 тысяч знаков плотностное правило дало бы два десятка вхождений одной и той же фразы, то есть ровно тот спам, от которого правило и защищает. Три-шесть точных вхождений плюс естественные вариации («выбрать модель под задачу», «выбор модели для проекта») достаточно на любой длине. Скрипт articles:seo частоту не проверяет — это ручной пункт.

Про «коммерческую страницу»

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

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

Про внешние ссылки

Ссылки на первоисточники ставить нужно, и nofollow им не нужен.

• PageRank не «утекает». Ссылка на чужой авторитетный сайт не понижает собственную страницу: это не игра с нулевой суммой. Прямого буста тоже нет — это подтверждал Джон Мюллер. Косвенная польза реальна: цитата на первоисточник работает как сигнал качества и E-E-A-T, особенно в тексте, построенном на цифрах.
• nofollow — только для платных, партнёрских и пользовательских ссылок. Закрывать им цитаты на исследования — плохая практика.
• Чем помечать такие ссылки. Яндекс поддерживает отдельные значения и разрешает их комбинировать: rel="sponsored" для рекламы и партнёрских программ, rel="ugc" для пользовательского контента, rel="nofollow" как общий случай, rel="nofollow sponsored" вместе. В справке Вебмастера прямо сказано, что значения rel робот воспринимает как рекомендацию не принимать ссылку во внимание, а не как запрет. У Google nofollow стал подсказкой с 2019 года. Модели «вес утекает наружу» нет ни у одного из двух.
• Вредят четыре вещи: битая ссылка (404 у источника бьёт по доверию к статье), ссылка на спамный сайт, платная без пометки и просто перебор. Норма — 2–5 качественных внешних ссылок на 1000 слов.
• Трафик утекает не через SEO, а через вкладку. Внешние ссылки в теле статьи рендерятся обычным <a href>: читатель уходит на чужой сайт и не возвращается. Лечится на уровне рендера — target="_blank" rel="noopener" для внешних ссылок, внутренние не трогать. noopener нужен от tabnabbing, а не для поиска. Контрдовод по доступности существует: принудительная новая вкладка отнимает у пользователя выбор.

---

ФАЗА 5: ПРОМТЫ ДЛЯ ИЛЛЮСТРАЦИЙ

Ключевое отличие от habr-article, который делает промты только для обложки.

Шаг 1. Классифицировать каждую точку из ФАЗЫ 1

Уровень	Содержимое	Реализация	Кто делает
Концептуальная иллюстрация	метафора, сцена, образ	промт для генерации	автор генерирует, агент заливает
Данные, служебная точность	схема процесса, простой граф	markdown-таблица	агент делает сразу
Данные, нужна наглядность	тот же смысл, но требуется вид	промт с жёсткими требованиями к подписям	автор генерирует, агент заливает

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

Mermaid в блоге — работает, доработку приняли

Статус на 2026-08-03: рендер подключён и покрыт тестами. В статьях для сайта можно использовать ```mermaid — flowchart и sequence.

Как это устроено, чтобы не искать заново:

• Плагин свой, lib/blog/rehype-mermaid.ts. Пакета rehype-mermaid в зависимостях нет и искать его бесполезно — грепом по package.json легко сделать ложный вывод, что рендера нет.
• Плагин превращает ```mermaid в <pre class="mermaid"> и снимает подсветку Shiki, а MermaidClient из components/spec/mermaid-client.tsx рисует блок в SVG на клиенте. На странице статьи он подключён: app/blog/[slug]/page.tsx. Сам пакет mermaid грузится лениво и только если блоки в статье есть.
• Тему плагин подставляет сам, под палитру сайта (фон #0a1526). В промтах и схемах её задавать не нужно.
• Проверка: npx vitest run lib/blog/rehype-mermaid.test.ts.

Inline-SVG по-прежнему вырезается — remarkRehype вызывается без allowDangerousHtml, на выходе пустой <p></p>. Схему в статью вставлять только через ```mermaid либо картинкой.

Когда всё-таки таблица, а не диаграмма. Markdown-таблица читается поиском и попадает в ответы ИИ-поисковиков, а диаграмма — нет: она рисуется на клиенте, и для робота там пусто. Поэтому данные, цифры и сравнения — таблицей. Диаграмма уместна для последовательности шагов и ветвлений, где ценность в форме, а не в тексте, и где тот же смысл в статье уже сказан прозой.

Как делать диаграмму, чтобы она читалась

Диаграмма всегда растягивается на ширину колонки статьи (~800px). Отсюда единственное правило, которое надо держать в голове: чем шире схема получается у Mermaid, тем мельче в ней текст, потому что вписывание — это пропорциональное сжатие.

• Целевая натуральная ширина — около 800px. Тогда масштаб единичный и подписи читаются в свои 14px.
• flowchart LR — максимум 5 узлов с короткими подписями (одно-два слова). Шесть узлов с фразами дают ширину под 1900px, схема ужимается впятеро, и текст становится нечитаемым.
• flowchart TD — для длинных подписей. Вертикаль растёт вниз, а вниз места сколько угодно.
• Проверять после публикации. Открыть страницу и посмотреть на подписи: если они мельче основного текста, схему надо переделать, а не оставлять.

Технически это обеспечено в lib/blog/rehype-mermaid.ts: useMaxWidth: true, wrappingWidth: 560 и палитра сайта, плюс снятие инлайнового max-width в components/blog/article-content.css.

Шрифт в диаграмме не переопределять. Mermaid меряет ширину узлов одним шрифтом, а рисует тем, что придёт каскадом из статьи; если они разные, текст вылезает за рамку и обрезается. В блоге это уже случалось с Manrope, и то же самое когда-то чинили для спеков. Обе точки — тема в плагине и правило в CSS — жёстко держат sans-serif 14px; менять надо сразу обе или ни одной.

quadrantChart запрещён и в паспортах. С кириллицей, дефисами и двоеточиями он ломает рендер всей страницы, а не только диаграммы. Проверено на офферах; в тестах плагина этот случай зафиксирован отдельно.

Шаг 2. Создать файл промтов

Путь: articles/pictures/{slug}/image-prompts.md

Содержимое:

1. Обложка — 2–3 варианта промта, 16:9, от 1600 по ширине. Конвейер ресайзит всё до 1600, поэтому 1600 — реальный минимум, а 1920×1080 — комфортный запас. Картинку меньше 1600 по ширине конвейер растянет.
2. По одному промту на каждую точку, и для каждого указать:
   • после какого H2 вставляется;
   • готовый alt;
   • готовая подпись под картинкой;
   • имя выходного файла в формате NN-название (например 03-crm-scheme).
3. Итоговая таблица: файл → место вставки → alt → подпись.
4. Сводный промт на весь набор — первым разделом файла, до разбора по кадрам. Требования к нему ниже, это обязательный пункт.

Формат файла — как у cover-prompts.md в habr-article, включая оценку вариантов звёздочками, раздел технических требований и раздел «что НЕ нужно генерировать».

Шаг 2а. Сводный промт: один блок на весь набор (ОБЯЗАТЕЛЬНО)

Автор не собирает набор по кускам. Он копирует один блок, отдаёт его агенту с генерацией изображений (Codex и подобные) и получает готовую папку. Поэтому файл промтов открывается разделом ## Сводный промт (скопировать целиком), внутри которого лежит ровно один ```-блок.

Что обязано быть внутри блока, в этом порядке:

1. Задание одной фразой: сгенерировать N отдельных изображений для статьи, по одному файлу на кадр. Явно: «не коллаж, не сетка, не варианты одного кадра в одном файле».
2. Общий стиль, который действует на все кадры: фон, два акцентных цвета с кодами, смысл цвета, свет изнутри, исполнение, соотношение 16:9, минимум 1600 px по ширине.
3. Общие запреты: текста и цифр в кадре нет вообще; третьего цвета нет; внешнего источника света, бликов и лучей нет; людей нет; мозгов, графов, роботов и прочих значков «это про ИИ» нет.
4. Нумерованный список кадров. Для каждого: имя файла с расширением (01-hero.png), назначение одной строкой (обложка или раздел статьи) и сам промт на английском, целиком, без отсылок вида «то же, что выше». Промты должны быть самодостаточными: агент генерирует их по одному и контекст соседнего кадра не помнит.
5. Куда сохранить: абсолютный путь articles/pictures/{slug}/.
6. Что вернуть в конце: список созданных файлов с размерами, чтобы автор сразу увидел, всё ли на месте.

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

• Английский для промтов, русский для инструкций. Модели генерации надёжнее понимают английский промт; инструкции агенту читает Codex, ему язык безразличен, а автору удобнее по-русски.
• В сводный блок идёт только выбранный вариант обложки. Альтернативы живут ниже, в разборе по кадрам, и в копипаст не попадают: агент сгенерирует всё, что увидит.
• Имена файлов в блоке, в итоговой таблице и в тексте статьи совпадают посимвольно. Расхождение ловится только на ФАЗЕ 6, когда конвейер уже запущен.
• Разбор по кадрам под блоком остаётся: там варианты со звёздочками, объяснение выбора, alt, подписи и место вставки. Сводный блок — для генерации, разбор — для решений.

Визуальный стиль сайта (ОБЯЗАТЕЛЬНО, снимать с последних статей)

Иллюстрации попадают в общую ленту раздела и должны читаться как один набор. Перед написанием промтов открыть 2–3 свежие обложки из aidevteam/frontend/public/blog/{slug}/01-hero.webp и убедиться, что стиль не поменялся с прошлого раза.

Два уровня строгости. Их нельзя путать — из-за этого набор и вырождается в три одинаковых кадра.

Обложка — жёсткий стиль, отступать нельзя. Она попадает в общую ленту раздела и работает на весь сайт, а не на одну статью. Здесь обязательны все пункты списка ниже, включая композицию и исполнение.

Внутренние картинки — обязательна только палитра. Фон, два акцента, смысл цвета и свет изнутри. Композиция, план, крупность, жанр и фактура — свободны, и внутри одной статьи они ДОЛЖНЫ различаться. Три кадра, собранные по одной композиционной схеме, — это брак набора, даже если каждый по отдельности нормальный.

Система по состоянию на август 2026 (снята с pochemu-ne-rabotaet-vnedrenie-ii, zamenit-li-ii-razrabotchikov, ai-bot-dlya-prodazh):

• Фон: почти чёрный с синим отливом, #0b1018–#0d1420, иногда еле заметная тёмная сетка. Светлых фонов нет.
• Ровно два акцента: бирюзово-голубой #29a8d0–#4cc4e8 и янтарно-оранжевый #f5a623–#ff6a2a. Третий цвет не вводить.
• Цвет несёт смысл: голубой — ровное, надёжное, предсказуемое, машинное; оранжевый — неустойчивое, рискованное, дорогое. Распределять осознанно.
• Свет: объекты светятся изнутри и роняют цветной отсвет на пол. Внешнего источника света нет.
• Композиция: один-два объекта, много пустоты, сопоставление слева-справа.
• Исполнение: чистый 3D-рендер или светящийся контур. Не фотореализм, не рисунок от руки, не плоские иконки.
• Соотношение: 16:9. И обложка, и внутренние — от 1600 по ширине (конвейер ресайзит до 1600); 1920×1080 берём как запас.

Устаревший стиль, не воспроизводить: изометрия с circuit board, неоновые сети из точек, роботизированные руки, золотой как третий акцент. Это эпоха статей про оркестратор. Файл public/blog/COVER-IMAGE-PROMPTS.md описывает именно её и как образец стиля не годится — он оставлен как история.

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

Предмет обязателен: где искать метафору

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

Метафора берётся из мира читателя, а не из мира данных. Мир читателя — это офис, склад, стол, чашка, коробка, папка, ключ, весы. Мир данных — шкалы, графики, полосы, узлы, сетки. Ошибка возникает на темах про измерения («доля рассуждений», «место в рейтинге», «две шкалы оценки»): у понятия нет предмета, и промт съезжает в диаграмму. Лечится вопросом: где эта проблема стоит у человека на столе? Медленный бот — остывающая чашка у экрана. Пустые генерации — вскрытые коробки на складе. Строгая проверка — лист с правками красной ручкой.

Запрет на самоцензуру предмета. Нельзя писать в промте abstract marks of light, never digits, abstract shapes, pure geometry и подобное. Запрет касается только текста и цифр в кадре, а не предметов: убрали надпись — предмет остаётся.

Сцена, а не объект в пустоте — но не в каждом кадре. Абстрактный образ разрешён и иногда работает лучше предметного: он хорош там, где объясняется механизм, а не переживание. Требование к набору, а не к каждой картинке:

• обложка — всегда предметная сцена. Она уходит в ленту раздела и должна читаться без подписи;
• хотя бы один внутренний кадр — вещь из мира читателя на столе, полке, подоконнике, в комнате;
• весь набор из условных форм — брак. Три кадра из полос, панелей и светящихся масс подряд — это не стиль, это отказ от смысла.

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

Слова-маркеры, по которым промт съехал в мир данных. Прочитать текст промта и поискать path, line, beam, panel, mass, filaments, shards, grid, row of identical forms, floating, against darkness, abstract. Каждое такое слово — повод спросить, осознанный ли это выбор. Для одного кадра из набора — да, для всех — нет.

Тест телефона (для предметных кадров). Можно ли собрать эту сцену из настоящих вещей и снять на телефон в тёмной комнате? Единственная разрешённая условность — что предметы светятся изнутри. К кадру, заявленному как абстрактный, тест не применяется.

Проверка перед отправкой промтов автору. Прочитать три своих промта подряд и назвать, что в каждом изображено одним существительным. Три одинаковых существительных или три раза «полосы/фигуры» — переписывать.

Идеи из обсуждений. Если на шаге 2b (сбор мнений сообщества) попались удачные картинки – схемы, мемы, наглядные сравнения, – их визуальный ход берётся отдельным вариантом промта «по мотивам обсуждений»: чужой файл не используется, идея описывается словами и генерируется заново в нашей палитре с изменённой композицией. Правила – в .claude/skills/living-text-style/references/community-research.md.

Разнообразие: стилистика — это палитра и свет, а не «схема из фигур»

Правило общее с Хабром и лежит в одном месте: .claude/skills/habr-article/references/cover-prompts-guide.md, раздел «Разнообразие». Коротко: стилистику держат почти чёрный фон, два акцентных цвета, свет изнутри объекта и пустота вокруг одного смыслового центра — и ничего из этого не про геометрию. Схему берём, когда картинка объясняет механизм; для обложки и метафоры — предметную сцену.

Язык текста НА картинке

Если на изображении есть надписи — они должны быть на русском и без опечаток. Генеративные модели плохо пишут кириллицей, поэтому в промте лучше просить минимум текста или вообще без него, а смысл выносить в подпись под картинкой.

ГЕЙТ

ФАЗА 5 завершается, и скилл останавливается.

ФАЗА 6 стартует только после явного подтверждения автора, что изображения сгенерированы и положены в articles/pictures/{slug}/.

Не начинать публикацию «пока без картинок, потом добавим». Статья без иллюстраций на месте размеченных точек читается хуже, чем статья, где их не планировалось вовсе.

---

ФАЗА 6: ЗАГРУЗКА И ПУБЛИКАЦИЯ

Выполняется агентом целиком.

1. Переименовать исходники

По таблице из ФАЗЫ 5, в формат NN-название.ext (строчные латинские буквы, цифры, дефисы). Конвейер откажется работать с именами вида c9f11cea-2fa8-450c.png и назовёт проблемные файлы.

2. Прогнать конвейер

cd /home/me/code/aidevteam/frontend
pnpm articles:images {slug} --from /home/me/code/articles/articles/pictures/{slug}

Результат: WebP + AVIF в public/blog/{slug}/, ресайз до 1600px, blur-заглушки и манифест images.json.

3. ПРОВЕРКА ИЗОБРАЖЕНИЙ (ОБЯЗАТЕЛЬНО)

Агент открывает каждый сгенерированный файл и читает его, сверяя с текстом статьи:

• числа на картинке совпадают с числами в тексте;
• подписи и термины написаны без опечаток;
• смысл изображения соответствует тому, что сказано в разделе.

Расхождение — не публикуем. Агент сообщает о проблеме и выдаёт исправленный промт.

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

4. Вставить изображения в текст

![осмысленный alt](/blog/{slug}/NN-name.webp "подпись под картинкой")

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

5. Заполнить frontmatter

Полный список полей и правила — в aidevteam/frontend/lib/blog/schema.ts. Это единственный источник правды, сверяться надо с ним, а не с примерами.

Обязательные: title, slug, publishDate, author, category, tags, excerpt, metaDescription, primaryKeyword, tldr, status.

Важно: category обязана входить в tags, а featuredImageAlt обязателен, если задан featuredImage.

Если правим уже опубликованную статью — проставить updatedDate. publishDate при этом не трогать: дата первой публикации остаётся исторической.

Скопировать в aidevteam/frontend/content/blog/{slug}.md.

6. Проверки

pnpm articles:validate
pnpm articles:seo
pnpm articles:links {slug}
pnpm build

7. Обратная перелинковка

pnpm articles:links {slug} показывает, откуда из старых статей стоит сослаться на новую. Показать предложения автору и вставить только подтверждённые.

Это единственный шаг, который переносит накопленный вес раздела на новую страницу, и его почти никто не делает.

8. Публикация

Коммит, push, деплой — по правилам репозитория aidevteam.

9. IndexNow

curl -X POST https://aidevteam.ru/api/indexnow \
  -H 'content-type: application/json' \
  -H "x-revalidate-secret: $REVALIDATE_SECRET" \
  -d '{"urls":["/blog/{slug}"]}'

Разрешение стоячее — спрашивать не надо. Автор снял этот гейт 2026-08-03: «смысл ждать от меня?». Пинг выполняется сразу после успешного деплоя, как часть публикации, и только для страниц этой статьи.

Границы разрешения: оно покрывает только IndexNow и только свежие или обновлённые URL раздела «Статьи». Массовая переотправка всего сайта, чужие домены и любые другие внешние обращения под него не подпадают.

REVALIDATE_SECRET лежит в окружении и в .env. Читать значение и тем более печатать его в лог или в отчёт нельзя — подставлять только через переменную:

cd /home/me/code/aidevteam/frontend
# У .env.local переводы строк CRLF — без tr посыплется «$'\r': command not found».
set -a; . <(tr -d '\r' < .env.local); set +a
curl -s -X POST https://aidevteam.ru/api/indexnow \
  -H 'content-type: application/json' \
  -H "x-revalidate-secret: $REVALIDATE_SECRET" \
  -d '{"urls":["/blog/{slug}"]}'

Успешный ответ — {"submitted":[…],"engines":[{"endpoint":"…yandex…","status":202}, {"endpoint":"…bing…","status":200}]}. Яндекс отвечает 202, Bing — 200; оба считаются успехом. В отчёте автору называть статусы, а не пересказывать «всё ок».

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

---

ФАЗА 7: TELEGRAM — ТОЛЬКО ДЛЯ НОВЫХ СТАТЕЙ

В режиме «адаптация» ФАЗА 7 не выполняется. Материал уже выходил на исходной площадке, и пост про него в канале уже был — со ссылкой на ту публикацию. Второй пост про тот же материал каналу не нужен. telegramPostUrl у адаптации остаётся пустым, скилл заканчивается на ФАЗЕ 6.

Ссылка со статьи на канал обязательна в любом режиме — это правило из раздела «Два входа», и от ФАЗЫ 7 оно не зависит.

Для режима «новая статья»:

1. Вызвать Skill('telegram-announcement') со ссылкой на https://aidevteam.ru/blog/{slug}.
2. Автор публикует пост в канале сам.
3. После публикации автор присылает ссылку на пост.
4. Агент дописывает telegramPostUrl в frontmatter и передеплоивает — на странице появляется блок со ссылкой на обсуждение.

---

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

Шаг	Скилл	Автор
Интервью и семантика	задаёт вопросы, собирает ядро	отвечает, подтверждает
Структура и текст	пишет	правит
SEO-чеклист	проверяет автоматически	—
Промты картинок	пишет промты	генерирует изображения
Проверка картинок	читает и сверяет с текстом	—
Публикация и деплой	делает целиком	—
Обратная перелинковка	предлагает места	подтверждает
Пост в Telegram (только новая статья)	готовит текст	публикует сам
IndexNow	пингует сам после деплоя	—

Чего скилл НЕ делает

• Не генерирует ANGELA-PUBLISHING-CHECKLIST.md — весь цикл, кроме постинга в Telegram, выполняет агент.
• Не постит в Telegram.
• Не готовит пост в канал для адаптации: тот материал уже анонсировался с исходной площадки.
• Не выдумывает цифры, кейсы и источники.
• Не переотправляет в IndexNow весь сайт: стоячее разрешение покрывает только страницы опубликованной или обновлённой статьи.
• Не публикует статью, если проверка изображений нашла расхождение с текстом.
• Не заводит вторую статью под запрос, который уже занят.

Прогон адаптации старых статей

Отдельная задача, по одной статье за раз.

1. Пройти по статьям в articles/habr/, оценить каждую по коммерческому потенциалу для B2B-семантики и предложить очередь. Часть материалов (например, бенчмарки моделей) под лидогенерацию не подходит — они остаются только на исходной площадке.
2. Отобранные адаптировать по одной, режимом «адаптация», полным циклом ФАЗА 0 → 7.
3. Каждая адаптация — отдельный прогон с отдельным гейтом на изображениях.