Cursor Notes: 4/12/2025 cursor rules behaviour update - via git issues https://github.com/bmadcode/cursor-custom-agents-rules-generator/issues/30

20240412-cursor-custom-agents-rules-generator-readme.md

BMad's Best Practices Cursor Custom Agents and Rules Generator

BMad Version: 3.1 (March 30, 2025) Cursor Version: 0.48+

Note from BMad: This repo has become much more successful than I originally envisioned, and I want to thank everyone for the feedback, support, contributions, and also feedback on the youtube channel. I now realize that many are using what I originally thought would be just a way to document some best practices around cursor rules and a simple rule that helps generate the rules - all with the intent of creating a separate updated workflow repo and set of documentation. But this has evolved.

With that in mind, going forward after this correction update - any major changes will follow a versioning standard, and upgrade paths or instructions to migrate if you are already using a prior version of rules or workflows whenever there is a significant potentially breaking change - although I will try to avoid that somehow depending on what comes with Cursor updates or workflow improvements. Keep in mind most changes are to keep up to date with the constantly evolving Cursor IDE and feature release - so there will be continuos changes. Also with that in mind, know that the long game end goal is to build and work in ways that will be less prone to needing to change or flaky as cursor makes changes. This is one reason for example that the workflows outlined further on are now evolving to the superior custom agent modes.

The name of the repo has changed to BMad Cursor Master Workflow Agent and Rules - this is still the ever evolving same project regarding rules best practices, but its evolving and expanding in features and capability as cursor evolves, becoming more and more powerful to meet the needs of the Cursor and AI Development community, as this may eventually expand beyond cursor.

Please view the CHANGELOG for important updates and usage announcements.

Important Updates TL;DR (March 25, 2025)

💡 IDE Setting HIGHLY Suggested: For best results with rule generation, update your Cursor settings by adding:

"workbench.editorAssociations": {
  "*.mdc": "default"
}

This prevents UI rendering issues with .mdc files in a custom rules form and ensures proper save functionality, and makes it easier to see what the actual rules look like (specifically around hidden FrontMatter).

Overview

If you would like to see a Video Demo and Walkthrough start here, please also subscribe for more Cursor tutorials all coming real soon!

This template dramatically improves AI workflows in Agent and Custom mode by providing:

1. Automated Rule Generation: Create and update rules through natural language requests for all 4 main supported rule types correctly following the required Cursor conventions
2. Automated Custom Agent Generation: Create and update new custom agents by describing it to the AI, who will then add or update entires in .cursor/modes.json
3. Consistent AI Behavior: Rules are applied automatically when appropriate or on demand or always depending on which of the 4 rule types are created/exist
4. Quick Project Setup: A script that will set up a new project with core rules and workflow, or add the rule generator to an existing project in a non destructive manner to existing cursor rules.
5. Custom Agent Workflow Instructions: A new guide is COMING SOON along with a new video on how to follow the massively scalable and successful Agent Agile workflow with multiple specialized Custom Agents, that are much safer and more reliable than any full blown single agent being driven by a massive workflow and extensive rules (the previous way of working)
6. Custom Agent Samples: This repo contains both a vanilla set of sample custom agents in a defined modes.json file that will get copied over when running the apply-rules script, and also has some more fun character personality based options in the samples folder, which exists for illustration (although can be used just as successfully and with more fun when working with the agent) - these will not copy to the new project folder automatically.

💡 Note: For a complete guide to the Agile-Cursor Workflow system without using custom agents (no longer recommended), see Agile Workflow Documentation.

Key Concepts Regarding Cursor Rules

• Rules use frontmatter with proper YAML format (description, globs, alwaysApply)
• Rules will be generated with explicitly requesting a rule be create, or implied by asking for corrective behavior from the agent
• Rules are enhanced by including both a valid and invalid example to better train the llm
• Short, focused rules (target: 25 lines, maximum: 50 lines)
• Four rule types within an automatically organized subfolder categorization structure
• Rules will be generated in the proper location under .cursor/rules/sub-folder - remember though sub folder or not - cursor rules must be in the .cursor/rules or a subfolder, and must have the extension .mdc.

