Agent Rules / 14 patterns
Patterns worth borrowing.
Different projects. Recurring ideas. Find a technique, then see how real projects put it to work.
Jump to a technique
Hard prohibitions
A short list of actions the file states the agent must never take, without hedging.
Why it works
Stated as flat "never" rather than "prefer not to", and usually naming the exact action rather than a category. Several files pair the rule with what to do when a user asks anyway.
Good and bad pairs
A style rule is shown with the wrong version beside the right one.
Why it works
Some files pair whole code blocks, others contrast inline within a sentence. The rule is stated once and then demonstrated twice, which removes the judgement call at the margins.
Generated file guards
Generated files are named, along with the generator to run instead.
Why it works
The lists are explicit paths rather than a description of what generated files look like. Several entries also name the command and, in a few cases, the extra steps that have to happen in the same change, such as deleting a superseded fixture.
Verification by change type
The kind of change is mapped to the specific checks that cover it.
Why it works
A rendering change maps to one command, a protocol change to another. Several files also state what the default test command leaves out, which is otherwise discoverable only by finding the gap.
Nested instruction files
Per-package AGENTS.md files, with a stated order of precedence.
Why it works
The root file covers repository-wide navigation and defers subsystem detail to a file next to the code. Where the files could conflict, the precedence order is written down rather than left to the agent.
Pointing at the source of truth
The file refuses to copy values that live somewhere authoritative.
Why it works
Version numbers, rule lists and counts are replaced with a pointer to the config, script or array that defines them. Some files state the reason directly: a copied value drifts from the thing it copied.
Router files
The entry file dispatches to deeper task guides rather than containing them.
Why it works
A short index maps a kind of work to the guide to read before starting it. The deeper document is loaded when the task touches that subsystem, instead of on every request.
Behavioral framing
Rules about how to approach the work rather than facts about the repository.
Why it works
Surface tradeoffs, do not over-build, touch only what was asked. Two files state outright that these sections were written from recurring mistakes in agent-authored changes to that repo.
House vocabulary
Specific words the project does and does not use, defined once.
Why it works
Ranges from fixing the spelling of a domain term across all prose, to defining the difference between two near-synonyms, to listing individual words that may not appear. Naming drift is hard to catch in review, which is what these rules are aimed at.
Architecture as narrative
How the system works, written out, rather than a list of rules about it.
Why it works
Request lifecycles, data flows and component boundaries. It lets the agent derive an answer for a case the file does not cover, at the cost of length.
Ratchets
Baselines that may only shrink and lists that may only grow.
Why it works
A known-violations file, a lint warning count, or a tombstone list, each with a direction of travel stated in the file and usually enforced in CI.
Contribution etiquette
Rules for what the agent may open, push or post on the project's behalf.
Why it works
Covers pull requests, issues, @-mentions and commit trailers. Two of these files give the reason as agent traffic specifically: unsolicited pull requests, and issues that attract duplicate work from other agents.
Scope layering
Different rules for different actors, with a test for which set applies.
Why it works
One file covers maintainers, external contributors and forks, and states how the agent determines which it is before the rules take effect.
Context budgeting
Rules governing what may enter the model context, with size caps.
Why it works
Appears in repos that build agents. The context window is treated as a resource with an owner, a cap per item, and a review threshold.
Ordered roughly from easiest to adopt to more specialized techniques.