Как написать правила Cline и проверить их загрузку

Начните с двух проверяемых правил

Добавьте в каталог .clinerules/ репозитория условия выполнения задачи и правило проверки и передачи результата. Включите оба файла, начните новую задачу и изучите план, diff и результаты тестов. Добавляйте условия путей после того, как базовая настройка заработает в вашем клиенте.

В статье есть полные примеры файлов и процедура приёмки. Мы проверили официальную документацию и публичный снимок исходного кода 23 октября 2026 года. Мы не запускали Cline на репозитории и не измеряли, улучшают ли эти инструкции поведение модели.

Правила добавляют инструкции в контекст модели. Они не создают границу разрешений или защищённую песочницу. Отдельно настройте подтверждения инструментов и доступ к репозиторию. Эти средства описаны в документации Auto Approve.

Выберите расположение для своего клиента

Руководство по конфигурации описывает правила проекта в .cline/rules/ и в старом формате .clinerules/. Там также указаны корневой AGENTS.md и глобальный ~/.agents/AGENTS.md. Примеры ниже используют только .clinerules/. Не копируйте одинаковые инструкции в оба каталога.

Текущий загрузчик также поддерживает старый файл .clinerules без расширения. Файл и каталог не могут занимать один путь. Перед преобразованием сохраните исходный текст, затем перенесите его в Markdown-файл нового каталога. Размещайте правила непосредственно в каталоге. Загрузчик читает файлы .md, .markdown и .txt, не обходя вложенные папки правил.

Для личных настроек общий механизм поиска путей проверяет ~/.cline/rules, ~/Cline/Rules и расположение Cline Rules в Documents. В Windows он также может искать в Documents, перенаправленном через OneDrive. Используйте расположение, которое показывает ваш клиент.

Документация правил указывает, что при конфликте правила проекта имеют приоритет над глобальными. Всё равно устраните противоречия. Числовые префиксы упорядочивают файлы. Они не создают иерархию разрешений и не доказывают, какую конфликтующую инструкцию выполнит модель.

Проверяйте клиенты отдельно:

• В редакторе откройте Rules значком весов и проверьте переключатель каждого файла.
• CLI использует документированные каталоги правил, но имеет собственную конфигурацию и управление подтверждениями. Проверьте cline config. Обзор CLI сейчас указывает, что глобальное автоматическое подтверждение включено по умолчанию. Проверьте настройку перед испытанием.
• Cloud Agents сейчас не загружает правила, skills, серверы MCP и коннекторы. Коммит с правилом не активирует его в облачной сессии.

Создайте условия задачи и правило передачи результата

Откройте корень репозитория в редакторе. Если .clinerules ещё не существует, создайте каталог. Сохраните каждый блок в указанный файл. Примеры предполагают проект JavaScript или TypeScript с package.json. Адаптируйте допустимые пути, пакетный менеджер и проверки к реальному репозиторию.

Сохраните .clinerules/01-task-contract.md:

# Условия задачи

Перед предложением изменений:
- Прочитайте README.md и package.json. Определите пакетный менеджер по lockfile.
- Изучите целевые файлы и соседние тесты. Не читайте файлы .env или учётные секреты.
- Укажите требуемое поведение, планируемые файлы изменений и нужные проверки.
- Если запрос не задаёт границы изменений, предложите их до редактирования.

Во время реализации:
- Меняйте только файлы, нужные для согласованной задачи. Сохраняйте посторонние изменения пользователя.
- До изменения зависимости или lockfile объясните необходимость.
- Если нужное изменение выходит за согласованные границы, остановитесь и объясните причину.

Сохраните .clinerules/02-checks-and-delivery.md:

# Проверки и передача результата

До передачи результата:
- Найдите команды проверок в package.json и README проекта.
- При изменении поведения добавьте или обновите целевой тест, если тестовая инфраструктура уже существует.
- Запустите нужный тест и настроенные проверки типов или lint для изменённого кода.
- Если необходимая проверка отсутствует или не запускается, сообщите об ограничении.

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

Правила требуют найти реальные команды. Они не предполагают наличие lint, typecheck или test в каждом проекте. Например, npm-проект может использовать команды ниже. Последние две требуют соответствующих скриптов и тестового инструмента, принимающего путь файла. Замените их реальными командами репозитория.

git status --short
npm run
git diff --check
npm run typecheck
npm test -- src/utils/parse-label.test.ts

Оставьте эти требования безусловными. Правило тестирования, загружаемое только для *.test.ts, может пропустить задачу, которая меняет код без создания теста.

Подтвердите загрузку перед оценкой поведения

В панели Rules проверьте, что оба файла видны в разделе проекта и включены. Затем изучите их изменения через Git. Текущая реализация расширения сохраняет переключатели в YAML-метаданных disabled. Отключение правила может изменить отслеживаемый файл. Проверьте diff, прежде чем отправлять временное личное решение команде.

Начните новый разговор в Plan с ограниченной задачей. Замените пути существующей функцией и тестом вашего проекта:

Только план. В src/utils/parse-label.ts измените parseLabel так, чтобы
функция отклоняла пустой ввод и ввод только из пробелов,
сохраняя поведение для корректных значений.
Границы изменений: этот файл и src/utils/parse-label.test.ts.
До редактирования укажите существующий код и команду теста.