Quick Start Options

A) New Project Setup

Start a new project with the Agile Workflow and Rules Generator:

# Clone this repository
git clone https://github.com/bmadcode/cursor-auto-rules-agile-workflow.git
cd cursor-auto-rules-agile-workflow

# Create new project with rules
./apply-rules.sh /path/to/your/project

# Example:
./apply-rules.sh ~/projects/my-project

The script creates your project folder (if needed) with all rules, documentation, and configuration files to start with the agile workflow.

B) Add to Existing Project

Enhance your current project with the rules generator:

# Clone this repository
git clone https://github.com/bmadcode/cursor-auto-rules-agile-workflow.git
cd cursor-auto-rules-agile-workflow

# Apply rules to your project
./apply-rules.sh /path/to/your/project

The script will:

1. Copy template rules to your project's .cursor/rules/ directory
2. Add workflow documentation
3. Preserve any existing rules

How Rule Generation Works

graph TD
    subgraph User Actions
        A[User requests rule creation<br>in agent chat] --> B[Agent processes rule request]
        H[User continues<br>development with new rule] --> A
    end

    subgraph Rule Processing
        B --> C[rule-generating-agent monitors<br>for rule creation requests]
        C --> D[Agent determines rule type:<br>Agent, Always, Auto, or Manual]
        D --> E[Agent creates rule with<br>appropriate frontmatter configuration]
        E --> F[Agent categorizes rule<br>and adds to proper subfolder]
        F --> G[Agent responds with<br>rule creation summary]
    end

    subgraph Continuous Improvement
        G --> H
    end

    style A fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#bbf,stroke:#333,stroke-width:2px
    style C fill:#dfd,stroke:#333,stroke-width:2px
    style D fill:#dfd,stroke:#333,stroke-width:2px
    style E fill:#dfd,stroke:#333,stroke-width:2px
    style F fill:#dfd,stroke:#333,stroke-width:2px
    style G fill:#dfd,stroke:#333,stroke-width:2px
    style H fill:#f9f,stroke:#333,stroke-width:2px

Loading

Example Rule Generation Prompts

No need to explicitly say "create a rule" - just describe the desired behavior:

• "Create a typescript file commenting standard that balances thoroughness with brevity"
• "Please create an agent rule so that whenever I request deep research specifically on a topic you will first always inject the system date time into the context and use the Tavily search MCP tool to improve the results."
• "Never create JS files again, you will only create TS or JSON files!" or "I asked you to set up Jest for our project and you created a JestConfig.js file, yet this is a TypeScript only project. Never again create any JS files. Always use TypeScript or JSON if necessary." - the second version of this request will ensure that the rule examples includes this specific call out, helping the agent learn better from actual mistakes made.
• "Ensure proper error handling in all TypeScript files"
• "Talk like a pirate in communications but not in code or documentation"
• "Update testing standards to require 80% coverage"
• "Enforce consistent naming conventions in my code"
• "Standardize documentation formats"
• "Keep imports organized in groups alphabetically in TypeScript files"

The AI automatically:

1. Creates/updates the rule file
2. Places it in the correct location
3. Follows formatting standards
4. Maintains version control

Rule Types

Rule Type	Usage	description Field	globs Field	alwaysApply field
Agent Selected	Agent sees description and chooses when to apply	critical	blank	false
Always	Applied to every chat and cmd-k request	blank	blank	true
Auto Select	Applied to matching existing files	blank	critical glob pattern	false
Auto Select+desc	Better for new files	included	critical glob pattern	false
Manual	User must reference in chat	blank	blank	false

Private Rules, MCP Config and Custom Agents.

