Cline Rules: как писать правила проекта для агента в .clinerules

Если вы в каждой новой задаче Cline пишете «используй типы», «не трогай папку legacy» и «после правок запусти тесты», это работа для файла правил. Cline rules хранятся в обычных markdown-файлах и подмешиваются к контексту каждой задачи. Ниже разберём, куда их класть, как формулировать и сколько токенов они съедают.

Сведения о форматах и путях взяты из документации Cline (docs.cline.bot) на 18 октября 2026. Интерфейс расширения меняется, поэтому названия пунктов меню сверяйте со своей версией.

Где лежат правила

Cline читает правила из нескольких мест:

• .clinerules/ или .cline/rules/ в корне проекта: правила, которые можно закоммитить и раздать команде;
• глобальная папка (на macOS и Linux это ~/Documents/Cline/Rules, на Windows Documents\Cline\Rules): личные предпочтения для всех проектов;
• файлы .cursorrules и .windsurfrules, если они уже есть в репозитории;
• AGENTS.md в корне проекта.

Если правила есть и в проекте, и глобально, Cline объединяет их, а при конфликте приоритет у правил проекта. Цифровые префиксы (01-coding.md) необязательны, но удобны для порядка.

Создать файл можно двумя способами: в панели Cline нажать значок весов слева от выбора модели и выбрать создание нового файла правил, либо ввести в чате /newrule и пройти короткий диалог. Ничто не мешает просто создать .clinerules/coding.md руками.

Как формулировать

Документация Cline советует несколько простых вещей, и они действительно работают:

1. Конкретность вместо общих слов. «Пиши понятные имена» бесполезно, «функции и переменные в snake_case, классы в PascalCase» выполнимо.
2. Причина рядом с запретом. «Не правь legacy/, этот код удалим во втором квартале» помогает агенту принять решение в пограничном случае.
3. Ссылка на эталонный файл вместо длинного описания: «обработку ошибок делай как в src/utils/errors.py».
4. Один файл на одну тему: стиль, тесты, архитектура. Тогда любой можно выключить переключателем, не удаляя.
5. Краткость. Правила занимают место в контексте, а устаревшие только путают.

Пример для Python

Файл .clinerules/python.md:

## Python: правила проекта

## Стиль
- Python 3.12, типы обязательны во всех новых функциях.
- Форматирование и линтер: ruff. Не добавляй новые зависимости без вопроса.
- Ошибки обрабатывай по образцу из src/utils/errors.py.

## Запреты
- Не меняй файлы в migrations/ и legacy/ (их генерирует отдельный процесс).
- Не печатай секреты и содержимое .env в ответ или в логи.

## Проверка после правок
1. `ruff check .`
2. `mypy src`
3. `pytest -q`
Если проверка падает, исправь причину, а не отключай проверку.

Команды ruff, mypy и pytest приведены как пример: подставьте те, что реально стоят в вашем проекте.

Пример для TypeScript с условным правилом

Правила можно привязать к путям. В начале файла добавляется YAML-блок paths, и правило включается только тогда, когда в контексте есть подходящие файлы (открытые вкладки, упомянутые в сообщении пути, файлы, которые Cline правит).

Файл .clinerules/frontend.md:

---
paths:
  - "src/components/**"
  - "src/hooks/**"
---
## Правила для React-компонентов

- Только функциональные компоненты и хуки.
- Общую логику выноси в собственные хуки.
- Типы пропсов описывай через `type`, без `any`.
- После правок: `npx tsc --noEmit`, затем `npm test`.

Правило без блока paths активно всегда. Пустой массив paths: [] значит «никогда», и этим удобно временно выключать файл. Документация отдельно советует называть пути в сообщении явно: «обнови src/services/user.ts» срабатывает надёжнее, чем «обнови сервис пользователей».

Memory Bank и skills

В поисковых запросах рядом с правилами часто встречаются cline memory bank и cline skills. Это связанные, но разные вещи.

Memory Bank по документации Cline не отдельная функция, а методика: набор markdown-файлов (projectbrief.md, activeContext.md, progress.md и другие), которые Cline читает в начале задачи, плюс инструкция, лежащая в обычном файле правил. Файлы с описанием проекта и текущим состоянием работ живут вместе с кодом, поэтому новая задача не начинается с нуля.

Skills тоже описываются в markdown (SKILL.md в папке навыка, например .cline/skills/), но, в отличие от правил, загружаются по требованию: в контексте всегда лежит только короткое описание, а полный текст подтягивается, когда запрос подходит. Правила же активны всё время. Поэтому постоянные требования («всегда типы») идут в правила, а редкие длинные инструкции («как выпускать релиз») лучше оформлять навыком.

Сколько стоят правила

Правила входят в контекст задачи, значит оплачиваются как входные токены в каждом запросе агента. Прикинем на примере, цены на 18 октября 2026.

Допустим, файлы правил занимают 1 500 токенов, а Cline делает в задаче 40 запросов. Формула: 1 500 × 40 = 60 000 входных токенов. На claude-sonnet-5-5 (вход $0.4 за 1M) это 60 000 / 1 000 000 × 0,4 = $0.024. На deepseek-v4.1-flash (вход $0.013 за 1M) выходит $0.00078.

Если разросшиеся правила занимают 8 000 токенов: 8 000 × 40 = 320 000 токенов, на claude-sonnet-5-5 это $0.128 за задачу, на deepseek-v4.1-flash $0.00416. В OpenAI-формате для Claude весь вход идёт по цене входа, без скидки за кэш. Суммы небольшие, но на десятках задач в день накапливаются, а главное, лишние правила размывают внимание модели. Условные правила с paths помогают не грузить фронтенд-инструкции, пока вы работаете с бэкендом.

Актуальные цены смотрите через GET https://api.zukko.pro/v1/models или на странице «Модели» в кабинете.

Подключение Cline к Zukko

Правила не зависят от провайдера, но для работы нужна модель. В Cline выберите провайдера OpenAI Compatible, укажите Base URL https://api.zukko.pro/v1, ключ fetch_... и идентификатор модели, например claude-sonnet-5-5. Адрес вводится целиком, вместе с /v1: без него запросы уйдут не туда и вернут 404. Пошаговая настройка описана в документации по расширениям VS Code↗, а общий разбор подключения есть в статье Cline: подключение к Claude и GPT через свой ключ↗. Ключ создаётся в кабинете↗.

Похожий подход к инструкциям описан в статьях про CLAUDE.md↗ и правила Cursor↗.

Частые вопросы

Cline не применяет мои правила, что проверить?

Убедитесь, что файл лежит в .clinerules/ или .cline/rules/ и включён переключателем в панели правил. Для файлов с paths проверьте, что нужные пути есть в контексте: назовите их в сообщении. Если YAML-блок записан с ошибкой, правило, по документации, всё равно активируется, но с видимым сырым содержимым.

Можно ли хранить правила в git?

Да, правила проекта для того и предназначены: закоммитьте .clinerules/, и вся команда получит те же требования. Личные предпочтения держите в глобальной папке.

Сколько правил писать?

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

Работают ли правила с любой моделью?

Правила приходят в модель как текст, поэтому технически работают с любой. Насколько точно конкретная модель их соблюдает, проверьте на своих задачах.

Чтобы попробовать, создайте ключ в кабинете Zukko, подключите его в Cline и начните с одного короткого файла правил.