In our large monolithic project, we need to apply many internal design patterns and code style guidelines for the Cursor agent to consider. Is it better to define these directly as Cursor rules, or should we store them in a /design folder and use a corresponding Cursor rule like the following?
# Validate implementation against design docs
When modifying or generating implementation, always check the `/design` folder to ensure the implementations follow the design patterns.
As the final step validate the result against the design documentation before completing the task.
I’m already familiar with the general use of Cursor rules. However, my question is specifically about the internal workings and optimization of how Cursor handles rules, especially in the context of large rule sets.
From an LLM perspective, it’s important to minimize unnecessary context to avoid introducing noise that could distract the model from its primary task. What I’m trying to understand is:
How does Cursor internally process rules, especially those with wildcard or “always” matching? Are all matching rules injected into the model’s context for every request, even if they’re not directly relevant? Or does Cursor selectively include only the rules that are pertinent to the current task despite enforcing wildcard?
The reason for my question is that if all rules (including irrelevant ones) are always included in the context, this could lead to inefficiency and degraded performance. That’s why we’re considering keeping extensive documentation and patterns outside of Cursor rules, so that only the relevant parts are brought into context as needed.
Could you clarify how Cursor optimizes rule inclusion under the hood, and whether our approach aligns with best practices for context efficiency?