cursor_rules

<rule_structure_requirements>

• Required Rule Structure:

  ---
  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) to reference files
  • Example: prisma.mdc for rule references
  • Example: schema.prisma for code references </file_reference_guidelines>

<code_example_guidelines>

• Code Examples:

  • Use language-specific code blocks

  // ✅ 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>