Один markdown и четыре площадки: skill для Claude Code с pre-flight перед публикацией

Редакция 2 сентября 2026 г.

Один исходный файл, четыре целевые площадки, три режима доведения до публикации: API на Dev.to, Chrome-черновики на Builder Center и Medium, финальный клик всегда за вами. Для соло-разработчика, который уже собирает цикл «агент пишет → skill гоняет скрипты», узкое место не генерация текста, а четыре слегка разных артефакта без единой проверки перед отправкой. В разборе publishing-kit для Claude Code автор показывает, как skill закрывает этот разрыв.

Что делает skill и откуда берётся один источник

publishing-kit — skill для Claude Code и набор небольших Python-скриптов. Alex Shev (xbill на Dev.to) описывает цепочку: один исходный markdown превращается в версии под Dev.to, AWS Builder Center, Medium и LinkedIn. Skill не подменяет редактора: он собирает payload, запускает проверки и доводит материал до черновика там, где это возможно.

Установка — через plugin marketplace (/plugin marketplace add xbill9/publishing-kit) или git clone репозитория github.com/xbill9/publishing-kit (лицензия Apache-2.0) с симлинком в ~/.claude/skills/publishing. Зависимости минимальны: Python 3, Pillow; для Dev.to нужен API-ключ в ~/.devto.key и публичный репозиторий со статьёй. Обложка и картинки для Medium подтягиваются по URL при рендере.

Архитектура намеренно плоская: один SKILL.md, reference-файлы с quirks каждой площадки, отдельный скрипт на задачу. Голос и структура вынесены в references/house-style.md: его можно заменить, и kit начнёт писать «другим автором», не трогая skill и скрипты. Для vibe-coding это узнаваемый паттерн: агент решает когда запускать шаг, скрипты делают детерминированное преобразование.

Скрипты сборки из одного markdown:

make-builder.py — версия для Builder Center (emoji убираются, добавляется AWS disclaimer);
make-medium.py — HTML для Medium, таблицы рендерятся в PNG;
make-linkedin.py — пост для LinkedIn;
make-cover.py --flow --sizes devto,builder — иллюстрация pipeline и обложки под геометрию площадок.

Проверка перед отправкой: что гоняется до публикации

Центральный ритуал — preflight.py --live: он выполняет все проверки и завершается с ненулевым кодом при любой ошибке. Конкретные условия:

обложка закоммичена и совпадает с HEAD;
геометрия обложки корректна;
front matter полный;
нет hard-wrapped абзацев;
каждый уже опубликованный URL загружается и сравнивается байт в байт с локальной копией на диске.

Вокруг этого работают специализированные проверки:

check-facts.py — извлекает цены, измерения и версии из текста и сообщает, какие из них не встречаются ни в одном evidence-файле (не судит об истинности, только о наличии артефакта);
check-article.py — находит hard-wrapped абзацы и указывает номер первой проблемной строки;
publish-devto.py при отправке на Dev.to делает unwrap, чтобы репозиторная копия оставалась читаемой при 95 колонках, а опубликованная страница — без лишних переносов.

Локальные проверки могут пройти, пока опубликованный URL отдаёт другое содержимое. Поэтому в kit есть отдельный контур сравнения «что на диске» и «что отдаёт площадка».

Типичный сценарий после установки: команда вроде «напиши бенчмарк и опубликуй на Dev.to под aws-builders». Claude Code пишет source, генерирует cover, трассирует числа, запускает pre-flight, сообщает о сбоях; после прохождения постит draft на Dev.to и отдаёт ссылку. Medium и Builder Center — отдельная команда: derive, рендер таблиц, работа в Chrome, заполнение редакторов. Публикация остаётся за человеком: последний клик — ваш, не агента.

API, Chrome и ручной финал по площадкам

Skill не обещает полностью безбраузерный контур на всех четырёх площадках. Режимы различаются:

