Как опубликовать статью на 4 платформы без боли: publishing-kit

Публикация технических статей: боль, которую можно устранить

Вы когда-нибудь публиковали одну статью на нескольких платформах? Если да, то знаете, сколько церемоний: обложка под каждый размер, рендер таблиц в картинки (Medium их съедает), удаление эмодзи для AWS, проверка каждого числа в тексте, копирование длинного markdown в браузерный редактор без API и запоминание, в какую организацию роутится статья. В итоге у вас четыре разных файла и непонятно, какой актуален. Я упаковал весь этот процесс в publishing-kit — навык для Claude Code и набор скриптов, чтобы вы могли просто попросить Клода опубликовать статью.

Что делает publishing-kit

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

Сборка артефактов

Один исходный файл превращается в markdown для dev.to, версию для AWS Builder Center с удаленными эмодзи и дисклеймером, HTML для Medium (таблицы рендерятся в PNG) и пост для LinkedIn. За это отвечают скрипты make-builder.py, make-medium.py и make-linkedin.py.

Обложка один раз

make-cover.py --flow --sizes devto,builder рисует схему пайплайна как иллюстрацию и рендерит её во всех нужных размерах. Имя файла — хэш содержимого, а скрипт сообщает, какие размеры шрифта переживут карточку в ленте 320px — именно там обложку чаще всего видят, и где диаграмма с мелкими подписями превращается в кашу.

Проверка фактов

check-facts.py извлекает из текста цены, размеры и версии и сверяет их с файлами-доказательствами. Он не скажет, правда ли число, но укажет, какие утверждения вы делаете по памяти.

Предполетная проверка

preflight.py --live запускает все проверки и завершается с ошибкой, если что-то не так: обложка не закоммичена или не совпадает с HEAD, геометрия неверная, фронт-маттер неполный, есть жесткие переносы строк, а опубликованные URL не совпадают байт в байт с локальными файлами.

Публикация через API

publish-devto.py --create использует фронт-маттер как payload, так что заголовок, теги и обложка передаются вместе с текстом. Флаг --org-slug направляет статью в нужное сообщество. Без браузера.

Управление редакторами без API

AWS Builder Center и Medium — это Chrome-задачи, и навык знает маршрут: передача данных через window.name, чек-сумма на обеих сторонах, проверка пустоты перед вставкой и подсчет якорей после.

Также в навык зашиты грабли, которые вы иначе узнали бы на следующий день после публикации:

• dev.to рендерит markdown с жесткими переносами (hard breaks on), поэтому исходник с переносами на 95 колонок приходит с лишними разрывами в каждом абзаце.
• dev.to не хранит вашу обложку, а проксирует её в соотношении 2.381:1, так что обложка 1376x768 теряет по 95px сверху и снизу.
• Medium теряет изображения с data URI при вставке, поэтому самодостаточный HTML приходит вообще без картинок.
• LinkedIn Posts API не умеет создавать черновик — только PUBLISHED при создании.

Установка

Самый быстрый путь — через маркетплейс плагинов:

/plugin marketplace add xbill9/publishing-kit
/plugin install publishing@publishing-kit

Предпочитаете классический способ? Клонируйте репозиторий и создайте симлинк на навык:

git clone https://github.com/xbill9/publishing-kit
ln -s "$PWD/publishing-kit/skills/publishing" ~/.claude/skills/publishing

Понадобится Python 3 с Pillow для обложек и таблиц, API-ключ dev.to в ~/.devto.key и публичный репозиторий для папки статьи — обложка и изображения для Medium подтягиваются по URL при рендеринге, так что незапушенное значит сломанное.

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

skill-footprint.py --where

Выведет директорию навыка. При установке из клона это skills/publishing, при установке из маркетплейса — путь с версией в кэше, что означает: ни одна команда, которую вы запишете, не переживёт обновление. Это важно, если вы планируете дорабатывать навык: установка делает снимок, а claude plugin update сравнивает версии, поэтому правки в той же версии не попадут в сессию. На время итераций используйте симлинк.

