Skip to content
RuleSellBeta
Sign up

Topic · A1

Cursor 2.0 Composer Rules: Tuning Your Config for the Multi-Agent Loop

How to write .cursor/rules files that work with Cursor 2.0 Composer's 8-agent parallel execution, semantic search, and new in-app browser. The old .cursorrules approach needs updating.

The RuleSell Editorial Team

RuleSell's editors review every AI-dev-tooling guide against primary sources — GitHub issues, official docs, and maintainer statements — before publishing.

Reviewed May 30, 2026

# Cursor 2.0 Composer Rules: Tuning Your Config for the Multi-Agent Loop Cursor 2.0 shipped Composer — up to 8 parallel agents, semantic search over your codebase, and an in-app browser. Your existing .cursorrules file was written for a single-agent assistant. It needs updating. This page covers what changed, how to restructure your rules for Composer's execution model, and the specific patterns that matter most.

What changed in Cursor 2.0

The Cursor 2.0 announcement introduced three changes that affect how rules should be written: Composer with parallel agents. Cursor Composer can now run multiple agent threads simultaneously — up to 8 — working on different parts of a task in parallel. A user request that would previously produce one agent editing files now produces a planned set of sub-tasks, executed concurrently. The rules you write apply across all threads. Semantic search context. Composer 2.0 searches your codebase semantically rather than requiring file pins. The agent decides what's relevant; you don't select the context. This shifts the role of rules: they're less about directing the agent to the right files and more about defining what to do with what it finds. In-app browser as a tool. Cursor 2.0 added a browser tool, expanding the agent's capability surface. An agent that can browse is an agent that can fetch external content, trigger the lethal trifecta risk class (see /topic/mcp-security), and spend time on tasks outside your codebase. If you don't want the browser used in routine coding sessions, write an explicit deny rule.

Migrating from .cursorrules to .cursor/rules/.mdc

The .cursorrules format is a single flat file. Cursor still reads it for compatibility, but the .cursor/rules/.mdc format is how Cursor 2.0 is designed to be configured. The advantages:
  • File-glob scoping. A rule can apply only to */.test.ts (test conventions) or src/app/api/ (API conventions), not to every file.
  • Attachment modes. alwaysAttach: true means the rule is always in context. onMatch: true means it's attached only when the matched file type is in context. This keeps the context budget lower.
  • Composability.* Multiple .mdc files are evaluated independently, which means you can version and review rule changes per concern rather than as one blob.
A migration structure: `` .cursor/rules/ conventions.mdc # Stack, naming, architecture — always attached testing.mdc # Test patterns — attached when .test. is in context deny.mdc # What not to do — always attached api.mdc # API patterns — attached for src/app/api/ ` Each file has a frontmatter block: `yaml
description: "API route conventions for Next.js App Router" globs: ["src/app/api//.ts"] alwaysAttach: false
`

Writing rules for parallel execution

The most important shift for Composer 2.0. When 8 agents run in parallel, rules that assume sequential execution can cause conflicts. Avoid sequential instruction chains in shared rules. A rule that says "first check if the test passes, then refactor, then update the snapshot" assumes one agent processes it in order. In parallel mode, two agents may hit the same rule at the same time at different stages. Write rules as policies, not procedures. Instead of: ` When refactoring, first run the test suite, then make changes, then verify. ` Write: ` All refactoring changes must have a passing test run recorded in the PR. Do not submit refactoring work without test evidence. ` The second form is a constraint that applies regardless of execution order. Make deny rules explicit and complete. In single-agent mode, a missed deny rule meant one agent did something wrong. In parallel mode, it means all concurrent agents do it wrong simultaneously. Write deny rules for every category of change you'd need to manually revert: ` DENY: Do not modify prisma/migrations/ without an explicit user confirmation in the conversation. DENY: Do not delete files. Propose deletions for review. DENY: Do not use the in-app browser for tasks that don't require external information. Prefer codebase context. DENY: Do not commit to main or master directly. ` Avoid rules that depend on agent memory across threads. Parallel agents don't share working memory. A rule that says "remember the schema from the last API file you edited" will not work when two agents are editing different API files at the same time. Rules should be stateless and context-bound.

The AGENTS.md + .cursor/rules split

For teams using Cursor and other agents, the right structure is: | Layer | File | Read by | |---|---|---| | Portable context (stack, commands, conventions) | AGENTS.md | Cursor, Claude Code, Codex, Gemini CLI, Aider, Antigravity, and 15+ others | | Cursor-specific rules (Composer config, .mdc scoping, browser deny) | .cursor/rules/*.mdc | Cursor only | | Claude Code-specific hooks | CLAUDE.md | Claude Code only | Put everything you'd want in any agent in AGENTS.md. Put everything that's specific to Cursor's execution model in .cursor/rules/. If AGENTS.md and .cursor/rules/ say the same thing, AGENTS.md wins — fewer places to update. See /topic/agents-md for the full AGENTS.md reference and the symlink pattern for Claude Code.

A Composer-tuned rules structure

Here is the full deny.mdc and conventions.mdc content that accounts for Cursor 2.0's parallel execution model: deny.mdc (always attached): `markdown
description: "Hard limits for all Composer agents" alwaysAttach: true

Hard limits

  • Never modify database migration files (prisma/migrations/) without explicit user confirmation.
  • Never delete files. Propose deletions with file path and reason.
  • Never push to main or master branch.
  • Never use the in-app browser except for tasks where external documentation is explicitly needed.
  • Never install new npm dependencies without listing the package name, version, and purpose in the conversation.
  • Never generate or modify environment variable files (.env, .env.local, .env.production).
` conventions.mdc (always attached): `markdown
description: "Architecture and naming conventions" alwaysAttach: true

Architecture

  • App Router only. No Pages Router.
  • Server Components by default. Client Components only when state or browser APIs are required.
  • Database access only through Prisma — no raw SQL in application code.
  • API routes in src/app/api/. External service calls in src/lib/services/.

Naming

  • Components: PascalCase. Hooks: camelCase starting with use. Utils: camelCase.
  • Test files: collocated at the same path as the module, with .test.ts suffix.

Quality gate

  • Every non-trivial change needs a test. If you write a function, write a test. No exceptions.
  • TypeScript strict mode is enabled. Do not use any or as any.
``

What to read next

  • /topic/agents-md — the portable cross-tool context layer; put conventions here, not in .cursorrules
  • /for/cursor — RuleSell catalog filtered for Cursor-compatible assets

Sources

  • Cursor. "Cursor 2.0". Official announcement of Composer, parallel agents, semantic search, and the in-app browser. October 29, 2025.
  • Cursor. Changelog. Composer 2.5 follow-up with additional multi-agent refinements, early 2026.
  • PatrickJS. awesome-cursorrules. 39.8k-star curated .cursor/rules collection. The demand signal for this topic.
  • agents.md. AGENTS.md reference. The cross-tool context standard that Cursor reads alongside .cursor/rules/.

Frequently asked

What changed in Cursor 2.0 that affects rules?
Three things matter for rules authoring: (1) Composer can run up to 8 parallel agent threads — rules you write may apply to multiple simultaneous agents, so contradictions and scope ambiguity matter more than in single-agent mode. (2) Composer 2.0 uses semantic search over your codebase rather than file-selection or folder-pinning — rules that tell the agent 'look in src/api/' are less necessary; rules that define conventions and constraints are more important. (3) The in-app browser adds a tool leg that wasn't in 1.x — if you're using rules to restrict external access, you need an explicit deny rule for the browser tool. ([source: cursor.com/blog/2-0](https://cursor.com/blog/2-0))
Should I migrate from .cursorrules to .cursor/rules/*.mdc?
Yes, if you're on Cursor 2.0+. The .cursor/rules/*.mdc format (introduced with Cursor's rules overhaul) lets you scope rules by file glob, set attachment behavior (always-on vs triggered), and compose multiple rules files. A single .cursorrules file can't do any of that. The migration is mostly mechanical: split by concern (conventions, deny rules, test rules), assign globs, set attachment mode. Cursor still reads .cursorrules for compatibility, but the .mdc format is the current design.
What is 'semantic search' in Cursor 2.0 Composer and how does it affect rules?
In Cursor 1.x, Composer asked you to pin or select files for context. In 2.0, Composer runs semantic search across your codebase to find relevant context automatically — it reads your index, matches relevant files, and pulls them into the agent's context. Rules you write no longer need to say 'look in this folder.' They should instead define what the agent should do with what it finds: naming conventions, architecture patterns, test requirements, deny rules.
How does parallel agent execution change rule design?
In Composer 2.0, a single user request can spawn up to 8 agent threads working on different parts of the codebase simultaneously. Each thread reads the same rules. This means: (1) rules must not assume serial execution — 'first do X, then do Y' instructions may not work when two agents are running at once; (2) rule contradictions that were harmless in single-agent mode become race conditions in parallel mode; (3) deny rules are more important because eight agents can make eight times the irreversible changes before you see a review step.
Can I use the same rules in Cursor and Claude Code?
The conventions layer — stack, naming, architecture — should live in AGENTS.md and will be read by both. The execution rules — how Cursor's Composer orchestrates agents, Cursor-specific tool use, .mdc glob scoping — are Cursor-specific. Keep the shared layer in AGENTS.md and the Cursor-specific layer in .cursor/rules/. Claude Code gets CLAUDE.md or a symlink from AGENTS.md.

Related topics