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

Пользовательские Workflows и Rules

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

Workflows​

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

Функция Workflows позволяет сохранять повторяющиеся промпты и использовать их вручную, когда это уместно. Workflow — это простой файл Markdown, который вы добавляете к своему промпту через поле ввода. Это позволяет переиспользовать эффективные пайплайны и повышать продуктивность.

Workflow может быть как глобальным, так и локальным:

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

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

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

Чтобы добавить Workflow, начните вводить #workflow в поле ввода — появится подсказка с доступными вариантами.

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

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

  • Попросите агента задать уместные вопросы перед переходом к реализации
  • Опишите, как агенту собирать контекст для запроса
  • Укажите ожидаемые шаги, которые агент должен выполнить
  • Вы можете прикреплять файлы к запросу и ссылаться на них в рабочем процессе
  • Делайте рабочие процессы переиспользуемыми с помощью плейсхолдеров (например: {goal}, {files}) и подставляйте значения при запуске

Примеры​

Workflow, который просит агента найти все TODO в прикреплённых файлах и реализовать их.

Цель: Найти и реализовать TODO в прикреплённых файлах (и в текущем открытом файле, если уместно).

Область:
- Работай только с прикреплёнными файлами и текущим открытым файлом. Если нужны более широкие изменения — спроси сначала.

Шаги:
1) Разбери предоставленные файлы и перечисли все TODO с путями к файлам и номерами строк.
2) Сгруппируй TODO по файлам/подсистемам и выяви зависимости или порядок выполнения.
3) Задай уточняющие вопросы по неоднозначным TODO (намерения автора, ограничения, критерии приёмки).
4) Предложи минимальный и безопасный план реализации со списком правок по файлам и запроси одобрение.
5) Реализуй TODO, сохраняя изменения маленькими и сфокусированными. Избегай несвязанных рефакторингов.
6) После правок кратко суммируй изменения (какие файлы затронуты, ключевые решения, возможные последующие шаги).

Вывод:
- Инвентарь TODO: таблица/пункты с file:line и кратким описанием.
- Вопросы (если есть): пункты.
- План (ожидает одобрения): пронумерованные шаги.
- Правки: выполни после одобрения и предоставь краткое резюме.

Workflow, который просит агента добавить комментарии в текущий открытый файл.

Цель: Улучшить читаемость кода, добавив краткие и точные комментарии без изменения поведения.

Область:
- Изменяй только текущий открытый файл, если пользователь не одобрит изменения в других местах.

Шаги:
1) Прочти весь файл, чтобы понять назначение, публичный API и сложную логику.
2) Составь план комментирования: комментарий к файлу/заголовку (если отсутствует), doc‑комментарии к функциям/классам и построчные комментарии к нетривиальной логике/инвариантам.
3) Уточни предпочтения по стилю, если неясно; иначе следуй существующим соглашениям проекта.
4) Добавь комментарии, делая их точными и избегая повторения очевидного кода.
5) Дай краткое резюме: что было прокомментировано и зачем.

Ограничения:
- Не меняй логику программы и форматирование дальше необходимого для комментариев.
- Держи комментарии краткими (обычно 1–3 строки) и выдерживай единый тон.

Вывод:
- План комментирования (кратко)
- Сводка внесённых комментариев с обоснованием