Рядом существует альтернатива в виде обычного markdown-файла контракта. Он проще: не требует особого формата и читается человеком как обычная документация. Поддерживается вложенность - инструкция ближе к рабочему файлу получает более узкую область действия. Это удобная модель для монорепозитория: общие инварианты сверху, специфика пакета рядом с его кодом. Командная строка дополнительно читает корневой файл соглашений другого агентного инструмента, так что один репозиторий может обслуживать несколько инструментов без дублирования смысла.

Командные правила стоят особняком, потому что управляются централизованно и имеют приоритет над проектными и пользовательскими. Принудительное правило нельзя отключить локально, и в этом его смысл: организация фиксирует обязательный минимум. Обратная сторона - такие правила надо писать особенно аккуратно: то, что нельзя отключить, будет мешать в каждом проекте, где оно не к месту. Хорошее командное правило описывает инвариант, одинаково верный для всех репозиториев, а не привычку одной команды.

Правило, которое не срабатывает, диагностируют по порядку, а не перебором. Сначала формат: лежит ли файл в нужном каталоге и с нужным расширением, есть ли заголовок. Потом режим: правило по маскам не включится, если открытый файл под маску не подходит, а правило по описанию не включится, если описание говорит о способности, а не о поводе. Формулировка соглашения о вызовах для сервисов бэкенда даёт агенту повод, формулировка полезные советы - нет. И только потом стоит подозревать содержание: слишком длинное правило теряется среди остального контекста, даже когда подключилось.

Самое важное ограничение этой части настройки: правила направляют, но не блокируют. Фраза никогда не читай секреты в правиле не заменяет ни файла исключений, ни ограничений файловой системы, ни hook. Кроме того, область действия у них разная: пользовательские правила применяются к разговору с агентом, но не к точечной правке, а подсказками в редакторе они не управляют вовсе. Ожидать от текста гарантии - самая частая ошибка здесь, и она тем опаснее, что правило выглядит выполненным ровно до того случая, когда его нарушение чего-то стоит.

Отсюда практическая манера писать правила. Одно правило - одно требование, сформулированное так, чтобы по коду было видно, выполнено оно или нет. Проверяй ввод на границе сервиса проверяемо, пиши качественный код - нет. Правило живёт рядом с кодом, меняется вместе с ним и проходит ревью как код: если требование устарело, его удаляют, а не оставляют на всякий случай. Набор из десятка коротких проверяемых правил работает лучше, чем один длинный документ о том, как у нас принято.

Типичные провалы предсказуемы. Положить обычный markdown в каталог правил и не понять, почему он не действует. Сделать все правила постоянными и оплачивать их контекстом в каждой задаче. Написать описание про способность вместо повода и получить правило, которое агент не выбирает. Записать в правило требование безопасности вместо детерминированного механизма. И ждать, что пользовательское правило подействует на подсказки в редакторе.