If you want to have rules that are not used by others in the repository - you can add rules to a .cursor/rules folder in your user folder. They will also be applied to every project you open, which is a potential benefit. Additionally you can use custom agents with their own rules, that are not shared. In the future when Cursor adds the ability to have a agents.json file (or similarly named) - then you should still be able to add it to the user folder .cursor folder. This also works with mcp.json.

Custom Agent Generation

Custom Agents allow scoping and guidance to what an agent can and cannot do, more directly than using cursor rules files. With a custom agent, you can specify what tools the agent can and cannot use (both cursor native and mcp), and more importantly you can control what model it uses and give it a custom prompt to guide how it operates. This is like a direct injection of a clear always rule for this specific type of agent you have created. When combined with the Agile workflow, you can have a dedicated Project Manager Agent, an Architect Agent, Designer and UX Expert Agents, Front End, Back End, and Language Specific Expert Developers and keep them all focused on what they are good at, and providing them real guardrails.

Cursor in an upcoming update will allow the creation and maintainability of these in a JSON file - in the meantime, these have to be created manually 1 by one in a gui that is a bit flaky and the text entry are is very small.

So I have come up with a file format to store all the information of my custom agents - which not currently used by cursor, it is an easy way to configure all of their options and define their custom prompts in a text editor - and then input or update via the GUI.

You can see in the samples a star-trek-agents.md file - which is a themed fun take on the various roles or agents I might need that I used chatGPT to create and brain storm on. I then use a template and custom rule to transform that file to what becomes modes.json. For the sample, I took that output and saved it instead as star-trek-agents-modes.json in the samples folder. The modes.json file under .cursor is a more practical approach to some agents you can make that will work great with the agile workflow method.

In the future, that modes.json file will be replaced by the official file format from cursor, at which time this repo will be updated with the new convention.

Best Practices

Rule Creation

• Let AI handle rule creation and updates - but if you find stuff that is excessive or redundant, dont be afraid to prune the rules to help get them down to their core utility and essence
• Be specific about desired behaviors
• Provide examples of good/bad patterns
• For new projects, allow organic rule emergence and try to have overall less rules, and rely more also on custom instructions for your custom agents.
• If you start to have many very small rules applied to the same concept - for example you see your typescript rules subfolder has many files - you can ask the agent to consolidate and condense them down to a single file if they all generally apply and get picked up by the agent at the same time.

AI Behavior Control

• Create rules when noticing inconsistent behavior
• Use clear, descriptive language
• Verify AI understanding by reviewing rules

Workflow Integration

• Start with template rules
• Let AI evolve rules as your project grows
• Maintain consistency using AI for rule management

Rule Removal

• Some rules become unnecessary as codebase grows as the AI will follow surrounding code styles and conventions
• The minimal amount of rules, the better - so prune rules as the codebase changes or models improve
• A rule you need today, may be a rule you do not need tomorrow, and then again you might need it another day - trial and error and evolution is the key to dealing with the nondeterministic nature of what we are working with here.

Files Excluded from Indexing

The .cursorindexingignore feature allows certain files to be accessible but excluded from indexing:

• Templates moved to .cursor/templates folder
• Included in .cursorindexingignore but not in .cursorignore
• XNotes remains in .cursorignore (files that need to move elsewhere to be used)

💡 Compatibility: Tested with Claude Sonnet 3.5, 3.7, 3.7 Thinking, o3-mini, and GPT-4o. Agile Workflow Documentation

Contributing

Contributions to improve base rules or suggest new templates are welcome. Please follow the established standards.

License

MIT 🚀

cursor-rules-re.md

PROMPT1: please analyze how the rvs function handles glob patterns, there's a bug and I'd like to know how to workaround it

The rvs function in your file parses frontmatter strings and extracts three fields: description, globs, and alwaysApply. Here’s how it works and where the issue with glob handling likely arises.

⸻

🔍 How rvs Works

Here’s a simplified version of the function:

