Rules: teaching the agent your conventions

Rules are standing instructions. The agent reads them at the start of every conversation, so you write a convention once instead of repeating it.

Where they live

.toolsxpo/rules/    in your repository — travels with the project
~/.toolsxpo/rules/  on your machine — applies everywhere
~/Documents/ToolsXpo/Rules/   also searched, if you prefer a normal folder

Project rules are for things the whole team should get. Global rules are for how you work.

Manage them from the Customize button beside the prompt box, which lists both and lets you toggle individual rules off without deleting them.

What makes a good rule

Rules work best when they are specific and checkable.

Good:

MARKDOWN
- Never use `as any`. If a type is wrong, fix the type.
- Tests go beside the file they test, named `<file>.test.ts`.
- This project uses tabs. Do not reformat to spaces.
- Database migrations are append-only. Never edit an applied migration.

Less useful:

MARKDOWN
- Write clean code
- Follow best practices

The second kind consumes context on every request and changes nothing, because the agent already believes it is doing that.

Negative rules earn their place

The most valuable rules are usually the ones that say don't. An agent will happily reformat a file, add a dependency, or "helpfully" rewrite an unrelated function — a single line forbidding it saves that argument permanently.

AGENTS.md

An AGENTS.md at your repository root is picked up automatically. If you already have one for another tool, ToolsXpo Code reads it — you do not need to duplicate it.

Rules versus skills

• Rules apply always. Use them for constraints.
• Skills load on demand, when a task matches. Use them for procedures.

A rule that only matters for one kind of task is better as a skill: it costs context on every request otherwise.

See also

• Skills
• Hooks