Rules

Модель ничего не помнит между запросами — каждый диалог начинается с чистого листа. Rules решают эту проблему: это markdown-файлы с инструкциями, которые агент подмешивает в контекст автоматически, без того чтобы вы каждый раз объясняли одно и то же заново.

Пример: если вы один раз напишете правило «в этом проекте используем snake_case для колонок БД и функциональные компоненты в React», агент будет следовать этому на каждой сессии — пока файл лежит на месте.

Где хранятся правила #

WorkAI различает два уровня:

• Персональные правила — ~/.workai/rules/*.md. Применяются во всех ваших проектах.
• Проектные правила — .workai/rules/*.md внутри репозитория. Действуют только в этом проекте и, если вы кладёте их в git, доступны всей команде.

Файл README.md в этих каталогах правилом не считается — его можно использовать для пояснений к набору правил.

Кроме собственного формата, WorkAI распознаёт файлы правил из других экосистем — переносить их вручную не нужно:

Экосистема	Что читаем
AGENTS.md	AGENTS.md в корне проекта; отдельно — вложенные **/AGENTS.md
Claude	CLAUDE.md, CLAUDE.local.md, .claude/CLAUDE.md, ~/.claude/CLAUDE.md, каталоги .claude/rules и ~/.claude/rules
Cursor	каталог .cursor/rules — и .mdc, и обычные .md
GitHub Copilot	.github/instructions, ~/.copilot/instructions, .github/copilot-instructions.md, ~/.copilot/copilot-instructions.md

Каждый источник включается и выключается отдельно — в Settings → AI rules, блок Compatibility. Там же видно, сколько файлов найдено по каждому источнику. Свой каталог правил тоже можно добавить: путь, дописанный в настройку chat.instructionsFilesLocations, появится в списке как отдельный источник.

Cursor обычно кладёт в .cursor/rules файлы .mdc и обычные .md там игнорирует. Мы читаем оба расширения: люди регулярно кладут туда .md руками, и молча их не видеть — ловушка.

Как правило активируется #

У правила есть три режима работы:

• Всегда — правило попадает в контекст каждого запроса. Это applyTo: '**' (а также **/* и *), плюс AGENTS.md, CLAUDE.md и copilot-instructions.md, которые подключаются всегда по своей природе.
• По glob — правило привязано к паттерну applyTo (например, src/**/*.tsx) и подключается, когда подходящий файл оказывается в контексте запроса.
• По решению модели — паттерна нет, есть только description. Такое правило не подставляется автоматически: агент видит его путь и описание в списке доступных правил и сам решает, прочитать ли файл. Поэтому от качества описания напрямую зависит, вспомнит ли агент о правиле в нужный момент.

Режим каждого найденного правила подписан в списке в Settings → AI rules — применяется всегда, применяется к перечисленным файлам или подключается по решению модели.

Если в applyTo перечислено несколько паттернов через запятую, они работают как «или»: **, src/** — это по-прежнему «всегда».

Вложенные AGENTS.md #

Если в поддиректориях проекта лежат свои AGENTS.md, WorkAI умеет находить их по всему воркспейсу — это отдельный источник, по умолчанию выключенный (настройка chat.useNestedAgentsMdFiles, переключатель в блоке Compatibility). Когда он включён, вложенные AGENTS.md не подставляются в каждый запрос целиком, а перечисляются агенту вместе с именем папки, к которой относятся, — и агент читает нужный, когда работает в этой части репозитория. Корневой AGENTS.md, в отличие от них, подключается всегда.

Формат файла #

Правило — обычный markdown-файл. Например:

---
description: Применять при правке React-компонентов
applyTo: "src/components/**/*.tsx"
---

- Именованные экспорты, не default
- Стили — в соседнем CSS-модуле, не инлайном
- Компонент длиннее 200 строк — разбивать на подкомпоненты

Открывающий --- должен быть самой первой строкой файла, и обе строки --- начинаются с самого начала строки, без отступа — иначе заголовок не распознаётся и не прочитаются ни description, ни applyTo.

Для always-правила задайте applyTo: '**'. В каталогах .workai/rules и .claude/rules файл без frontmatter вообще тоже применяется всегда — обычный .md там не мёртвый.

Поля Cursor понимаются как есть, переписывать чужие правила не нужно:

• globs — синоним applyTo (принимается и строкой, и списком);
• alwaysApply: true — то же, что applyTo: '**', и оно сильнее globs.

Родным полем остаётся applyTo — в новых файлах лучше писать его.

Как создать правило #

Быстрее всего — команда /create-rule в чате: опишите требование словами, и файл создаст сам агент. Он посмотрит историю диалога (в короткой фразе конкретики обычно меньше, чем в предшествующем обсуждении), проверит, нет ли уже правила на эту тему — и тогда дополнит существующий файл вместо второго рядом, — выберет режим применения и напишет тело как рабочую инструкцию, а не пересказ вашей фразы. Имя файла будет коротким латинским (address-by-weekday.md), а не транслитом. В конце агент коротко скажет, что получилось и какое место в правиле самое спорное.

