Skip to main content

Cursor Rules – Customizing Your Development Experience

· 5 min read
Bruno Carneiro
Fundador da @TautornTech

One of Cursor's most powerful features is Rules. They allow you to create persistent instructions that guide the Agent's behavior, ensuring consistency, standardization, and complete customization of your development experience.

What are Cursor Rules?

Rules are system-level instructions that provide persistent context to the Agent. Unlike prompts in a conversation, Rules are:

  • Persistent: Automatically applied in every conversation
  • Reusable: Shared among team members
  • Contextual: Can be applied based on files, patterns, or manually
  • Versionable: Stored in .cursor/rules and versioned with Git

Types of Rules

Cursor supports four types of Rules:

1. Project Rules

Stored in .cursor/rules, versioned and scoped to your codebase. Perfect for:

  • Domain-specific knowledge
  • Project architecture patterns
  • Automated workflows
  • Templates and conventions

2. User Rules

Global rules in your Cursor environment. Used for:

  • Preferred communication style
  • Personal coding conventions
  • Development preferences

3. Team Rules

Managed in the Cursor dashboard (Team and Enterprise plans). They allow:

  • Organizational standards
  • Compliance and security
  • Company best practices
  • Mandatory enforcement

4. AGENTS.md

Simple markdown file at the project root. A simpler alternative for straightforward cases.

How Do Rules Work?

Rules are included at the beginning of the model's context, providing consistent guidance. This means:

  1. Persistent Context: The Agent always knows the project's rules
  2. Consistency: Same instructions applied in every conversation
  3. Less Repetition: No need to repeat instructions every conversation
  4. Sharing: The whole team uses the same rules

Structure of a Rule

Each Rule is a folder containing a RULE.md file:

.cursor/rules/
my-rule/
RULE.md # Main rule file
scripts/ # Helper scripts (optional)

RULE.md Format

---
description: "This rule defines standards for frontend components"
alwaysApply: false
globs: ["**/*.tsx", "**/*.ts"]
---

# My Rule

When working on components:
- Always use TypeScript
- Prefer functional components
- Use Tailwind for styling
- Follow the project's naming convention

@component-template.tsx

Types of Application

Always Apply

Applied in every conversation. Use for fundamental project rules.

---
alwaysApply: true
---

- Always use TypeScript
- Follow the project's code standards

Apply Intelligently

The Agent decides when to apply based on the description. Use for contextual rules.

---
description: "Standards for React components"
alwaysApply: false
---

When creating React components:
- Use functional components
- Prefer hooks over classes

Apply to Specific Files

Applied when files match the pattern. Use for file-type-specific rules.

---
globs: ["**/*.test.ts", "**/*.spec.ts"]
---

For test files:
- Use Jest as the framework
- Follow the AAA pattern (Arrange, Act, Assert)

Apply Manually

Applied when mentioned with @ in the chat. Use for optional rules.

---
description: "Template for creating new services"
alwaysApply: false
---

@my-rule Create a new service following this template

Practical Examples

Rule for API Standards

---
description: "Standards for creating API endpoints"
globs: ["**/api/**/*.ts", "**/routes/**/*.ts"]
---

# API Standards

When creating endpoints:
- Use Zod for validation
- Return appropriate status codes
- Include error handling
- Document with JSDoc
- Add unit tests

@api-template.ts

Rule for React Components

---
description: "Standard structure for React components"
globs: ["**/*.tsx"]
---

# React Component Standards

Components should:
- Be functional
- Use TypeScript
- Have typed props
- Follow naming convention: PascalCase
- Be in separate files

Structure:
```tsx
interface Props {
// props here
}

export function ComponentName({ prop }: Props) {
// implementation
}

### Rule for Workflows

```markdown
---
description: "Workflow for application analysis"
alwaysApply: false
---

When asked to analyze the application:
1. Run `npm run dev`
2. Capture console logs
3. Analyze performance
4. Suggest prioritized improvements

Best Practices

✅ DO

  • Be specific: Clear and concrete instructions
  • Use examples: Reference files with @filename
  • Stay focused: Smaller and more specific Rules
  • Document: Explain the "why" behind rules
  • Version control: Keep Rules in Git

❌ DON'T

  • Don't be vague: Avoid "be consistent"
  • Don't overdo it: Very long Rules are less effective
  • Don't duplicate: Reuse Rules when possible
  • Don't ignore context: Rules should make sense for the project

Day-to-Day Benefits

Consistency

  • The whole team follows the same standards
  • More uniform and maintainable code
  • Fewer debates about style

Productivity

  • Less time explaining standards
  • Agent already knows the project's rules
  • Fewer convention errors

Onboarding

  • New team members learn standards quickly
  • Living documentation that's always up to date
  • Fewer questions about "how to do it"

Quality

  • Standards applied automatically
  • Less code review about style
  • Focus on logic and architecture

Integration with Commands

Rules work perfectly with Commands. You can create Commands that use the project's Rules, creating powerful and reusable workflows.

Conclusion

Cursor Rules are fundamental to creating a truly personalized development experience. They transform Cursor from a generic tool into an assistant that deeply understands your project and its patterns.

By investing time in creating well-structured Rules, you:

  • Increase team productivity
  • Improve code quality
  • Accelerate onboarding
  • Standardize workflows

In the next article, we'll explore Cursor Commands and how to create powerful automated workflows.

Next Steps

  • Create your first Rule for a pattern in your project
  • Explore different types of application
  • Share Rules with the team
  • Read about Cursor Commands
tip

Deepen Your Knowledge

Want to learn more about Cursor? Explore our complete documentation trail:


Related Articles:

References: