Mode frontmatter field in .mdc rules for built-in mode targeting (Agent/Plan/Debug/Ask)

Ideas Feature Requests
,
1

Feature request for product/service

Cursor IDE

Describe the request

Problem

Currently, .mdc rule files have three activation controls: alwaysApply, globs, and description. None of these allows targeting a specific built-in interaction mode (Agent, Plan, Debug, Ask).

This forces rules that are only relevant in certain modes to either:

Use alwaysApply: true, wasting context tokens in every prompt regardless of mode
Use alwaysApply: false, risking the rule not loading when it matters
Use cases

A “debug logging” rule that enforces project logging is most critical in Debug mode (where the AI adds diagnostic instrumentation) but is also needed in Agent mode (when writing new code). It’s irrelevant in Plan and Ask modes.

A “preserve existing comments” rule matters in Agent mode (code edits) but adds noise in Ask mode (read-only questions) and Plan mode (no edits happen).

Architecture/codebase-map rules are useful in Plan mode and Ask mode for answering “where does X go?” questions, but irrelevant during active debugging.

Proposed solution

Add an optional mode field to the .mdc frontmatter:

---
description: Debug logging must use the project instruments
mode: [agent, debug]
alwaysApply: true
---
mode accepts an array of built-in mode names: agent, plan, debug, ask

When the mode is present, the rule only loads in the specified modes
When mode is absent, current behavior is preserved (mode-agnostic)
mode works alongside existing alwaysApply and globs — it's an additional filter, not a replacement
This would reduce token waste from always-on rules while ensuring rules are active exactly where they matter.
4

Hey @Mihail_Popovici!

Thanks for the suggestion! Out of curiosity, have you considered using Skills? If you mention the mode in the description, the Agent will be likely to use it when that mode is used.

6

Thanks for the suggestion! Skills are useful for workflows, but they don’t solve this problem well:

  1. Maintenance burden: A skill would need to manually enumerate “use rule X in mode A, rule Y in mode B” — essentially reimplementing mode-targeting logic in prose. Every time a rule is added or its mode relevance changes, the skill must be updated, too.

  2. Scales poorly: With 50+ rules across multiple domains (architecture, C++ style, testing, documentation, utilities), maintaining a skill that maps each rule to its relevant modes becomes a parallel tracking system that can drift out of sync with the rules themselves.

  3. A mode field is declarative and local: Each rule declares its own mode relevance right in its frontmatter — no external coordinator needed. Adding a new rule just means setting mode: [agent, debug] it in that file. Nothing else changes.

The core issue is that rule activation and mode awareness are orthogonal concerns. alwaysApply and globs handle what content triggers a rule. A mode field would handle which workflow context the rule is relevant in. Skills are great for procedural workflows, but this is a metadata/filtering problem that belongs in the rule system itself.