Эта статья началась ровно там, где и должна была начаться: в длинном рабочем чате Codex. Мы со Стёпой только что закончили локальный публикатор для pimenov.ai, упаковали его в скилл, проверили на трёх типах материалов и опубликовали код. Следующая моя фраза была простой: «Теперь напиши статью про то, что мы сделали».
Раньше в этот момент пришлось бы менять режим работы. Собрать заметки, найти актуальную редакционную инструкцию, открыть нужную базу, заново объяснить контекст, подготовить свойства и отдельно заняться иллюстрациями. Теперь достаточно вызвать скилл $create-pimenov-ai-material в том чате, где уже находится вся история задачи.
Скилл видит переданный контекст, заново читает правила редакции и собирает готовый кандидат. После согласования он создаёт оформленный черновик в Notion. Так производственный процесс становится продолжением самой работы, а не отдельным ритуалом после неё.
Самые интересные материалы часто появляются между задачами
Идея для статьи редко приходит в пустом документе. Обычно она возникает после запуска продукта, разбора ошибки, удачного эксперимента или разговора с клиентом. В рабочем чате уже лежат решения, ссылки, аргументы, ограничения и результаты проверок.
Проблема начинается после появления этой идеи. Контекст приходится переносить вручную. При каждом переносе часть деталей теряется, а редакционная задача начинается почти с нуля. Человек снова пересказывает агенту, что произошло, почему это интересно и какие выводы можно сделать.
Я решил оставить материал в его естественной среде. Если рабочая сессия уже содержит достаточно данных, она становится источником статьи. Я вызываю скилл и добавляю редакционный угол: что именно интересно читателю, какую мысль нужно раскрыть и какой формат выбрать.
Это даёт важное преимущество: статья опирается на фактический след работы. В текущем случае таким следом стали код публикатора, тесты, тестовые черновики для Блога и Базы знаний, первый реальный материал и весь разговор о том, как должен выглядеть универсальный процесс.
Один вызов включает целую редакционную линию
$create-pimenov-ai-material выглядит как одна команда, но за ней работает последовательный производственный контур.
Сначала скилл определяет, что уже есть в чате. Это может быть готовый черновик, набор ссылок, локальные файлы, расшифровка или история разработки. Если данных достаточно, агент не просит приложить их повторно.
Затем выбирается режим. Готовый авторский текст обрабатывается бережно: факты, структура и позиция сохраняются. При работе от источников Codex исследует тему, выбирает угол и пишет материал с нуля.
После этого материал маршрутизируется в один из трёх разделов pimenov.ai:
- Статья для развёрнутой позиции, кейса или анализа;
- Блог для короткой реакции и одного наблюдения;
- База знаний для руководства, инструмента или справочного материала.
У каждого раздела своя база Notion, схема свойств, набор допустимых тегов и визуальный формат. Произвольную базу в публикатор передать нельзя. Это защищает процесс от случайной записи не туда.
Инструкции живут в Notion и читаются заново
Редакционные правила меняются. Я уточняю голос, замечаю новые шаблонные обороты, пересматриваю визуальные форматы и корректирую обязательный футер. Если скопировать эти правила внутрь скилла, через несколько недель он начнёт писать по устаревшей редакции.
Поэтому скилл хранит только стабильную карту: идентификаторы страниц с инструкциями, целевые базы, границы разрешений и контракт публикатора. Перед каждым материалом Codex открывает актуальные страницы Notion:
- верхнеуровневую инструкцию о голосе и запретах;
- ядро редакционного процесса;
- стандарт текста и проверку GPT-tells;
- правила визуального стиля;
- требования к связанным материалам и призыву к действию.
В пакет материала записываются версия, время последнего изменения и контрольная сумма содержания каждой инструкции. Эти сведения позволяют позже понять, по какой редакции правил собирался конкретный материал.
Если инструкция изменилась после согласования текста, прежнее подтверждение перестаёт действовать. Кандидат нужно проверить и собрать повторно. Эта граница кажется строгой, зато она убирает тихое расхождение между тем, что человек утвердил, и тем, что публикатор собирается записать.
До Notion существует проверяемый пакет материала
Codex не отправляет текст в систему управления контентом сразу после написания. Сначала создаётся локальный пакет материала. В нём находятся рабочая редакция, свойства страницы, список источников, сведения о версиях инструкций, готовые изображения, связанные материалы и упорядоченное дерево блоков.
Пакет хранится в отдельной локальной папке. Главный файл material.json описывает тип материала, целевую базу, свойства страницы, источники, изображения и последовательность блоков. Публикатор не принимает произвольный адрес базы: тип материала однозначно выбирает нужную таблицу и набор обязательных свойств.
Перед записью выполняется локальная проверка без обращения к Notion. Она проверяет адресный идентификатор, длину описания, публичный URL, статус, количество изображений, пути к файлам и структуру блоков. Следом запускается проверка с авторизацией на живой схеме Notion. Она сверяет доступные теги, ищет дубли и подтверждает связанные материалы. В техническом результате обязательно должно быть writes=0.
Так я отделил подготовку от необратимого действия. Почти весь процесс можно пройти, обсудить и переделать без единой новой страницы в Notion.
Как генерируются обложки и иллюстрации
Изображения создаются внутри того же прохода Codex. Сначала скилл перечитывает актуальную визуальную инструкцию в Notion, затем формирует отдельный промпт для каждого изображения и запускает встроенную генерацию. В страницу никогда не попадает заглушка с промптом: публикатор загружает готовый файл.
Для трёх типов материалов действуют разные визуальные контракты:
- Статья получает одну обложку и две содержательные внутритекстовые иллюстрации. Третья возможна только тогда, когда в тексте есть отдельный раздел, которому действительно нужна собственная визуализация.
- Блог получает одну обложку в утверждённом стиле «Живой оптимистический футуризм». По умолчанию внутри короткого поста дополнительных изображений нет.
- База знаний получает одну обложку в стиле Flat Vector. Схемы, таблицы и примеры внутри руководства оформляются нативными блоками Notion, а дополнительные сгенерированные иллюстрации по умолчанию не создаются.
У каждого изображения сохраняется исходный промпт, чтобы можно было восстановить историю генерации. Принятый вариант переводится в WebP размером 1600×900 с помощью cwebp, а webpinfo проверяет формат, размеры и целостность файла. Ограничение одного файла — 20 MB.
Обложка загружается в Notion один раз, после чего тот же внутренний файл используется в двух местах: в свойстве базы Обложка и как нативная обложка самой страницы. Для статьи ещё два файла вставляются в заранее определённые места дерева блоков. После создания проверка считает изображения и сверяет их расположение с локальным пакетом.
Промпты остаются в технических сведениях пакета. Читатель видит только готовые изображения, а редактор при необходимости может понять, какой замысел использовался для каждого из них.
Финальное решение остаётся у человека
После проверок я вижу собранный кандидат целиком: заголовок, описание, теги, текст, источники, обложку, две иллюстрации, блок «По теме» и призыв к действию. Можно попросить изменить угол, переписать фрагмент, заменить изображение или вернуться к источникам.
Для записи недостаточно случайной реакции или согласия с отдельной правкой. Codex задаёт прямой вопрос: «Создать этот материал одним черновиком в Notion?». После однозначного подтверждения он сам передаёт публикатору внутреннюю техническую команду, привязанную к выбранному типу материала.
Такое финальное разрешение на запись защищает от случайной публикации во время обсуждения. Страница всегда создаётся со статусом Черновик. Дата публикации по умолчанию остаётся пустой, но я могу прямо указать её при подтверждении материала. Directus, сайт и публичный выпуск находятся за пределами этого скилла.
Редактором остаюсь я. Я определяю тему, оцениваю текст, принимаю визуалы и даю финальное разрешение. Codex берёт на себя тяжёлую производственную часть и доказательство того, что результат записан корректно.
Создать страницу недостаточно
Успешный ответ API ещё не доказывает, что статья получилась целой. Может потеряться ссылка, нарушиться порядок блоков или не загрузиться изображение. Поэтому после создания публикатор читает страницу через прямой Notion API и сравнивает её с локальным пакетом.
Проверяются свойства, статус, полный и форматированный текст, ссылки, подписи, дерево вложенных блоков, внутренние файлы Notion и нативная обложка. Затем страница независимо перечитывается через коннектор Notion. Два разных пути чтения уменьшают риск принять частичный результат за готовый.
Если страница создалась только частично, публикатор останавливается и возвращает её идентификатор. Он не удаляет черновик и не создаёт замену автоматически. Решение о восстановлении остаётся отдельным действием.
Я проверил контур на всех трёх форматах
Сначала публикатор прошёл локальные тесты. Старый процесс статей сохранил обратную совместимость, а новый исполняемый модуль получил отдельные контракты для Блога и Базы знаний.
Затем я создал два тестовых черновика. Блог получил обложку в собственном стиле без внутритекстовых иллюстраций. Страница Базы знаний получила другую обложку, обязательную категорию, оглавление, блок кода и таблицу. Оба черновика прошли прямую проверку и независимое чтение.
Первый реальный запуск показал, что скилл работает и за пределами чата разработки. В другой задаче я передал контекст, получил написанную статью и оформленный черновик Notion. После этого я отдельно разобрал процесс, нашёл неточность в сведениях о времени и добавил явный механизм для одобренных визуальных исключений.
Финальная версия публикатора прошла 29 тестов. Код, скилл и технический отчёт опубликованы в основном репозитории проекта. Глобальная установка сделана ссылкой на канонический исходник, поэтому любой новый чат Codex видит тот же рабочий процесс.
Что меняется в повседневной работе
Теперь момент «из этого получилась бы статья» превращается в действие. Не требуется вспоминать устройство базы или искать последнюю версию инструкции. Можно продолжать разговор в текущей задаче и вызвать скилл.
Дополнительный контекст тоже передаётся прямо в чате. Например: сделать акцент на управленческом выводе, сохранить авторскую формулировку, объяснить техническую часть проще или подготовить материал именно для Блога. Скилл использует этот комментарий вместе с уже накопленными источниками.
За счёт этого редакционная система становится общей для разных процессов. Сегодня статья появляется после разработки публикатора. Завтра она может вырасти из клиентского исследования, архитектурного решения, расшифровки встречи или эксперимента с новым инструментом.
Главный эффект здесь связан со снижением потерь. Я сохраняю контекст работы, применяю актуальные правила и получаю проверяемый черновик в одном процессе. Публикация по-прежнему требует моего решения, зато путь от готовой мысли до материала стал гораздо короче.
По теме
Мои Codex skills: как мы собираем дисциплину для ИИ-агента
Codex Record & Replay: покажите рабочий процесс один раз — и он станет навыком
Skills и Plugins в Codex App: установка, использование и создание своих
Если у вас тоже рабочие идеи рождаются внутри длинных проектных чатов, такой контур можно адаптировать под вашу редакцию и правила проверки.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov