Cursor Global Rules: Set Defaults Across Every Project

Cursor global rules are instructions that apply across every project you open, stored outside any repository. They let you set personal defaults once — your preferred code style, how you like responses formatted, habits the AI should follow everywhere — without repeating them in each project's rules file.

Global rules work best for preferences that are about you, not the project. Project-specific context — the approved build commands, the team's naming conventions, the decisions behind the architecture — belongs in fenbs or in the project's own rules file, where the next assistant can find it alongside the work.

Where global rules are stored

Global Cursor rules live in Settings under "Rules for AI". Everything you write there applies to every project and every Cursor session on that machine. You can also set them in ~/.cursor/rules/ as Markdown files if you prefer to keep them in a text editor.

Rules in a project's .cursor/rules/ folder or .cursorrules file are loaded on top of global rules when you open that project. If the same instruction appears in both, the project-level rule takes precedence. That layering is what makes Cursor rules hierarchy useful: global for the person, project for the codebase.

What belongs in global rules

Good global rules are short, stable, and personal. They should not describe any single project. Ask yourself: would this instruction make sense in a project I have never opened before? If yes, it might belong globally. If it depends on knowing the codebase, it belongs in the project.

• Response format preferences: how long answers should be, whether to show code diffs, preferred explanation depth.
• Personal coding style: language-level preferences that you apply everywhere regardless of team conventions.
• Behavioral defaults: always ask before deleting files, always show the command before running it.
• Language or locale settings that apply to all your work.
• A reminder to read project-level rules and context before starting.

What does not belong in global rules

Global rules are the wrong place for anything that is specific to one project or one team. If a rule mentions a file path, a library name, a build command, or an architectural decision, it should be in the project's rules file instead. Mixing project facts into global rules means those facts follow you into unrelated projects and confuse an assistant working on different code.

Decisions and reasoning behind conventions belong in fenbs, not in either rules file. A global rule can remind an assistant to read the project context from fenbs at the start of a session. The actual context lives in fenbs, where it is linked to the tasks and can be updated by anyone on the team.

A starting template for global rules

# Personal defaults

## Response style
- Keep explanations short unless I ask for more detail.
- Show a diff or a minimal edit rather than the full file when possible.
- Ask before deleting or moving any file.

## Code style
- Prefer explicit types over inferred ones where the type is non-obvious.
- Keep functions short: one clear purpose per function.

## At the start of a session
- Check for a .cursorrules or .cursor/rules/ file in the project root.
- If the project is connected to fenbs over MCP, read the project context,
  Rules, and Where we left off before doing any work.

Keeping global and project rules from conflicting

Conflicts between global and project rules usually come from rules that are too broad. A global rule that says "always use tabs" will conflict with a project that enforces spaces through Prettier. Write global rules for preferences, not for universal code style mandates.

If you find yourself overriding a global rule in every project, move it out of global rules entirely. Either it belongs in a project template you copy when starting new work, or it belongs in fenbs as a standing rule you ask assistants to read.

How to set up global Cursor rules with fenbs

1. Create a free account and add your current project to fenbs. Write the conventions specific to this project as Decisions and rules rather than global Cursor rules.
2. In Cursor Settings, write your global rules for personal preferences only. Add a line reminding the assistant to read project-level context at the start of each session.
3. Connect Cursor to fenbs over MCP from Integrations. The assistant will then read the project Decisions, Where we left off, and the current tasks at session start.
4. For each new project, add its specific context to fenbs rather than updating your global rules. Your global rules stay stable; the project context stays in fenbs.

Testing global rules in a new project

When you open an unfamiliar project with global rules active, spend a few minutes checking whether any of your global rules conflict with that project's setup. A global rule about preferred variable naming will apply immediately, even if the existing codebase uses a different convention. The safest global rules are behavioral ones — ask before deleting, show a diff before applying — rather than style mandates.

If you contribute to open source projects or work across client codebases, consider keeping your global rules minimal enough that they help without imposing your preferences on someone else's project. The project-level rules in each repository should carry the actual conventions; your global rules should carry only what is genuinely universal to how you work.

What to watch for

Global rules accumulate over time. Review them every few months and remove anything that no longer reflects how you work. A long list of global rules increases the chance that one contradicts a project-level rule, and it makes the rules harder for an assistant to follow reliably.

If you work across very different stacks — say, both mobile and backend — consider whether a single set of global rules still makes sense or whether separate Cursor profiles would serve you better. The Cursor alternatives guide compares how other AI coding tools handle user-level defaults.