Задача «обновить текст статьи» кажется локальной, пока вместе с текстом не меняются её URL, дата и накопленные просмотры. Агент может получить технически корректную запись и при этом испортить историю публикации. Доменный skill нужен, чтобы такие последствия входили в постановку работы с самого начала.
Возьмём существующий блог: материал хранится в базе, доступен по slug, имеет статус, дату и счётчик просмотров. Ниже — учебная процедура обновления контента. Она не описывает выполненную миграцию и не даёт разрешения менять production.
Начните с того, что должно сохраниться
Перечень полей модели сам по себе мало помогает. В процедуре нужна связь между действием и последствием. Если меняется только текст, ссылка должна продолжать вести к той же статье, а обновление контента не должно обнулять статистику.
Объект: существующая статья, найденная по стабильному slug.
Разрешённые изменения: поля текста, явно указанные в задаче.
Сохранить: id, slug, views, статус и дату публикации,
если изменение этих полей отдельно не входит в задачу.
Перед записью:
- показать текущий объект и планируемые поля;
- проверить, не редактировался ли текст после подготовки обновления;
- при конфликте не затирать неизвестное изменение.
После записи:
- сверить изменённые и сохраняемые поля;
- проверить публичную страницу и связанные выдачи.
Здесь запрет связан с задачей, а не объявлен вечным. Перенос URL может быть отдельной обоснованной работой с редиректом. Изменение даты тоже возможно, если человек именно этого просит. Skill должен отличать намеренное изменение от побочного эффекта массовой операции.
У каждого правила должно быть основание
Напротив инварианта запишите источник: решение владельца продукта, существующий тест, ограничение базы или участок кода. Если источник не найден, обозначьте предположение и вынесите его на обсуждение до записи данных.
Например, «просмотры сохраняются при редакционной правке» — продуктовое требование. Механизм его выполнения ищется в конкретном обновляющем коде. «HTML очищается перед выводом» — правило безопасности, которое проверяется в шаблоне и конфигурации очистителя. «Контент всегда восстанавливается из сидеров» нельзя считать фактом лишь потому, что сидеры существуют.
Особенно опасно переносить в новый проект чужой порядок развёртывания. Инструкция пересоздать базу ради обновления текстов несовместима с сохранением пользовательских данных. Сначала выясняется реальный источник контента и способ обновления, затем формируется процедура.
Покажите путь записи и чтения
Доменный skill полезно дополнить короткой картой: где объект меняется, где показывается, какие производные данные от него зависят. Для статьи это может быть команда импорта, модель, обработчик пересчёта времени чтения, шаблон, кэш списков, RSS и sitemap.
Не нужно копировать в файл всю архитектуру приложения. Достаточно назвать подтверждённые точки входа и способ найти актуальные реализации. Путь к файлу лучше длинного пересказа его методов: агент сможет открыть текущий код, а человек — проверить основание вывода.
Обратите внимание на обходные пути. Обновление через модель и прямой SQL могут запускать разные обработчики. Если процедура зависит от пересчёта поля, это нужно проверить на выбранном пути записи. Общая фраза «сохрани статью» оставляет эту разницу незаметной.
Перенесите проверяемое в механизмы
Skill напоминает о правиле, но не обеспечивает его исполнение. Стабильность статистики лучше дополнительно проверять тестом обновления: создать статью с ненулевыми просмотрами, выполнить изменение текста и убедиться, что счётчик сохранился. Контроль конфликта должен быть реализован в команде или сервисе записи, если процесс на него рассчитывает.
Проверка повторного запуска отвечает на другой вопрос. Если одно обновление применить дважды, появится ли дубль, изменится ли дата, повторится ли побочный эффект? Идемпотентность нельзя доказать наличием слова updateOrCreate: оно ещё ничего не говорит о том, какие поля перезаписываются и что делает обработчик сохранения.
В документации Claude Code отдельно проводится граница между текстовыми инструкциями и ограничениями, которые обеспечивает клиент. Этот принцип полезен и при проектировании своего процесса: инструкция описывает ожидаемое поведение, а права доступа и проверки создают независимую защиту.
Добавьте сценарий отказа
Хорошая процедура умеет закончиться без записи. Для учебного обновления полезен такой случай: исходный текст прочитан, затем редактор меняет его через админку, после чего запускается подготовленный импорт. Ожидаемый результат — сообщение о конфликте с указанием статьи, а не молчаливое восстановление старой версии.
Ещё один случай — статья не найдена. Если задача звучала как обновление существующей записи, создание новой должно быть отдельным решением. Иначе опечатка в slug превращается в новую публикацию и скрывает исходную проблему.
В отчёте агент должен показать идентификатор изменённой записи, перечень затронутых полей, результаты проверок и нерешённые ограничения. Фраза «всё сохранено» без сравнения состояния не позволяет принять работу.
Обновляйте skill вместе с поведением
Назначьте владельца правила и событие пересмотра: изменение команды импорта, схемы данных или процедуры публикации. Проверка по календарю может дополнять этот процесс, но не заменяет его. Между двумя плановыми ревизиями механизм записи уже способен измениться.
Доменные инструкции должны объяснять цену ошибки и направлять к доказательству. Общий порядок ревью можно взять из переносимого ядра, но решение о том, какие данные сохраняются, остаётся за владельцем конкретного продукта.