Как это выглядит на практике

После установки вы общаетесь с Claude Code так:

«Опиши этот бенчмарк и опубликуй его на dev.to в aws-builders»

Клод пишет исходную статью, генерирует обложку в двух размерах, сверяет числа с вашими артефактами запуска, прогоняет предварительную проверку, сообщает об ошибках и, когда всё проходит, публикует черновик и даёт ссылку. Затем:

«Теперь сделай версии для Medium и Builder Center»

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

Отладка публикации, которая пошла не так

Это половина, которая удивила меня больше всего, и где сосредоточена основная ценность навыка.

Страница не выглядит как файл

Сверяйтесь с тем, что реально отдаёт сайт, а не рассуждайте о том, что вы запушили:

python3 ../../skills/publishing/scripts/check-links.py article.md

Вывод покажет, какие URL доступны и совпадают ли байты с диском. Ошибка FAIL означает «HTTP 200, но отдаваемые байты отличаются от диска» — обычно это изображение, перегенерированное после коммита. Остальные проверки в наборе оперируют локальным состоянием: есть ли файл, отслеживается ли он. Каждая из них может пройти, а опубликованный URL будет отдавать другое содержимое.

Абзацы выглядят рваными

check-article.py сообщает о жёстких переносах с номером строки первого из них, а publish-devto.py разворачивает их на выходе, так что ваша репозиторная копия остаётся читаемой при 95 колонках, а опубликованная страница — нет.

На Medium отсутствует изображение

Вы вставили -embed.html. Вставляйте -hosted.html, который ссылается на реальные URL, которые Medium перехостит, и сначала закоммитьте изображения.

Число в статье не подкреплено артефактом

check-facts.py укажет на него. Каждое неподтверждённое утверждение — одно из трёх: измерено, но не записано; арифметика, которую нужно пометить как арифметику; или утверждение по памяти. И всегда именно третье оказывается неверным.

Под капотом

Один SKILL.md, файл-справочник по особенностям каждой платформы и скрипт на каждую задачу. Навык решает, когда запускать скрипты; скрипты можно запускать независимо, и они выводят, что сделали.

Часть, которую стоит позаимствовать для своих навыков, — references/house-style.md. Голос, порядок секций, формулы вступления и заключения живут в этом файле, и ничто в SKILL.md или скриптах от него не зависит. Замените файл — и набор будет писать как кто-то другой.

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

Собачий корм: эта статья и её обложка

Каждый артефакт здесь создан с помощью набора. Обложку отрендерил make-cover.py, версию для Builder Center сделал make-builder.py, сборку для Medium — make-medium.py, а черновик на dev.to опубликовал publish-devto.py.

Два числа на обложке реальны, и оба найдены при использовании набора на себе:

• dev.to, жёсткие переносы: 47 из 62 в опубликованной статье содержали лишний разрыв
• Medium, изображения, вставленные как data URI: 0 из 4 выжили; с реальными URL — 4 из 4

Первая проблема случалась с моими статьями месяцами. Вторая стоила полной переделки при первом возникновении. Ни той, ни другой нет в документации платформ, и теперь обе стали проверками.

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

• make-medium.py имел захардкоженный репозиторий другого проекта как базовый для изображений;
• check-article.py пропускал обложку, которая была отслежена, но перегенерирована;
• make-cover.py терял значение --tile, начинающееся с дефиса, из-за argparse;
• check-facts.py читал 127.0.0.1 как номер версии;
• unwrap() пропускал цитаты, поэтому TL;DR этой статьи опубликовался пятью отдельными строками — а проверка, которая должна была это поймать, тоже пропускала цитаты и соглашалась.

Практический вывод: что делать прямо сейчас

Установите publishing-kit и попробуйте опубликовать свою следующую статью на dev.to через API. Даже если вы не используете все платформы, проверка фактов и предварительная проверка сэкономят вам часы отладки. А если вы пишете собственные навыки для Claude Code, возьмите на вооружение подход с отдельным файлом стиля — это сделает ваши навыки гибкими и переиспользуемыми.