Category
Rules and constraints for AI coding agents
A rule is a constraint an AI coding agent must follow inside a scope. It is the strongest thing a team can write down, because a well placed strict rule blocks a class of mistake before it lands rather than explaining it again in review. Three settings decide whether a rule holds: where it applies, how strongly it surfaces, and what happens when it is violated.
A constraint an AI coding agent must follow within a defined scope. Unlike a memory, which the agent weighs against the situation, a rule is written for things that are not negotiable: never use the service role key in browser code, money is stored as integers in cents, migrations run before the matching code change.
A rule is not a preference and not a suggestion. If the honest answer is "it depends, the agent should think about it", that is a memory. Writing it as a rule spends the credibility of every other rule you have.
Why one instruction file stops holding
The usual first home for rules is the file the agent already reads: CLAUDE.md, AGENTS.md, .cursorrules. It works, and for one person on one repository with a page of conventions it is the correct answer.
It comes apart in a specific way. As the file grows, the rules that matter for the file in front of the model compete with rules about parts of the codebase nobody is touching. Nothing announces the failure: the agent still reads the file, still sounds confident, and quietly gives less weight to the line that was load-bearing. Cursor's own guidance is to keep a rule file under 500 lines, which is an admission of the same mechanism. Long read: why global AI instructions break down at team scale.
The fix is not a shorter file. It is to stop modelling a constraint as a line in a document and start modelling it as an object with a scope.
What a flat file cannot express
Where the rule applies. A Tailwind-only rule for
apps/webhas no business firing while the agent works in the data pipeline. A file at the repository root cannot say that.How strongly it applies. A security constraint and a naming preference read identically as bullet points. The model has no signal about which one it may trade away.
What happens on a violation. A document can describe a constraint. It cannot refuse a change that breaks it.
Who changed it and why. Anyone with push access edits the file. There is no review trail for the rule itself, and no way to notice one has gone stale.
The three settings that decide whether a rule holds
Pathrule stores a rule as an object rather than a line. Scope decides where it applies, priority decides how aggressively it surfaces, and enforcement decides what happens when something violates it. They are independent on purpose: a stylistic rule can be scoped tightly, and a project-wide rule can still be advisory.
A rule, as it is actually stored name: No service role key in browser code scope_type: folder # folder | file_type | project node_path: /apps/web priority: high # high | medium | low enforcement: strict # advisory | strict Never use the Supabase service role key in code that ships to the browser. Read through the authenticated client.
Scope: where it applies
`folder`. A directory subtree. The right default for area-specific constraints: anything under
apps/api/auth, anything underservices/billing. The scope type and the node path the rule is attached to together decide what the agent sees.`file_type`. Files matching a glob such as
*.tsxor**/*.test.ts. For cross-cutting concerns tied to a kind of file rather than a place in the tree.`project`. Everywhere in the workspace. Use sparingly: a project rule rides every prompt, which is the cost the flat file was already paying.
Priority: how strongly it surfaces
`high`. Always injected when the scope matches. Reserve it for violations that cause bugs, security regressions or compliance problems.
`medium`. The default. Surfaces when the hook judges it relevant to the current task. The right level for "almost always, but not load-bearing".
`low`. Stylistic. Surfaces when there is room and the topic is on point. Taste and convention live here.
Enforcement: what happens on a violation
`advisory`. The rule arrives as context. The agent weighs it and decides how to apply it. Most rules should be advisory, because most constraints have a legitimate exception somewhere.
`strict`. A strict rule with a matching pattern is enforced by the local hook, which blocks a violating change before it lands and surfaces the rule as the reason. The correction happens before review instead of after it. Rules as guardrails.
Where blocking is actually possible
Worth stating plainly, because it depends on the surface rather than on the rule. Studio handles strict enforcement for the agents it runs. Pathrule CLI also registers the available hooks for standalone Claude Code, Cursor, Codex and GitHub Copilot. Windsurf and the Remote MCP endpoint receive rules as context but have no Pathrule pre-write event, so there is nothing to block with: a rule delivered there is advisory in practice however it is configured.
A rule in a file vs a rule as an object
| A line in an instruction file | A scoped, typed rule |
|---|---|
| Ships on every turn, in every directory. | Fires only where its scope matches. |
| Reads the same as every other bullet point. | Carries a priority, so the agent knows what it may not trade away. |
| Describes a constraint. | A strict rule can block a violating change before it lands, where the surface supports it. |
| Token cost grows with every rule the team adds. | Token cost scales with the relevant slice, not the whole rule set. |
| Edited by anyone with push. No trail for the rule itself. | Versioned and reviewable, with a self-audit that surfaces stale and conflicting entries as suggestions. |
| One file per tool. The same rule maintained three times. | One rule, delivered to every agent the team runs. |
Side by side with the files themselves: Pathrule vs CLAUDE.md and Pathrule vs Cursor Rules.
Rules, memories and skills
The three types answer three different questions, and choosing the wrong one is the most common authoring mistake. A memory says what is true here and is weighed against the situation. A rule says what must not happen and is not. A skill says how a job is done, step by step, and is invoked by name.
The test is simple. If it depends on the situation, it is a memory. If it is non-negotiable, it is a rule. If it is a sequence someone keeps walking through, it is a skill. Long read: memory, rules and skills: three kinds of team knowledge.
Which agents receive rules
Frequently asked questions
What is an AI agent rule?
A constraint an AI coding agent must follow inside a defined scope. A rule carries a scope type (folder, file_type or project), a priority (high, medium or low) and an enforcement level (advisory or strict), which together decide where it applies, how strongly it surfaces and what happens when something violates it.
What is the difference between a rule and a memory?
A memory says what is true here and the agent weighs it against the situation. A rule says what must not happen and is not up for negotiation. If the honest answer is "it depends, the agent should think about it", write a memory instead: writing it as a rule spends the credibility of every other rule you have.
Why does my AI agent ignore its rules?
Usually because the rule competes with unrelated guidance in a long instruction file, because its scope is wrong so it never fires on the paths where it matters, or because it is written as a preference and is therefore correctly weighed away. Long reads: why Cursor rules get silently ignored and why Claude Code ignores your CLAUDE.md.
Can a rule actually block a change, or only advise?
Both are available, and it depends on the surface. A strict rule with a matching pattern is enforced by the local hook, which blocks a violating change before it lands and surfaces the rule as the reason. Studio does this for the agents it runs, and Pathrule CLI registers the available hooks for standalone Claude Code, Cursor, Codex and GitHub Copilot. Windsurf and Remote MCP receive rules as context with no pre-write event to block on.
How many rules should be high priority?
Few. High priority means always injected when the scope matches, so it is a budget: if half your rules are high priority, none of them are. Reserve it for violations that cause bugs, security regressions or compliance problems, and default everything else to medium.
How is this different from Cursor Rules or CLAUDE.md?
Those are files, and a file cannot express where a constraint applies, how strongly, or what to do when it is violated. Pathrule stores a rule as an object with scope, priority and enforcement, delivers only the rules matching the current path, and sends the same rule to every agent the team runs rather than one copy per tool. Side by side: Pathrule vs Cursor Rules and Pathrule vs CLAUDE.md.
Do I have to delete my existing rule files?
No. Pathrule sits above them. CLAUDE.md, AGENTS.md and .cursorrules keep doing what they are good at, which is repository-wide constants. Pathrule carries the path-scoped constraints those files cannot model well.
Can the same rule apply to more than one path?
Yes. Rules are reusable: one rule object can be attached to several nodes, so a shared constraint is written and reviewed once rather than copied per directory. Writing rules covers the authoring detail.