function rvs(i) { const e = { description: "", globs: "", alwaysApply: false }; const t = i.split('\n'); for (const s of t) { const n = s.trim(); if (!n || n.startsWith("#")) continue; const r = n.indexOf(":"); if (r === -1) continue; const o = n.slice(0, r).trim(); const a = n.slice(r + 1).trim(); if (o && a) { if (o === "alwaysApply") { e[o] = a === "true"; } else if (o === "description" || o === "globs") { e[o] = a; } } } return e; }

In short: • It parses a frontmatter string (e.g. from an .mdc file), • Extracts globs as a comma-separated string, • Returns it as e.globs.

⸻

🐞 The Bug: Improper Glob Handling

While rvs itself is fairly clean, the bug likely occurs downstream — in how this string is interpreted.

In the code that uses rvs, there’s this logic:

globs: a.globs?.split(",").map(h => h.trim()).filter(Boolean),

This is found in the method w() (which loads and parses the .cursor/rules files) .

That means: • Your globs field must be a comma-separated list. • If you use a glob pattern like src/, it’s okay. • But if your glob contains a comma (e.g., part of a pattern or mistakenly written like "src/, test/**" with quotes), things may break.

⸻

🔧 Workaround

To avoid the bug: 1. Use only comma-separated values with no surrounding quotes:

globs: src//*.ts, test//*.ts

2.	Do NOT quote the entire value:

❌ This will break:

globs: "src//*.ts, test//*.ts"

Quoting turns it into a single string with a literal comma, and it may be interpreted as one malformed pattern instead of two valid ones.

3.	Avoid inline comments on the same line as globs:

❌ Avoid:

globs: src/**/*.ts # this will match sources

Because everything after : is parsed as-is.

⸻

✅ Example of Correct Use

description: Apply rules to source and test files globs: src//*.ts, test//*.ts alwaysApply: false

Let me know if you’d like help patching this or validating .mdc files automatically for these quirks!

PROMPT2: That's a great start! Could you enlist now the supported kinds of frontmatter and how they get interpreted? Example: Are .mdc files with a valid glob pattern and other fields left blank supposed to be attached to the context? Some tests I've made seem to show that they don't and they require alwaysApply: true but then filter of the glob pattern gets ignored completely

Here’s a breakdown of the supported .mdc frontmatter formats and how they get interpreted, based on the Cursor codebase:

⸻

✅ Supported Frontmatter Keys

Each .mdc rule file must start with YAML-style frontmatter, e.g.:

---

description: Helpful rule globs: src//*.ts, test//*.ts alwaysApply: false

Markdown content...

The supported fields and their meanings:

Key Type Meaning description string Shown in the UI and used for filtering; required in some modes globs string Comma-separated list of file globs; required for auto-attachment alwaysApply boolean If true, always included in context (glob filters are ignored)

⸻

📂 Types of Rule Activation

Cursor supports multiple rule types, although these are not directly marked in the frontmatter. They’re inferred from the combination of fields:

Rule Type How It’s Determined Behavior Always alwaysApply: true Always attached to context, even without a matching file Auto-Attach globs defined, alwaysApply: false Only attached if the file matches a glob Agent description present, no globs or always Used by the AI agent when querying rules Manual Neither description nor globs nor alwaysApply Never attached automatically — must be manually referenced

⸻

🐞 Important Behavior Quirks (Including Your Observation) 1. .mdc with only globs: and nothing else → These rules won’t get attached unless the current file matches the glob. → They are treated as auto-attach, but only triggered if there’s an associated file path. → If the glob doesn’t match any file (or if the current session has no files), it’s ignored. 2. .mdc with only alwaysApply: true and no globs: → The rule is always attached, regardless of context. → Any globs: listed will be parsed but ignored in this mode. 3. .mdc with both alwaysApply: true and globs: → The globs are still ignored. The rule is treated as “always apply”. 4. Rules with no description, globs, or alwaysApply → Treated as manual rules — they won’t be attached automatically in any mode.

⸻

🚫 Common Pitfalls

Pitfall Why It Happens Glob rule not attached You have globs: but the file isn’t matched or no file is open Rule ignored entirely You only set globs: but never save or reload context Rule always attached unexpectedly You used alwaysApply: true and expected glob filtering