То же самое доступно из настроек: Settings → AI rules → Project rules → Create открывает чат с уже набранной командой.

Правила можно писать и руками — как обычные markdown-файлы в .workai/rules/ или ~/.workai/rules/. Список всех найденных правил с поиском, редактированием и удалением открывает команда /instructions.

Для коротких личных предпочтений — «отвечай по-русски», «без лишних предисловий» — есть более быстрый путь: кнопка Add в секции Personal rules. Она сохраняет строку прямо в ваши настройки, без файла; такие правила применяются во всех проектах и всегда. Всё, что должно жить в репозитории и разделяться с командой, лучше писать файлом.

Как выключить правило, не удаляя его #

В Settings → AI rules у каждого правила есть переключатель. Выключенное правило остаётся в списке (приглушённым, чтобы не спутать с удалённым), но не уходит агенту — ни содержимым, ни упоминанием в списке доступных. Включить обратно можно там же.

Это работает и для AGENTS.md с CLAUDE.md: они подключаются к каждому запросу, и возможность их выключить нужна тем более.

Целый источник выключается одним переключателем в блоке Compatibility — например, если в проекте лежат правила Copilot, которые вам не нужны.

Сколько правил можно подключить #

Правила занимают место в контексте, поэтому есть потолок: до 64 файлов за запрос, около 128 тысяч символов на одно правило и около 512 тысяч символов на все правила вместе.

Правило, которое не влезло в свой потолок, не выбрасывается молча — оно обрезается, и в тексте остаётся пометка, что показаны только первые символы файла. А вот правила сверх 64 файлов или сверх общего потолка в запрос уже не попадают вовсе.

Практический вывод: applyTo: '**' стоит контекста в каждом запросе. Ставьте его для правил про стиль общения и процесс, а правила про конкретные файлы привязывайте глобом.

Как правила доходят до модели #

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

Кроме того, все найденные правила перечисляются описью: путь, описание и applyTo, без содержимого. Отсюда и берётся возможность агента самостоятельно дочитать правило, которое по своему режиму не подставилось.

Правило по ссылке #

Правило можно передать ссылкой вида workai://share/rule?name=<имя>&text=<текст>. По такой ссылке WorkAI не записывает ничего сразу: сначала показывается диалог с именем будущего файла и его полным текстом целиком, и только после подтверждения файл сохраняется в .workai/rules/<имя>.md и открывается в редакторе. Существующий файл с тем же именем не перезаписывается.

Имя — латиница в нижнем регистре и цифры, слова через дефис, до 64 символов; длина всей ссылки ограничена 8000 символов. Ссылка сработает, только когда в клиенте открыта папка или воркспейс, — иначе правилу некуда лечь.

Хорошие практики #

• Держите правило сфокусированным на одной теме — если оно разрастается, разбейте на несколько файлов.
• Пишите description в форме «применять, когда …» и кладите внутрь слова, по которым правило будут искать: для правил в режиме «по решению модели» описание — единственная поверхность обнаружения.
• Пишите конкретно: не «следуй хорошим практикам», а «используй zod для валидации всех API-эндпоинтов».
• Ссылайтесь на документацию проекта, а не копируйте её в правило — копия устареет.
• Не дублируйте содержимое стайл-гайдов — для этого есть линтер, и общие конвенции языка агент знает и так.
• Держите файл компактным, чтобы он читался целиком.
• Добавляйте правило, когда замечаете, что агент раз за разом ошибается в одном и том же месте, а не заранее «про запас».
• Коммитьте проектные правила в git — тогда ими пользуется вся команда, а не только вы.

Почему правило не применяется #

Частые причины, по порядку проверки:

1. Режим. Если у правила нет ни applyTo, ни description, подключать его агенту не по чему. Посмотрите подпись режима в списке правил.
2. Glob не совпал. Правило с applyTo подключается, когда подходящий файл попал в контекст запроса. Если вы обсуждаете задачу «вообще», а файлов в контексте нет, правило про **/*.py не сработает.
3. Правило или источник выключены. Проверьте переключатели в Settings → AI rules, включая блок Compatibility.
4. Сломанный frontmatter. Отступ перед --- — и заголовок не читается: пропадают и description, и applyTo. В редакторе такой файл подсвечивается диагностикой.
5. Вложенные AGENTS.md по умолчанию выключены — это отдельный источник.

Rules и Skills — в чём разница #

Оба механизма расширяют возможности агента, но по-разному:

• Rules — это требования, которые вы задаёте сами; персональные применяются везде, проектные — только в текущем проекте.
• Skills — это переиспользуемая процедура для конкретной задачи; в отличие от правила, подгружается только когда релевантна.

То есть правило — это постоянный контекст («так у нас принято»), а skill — это инструкция «как делать X», которую агент достаёт с полки только когда действительно занимается X. Подробнее о них — на соседней странице документации про Skills.