Skip to main content

User-defined Workflows and Rules

Rules​

What is the Rules feature?​

The Rules feature allows you to ensure the Explyt Agent follows your instructions for specific contexts. A rule is a Markdown snippet that is added to the system prompt. Well-defined rules can significantly improve your experience with the Explyt Agent.

A rule can be of two types:

  • Global rules are stored in .explyt folder in your home directory and shared across all projects on your local machine.
  • Local rules are stored in .explyt folder in your project directory and visible only in that project. You can commit some of the project rules via VCS if you want to share effective rules with your colleagues.

A rule also has a glob pattern to specify the scope when the rule should be applied. Internally, the rule's content is added to the system prompt when your currently open file matches the glob pattern. The glob pattern is located at the top of the rule:

---
filePattern: "**/*"
---
The rule content goes here...

To create a rule, follow these steps:

  • Open a new chat
  • Open the rule creation dialog
  • Enter a filename, choose whether the rule is local or global, and press OK
  • In the opened file, specify the file pattern and put the Markdown content of your rule

Rules can be enabled or disabled manually via the chat UI.

Best practices​

Here are some tips for improving your experience when using rules:

  • Specify a scope for when the rule should be applied
  • Instruct the agent on the expected steps the agent should follow when completing your queries
  • Instruct the agent what it should not do (for example, editing forbidden files)
  • Define the desired output format (for example: plan, proposed edits, summary) to make results predictable
  • Ask agent

Examples​

Here are some ideas for your rules:

Rule that requires the agent to ask you as many questions as possible before moving to the implementation step.

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

Goal: Maximize clarification before implementation.

When triggered: When user asks to edit/refactor/write new code.

Instructions:
- First, carefully read the user's request and the currently open file.
- Ask focused clarifying questions before any implementation. Aim for at least 5 questions unless the request is trivially scoped; if fewer questions suffice, explain why.
- Cover scope, target files/modules, constraints, acceptance criteria, risks, environment/tooling, and expected output format.
- Group questions in a single message and wait for the user's answers before making any changes.

Constraints:
- Do not edit files or run commands until the user explicitly approves proceeding.
- Do not assume missing information; if something is unclear, ask.

Output format:
- Questions: a bullet list of specific questions.
- Assumptions (if any): explicitly stated and limited.
- Draft plan (pending approval): 3–7 concise steps.

Rule that requires the agent to gather context thoroughly, search for usages, and ask the user for more information.

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

Goal: Thoroughly understand the request and its impact area before editing.

When triggered: When user asks to work with existing code.

Instructions:
- Identify key entities (classes, functions, files, feature names) from the request and the open file.
- Search the project for definitions and usages of these entities; review adjacent and entry-point files.
- Summarize the relevant context: responsibilities, dependencies, invariants, and side effects.
- If any ambiguity remains, ask the user targeted follow-up questions.

Constraints:
- Avoid speculative changes; do not edit until you present a plan and get approval.
- Prefer minimal-impact changes and clearly call out potential risks.

Output format:
- Context Summary: 5–10 bullets with findings and links/paths to files.
- Impact Analysis: which files/components are affected and why.
- Open Questions: bullets.
- Plan (pending approval): concise, step-by-step.

Rule that requires the agent to provide a plan and wait for the user's approval before moving to the implementation step.

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

Goal: Present a clear implementation plan and obtain explicit approval before changes.

When triggered: When user asks to implement a new functionality.

Instructions:
- Propose a minimal, safe plan with numbered steps, expected outputs, and the list of files to be edited.
- Mention alternatives (if any) with brief trade-offs.
- Request explicit approval (e.g., "Approve plan"), and do not proceed without it.

Constraints:
- Keep the plan concise (5–10 steps) and include a rollback/backout idea if relevant.
- Do not touch unrelated files.

Output format:
- Plan: numbered steps.
- Files to change: bullet list with paths and rationale.
- Risks/Checks: short bullets.
- Approval prompt.

Rule that requires the agent to write tests in the GIVEN-WHEN-THEN format. Note the filePattern option.

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

Goal: Ensure tests follow the GIVEN–WHEN–THEN (Arrange–Act–Assert) structure.

Instructions:
- Name tests descriptively (e.g., `shouldCalculateTotal_whenCartHasDiscounts`).
- Structure each test into clearly separated sections using comments: `GIVEN`, `WHEN`, `THEN`.
- Keep tests deterministic; avoid time/network randomness and excessive mocking.
- Cover happy-path, edge cases, and error scenarios where applicable.
- Do not modify production code solely to fit tests without user confirmation.

Example skeleton inside a test:
- GIVEN: set up inputs, collaborators, and state
- WHEN: invoke the unit under test
- THEN: assert expected outcomes (values, interactions, exceptions)

Workflows​

What is the Workflows feature?​

The Workflows feature allows you to save repeated prompts and manually use them when appropriate. A workflow is a simple Markdown file that you add to your prompt via the input area. This allows you to reuse effective pipelines and boost your productivity.

A workflow can also be either global or local:

  • Global workflows are stored in .explyt folder in your home directory and shared across all projects on your local machine.
  • Local workflows are stored in .explyt folder in your project directory and visible only in that project. You can commit some of the project workflows via VCS if you want to share effective workflows with your colleagues.

To create a workflow, follow these steps:

  • Open a new chat
  • Open the workflow creation dialog
  • Enter a filename, choose whether the workflow is local or global, and press OK
  • In the opened file, put the Markdown content of your workflow

To add a workflow, simply start typing #workflow in the input area and a hint with available workflows will appear.

Best practices​

Here are some tips for improving your experience when using workflows:

  • Instruct the agent to ask you appropriate questions before moving to the implementation
  • Instruct the agent on how to gather context for the request
  • Specify the expected steps the agent should take
  • You can attach files to your request and reference them in your workflow
  • Keep workflows reusable by using placeholders (for example: {goal}, {files}) and filling them when invoking

Examples​

Workflow that asks the agent to find all TODOs in the attached files and implement them.

Goal: Find and implement TODOs in the attached files (and the currently open file, if relevant).

Scope:
- Operate only on the attached files and the currently open file. If broader changes are needed, ask first.

Steps:
1) Parse the provided files and list all TODOs with file path and line number.
2) Group TODOs by file/subsystem and identify dependencies or ordering.
3) Ask clarifying questions for ambiguous TODOs (owner intent, constraints, acceptance criteria).
4) Propose a minimal, safe implementation plan with a file-by-file edit list and request approval.
5) Implement TODOs, keeping changes small and focused. Avoid unrelated refactoring.
6) After edits, summarize changes (files touched, key decisions, potential follow-ups).

Output:
- TODO Inventory: table/bullets with file:line and short description.
- Questions (if any): bullets.
- Plan (pending approval): numbered steps.
- Edits: apply once approved, then provide a brief summary.

Workflow that asks the agent to add comments to the currently open file.

Goal: Improve code readability by adding concise, accurate comments without changing behavior.

Scope:
- Only modify the currently open file unless the user approves changes elsewhere.

Steps:
1) Read the entire file to understand purpose, public API, and complex logic.
2) Draft a commenting plan: file/header comment (if lacking), function/class doc comments, and inline comments for non-obvious logic or invariants.
3) Ask about style preferences if unclear; otherwise follow the project's existing conventions.
4) Apply comments, keeping them precise and avoiding restating obvious code.
5) Provide a short summary of what was commented and why.

Constraints:
- Do not change program logic or formatting beyond what's necessary for comments.
- Keep comments brief (1–3 lines typically) and maintain consistent tone.

Output:
- Comment Plan (brief)
- Applied changes summary with rationale