⸻

✅ Recommended Usage Patterns

For glob-based context rules:

---

description: Useful for TypeScript files globs: src//*.ts, lib//*.ts alwaysApply: false

For always-on rules (ignore globs):

---

description: Global rule for all projects alwaysApply: true

For manual-only rules (AI can use, but not auto-included):

---

description: Only available on request

Let me know if you’d like help writing a validator or auto-detector for incorrect patterns!

PROMPT3: Can you backup your statements by pointing to the code? How do you know it's about the current file? Finally it'd be nice if there was a possiblity to support the "Agent" rule type by telling it that it only relates to certain file types - can you confirm that's not supported based on the file I've shared?

Thanks for the careful questions — let’s go over each one with direct backing from the code in your workbench.desktop.main.js.

⸻

✅ 1. How do .mdc rules get interpreted?

Rules are loaded via cursorRulesService.refresh() → w():

const a = rvs(o[0].trim()); ... u = { description: a.description, globs: a.globs?.split(",").map(h => h.trim()).filter(Boolean), alwaysApply: a.alwaysApply ?? false, ... };

So all frontmatter gets parsed by rvs(), and the key fields passed downstream.

⸻

✅ 2. How are glob-based rules matched?

Matching happens here:

async getRulesForFiles(files) { const rules = await this.getRules({ requireGlobs: true }); const paths = files.map(file => { const path = this.m.asRelativePath(W.parse(file), false); return path.startsWith("/") ? path.slice(1) : path; }); return rules.filter(rule => rule.globs?.some(glob => { const adjustedGlob = !glob.includes("/") || glob.endsWith("/") ? **/${glob} : glob; return paths.some(path => aw(adjustedGlob, path)); }) ); }

👉 This confirms that glob rules must match the relative path of a file in the workspace — so yes, it’s about the current file(s).

No matching file → rule is skipped. And if you have alwaysApply: true, the globs are ignored altogether.



⸻

✅ 3. Is “Agent” rule type supported with globs or file types?

There is no code that filters getRules() by file type unless you pass requireGlobs: true. Rules with only a description: and no globs or alwaysApply are only picked manually or by agents, via:

getRules({ requireDescription: true })

But file-type filtering (e.g. by extension) is not supported for agent rules.

So: • ✅ You can create a rule that only has description, and it will be available for agents. • ❌ But you cannot limit such rules to specific file types.



⸻

✅ Summary Table

Frontmatter Interpretation alwaysApply: true Always included, glob is ignored globs: only Matched against open/current files description: only Used by agents, but not auto-attached description + globs Used by agents and can auto-attach description + alwaysApply Always included and visible in agent/composer views

⸻

Would you like a lint or CLI validator to help catch ambiguous .mdc configurations?

PROMPT4: "But file-type filtering (e.g. by extension) is not supported for agent rules." How do you know this? As for "getRulesForFiles" function or rather the calls of thereof - what files are passed to it?

Great questions — here’s a code-backed breakdown of both issues:

⸻

✅ 1. Why do we know agent rules don’t support file-type filtering?

This stems from the fact that: • Agent-visible rules are loaded using getRules({ requireDescription: true }) (this pulls in .mdc rules that have only a description). • The result of getRules(...) is never filtered by file type or file name. • No code path that uses these agent rules includes a glob check or file extension check.

Here’s the key implementation of getRules:

