Rules

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

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

Типы Rules:

• глобальные Rules хранятся в папке .veai в домашнем каталоге и доступны во всех проектах на вашей машине.
• Локальные Rules хранятся в папке .veai в каталоге проекта и видны только в этом проекте. Некоторые Rules проекта можно коммитить в VCS, чтобы делиться эффективными правилами с коллегами.

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

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

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

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

Rules можно вручную включать и выключать в интерфейсе чата.

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

Несколько советов, как повысить эффективность использования 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: проверь ожидаемые результаты (значения, взаимодействия, исключения)