I think the landscape for input context has become a bit muddled and hard to follow, specifically calling out modes and user rules.
This is what I understand from my own experience and the Cursor Docs.
Project Rules => Stored in .cursor/rules , version-controlled and meant to be project specific. Applied based on glob pattern, always applied, or only applied if specifically included (and even then Cursor selects only a few which seem relevant for the given request).
Memories (new) => Automatically generated rules based on your conversations in Chat. Requires privacy mode to be disabled and always applied.
User Rules (new) => Global to user for all projects and always applied. Does not support MDC format.
Custom Modes => Allows a developer to switch to a custom mode where they can define which tools/models are available and include specific instructions.
I’d put up a post recently requesting something like user rules, but I’m not sure how different this implementation is from previous features that allowed for supplying global additional context. They also seem very similar in practice to the custom modes instruction context, except they always apply no matter the custom mode.
I still think a better version of user rules would be more similar to project rules, but located at a user level app or documents folder on their machine. This would allow for syncing these easily to a repository and sharing with others. For myself most of my project rules would then convert to be user rules since most of my rules are general to how I develop Unity projects.
I thought I’d read that user rules were supposed to be machine specific, but some users have reported finding them synced across different machines.
Hi Jeff, yes this is one of the common but sometimes contradicting requests, users want either to have shared rules or to not share them at all
User Rules came from the original .cursorrules but apply to whole system, and as you mentioned likely to the account, though I have also no additional info as I use a single device.
Thank you for the feature request! In your case specifically sharing the rules makes sense as you work on the same technology.
Hi @T1000 , the issue from my perspective is simpler than either sharing or not sharing and more about needing to copy the same project rules with full MDC formats and functionality between different projects. In my own use case I manage 4-5 live game projects at a time, as well as around 25+ libraries. Each has their own Unity project and repository and its simply not feasible to keep them synced via copy/pasting around.
Ideally something like user rules would support having a single location that would allow for MDC formats and glob pattern application from the project root, but instead it’s just another place to stick global input context (lacks project rules granularity) and feels duplicative of the instructions a developer can provide with custom modes.
Hey, the new user rules are stored in the cloud, which might be convenient for some users. If you need specific rules for a project, you can use .cursorrules or project rules. However, I think we need a toggle to enable or disable user rules.
Regarding MDC support, it’s a good idea and could potentially be a feature request.
MDC support for rules (user or project) definitely feels like a baseline feature. In practice, most of the MDC frontmatter for my rules are project independent, even if the glob pattern uses paths. Here’s a few examples:
---
description: Apply C# naming conventions when writing code to ensure consistent code style
globs: **/*.cs
alwaysApply: false
---
---
description: Apply Unity prefab editing best practices when modifying prefabs through editor scripts
globs: **/Editor/**/*.cs
alwaysApply: false
---
---
description: Apply documentation standards when writing or updating code and documentation files
globs: **/*.{cs,md}
alwaysApply: false
---
The content for these rules are fairly small (50-75 lines max), but large and specific enough I wouldn’t want to paste these all together into the current global user rules paradigm.
