How to Split System, User, and Project Prompts
When an agent seems to follow the “wrong” rule, it is usually not one file—it is several layers loaded into context at once. In Cursor, team, project, and user rules merge; the chat turn (and optional slash commands) sits on top. No pricing, no full Skills-vs-Rules matrix, no commands file tutorial.
This post covers only what belongs where, who wins on conflict, and how to split when it gets too long. Grounded in Rules, Agent overview, and Customize Cursor.
What goes where?
One-line answer: Org-wide / compliance → Team (system-grade), repo / domain → Project, tone / personal taste → User, this task only → chat (or a / command).
Map the everyday “system / user / project” labels onto Cursor’s docs:
| Layer (practical name) | What it is in Cursor | Put here | Do not put here |
|---|---|---|---|
| System-grade | Team Rules (dashboard) + product Agent system instructions | Security, license, banned paths, org standards | Personal tone, one-repo API quirks |
| Project | .cursor/rules/*.mdc, root / nested AGENTS.md | Build/test commands, architecture, domain constraints, glob-scoped style | Full “sometimes” checklists on every chat |
| User | Customize → Rules (User Rules) | Reply length, language, personal coding taste | Policies that must bind the whole team |
| Turn (this chat) | Chat message, optional .cursor/commands /name | Goal, scope, success criteria for this run | Standing rules you need every session |
Placement sense:
- Must be identical across repos and people → Team (or enforced org rules).
- True only for this codebase → Project Rules /
AGENTS.md. Prefer plainAGENTS.mdwhen simple; use.mdcwhen you need Always / Intelligent / globs /@rule. - True only on your machine → User Rules. Docs: User Rules apply to Agent (Chat), not Inline Edit (Cmd/Ctrl+K).
- Once today → write it in chat or fire a
/command. Do not novelize workflows into standing layers.
Boundary vs Skills/Rules and commands posts: this piece is hierarchy and precedence. Skills package capabilities; commands are on-demand reusable prompts. “Always seeps in” vs “fire when needed” is only the Turn row vs Project/User rows in the table above.
Who wins on conflict?
One-line answer: Per Cursor’s Rules docs, on conflicting guidance Team → Project → User (earlier wins). Inside a project, prefer more specific instructions (nested AGENTS.md, matching globs). The explicit chat request sets this turn’s goal on top, but it does not erase an enforced Team Rule.
Official merge order:
| Rank | Source | On conflict |
|---|---|---|
| 1 | Team Rules | Wins. If Enforced, members cannot disable in Customize |
| 2 | Project Rules / active AGENTS.md | Repo and path context |
| 3 | User Rules | Personal global; yields to team/project |
Common conflict patterns:
- User “keep answers short” vs Project “attach test logs on every change” → project procedure wins; keep User for tone only.
- Team “no secrets / prod credentials” vs chat “show me
.env” → Team (and safety) wins. Chat steers the goal; it does not override enforced policy. - Root
AGENTS.md“npm test” vspackages/api/AGENTS.md“pnpm test:api” → nested files are more specific for that directory. Cursor combines nestedAGENTS.mdwith parents; more specific wins. - Always Project Rule vs Intelligent / globs → Always loads every session; glob/description rules attach when relevant. Keep long “sometimes” procedures out of Always.
One shared sentence for the team speeds debugging: “Security/bans = Team, repo conventions = Project, tone = User, procedure shortcuts = commands.”
When is it too long?
One-line answer: Keep rules focused (docs suggest under ~500 lines) and split; put only short constraints in Always; move long procedures to commands or Intelligent/globs; split repo notes with nested AGENTS.md.
Signals it is too long:
- One Always file holds style guide + release playbook + API catalog
- User Rules mix company policy and per-repo build commands (leaks into every project)
- The same paragraph is copy-pasted across Team / Project /
AGENTS.md/ README and drifts - Agent “forgets” rules while Always bloat burns context budget
Trim in this order:
- Shorten Always. Keep bans, required headers, minimum test bar. (Rules: under ~500 lines; split large rules.)
- Scope with globs. e.g.
src/components/**/*.tsx. - Occasional procedures →
.cursor/commands./only when needed—no per-chat tax. (File location and args belong to the commands post.) - Monorepos → nested
AGENTS.md. Root = shared; package = local commands only. @-reference files instead of pasting full guides. Docs recommend references over stale copies.- Delete duplicates. If Team already says it, Project needs one line: “follow Team security rules.”
Agent overview frames Agent as Instructions + Tools + Model. What you tune day to day is mostly Instructions (rules, AGENTS, chat). Length problems are a layering problem, not a “smarter model” problem.
FAQ
If User and Project Rules both apply, which one runs?
They merge. On conflict, docs put Project ahead of User. Team, if present, is ahead of both.
Is AGENTS.md enough, or do I need .cursor/rules?
For simple repo instructions, AGENTS.md is enough. When you need Always / globs / @rule application types, use .mdc Project Rules. Do not paste the same paragraph into both.
Can chat say “ignore that rule”?
You can restate this turn’s goal, but do not assume chat disables Enforce Team Rules or security bans. To shrink personal Always, edit or toggle in Customize.
How is this different from Skills or commands?
This post is where standing prompts live and who wins. Not the Skills matrix, /migrate-to-skills, command args/files, or pricing/limit numbers.
Sources
- Rules — Team / Project / User / AGENTS.md; conflict order Team → Project → User
- Agent overview — Instructions + Tools + Model
- Customize Cursor — entry points for Rules, Commands, and other customization