Skip to main content
A domain is a named subject with triggers attached to it. When your prompt or the file you are editing matches one of those triggers, everything attached to that domain becomes eligible to arrive. That is the whole mechanism, and it is deliberately plain.

​
Triggers are in a file, content is in the graph

domains.toml holds triggers only: the keywords that match against prompts and the paths that match against files. The rules, decisions and notes attached to a domain live in the graph. Two commands rather than one, for a reason. Triggers are policy you write and read as text, so they belong in a file you can put under version control and copy to another machine. Content accumulates as you work, gets edges to projects and entities, and needs to be queryable. Keeping them apart means you can retune what fires without touching what is said, and add what is said without editing config.

​
How a match is decided

Matching is substring matching on the text and path matching on files. Nothing is fuzzy, nothing is semantic, and nothing is scored. A trigger either appears in what you sent or it does not. That is a real constraint and it is worth planning around. A domain triggered on invoice does not fire on billing, and one triggered on auth fires on author too. Pick trigger words the way you would pick a grep pattern, then check.

​
Check before you rely on it

base context runs the same matching that runs during a turn, without sending anything. Paste in the prompt you actually mean to send. Either a domain matched or it did not, and you find out in a second rather than after a session where nothing arrived. base domain get <name> shows one domain’s full configuration, so you can confirm a trigger landed where you meant it to.

​
Three sources, merged by name

Domains come from three places, loaded in this order:
  1. The global ~/.base-gbl/domains.toml, which applies everywhere.
  2. The workspace’s own .base/domains.toml, which overlays the global set by name.
  3. Any installed extensions, which merge in at the lowest priority.
Overlaying by name means a workspace can redefine a global domain for that workspace alone, and everything else stays as it was.
The domain write commands do not all target the same tier. create, remove-trigger and remove only ever touch the global file. add-trigger writes the workspace file. So a domain you create and then add a trigger to ends up split across two files, and a trigger added inside a workspace cannot be removed from the command line.list and get read both tiers merged, which is exactly why this is easy to miss: the domain keeps looking right. Established from source at 4866996, the commit the shipped 0.13.2 binary was built from. Until it changes, edit the workspace .base/domains.toml by hand when you need to take a workspace trigger back off.

​
Rules carry their reasoning

A rule with --rationale is injected as the rule followed by its reason. Write the reason. A bare instruction gets argued with when it collides with something the agent thinks is more sensible; an instruction with a reason attached usually survives the collision.

​
Next

Tiers and scoping

Global and workspace, how they merge, and what stays out of the other project.

Context reference

Every domain, rule, standard and star-command command, with its flags.