Перейти к основному содержимому

Rules

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

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

Типы Rules:

  • Глобальные Rules хранятся в папке .explyt в домашнем каталоге и доступны во всех проектах на вашей машине.
  • Локальные Rules хранятся в папке .explyt в каталоге проекта и видны только в этом проекте. Некоторые 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: проверь ожидаемые результаты (значения, взаимодействия, исключения)