Global .cursor/rules directory

Feature Requests
1

It would be nice to have the possibility of defining user-level Cursor Rules, not tied to any project but available in all of them.

For example, I just wrote a rule to explain Cursor how to autonomousy create a branch, commit, push and open a PR. I would like to have it in my home directory, and not commit it in every GitHub project I work on.

This would also help people to create custom workflows without polluting the repos that might be used by other people.

5 Likes
2

have you tried saving these in the Rules for AI section in cursor settings? it is meant to work as user-level cursor rules only

1 Like
3

It works, but that is a free text field, not separate rule files. Therefore, that rule is loaded in the context of every session. It would be nice to have separate files for separate use cases, also in a global context.

2 Likes
4

hmm I can understand. maybe they’ll add this in a future update. Till then you could just copy the ones over which are required for each project!

1 Like
5

We don’t currently have a global rules directory feature, but you may be able to create a local .cursor/rules directory in your home folder as a workaround, and then just create symlinks to that directory in each of your projects - I haven’t tried this, so it may not work!

1 Like
6

even if this works its undesireable. the idea is to have some shared global rules (eg: rule to assist making new rules) and a folder for rules relevant to the project

3 Likes
7

I’d like to bump this idea and potentially modify it a bit: provide a setting that lets the user provide an absolute local path to a .cursor/rules directory on their machine.

This actually works quite well for the Vale extension. This enables you to create a repo with all your rules and anyone can pull it down and point to it locally to stay in sync.

Cursor could leverage this to build a community library around where you can locally install and point to rule sets made and maintained by users and upvote more effective ones.

I’ve provided a screenshot of the related Vale extension field that accomplishes the same idea. For context, my team of technical writers all use the same Vale config and it’s easy to manage this way. (It also supports local overrides, if that sounds interesting to you).

image
image2130×786 72.3 KB

I think this is a better long-term play because of the smart tool calling scenario. why would I want to keep re-adding rule sets I like across projects when I could have a library of excellent ones that have proven call descriptors and instructions? As a tech writer, for example, I just need the same style guide on markdown and rst files across 4-5 repos.

2 Likes
8

I agree
Having global rules is really important, the reasoning is simple:

I prefer not to share my rules publicly with teammates or online. I prefer a local directory to store them, such as /usr/local/bin/cursor/rules.

Copying and pasting rules for each project, branch, or worktree and adding them as .gitignore entries isn’t practical.

While the idea of project-based and shareable rules is great, it doesn’t cover many other use cases.

1 Like
9

+1 on providing a path to the .cursor directory
I connect to my project remotely and don’t have write access to the project’s root directory

1 Like
10

When I’m working on a team, I’m usually hesitant to add something directly to the project-level rules without trying it out first. Ideally, I’d like a way to define rules that are just for me—so I can test them privately and see how they work in practice. If a rule turns out to be useful and stable, then I’d feel more confident promoting it to the shared project rules.

1 Like
11

@pietrodn I strongly agree!

If we use coding as a model, then this is typically accomplished with include directives.

I propose the following general scheme (most or all of this may not be new):

  • Be able to include rule files in other rule files
  • Permit YAML, JSON, Markdown, and free text, and permit the use of their respective file extensions
  • Use a specific directory for the shared area such as ~/cursor/rules-library, and ideally make this configurable, possibly even supporting specifying multiple such directories; note that the name includes ‘library’ to denote availability rather than unconditional inclusion
  • Support multiple directory levels, e.g. %languages/ruby.md
  • Use a leading character such as ‘%’ in an include directive to mean that the file to include is in the shared global (user) project rules directory tree (e.g. ~/cursor/rules-library); the absence of this character means that the file to include is in the project rules directory tree:
    • Global paths: %path/to/file.md → ~/.cursor/rules-library/path/to/file.md
    • Project paths: path/to/file.md → [project-root]/.cursor/rules/path/to/file.md

The inclusion code might look something like this:

@include %ruby-rules.md            # Global include for Ruby-specific rules
@include %languages/ruby-rules.md  # Global include from a subdirectory
@include lint-policies.md          # Project-specific include