Проверьте, что ответ определяет два разрешённых файла, существующую реализацию и нужные проверки. Заявления "я загрузил правила" недостаточно. Сопоставьте план с изученными файлами. Если план подходит, переключитесь в Act с выбранными подтверждениями и разрешите попытку изменения.

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

Добавьте условное правило и проверьте оба случая

Руководство по правилам определяет paths как массив glob-шаблонов относительно корня проекта. Любой совпавший путь может активировать правило. Контекст могут задавать вкладки редактора, пути в запросе и файлы задачи. Совпадение не отменяет выключенный переключатель.

Сохраните необязательный файл .clinerules/20-typescript.md:

---
paths:
  - "src/**/*.ts"
  - "src/**/*.tsx"
---

# Изменения TypeScript

Для задачи, меняющей файл .ts или .tsx внутри src:
- Во время приёмки правил включите TS-RULE-ACTIVE один раз в начальный план.
- Изучите соседние типы перед добавлением нового публичного типа.
- Сохраняйте экспортируемые сигнатуры, если задача не требует изменения API.
- Объясняйте каждое новое any или комментарий подавления ошибки TypeScript.

Проверяйте условия путей в установленном клиенте. Текущий модуль отображения правил SDK выбирает включённые правила, не оценивая paths в этой функции. Изучение этого кода не доказывает одинаковую работу условий в редакторе, Desktop и CLI. Храните обязательные ограничения в безусловных файлах, пока не проверите свой клиент.

1. Начните новую задачу в редакторе и укажите реальный совпадающий файл вне вставленного блока кода. Найдите описанное в документации уведомление об условном правиле и временный маркер TS-RULE-ACTIVE.
2. Начните другую новую задачу о Markdown-файле вне src. Сначала закройте совпадающие вкладки TypeScript. Проверьте, что правило не активируется.
3. Отключите необязательное правило и повторите задачу с совпадением. Проверьте, что правило остаётся неактивным. Затем восстановите нужное состояние переключателя.
4. После приёмки удалите требование временного маркера, оставив полезные соглашения по коду.

Маркер проверяет передачу инструкции, а не качество кода. Оценивайте соблюдение по реальному diff и проверкам. Модель может проигнорировать или неверно понять загруженное правило.

Найдите причины отсутствующих или неожиданных правил

Проверьте причины по порядку, прежде чем расширять набор:

1. Уточните клиент и корень рабочей области. Облачная сессия не загружает эти файлы. Открытая как проект подпапка может изменить поиск корневых правил.
2. Проверьте точный путь и переключатель. Размещайте непустой Markdown непосредственно в .clinerules/ или .cline/rules/. Ищите disabled: true и противоречащие копии в глобальных правилах или AGENTS.md.
3. Проверьте разделители и отступы YAML. Используйте массив строк в кавычках из примера. Документация описывает некорректный YAML как fail-open, но текущий парсер SDK выдаёт ошибку. Исправьте синтаксис, не полагаясь на резервное поведение.
4. Проверьте контекст и glob. src/*.ts не охватывает вложенные каталоги. Начните новую задачу, укажите точный относительный путь и закройте посторонние совпадающие вкладки. Документированное поведение paths: [] означает отсутствие совпадений. Не используйте пустой массив для постоянно действующего правила.
5. Разделяйте загрузку и соблюдение. Если видимое правило загружено, но патч его нарушает, сократите инструкцию, устраните конфликты и повторите небольшую приёмочную задачу. Запишите версию клиента, прежде чем делать вывод о дефекте Cline в целом.

Ведите отдельную запись для каждой попытки:

Запись	Что сохранить
Среда	Клиент и версия, коммит репозитория, провайдер и точная модель
Состояние правил	Файлы, коммит или diff правил, переключатели, совпадающий путь
Подтверждение загрузки	Панель Rules, условное уведомление при наличии, результат маркера
Подтверждение задачи	Запрос, предложенные границы, итоговый diff, посторонние изменения
Приёмка	Точные команды и результаты, ручные исправления, оставшиеся ошибки

Поддерживайте правила как проверяемые файлы проекта

Коммитьте общие правила вместе с кодом, который они описывают. Назначайте проверяющего для изменений правил и добавляйте небольшую приёмочную задачу в описание. Когда меняется скрипт, каталог или соглашение, обновляйте правило в том же pull request. Личные настройки храните глобально, а учётные секреты исключите из всех общих правил.

Коллекция "awesome .clinerules" может дать идеи, но проверяйте каждую инструкцию перед импортом. Удаляйте ссылки на отсутствующие файлы, неподдерживаемые команды, широкие требования автоматического подтверждения и противоречия. Небольшой набор проверенных инструкций проще рецензировать.

При переносе старых правил Roo учитывайте официальное объявление. Расширение, Cloud и Router закрылись 15 мая 2026 года. Перепишите намерение для Cline и повторите приёмку. Переименование старого файла правил Roo не переносит ограничения режимов, разрешения и облачные сервисы. Наше руководство по переходу с Roo на Cline описывает миграцию. Для выбора поддерживаемого клиента прочитайте сравнение Kilo Code и Cline.