Площадка	Как skill доводит материал
Dev.to	API: `publish-devto.py --create` — front matter уходит как payload (title, tags, cover вместе с телом); флаг `--org-slug` маршрутизирует в community channel. Браузер не нужен.
AWS Builder Center	«Chrome work» — редактор без API; skill передаёт payload через `window.name`, checksum с обеих сторон, проверка пустоты до paste, подсчёт landmark после paste.
Medium	Аналогично Builder Center; таблицы рендерятся в PNG (`make-medium.py`), потому что импортёр Medium «съедает» таблицы.
LinkedIn	Отдельный пост (`make-linkedin.py`); Posts API не создаёт draft — при создании принимается только состояние `PUBLISHED`.

На всех площадках, где применимо, skill останавливается на draft и отдаёт ссылки. Финальная публикация — осознанное действие редактора, а не автоматический клик агента.

Для агентного workflow это важное разграничение: skill снимает рутину преобразования и первичной валидации, но не подменяет ответственность за то, что уходит в ленту под вашим именем.

Отладка, когда площадка «ломает» разметку

Главный инструмент диагностики расхождения «страница ≠ файл» — check-links.py:

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

Скрипт проверяет branch URL-ы: HTTP-статус и совпадение отданных байт с диском. Сообщение FAIL при HTTP 200, но расхождении байт — типичный случай: изображение перегенерировали после коммита.

Другие сценарии из практики автора (измерения от 31 августа 2026):

Симптом	Что делать
Рваные абзацы на Dev.to	`check-article.py` + unwrap в `publish-devto.py`
Пропали картинки на Medium	Вставляли `-embed.html` вместо `-hosted.html`; нужны реальные URL, которые Medium re-hosts, и коммит изображений заранее
Число без артефакта	`check-facts.py` называет claim; автор классифицирует как «measured but never archived», «arithmetic» или «asserted from memory»

Dogfooding на этом же материале дал наглядные цифры: на Dev.to 47 из 62 абзацев с hard-wrapped текстом несли лишний break в опубликованной версии; на Medium 0 из 4 картинок, вставленных как data URI, сохранились. При реальных URL прошли 4 из 4.

Платформенные капризы, которые kit учитывает в скриптах:

Dev.to: markdown с hard breaks on, source wrapped at 95 columns, даёт лишний break в каждом абзаце;
Dev.to: cover проксируется с соотношением 2.381:1 — обложка 1376×768 теряет 95px сверху и снизу;
Medium: data: URI images при paste не сохраняются;
LinkedIn Posts API: draft при создании недоступен.

check-facts.py отвечает на вопрос «есть ли артефакт под это число», а не «верно ли число». Для соло-автора, который ускоряет черновики агентом, это защита от «красивого текста с цифрами из воздуха», слабое место любого агентного контура публикации.

Что переносится в ваш skill-стек

В первоисточнике нет сравнения с Cursor, MCP или rules других IDE — только Claude Code и формат SKILL.md. Но сама схема переносима: один markdown, skill оркестрирует скрипты, pre-flight ловит расхождения до того, как читатель увидит четыре версии одной мысли.

Если вы собираете похожий контур в другой агентной среде, имеет смысл украсть три идеи из kit:

Разделение ролей: агент решает последовательность, скрипты делают преобразование без галлюцинаций в формате.
Byte-for-byte сверка опубликованного URL с диском, не только «файл существует и tracked».
Draft-by-default: автоматизация до черновика, финал за человеком.

skill-footprint.py --where печатает путь skill-директории; skill-footprint.py без флагов считает размер skill и token cost. Полезно, когда решаете, сколько контекста отдавать агенту на каждый цикл публикации.

Источники

Alex Shev (xbill), «Streamline Publishing with a Claude Code Skill» — Dev.to (опубликовано 1 сентября 2026; дата доступа при обогащении: 2 сентября 2026 UTC)
Репозиторий publishing-kit — https://github.com/xbill9/publishing-kit (Apache-2.0; дата доступа: 2 сентября 2026 UTC)