Cursor System Prompt: What You Can Read and Customize
Cursor reads project rules files rather than a traditional system prompt. Here is what you can set, what the editor controls, and why treating leaked prompts as configuration is a mistake.
Updated 5 min read
Cursor does not expose a user-editable system prompt in the way a chat API does. Instead, it reads rules you define in project files and global settings, then combines them with its own internal instructions. Those user-defined rules are the closest equivalent to a system prompt, and they are the part you can actually control.
Cursor's internal instructions have been leaked and published online several times. Treating those leaks as a configuration guide is a mistake: they are read-only, change without notice, and attempting to override them in your rules usually does not work. Tools like fenbs keep your editable project rules in a shared record that any connected AI can read, so the rules you write persist across sessions and contributors.
The layers of Cursor instructions
Cursor's behavior is shaped by three layers. The first is Cursor's own internal system instructions, set by the Cursor team. These cover how the editor handles code suggestions, the chat feature, and safety constraints. You cannot read or edit them.
The second is global rules, which you set in Cursor's settings under "Rules for AI." These apply to every project you open in Cursor on that machine. Use them for preferences that should be consistent everywhere: your preferred programming language, documentation style, or a standing preference for concise answers.
The third is project-level rules, which you set in a .cursor/rules directory in your repository (the newer format) or a .cursorrules file (the older format, still supported). Project rules apply only to that repository and can be more specific: architecture patterns, naming conventions, constraints on what to touch.
What to put in your rules files
Rules work best when they are specific. Vague preferences like "write clean code" give Cursor no real guidance. Specific rules like "always use TypeScript interfaces rather than type aliases for object shapes in this project" do.
- Language and version: "This project uses Python 3.11. Do not use syntax from earlier versions."
- Style: "Follow the project's existing naming conventions. New function names use camelCase."
- Architecture: "Do not add new files to src/legacy. Direct questions about that directory to the team."
- Testing: "Every new function needs a unit test. Tests live in the corresponding __tests__ folder."
- Limits: "Do not rewrite working functions unless asked to refactor. Suggest alternatives instead."
See Cursor rules examples for a set of rules you can adapt to your own project. For a broader comparison of Cursor with other AI coding editors, see Cursor alternatives.
Why leaked system prompts are not a configuration guide
Cursor's internal system prompt has been shared publicly several times. Those leaks show how Cursor frames its internal instructions to the model at a point in time. They are not a template for your own rules, and they are not stable: Cursor updates them frequently without announcing changes.
If you copy leaked content into your rules files hoping to change Cursor's built-in behavior, you are likely to produce conflicts between your instructions and the current internal instructions. The result is usually unpredictable output, not better output.
Use the leaked prompts as a study in how AI coding instructions are structured. Do not treat them as instructions you can extend or override. See system prompt leaks for more on what published leaks can and cannot tell you about AI behavior.
Keeping rules reusable across tools
One limitation of Cursor rules files is that they are editor-specific. If you work in Cursor for some tasks and Claude Code or Codex for others, you end up maintaining separate instruction sets for each tool. Rules that should apply to the project end up duplicated and out of sync.
A shared project record outside any single editor solves this. Write the authoritative version of each project rule once, in a central place. Reference it from your Cursor rules file and from whatever other tools you use. When a rule changes, change it in one place.
Keep your project rules in one shared record
fenbs stores project rules and approved prompts that Cursor, Claude Code, Codex CLI and other connected tools can all read. Add your most important project constraints as Decisions with the reasoning behind them. Every connected AI reads the current version at the start of a session.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
How to do this with fenbs
- Create a free account and add a project for the codebase you are working in with Cursor.
- Write your project rules in Cursor's rules format. Use the criteria above: specific, actionable, with a reason for each constraint.
- Add the most important rules as Decisions in fenbs so the reasoning is recorded and the rules are available to other connected tools.
- Connect Claude, Claude Code or another supported tool over MCP from Integrations to read the shared project context.
- Keep the rules in sync: when you update a rule in your Cursor rules file, update the corresponding entry in fenbs.
fenbs connects to Cursor over MCP, so Cursor can read your project rules, tasks and context from fenbs directly. See the Cursor guide at Integrations for setup steps. For an overview of Cursor's full feature set, see what is Cursor AI.
The practical benefit of a shared record is that when a project rule changes, you change it once. If the rule only lives in your local Cursor rules file, a colleague working in a different editor never sees the update. A rule in fenbs is readable by any connected tool, so the same constraint reaches Cursor, Claude Code and any other AI in your workflow without manual copying.