Writing rules for the agent

A rule carries an instruction you would otherwise repeat in every conversation: the project’s naming convention, the test framework to use, a directory that must not be touched.

A rule is part of your instructions. It is therefore written in your configuration: the developer’s instructions are the only source of control for a session, and a file read from the repository is not one (security white paper V3, section 5.2). The section Instruction files present in a repository describes what the agent does with those files.

Writing the rule in the configuration file

The rules block in ~/.lemniscate/workstation.yaml accepts plain-text instructions, or an object:

name: Local Config
version: 1.0.0
rules:
  - Répondre en français.
  - name: Pas de secrets
    rule: Ne jamais écrire de clé d'API dans un fichier suivi par git.
    globs: "**/*.ts"

In object form, name and rule are both required. The globs, regex and alwaysApply fields have the same meaning there as in a rule file, described below.

Writing the rule in your personal directory

A .md file placed in ~/.lemniscate/rules/ is a rule that follows you across all your repositories. Subdirectories are traversed.

# Conventions de test

- Les tests utilisent Vitest, jamais Jest.
- Aucun accès réseau dans un test.
- Les messages d'erreur sont en français.

Without front-matter, the rule applies to every request, whatever file is open.

A rule that applies only to certain files

Front-matter states what the rule applies to:

---
name: Composants React
description: Conventions des composants de l'interface
globs:
  - "src/components/**/*.tsx"
---

- Un composant par fichier, exporté nommément.
- Aucun appel réseau dans un composant : passer par un hook.

Fields recognized in the front-matter:

Field	Effect
name	the displayed name; failing that, the last two path segments
description	a sentence, intended for the model
globs	the files concerned, a string or a list
regex	a regular expression on the content
alwaysApply	forces the rule to apply, or prevents it
invokable	makes the rule a command to call, not a permanent rule

The invokable field moves the file from one family to the other: a callable rule is no longer attached to your requests, it waits for you to type its name. Conversely, an ordinary rule file does not appear in the list of commands.

Front-matter with invalid YAML is ignored without an error: the whole file becomes the body of the rule, and the globs it declared do not exist. A rule that applies everywhere when it targeted a single directory is diagnosed there.

The terminal keeps only the rules that apply unconditionally. A rule carrying globs, regex or alwaysApply: false triggers depending on the files in context; lemni has no such notion and discards it, whether it comes from the rules block or from the personal directory.

Two combinations worth knowing

Without globs, without regex and without alwaysApply, the rule always applies.

alwaysApply: false with neither globs nor regex gives a rule that never applies: nothing triggers it. This is a way to disable a rule without deleting it.

A rule for a single session

In lemni, the --rule option adds a rule for the session it starts. It takes a text, or the path to a file on your workstation, and can be repeated:

lemni --rule "Répondre en français." --rule "Les tests utilisent Vitest."

Instruction files present in a repository

A repository may contain files written to instruct an agent: an AGENTS.md or CLAUDE.md file at the root, an .lemniscate/rules/ directory, a rules.md placed in a directory.

These files are part of the working copy. The agent can read them like any other file in the repository, and their content is then marked as untrusted and presented to the model in an area separate from your instructions. Content read from the repository activates no tool and widens no permission: the available tools are fixed by the project policy before any read (security white paper V3, section 5.2).

For a convention written in one of these files to count as an instruction, read it over and copy it into one of your rules.

When two rules contradict each other

You can set an instruction in several places, and two instructions can contradict each other. The product decides based on scope.

Each instruction is handed to the agent labelled with the scope it was written for, from the broadest to the narrowest:

Scope	What it covers
product	the product’s base message
configuration	the rules block of your configuration file, the --rule option
personal	the files in your personal rules directory

The narrowest scope wins, and the agent is instructed to say which one it set aside. A rule from your personal directory therefore takes precedence over an entry in the rules block, and any rule you write takes precedence over the product’s base message.

Two instructions in the same scope cannot be ranked. Two files in your personal directory are peers: the agent is instructed to report the contradiction rather than pick one. Their file names play no part in the decision.

No rule changes the project policy. That policy is written by the administrator, evaluated by the gateway before every action, and is not read as an instruction by the model (security white paper V3, section 5.1).

Checking that a rule is taken into account

In the IDE, saving a rule file reloads the configuration: the rule is active on the next request, with no restart. lemni reads the rules when the session starts: after writing a rule, restart it.

The least ambiguous check is to put in the rule an instruction whose effect is visible in the reply, a required wording or an expected refusal, then ask for it. A rule that changes nothing in the reply is not loaded.

You can also ask the agent where an instruction comes from: each rule reaches it with the name of the file that carries it, and it can quote that name.