Rules

What is the Rules feature?

The Rules feature lets you make sure the Explyt agent follows your instructions in 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.

Rule types:

• Global — a personal rule for several unrelated projects. For example, use it to make the agent answer in the same format in every project. When you create the Rule, enable Create as global rule (available in all projects), enter a file name and click OK.
• Project — a rule for the conventions of a single repository. For example, use it so the whole team follows the test style adopted in the project. When you create the Rule, leave Create as global rule off, enter a file name and click OK. You can commit the project Rule file to VCS and share it with colleagues.

A Rule also has a glob pattern that defines the scope where the rule applies. Internally, the Rule's content is added to the system prompt when the currently open file matches that glob pattern. The glob pattern is specified at the top of the Rule file:

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

When to pass the rule to the agent

The strictness field in the frontmatter sets the point at which the rule is delivered:

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

Three values are available:

1. system — for a stable baseline instruction that only needs to be delivered once. For example, you can set the response language or the general result format without spending tokens repeatedly. Specify strictness: system or omit strictness entirely: this is the default value;
2. user-message — for an instruction that must be repeated before every new request in a long conversation. Specify strictness: user-message in the frontmatter;
3. tool-call — for a requirement the agent must take into account after every tool action. Specify strictness: tool-call in the frontmatter.

The more often Explyt repeats the rule, the more tokens or minutes it spends.

To create a Rule, follow these steps:

• Open a new chat.
• Open the rule creation dialog.
• Enter a file name, choose Project or Global, and click OK.
• In the opened file, specify the file pattern and add the Markdown content of the Rule.

Temporarily disable a Rule

Disable a Rule when it gets in the way of the current task or conflicts with another instruction, but you will still need it later. Open the Rules list in the chat and clear the checkbox next to the file. To apply the rule again, select the checkbox back. Disabling does not delete the file.

Delete a Rule

Delete a Rule when the instruction is obsolete and should no longer be used. Open the Rules list, click the delete button next to the file and confirm the action. Explyt deletes the Rule file itself; you cannot restore it with the toggle afterwards.

Best practices

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

• Specify the scope where the rule should be applied
• Instruct the agent on the expected steps it 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

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 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)