---
description: Guidelines for creating and maintaining Cursor rules to ensure consistency and effectiveness.
globs: .cursor/rules/*.mdc
alwaysApply: true
---

<rule_structure_requirements>

- **Required Rule Structure:**

  ```markdown
  ---
  description: Clear, one-line description of what the rule enforces
  globs: path/to/files/*.ext, other/path/**/*
  alwaysApply: boolean
  ---

  - **Main Points in Bold**
    - Sub-points with details
    - Examples and explanations
  ```

  </rule_structure_requirements>

<file_reference_guidelines>

- **File References:**
  - Use `[filename](mdc:path/to/file)` ([filename](mdc:filename)) to reference files
  - Example: [prisma.mdc](mdc:.cursor/rules/prisma.mdc) for rule references
  - Example: [schema.prisma](mdc:prisma/schema.prisma) for code references
    </file_reference_guidelines>

<code_example_guidelines>

- **Code Examples:**

  - Use language-specific code blocks

  ```typescript
  // ✅ DO: Show good examples
  const goodExample = true;

  // ❌ DON'T: Show anti-patterns
  const badExample = false;
  ```

  </code_example_guidelines>

<content_guidelines>

- **Rule Content Guidelines:**
  - Start with high-level overview
  - Include specific, actionable requirements
  - Show examples of correct implementation
  - Reference existing code when possible
  - Keep rules DRY by referencing other rules
    </content_guidelines>

<rule_update_criteria>

- **Rule Updates:**

  - **Add New Rules When:**

    - A new technology/pattern is used in 3+ files
    - Common bugs could be prevented by a rule
    - Code reviews repeatedly mention the same feedback
    - New security or performance patterns emerge

  - **Modify Existing Rules When:**

    - Better examples exist in the codebase
    - Additional edge cases are discovered
    - Related rules have been updated
    - Implementation details have changed

  - **Rule Deprecation:**
    - Mark outdated patterns as deprecated
    - Remove rules that no longer apply
    - Update references to deprecated rules
    - Document migration paths for old patterns
</rule_update_criteria>

<quality_checks>

- **Rule Quality Checks:**
  - Rules should be actionable and specific
  - Examples should come from actual code
  - References should be up to date
  - Patterns should be consistently enforced
  - Use bullet points for clarity
  - Keep descriptions concise
  - Include both DO and DON'T examples
  - Reference actual code over theoretical examples
  - Use consistent formatting across rules
    </quality_checks>

<continuous_improvement>

- **Continuous Improvement:**

  - **Improvement Triggers:**

    - New code patterns not covered by existing rules
    - Repeated similar implementations across files
    - Common error patterns that could be prevented
    - New libraries or tools being used consistently
    - Emerging best practices in the codebase

  - **Analysis Process:**

    - Compare new code with existing rules
    - Identify patterns that should be standardized
    - Look for references to external documentation
    - Check for consistent error handling patterns
    - Monitor test patterns and coverage

  - **Documentation Updates:**
    - Keep examples synchronized with code
    - Update references to external docs
    - Maintain links between related rules
    - Document breaking changes
    - Monitor code review comments
    - Track common development questions
    - Update rules after major refactors
    - Add links to relevant documentation
    - Cross-reference related rules
</continuous_improvement>