В общей процедуре ревью появился новый пункт: проверять, сохраняет ли повторный запуск операции пользовательские данные. В одном проекте skill уже обновлён, в другом осталась старая версия, а в третьем файл дополнительно изменили локально. Простое копирование поверх всех трёх исправит одно расхождение и может создать другое.
Обновление skills стоит рассматривать как поставку небольшой зависимости. Нужны известный источник, версия, список получателей и способ обнаружить локальную правку. Ни отдельный репозиторий, ни плагин сами по себе не решают вопрос конфликтов.
Сначала определите, какие файлы общие
Для примера общий code-review/SKILL.md описывает порядок оценки патча. Команда тестов, пути и доменные ограничения остаются в каждом проекте. Эту границу нужно установить до синхронизации, иначе общий файл незаметно начнёт переносить чужое имя контейнера.
Решение о составе ядра разобрано в отдельной статье. Здесь предполагаем, что переносимая часть уже выделена. Локальные инструкции не должны редактироваться скриптом доставки по широкому шаблону вроде «скопировать всё из служебного каталога».
Управляемый список может выглядеть так. Это предложенный формат собственного манифеста, не стандарт Agent Skills:
{
"package": "engineering-workflow",
"version": "1.3.0",
"managed_files": [
"code-review/SKILL.md",
"code-review/references/report.md"
],
"local_files": [
"project-commands.md",
"domain-rules.md"
]
}Имена файлов в примере иллюстративные. В реальной установке манифест должен соответствовать тому, что действительно поставляется и читается. Отдельно храните контрольные суммы установленной версии, если будете определять локальные изменения автоматически.
Для обновления нужны три состояния
Есть исходная версия пакета, установленная ранее; текущий файл получателя; новая версия источника. Сравнение только текущего и нового файла показывает различие, но не объясняет его происхождение.
Если текущий файл совпадает с ранее установленным, обновление можно подготовить обычной заменой. Если он отличается, это локальная правка или повреждение. Нужно показать diff и принять решение: перенести полезное изменение в общее ядро, оставить локальное расширение отдельно или сознательно отказаться от него.
Не называйте несовпадение ошибкой автоматически. Проект может намеренно оставаться на старой версии, потому что новый skill требует недоступного инструмента. Такое исключение лучше записать с причиной, чем регулярно перетирать при следующем запуске.
Разделите просмотр и применение
Собственному инструменту доставки полезны три режима. Проверка сообщает о расхождениях без записи. План показывает, какие файлы появятся или изменятся. Применение выполняет уже понятный набор операций и сохраняет сведения об установленной версии.
Это контракт проектируемого инструмента, а не команда, которая существует в любом репозитории. Если вы ещё не написали такой инструмент, начните с ручного diff для одного получателя. Не публикуйте в инструкции выдуманный sync-skills --apply без реализации.
В плане должны быть видны удаления. Исчезновение файла из новой версии пакета не означает, что его можно молча убрать у получателя: на него могут ссылаться локальные правила. Сначала найдите потребителей и подготовьте переход. Предыдущую рабочую версию сохраните для отката.
Проверьте установленную копию
Сравнение байтов доказывает доставку файла, но не работу процедуры. После переноса проверьте обнаружение skill выбранным инструментом, доступность справочников и выполнение одного характерного запроса.
Для ревью можно взять небольшой учебный патч с заранее известной ошибкой повторного запуска. Исполнитель должен назвать конкретное последствие и место проверки. Второй запрос — обычная редакционная правка текста — помогает убедиться, что skill не захватывает постороннюю работу.
У удалённых сред есть отдельная граница. Документация Cursor различает проектные и пользовательские skills и условия их доступности Cloud Agents. Поэтому успешный запуск на ноутбуке не доказывает, что облачный агент получил тот же набор. Проверяйте окружение, в котором процедура будет использоваться.
Версия должна объяснять изменение поведения
Дата изменения помогает найти свежий файл, но не объясняет совместимость. В заметке к версии лучше написать: «ревью теперь проверяет повторный запуск изменения данных; отчёт содержит отдельный пункт о сохранности существующих записей».
Пользовательские поля происхождения можно держать в манифесте доставки или в metadata фронтматтера, предусмотренном спецификацией. Они остаются вашими данными учёта. Не обещайте, что любой агент по ним сам обновит пакет или проверит подпись.
Для отката важно вернуть комплект согласованных файлов, а не только SKILL.md. Новое тело может ссылаться на новый справочник; старый справочник может не подходить новому порядку работы. Версия относится ко всему пакету.
Когда ручной перенос достаточен
Если получателей мало и изменения редкие, ручной перенос с diff и записью версии вполне прозрачен. Автоматизация становится полезной, когда одно и то же сравнение регулярно повторяется или пропуски обновлений уже мешают работе.
Начните с одного пилотного проекта, проверьте поведение, затем обновляйте остальные. Критерий успеха — известная рабочая версия у каждого получателя и сохранённые локальные решения. Одинаковые файлы во всех папках сами по себе не гарантируют одинаково правильную работу.
