BIG BANG OF AGENT RULES

TLDR: Last weekend, I spent several hours digging through publicly available cursor rules files and analyzing existing usage patterns. Despite the presence of a lot of garbage and auto-generated content, I found several distinct strategies that people use to shape AI agent behavior.

What Are Agent Rules, Anyway?
For those unfamiliar, these rules are configuration files that shape how AI coding agents behave in your project. Think of them as prompting for developers — you write instructions about your preferred coding style, project structure, or workflow, and the agent tries to follow them. And, well, yeah, it's basically just prompting under the hood, which means not all of them are useful.

Intro

Last weekend, it was too hot outside, so I finally managed to investigate something that had been bothering me for a while: how people actually use cursor rules in practice. You've probably seen these `.cursorrules` files scattered across GitHub repos, but are those really useful or they are just a cargo cult? I’ve read many recommendations and descriptions of different practices; I wrote such rules myself, but I wonder if there are systematic practices to use them. It's hard to say without proper analysis.

You can probably guess what happened next — what started as a quick investigation turned into several hours of repository digging and analysis.

I started by searching for `.cursorrules` and `.cursor/rules/` across GitHub. After filtering out obvious duplicates and auto-generated content, I ended up with several hundred unique examples from real projects.

Despite the fact it seems that analyzing configuration files should be straightforward, in practice, there were several problems, such as:

• a lot of the content is copy-pasted without understanding;

• many rules seem to be auto-generated by other AI tools (meta-rules generating meta-rules, if you will;)

• the actual effectiveness is hard to measure without running controlled experiments.

However, I managed to identify some interesting patterns so I’m sharing them here.

Types of Agent Rules In A Wild

After going through all the examples, I found that people commonly use agent rules in several distinct ways:

1. Basic Behavior Shaping

This is probably the most practical category. If you have repetitive issues with agent behavior, you formulate specific requirements as rules. Some random examples that make sense:

• Preventing blocking commands: Deny usage of interactive commands like `more` or `less` that halt agent execution;

• Auto-commit enforcement: Make the agent automatically commit changes with proper conventional commit messages;

• Output control: Rules like "Never use apologies," "No Unnecessary Confirmations," and "Avoid giving feedback about understanding in comments;"

• Emoji management: Whether you want the agent to use emojis or strictly avoid them.

2. Language/Framework Specific Guidelines

This approach augments your codebase with specific style guidelines. It's particularly useful for tools that allow multiple usage styles (you better pick one and enforce it).

I found working examples for bash scripting standards, some C++ guidelines, Python rule, generic or with scikit-learn. The quality varies significantly, but the good ones are usually quite detailed and focused.

Another straightforward example is enforcing specific commit message formats (conventional commits, etc.); examples: [1], [2], [3]

Moreover, you can use this pattern to describe best practices for lesser-known libraries where the agent needs extra context (since it’s not presented in pre-train data well).

3. Process Standardization

These rules enforce standard development processes. Often, there is no single right way to do something; instead, there are several ways to approach writing your documentation, for example. Therefore, it’s a good idea to guide your agent in a specific way that aligns with your practices. Some particular examples include:

• Documentation guidelines with specific formats and requirements: [1], [2], [3].

• Code review instructions with checklists and criteria (example).

• Testing guidelines specifying coverage requirements and testing patterns (example).

• Accessibility standards for web app development (example).

4. Project Structure Rules

This is where you document how your particular codebase is organized. It's helpful for keeping things clean, but you have to understand your own architecture first.

For instance, there are real examples like NVIDIA's NeMo Agent Toolkit and the PlatformPlatform repo — both have quite detailed rule sets that clearly evolved with their projects.

5. Role-Playing Agents Orchestration

The next level of ambitions: splitting responsibilities between differently-prompted agents.

For example, aforementioned PlatformPlatform splits work into several separate activities — create PRD, convert to a task plan, implement, commit, and review. Other examples use an agile-like setup with separate PM, architect, and developer roles.

It's still challenging to quantify the actual effectiveness of one version over another in practice, but the general idea seems reasonable for complex projects.

6. Meta-Rules

Finally, there are rules about creating rules automatically. Honestly, I find them harmful and scary so far — they tend to produce garbage without any quality control.

However, since they exist in the wild, here they are: [1], [2], [3], [4]. Use at your own risk.

Final Thoughts

If you want to examine examples yourself, start with:

• Online searchable directories like CursorList and Cursor Directory;

• curated lists like PatrickJS/awesome-cursorrules or ivangrynenko/cursorrules

Despite the hype around AI coding agents, agent rules could be pragmatical, useful and controllable tools. Based on my findings, the most effective rules seem to be:

1. Specific and actionable: "Don't use these commands" works better than "write good code";

2. Project-aware: Rules that describe your actual codebase structure;

3. Clear preferences and examples rather than generic guidelines and recommendations;

4. Proof Tested: Rules that evolved from real usage rather than theoretical considerations.

The worst rules are auto-generated, overly generic, or trying to do too much at once.

There's no magic formula — you need to understand what you want, experiment with different approaches, and iterate based on actual usage.

But when done well, they can genuinely improve your development workflow. Just remember: it's prompting all the way down :)