При каждой публикации приходится напоминать агенту про предпросмотр, дату, обложку и ссылки. Возникает желание сразу оформить большой скилл. Но сначала нужно выяснить, повторяется ли сама процедура: одинаковое название задачи ещё не означает одинаковый порядок действий.
Эта статья — о выборе момента для автоматизации рабочего процесса. Формат файла и описание скилла разобраны отдельно. Здесь результатом будет небольшая проверенная процедура, которую имеет смысл поддерживать.
Записать один законченный проход
Возьмём учебный пример публикации статьи в блоге. Текст уже согласован, но материал может быть черновиком, запланированной публикацией или обновлением существующей записи. Выпишите фактический порядок действий и для каждого шага укажите, откуда берётся информация.
Вход: slug статьи и намерение автора.
Проверить текущий статус, дату и доступность обложки.
Открыть предпросмотр: заголовки, код, изображения, ссылки.
Показать автору изменения публичных полей.
Применить согласованный статус и дату.
Проверить публичный адрес и связанные списки.
Выход: адрес, состояние публикации, список проверок.
Это заготовка процесса, а не разрешение публиковать любую найденную статью. Если задача состояла в исправлении опечатки, переход из черновика в опубликованное состояние не следует из этой инструкции.
Отделить правило от случайности
Сопоставьте несколько задач. В одной менялся только текст, в другой — дата выхода, в третьей публикация была отложена. Если процедура требует каждый раз новой логики, сначала опишите варианты входа. Общее правило здесь — сохранить дату при обычной правке; установка новой даты относится к отдельному намерению автора.
Число повторов — подсказка, а не закон. Редкая операция с дорогой ошибкой может заслуживать инструкции сразу. Частая операция из одной очевидной команды может годами обходиться без отдельного скилла. Решение зависит от потерь при пропуске шага и стоимости поддержки.
Выбрать подходящую форму
Постоянное правило проекта — например, где запускать тесты — удобно хранить в общих инструкциях. Детерминированную проверку существования обложек лучше сделать командой. Скиллу остаётся последовательность решений: выяснить намерение, выбрать ветку процедуры, запустить подходящие проверки и объяснить результат.
Не заставляйте модель вручную повторять то, что надёжно проверяет программа. И не прячьте редакционное решение внутри скрипта: «у статьи есть обложка» можно вычислить, «статья готова для читателя» требует содержательной оценки.
Спецификация Agent Skills описывает структуру пакета с SKILL.md и дополнительными ресурсами. Она задаёт способ упаковки инструкции, но не решает за автора, какой рабочий процесс стоит упаковать.
Проверить процедуру на разных входах
До регулярного использования подготовьте маленький набор задач. Для публикации достаточно начать с трёх различающихся ситуаций: готовый черновик, правка уже опубликованного текста и материал с недоступной обложкой. Для каждой заранее запишите ожидаемое действие.
| Ситуация | Ожидаемый результат |
|---|---|
| Согласованный черновик | Публикация с указанной датой, проверенный публичный URL |
| Исправление опечатки | Текст исправлен, дата и статус сохранены |
| Обложка недоступна | Проблема названа до публикации, нет подмены случайной картинкой |
Прогоняйте это на копии данных или тестовых записях. Важно посмотреть и успешную ветку, и отказ. Процедура, которая на любом входе заканчивается словом «готово», не помогает отличить завершённую работу от пропущенного условия.
Назначить повод для пересмотра
У инструкции должен быть владелец и понятный повод обновить её. Изменился способ предпросмотра, появилась новая схема хранения картинок, публикация теперь запускается отдельной командой — старый порядок нужно пересмотреть вместе с реализацией. Ссылка на устаревший экран не становится правильной от того, что файл лежит в репозитории.
Сохраняйте примеры неудачного применения рядом с проверками процесса. Они объясняют, зачем существует конкретный шаг. Если условие перестало защищать от реального сбоя, его можно удалить после проверки, вместо бесконечного накопления запретов.
Первый полезный скилл уменьшает объём повторных объяснений и оставляет видимыми точки человеческого решения. Если после его появления приходится читать ещё больше инструкций и исправлять неверно выбранную процедуру, вернитесь к границам задачи. Упаковка не исправляет неопределённый процесс.