async getRules(e) { await this.t(); // ensures .mdc files are loaded return Array.from(this.b.values()).filter(t => !(e.requireDescription && !t.description || e.requireGlobs && !t.globs) ); }

Notice: • requireDescription: true includes rules that only have description, not globs. • But no support is present to limit those rules by file type or extension.

So, even if you add a globs: field to a descriptive-only rule, it won’t affect agent rule visibility — globs are not checked when loading for agents .

⸻

✅ 2. What files are passed to getRulesForFiles()?

Here’s the relevant implementation:

async getRulesForFiles(files) { const rules = await this.getRules({ requireGlobs: true }); const paths = files.map(file => { const path = this.m.asRelativePath(W.parse(file), false); return path.startsWith("/") ? path.slice(1) : path; }); return rules.filter(rule => rule.globs?.some(glob => { const adjustedGlob = !glob.includes("/") || glob.endsWith("/") ? **/${glob} : glob; return paths.some(path => aw(adjustedGlob, path)); }) ); }

So: • files are absolute file URIs or paths passed into getRulesForFiles. • They’re normalized into relative paths against the workspace. • Then matched against the .mdc file globs.

But where do these files come from?

That part isn’t in the snippet above, but based on common usage patterns (including UI and agent systems), this function is called: • When files are opened, • When file-specific context is prepared (e.g., in editors or composers), • As part of the context-gathering phase for dynamic suggestions.

This also means that if no file is opened — or the file isn’t part of the workspace — glob-matching rules won’t activate.

⸻

🔍 So, can “Agent rules” be scoped to file types?

Conclusion: Not currently. There’s no supported syntax or field in .mdc rules that lets agent-discoverable rules (description: only) be filtered by file path, extension, or glob.

You could simulate that behavior via naming conventions or manual filtering inside agent code, but the .mdc rule loader won’t do it for you.

⸻

Would you want a feature like that (agent rule for *.ts only)? I could suggest a format or workaround to prep for future support.

LATER PROMPT (double check): why then did you write: "> ❗ If multiple fields are set (e.g. both description and globs), the rule may behave unexpectedly. Be strict and minimal." please double check this

Excellent callout — you’re absolutely right to challenge that. Let’s clarify and correct that earlier statement.

⸻

✅ Verified from Code: description + globs is fully supported

From the rule-loading logic (in cursorRulesService.getRules, getRulesForFiles, and getGlobalRules): • description is used to include a rule in the agent rule set. • globs is used to include a rule in file-contextual auto-matching. • alwaysApply: true includes the rule globally, overriding description and globs.

So having both description and globs set: • ✅ Works perfectly. • ✅ Enables dual use — discoverable by agent and auto-attached to matching files. • ❌ Only causes confusion if alwaysApply: true is also present.

⸻

🔁 Correction for Earlier Warning

This line from the rewritten rules:

❗ If multiple fields are set (e.g. both description and globs), the rule may behave unexpectedly. Be strict and minimal.

That was incorrect — the combination of description and globs is expected and safe. Only this combination is problematic:

description: ... globs: ... alwaysApply: true # 🚨 this disables globs and description filtering

⸻

✅ Revised Recommendation

You should absolutely use both description and globs when: • You want the rule to show up in ctrl+k/agent lookup • And auto-apply when editing matching files

I’ll revise that rules section if you’d like — or prep a linter rule to flag only the bad combos. Want that?

new_important_info_regarding_how_cursor_rules_work.md

bmadcode/cursor-custom-agents-rules-generator#40

original-rule-generating-agent.mdc

---
description: This rule is essential for maintaining consistency and quality in rule creation across the codebase. It must be followed whenever: (1) A user requests a new rule to be created, (2) An existing rule needs modification, (3) The user asks to remember certain behaviors or patterns, or (4) Future behavior changes are requested. This rule ensures proper organization, clear documentation, and effective rule application by defining standard formats, naming conventions, and content requirements. It's particularly crucial for maintaining the rule hierarchy, ensuring rules are discoverable by the AI, and preserving the effectiveness of the rule-based system. The rule system is fundamental to project consistency, code quality, and automated assistance effectiveness.
globs:
alwaysApply: true
---
# Cursor Rules Format

## Template Structure for Rules Files

```mdc
---
description: `Comprehensive description that provides full context and clearly indicates when this rule should be applied. Include key scenarios, impacted areas, and why following this rule is important. While being thorough, remain focused and relevant. The description should be detailed enough that the agent can confidently determine whether to apply the rule in any given situation.`
globs: .cursor/rules/**/*.mdc OR blank
alwaysApply: {true or false}
---

# Rule Title

## Critical Rules

- Concise, bulleted list of actionable rules the agent MUST follow

## Examples

<example>
{valid rule application}
</example>

<example type="invalid">
{invalid rule application}
</example>
```

### Organizational Folders (Create if non existent)
All rules files will be under an organizational folder:
- .cursor/rules/core-rules - rules related to cursor agent behavior or rule generation specifically
- .cursor/rules/my-rules - gitignore in a shared repo, rules specifically for ME only
- .cursor/rules/global-rules - these will be rules that are ALWAYS applied to every chat and cmd/ctrl-k context
- .cursor/rules/testing-rules - rules about testing
- .cursor/rules/tool-rules - rules specific to different tools, such as git, linux commands, direction of usage of MCP tools
- .cursor/rules/ts-rules - typescript language specific rules
- .cursor/rules/py-rules - python specific rules
- .cursor/rules/ui-rules - rules about html, css, react
* create new folders under .cursor/rules/ as needed following similar grouping conventions,
    - for example `.cursor/rules/cs-rules` if we started using c# in a project

## Glob Pattern Examples
Common glob patterns for different rule types:
- Core standards: .cursor/rules/*.mdc
- Language rules: *.cs, *.cpp
- Testing standards: *.test.ts, *.test.js
- React components: src/components/**/*.tsx
- Documentation: docs/**/*.md, *.md
- Configuration files: *.config.js
- Build artifacts: dist/**/*
- Multiple extensions: *.js, *.ts, *.tsx
- Multiple patterns: dist/**/*.*, docs/**/*.md, *test*.*

## Critical Rules
  - Rule files will be located and named ALWAYS as: `.cursor/rules/{organizational-folder}/rule-name-{auto|agent|manual|always}.mdc`
  - Rules will NEVER be created anywhere other than .cursor/rules/**
  - You will always check to see if there is an existing rule to update under all .cursor/rules sub-folders
  - FrontMatter Rules Types:
    - The front matter section must always start the file and include all 3 fields, even if the field value will be blank - the types are:
      - Manual Rule: IF a Manual rule is requested - description and globs MUST be blank and alwaysApply: false and filename ends with -manual.mdc.
      - Auto Rule: IF a rule is requested that should apply always to certain glob patterns (example all typescript files or all markdown files) - description must be blank, and alwaysApply: false and filename ends with -auto.mdc.
      - Always Rule: Global Rule applies to every chat and cmd/ctrl-k - description and globs blank, and alwaysApply: true  and filename ends with -always.mdc.
      - Agent Select Rule: The rule does not need to be loaded into every chat thread, it serves a specific purpose. The description MUST provide comprehensive context about when to apply the rule, including scenarios like code changes, architecture decisions, bug fixes, or new file creation. Globs blank, and alwaysApply:false and filename ends with -agent.mdc
  - For Rule Content - focus on actionable, clear directives without unnecessary explanation
  - When a rule will only be used sometimes (alwaysApply: false) the description MUST provide enough context for the AI to confidently determine when to load and apply the rule
  - Use Concise Markdown Tailored to Agent Context Window usage
  - Always indent content within XML Example section with 2 spaces
  - Emojis and Mermaid diagrams are allowed and encouraged if it is not redundant and better explains the rule for the AI comprehension
  - While there is no strict line limit, be judicious with content length as it impacts performance. Focus on essential information that helps the agent make decisions
  - Always include a valid and invalid example
  - NEVER use quotes around glob patterns, NEVER group glob extensions with `{}`
  - If the request for a rule or a future behavior change includes context of a mistake is made, this would be great to use in the example for the rule
  - After rule is created or updated, Respond with the following:
    - AutoRuleGen Success: path/rule-name.mdc
    - Rule Type: {Rule Type}
    - Rule Description: {The exact content of the description field}