Directives

The rules an agent is bound by. Directives resolves library rules plus the files that govern a project, in precedence order, then delivers them in the native form each harness understands.

Part of the brain.

The layers#

Read lowest precedence first, so each layer refines the ones before it:

The project library layer is omitted when no project is selected. More specific layers win, so repository and nested rules refine shared library and operator rules without copying them.

Vendored paths (node_modules, .git, dist, build) are excluded. A CLAUDE.md that came in with a dependency is not a directive.

Live files and library rules#

Filesystem directives are read live rather than indexed. Library rule documents come from the Library store and give teams a shared rule surface without writing files into each repository.

That means a rule you write takes effect on the very next session, with nothing to reindex or restart.

Delivery and diagnosis#

The resolved stack is common, but delivery is provider-specific. Claude Code loads its native files and receives the library and harness-neutral remainder as appended system context. Codex receives the stack in its run-local AGENTS.md; Copilot receives one ordered instructions file; Cursor receives it through the trailing prompt positional because its CLI has no separate system-prompt channel. A worker launch records an immutable directives-received snapshot in its run artifacts. Inspect that snapshot when diagnosing behavior: it answers what the worker actually received at launch even if a library rule or file changed afterward.

How agents use it#

Searching is the normal path: it splits each file into sections and matches per section, so a hit is the specific rule rather than the whole document. Listing the hierarchy is the orientation step when a search comes back empty.

Resolving the complete hierarchy is available but deliberately a last resort, since it inlines every file's content and costs roughly 18,000 tokens on a typical repository. It is for when the rules themselves are the subject of the work.

How directives affect review#

Review workers receive three complementary inputs. The review-criteria library document is the explicit grading rubric shared by code-task's self-review and formal-review chains. The role orientation tells each worker how to behave as a reviewer. The resolved directives above supply ordered tenant, operator, project, and nested constraints for the repository being reviewed.

Precedence applies within that directive stack: more specific layers refine broader ones. A repository rule can therefore tighten or specialize an expectation, but directive resolution does not substitute for the separately fetched rubric. The review chains stop if that rubric is missing or blank.

Every supported provider receives the same resolved meaning through its native instructions mechanism, even though the transport differs. The recorded directives-received snapshot remains the evidence of what a particular review worker saw. See How code is judged for where these inputs sit in code-task.

Why it matters#

This is the layer that makes an agent's output look like your codebase rather than generic output. A rule you write once, whether a testing convention, an import style, or a library you have banned, governs Claude, Codex, Copilot and Cursor workers and the supported interactive clients that load the same stack.

Full command surface: CLI & contract reference.