В проекте появились четыре указания: запускать PHP внутри контейнера, очищать HTML перед выводом, проверять превью статьи и сохранять отчёт о текущей задаче. Если сложить их в один большой файл, агент получит смесь постоянных правил, процедур и временного состояния. Если сделать четыре skills, простая работа начнётся с выбора инструкций.
Разложим эти указания по назначению. Задача здесь — определить место правила, чтобы его было легко найти, применить и обновить. Синтаксис SKILL.md разобран отдельно в статье о формате и выборе skill.
Четыре места для разных видов знания
Постоянные условия работы относятся к инструкциям проекта. Например: PHP-команды выполняются в сервисе webserver, публичные шаблоны используют общий layout, HTML проходит через очиститель. Эти сведения нужны при соответствующих изменениях независимо от конкретной редакционной процедуры.
Повторяемая процедура относится к skill. У неё есть узнаваемый вход и результат: проверить превью существующего черновика, подготовить миграцию контента, провести визуальную проверку. Внутри есть последовательность или набор решений, которые не хочется заново собирать для каждой задачи.
Большой справочник относится к документации. Описание всех параметров команды, история архитектурного решения или каталог редких ошибок могут быть полезны, но их не требуется загружать при каждом запуске. Из инструкции нужна ссылка с объяснением, когда этот материал читать.
Текущее состояние относится к задаче или передаче работы: что уже изменено, какая проверка упала, какой вопрос остался. Запись «сегодня продолжаем перенос обложек» в постоянном руководстве быстро станет ложной.
Одно требование может иметь несколько представлений
Рассмотрим правило очистки HTML. В инструкции проекта достаточно указать действующий механизм и место его применения. В коде должен находиться сам вызов очистителя. В тесте — пример опасного содержимого, которое не проходит на публичную страницу. В процедуре ревью — требование проверить эту границу, если патч затрагивает вывод контента.
Это не четыре копии одного текста. У каждого представления отдельная работа: ориентир, выполнение, доказательство и проверка изменения. Проблема начинается, когда один и тот же список разрешённых тегов вручную переписан в нескольких Markdown-файлах и расходится с конфигурацией.
Поэтому вопрос «это skill или AGENTS.md?» иногда поставлен слишком узко. Правило, которое можно обеспечить программно, не стоит оставлять только в инструкции. Skill может направить к тесту, но не заменить его.
Когда отдельный skill оправдан
Проверка превью имеет понятный вход — черновик — и результат — адрес с замечаниями. Она задействует несколько мест проекта и должна сохранить статус публикации. Это хороший кандидат для отдельной процедуры.
А строка «используй русский язык интерфейса» не требует собственного каталога. У неё нет отдельного результата, который можно предъявить после вызова. Достаточно инструкции проекта и проверки конкретного UI.
Частота тоже имеет значение, но универсального порога «после третьего раза» нет. Редкая операция может заслуживать документации из-за высокой цены ошибки. Частая операция может оставаться одной командой. Оцените, какое решение сохраняет skill и кто будет поддерживать его при изменении процесса.
Кандидат: проверка превью статьи
Вход: slug существующего черновика
Результат: адрес, замечания, выполненные проверки
Особое условие: не менять публичный статус
Зависимости: механизм превью, доступ к браузеру
Владелец: редактор или разработчик процедуры публикацииЕсли эту карточку не удаётся заполнить без общих слов, отдельный skill пока не проясняет работу. Возможно, нужен обычный абзац документации или более точная постановка текущей задачи.
Не переносите правила загрузки между продуктами
AGENTS.md нельзя описывать как файл, который любой инструмент читает только по просьбе. Codex имеет документированный порядок поиска инструкций по уровням, включая варианты override. Это нужно проверять по его руководству.
У Claude Code собственные правила для CLAUDE.md и поддержки AGENTS.md; поведение зависит от версии, настройки и наличия других файлов. Наличие двух документов ещё не доказывает, что оба загружены. Документация Claude Code описывает эти условия отдельно. У Cursor правила проекта и skills также имеют разные механизмы; переносить параметры одного в другой по сходству названий нельзя.
В репозитории с несколькими инструментами храните общий смысл в одном поддерживаемом источнике, а способ подключения проверяйте для каждого клиента. Слова «прочитай соседний файл» и штатный импорт могут работать по-разному. Не обещайте автоматическую загрузку, пока не проверили её в новой сессии.
Как разобрать разросшееся руководство
Пометьте абзацы как постоянное правило, процедура, справка или состояние. Затем выберите одну процедуру и перенесите её целиком, сохранив в руководстве короткий маршрут. Не начинайте с сокращения до заданного числа строк: так легко удалить причину ограничения, оставив только запрет.
Проверьте две задачи: подходящую для вынесенной процедуры и постороннюю. В первой агент должен найти нужный порядок работы, во второй — не читать длинную инструкцию без причины. Сравните результат с прежним поведением на тех же входных данных.
После переноса найдите дубликаты старого текста. Если в одном месте публикация начинается с превью, а в другом сразу с изменения статуса, более короткий файл проблему не решил. Ответственность за выбор действующего правила остаётся у человека, который ведёт процесс.
