Skip to main content

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)