logo
27

Writing Cursor Rules

⏱️ 15 min

Cursor Rules Guide

What Are Cursor Rules?

Cursor Rules tell AI how your project works. By defining rule files, you give AI context about:

  • Your coding standards
  • Common patterns and conventions
  • Mistakes to avoid
  • Specific technical requirements

Required Rule Structure

Every rule file should follow this 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

File References

# Use [filename](mdc:path/to/file) to reference files

[prisma.mdc](mdc:.cursor/rules/prisma.mdc) for rule references
[schema.prisma](mdc:prisma/schema.prisma) for code references

Code Examples

Use language-specific code blocks in rules:

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

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

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

Rule Maintenance

  • Update rules when new patterns emerge
  • Add examples from actual codebase
  • Remove outdated patterns
  • Cross-reference related rules

Best Practices

  • 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

Rule File Locations

  • Project-level: .cursor/rules/ - project-specific rules
  • User-level: ~/.cursor/rules/ - cross-project universal rules

Example: TypeScript Rule

---
description: TypeScript coding standards for this project
globs: '**/*.ts, **/*.tsx'
alwaysApply: true
---

-   **Type Safety**

    -   Always use explicit return types for functions
    -   Avoid `any` type, prefer `unknown` for uncertain types
    -   Use strict null checks

-   **Naming Conventions**

    -   Interfaces: PascalCase with `I` prefix (e.g., `IUser`)
    -   Types: PascalCase (e.g., `UserRole`)
    -   Constants: UPPER_SNAKE_CASE

-   **Code Organization**
    -   One component per file
    -   Group imports: external, internal, types
    -   Export from index files

Example: Git Commit Rule

---
description: Git commit message standards
globs: ''
alwaysApply: false
---

-   **Commit Format**: `type(scope): description`

-   **Types**:

    -   ✨ feat: New features
    -   🐛 fix: Bug fixes
    -   📝 docs: Documentation
    -   ♻️ refactor: Code restructuring
    -   ✅ test: Tests

-   **Best Practices**:
    -   Keep commits atomic and focused
    -   Write in imperative mood
    -   Explain why, not just what

Next Steps

Check out Git Commit Conventions & Emoji to level up your commit quality.

[VIBE_CODING_LAB_BANNER]