metarules.mdc

---
description: Use this when you are writing new Cursor rules or updating existing rules
globs: .cursor/rules/*.mdc
alwaysApply: false
---

Search the web for documenation, tutorials and style guides to help inform the rules.
All new MDC rules MUST be created in the `.cursor/rules` directory
Each rule MUST be in a separate file
Rule files MUST use the `.mdc` extension
Each rule file starts with a frontmatter section like this:
```markdown
---
description: A description of when the rule should be used. This is a way to group related rules together. Specify the npm:library-name or pypi:library name whenever possible.
globs: Optional comman-separated list of file patterns with wildcards to identify where these rules should be applied.
alwaysApply: true or false depending if these are rules which should be applied to every conversation. This is very rarely true.
---
```

Group rules into related sections with ## headings.
Each rule should be its own list item ( - ) on its own line.
Rules should be short, as specific as possible, and they should be actionable.
Rules should be directly related to the scope as defined in the description.
Whenever possible, prefer positive framing of what to do over negative framing of what not to do.
Ignore any rules which are common knowledge and would already be followed by an LLM.

When creating rules for a programming language:
- class, functiona and variable naming conventions
- how and when to group code into modules, pacakages or other language-specific structures
- preferences about programming paradigms like functional or object-oriented programming
- preferences about usage of new language constructs
- preferences about typing and generics
- preferences about error checking and guard statements
- preferences about data schema modeling
- when to use built-in data types and when to create your own
- exeception handling best practices

When creating rules for frameworks:
- recommended directory structure of new projects
- how to group and organize compoonents
- important design conventions
- data fetching strategies
- route handling conventions
- which utility or helper functions to use and when 
- input validation best practices
- data model design best practices
- caching, data persistence and session management guidelines

When creating rules for libraries:
- which features the library should be used for
- any API keys or configuration needed
- common mistakes and how to avoid them
- recommended libraries to use with it
- how to customize or extend the library functionality, if applicable

When creating rules for specific tasks:
- important design considerations for that feature
- preferences for which libraries and frameworks to use
- common mistakes and how to avoid them