Правила (Rules)

Что такое функция Rules?

Функция Rules позволяет гарантировать, что агент Veai следует вашим инструкциям в конкретных контекстах. Rule — это фрагмент Markdown, который добавляется к системному промпту. Хорошо сформулированные Rules могут значительно улучшить ваш опыт работы с агентом Veai.

Типы Rules:

• Global — личное правило для нескольких несвязанных проектов. Например, используйте его, чтобы во всех проектах агент отвечал в одном формате. При создании Rule включите Create as global rule (available in all projects), укажите имя файла и нажмите OK.
• Project — правило для соглашений одного репозитория. Например, используйте его, чтобы вся команда соблюдала принятый в проекте стиль тестов. При создании Rule оставьте Create as global rule выключенным, укажите имя файла и нажмите OK. Файл проектного Rule можно закоммитить в VCS и передать коллегам.

У Rule также есть glob‑шаблон, который задаёт область применения правила. Внутренне содержимое Rule добавляется к системному промпту, когда текущий открытый файл соответствует этому glob‑шаблону. Glob‑шаблон указывается в верхней части файла Rule:

---
filePattern: "**/*"
---
Содержимое правила размещайте здесь...

Когда передавать правило агенту

Поле strictness во frontmatter задаёт целевой момент передачи правила:

---
filePattern: "**/*"
strictness: user-message
---
Содержимое правила размещайте здесь...

Доступны три значения:

1. system — для стабильной базовой инструкции, которую достаточно передать один раз. Например, так можно задать язык ответов или общий формат результата без повторного расхода токенов. Укажите strictness: system или не добавляйте strictness: это значение используется по умолчанию;
2. user-message — для инструкции, которую важно напоминать перед каждым новым запросом в длинном диалоге. Укажите strictness: user-message во frontmatter;
3. tool-call — для требования, которое агент должен учитывать после каждого действия с инструментами. Укажите strictness: tool-call во frontmatter.

Чем чаще Veai повторяет правило, тем больше токенов или минут расходуется.

Чтобы создать Rule, выполните шаги:

• Откройте новый чат.
• Откройте диалог создания правила.
• Введите имя файла, выберите Project или Global и нажмите OK.
• В открытом файле укажите шаблон файлов и добавьте Markdown‑содержимое Rule.

Временно выключить Rule

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

Удалить Rule

Удаляйте Rule, когда инструкция устарела и больше не должна использоваться. Откройте список Rules, нажмите кнопку удаления рядом с файлом и подтвердите действие. Veai удалит сам файл Rule; восстановить его через переключатель уже нельзя.

Рекомендации

Несколько советов, как повысить эффективность использования Rules:

• задавайте область, в которой правило должно применяться
• инструктируйте агента о ожидаемых шагах, которых он должен придерживаться при выполнении ваших запросов
• укажите, чего агенту делать не следует (например, редактировать запрещённые файлы)
• определяйте желаемый формат вывода (например: план, предлагаемые изменения, краткое резюме), чтобы сделать результат предсказуемым

Примеры

Идеи для ваших Rules:

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

---
filePattern: "**/*"
---

Цель: максимально прояснить задачу до начала реализации.

Когда срабатывает: когда пользователь просит отредактировать/рефакторить/написать код.

Инструкции:
- сначала внимательно прочитай запрос пользователя и текущий открытый файл.
- задай сфокусированные уточняющие вопросы до любой реализации. Стремись к минимум 5 вопросам, если только задача не тривиальна; если вопросов меньше, объясни почему.
- покрой темы: объём работ, целевые файлы/модули, ограничения, критерии приёмки, риски, окружение/инструменты и ожидаемый формат результата.
- сгруппируй вопросы в одном сообщении и дождись ответов пользователя перед любыми изменениями.

Ограничения:
- не редактируй файлы и не запускай команды без явного одобрения пользователя
- не додумывай отсутствующую информацию; если что‑то непонятно — спроси

Формат вывода:
- вопросы: маркированный список конкретных вопросов
- предположения (если есть): явно и кратко
- черновой план (ожидает одобрения): 3–7 лаконичных шагов

Правило, требующее тщательно собрать контекст, найти использования и задать пользователю дополнительные вопросы.

---
filePattern: "**/*"
---

Цель: тщательно понять задачу и область влияния до редактирования.

Когда срабатывает: когда пользователь просит работать с существующим кодом.

Инструкции:
- определи ключевые сущности (классы, функции, файлы, названия фич) из запроса и открытого файла.
- найди в проекте определения и использования этих сущностей; посмотри соседние и входные точки.
- суммируй релевантный контекст: ответственности, зависимости, инварианты и побочные эффекты.
- если остаются неоднозначности, задай целевые уточняющие вопросы.

Ограничения:
- избегай предположительных изменений; не редактируй до представления плана и получения одобрения.
- предпочитай изменения с минимальным воздействием и явно указывай потенциальные риски.

Формат вывода:
- сводка контекста: 5–10 пунктов с находками и путями к файлам.
- анализ влияния: какие файлы/компоненты затрагиваются и почему.
- открытые вопросы: пункты.
- план (ожидает одобрения): краткий пошаговый.

Правило, требующее предоставить план и дождаться одобрения пользователя перед началом реализации.

---
filePattern: "**/*"
---

Цель: представить понятный план реализации и получить явное одобрение перед изменениями.

Когда срабатывает: когда пользователь просит реализовать новый функционал.

Инструкции:
- предложи минимальный и безопасный план с пронумерованными шагами, ожидаемыми результатами и списком редактируемых файлов.
- упомяни альтернативы (если есть) с краткими компромиссами.
- запроси явное одобрение (например, «Одобряю план») и не продолжай без него.

Ограничения:
- держи план кратким (5–10 шагов) и, при необходимости, добавь идею отката.
- не трогай несвязанные файлы.

Формат вывода:
- план: пронумерованные шаги.
- файлы к изменению: список с путями и обоснованием.
- риски/проверки: короткие пункты.
- запрос одобрения.

Правило, требующее писать тесты в формате GIVEN-WHEN-THEN. Обратите внимание на параметр filePattern.

---
filePattern: "**/*Test.kt"
---

Цель: обеспечить следование структуре GIVEN–WHEN–THEN (Arrange–Act–Assert).

Инструкции:
- давай тестам выразительные имена (например, `shouldCalculateTotal_whenCartHasDiscounts`).
- структурируй каждый тест на чётко отделённые секции комментариями: `GIVEN`, `WHEN`, `THEN`.
- держи тесты детерминированными; избегай случайностей времени/сети и избыточного мокинга.
- покрывай «счастливый путь», крайние случаи и ошибки, когда применимо.
- не меняй продакшн‑код только ради соответствия тестам без подтверждения пользователя.

Пример скелета внутри теста:
- GIVEN: подготовь входные данные, коллабораторов и состояние
- WHEN: вызови тестируемую единицу
- THEN: проверь ожидаемые результаты (значения, взаимодействия, исключения)