Stop Writing Cursor Rules by Hand: A Guide to Automated Rule Generation

“The best documentation is the code itself.” — Every pragmatic developer

We’ve all been there. You start a new project, promising yourself that this time, you’ll keep the documentation up to date. You write a beautiful CONTRIBUTING.md, set up strict linting rules, and maybe even write a few guidelines for your AI assistant.

Two weeks later? The docs are stale, the linter is being ignored (or disabled), and your AI assistant is hallucinating patterns that you refactored days ago.

Enter Cursor Rules.

If you’re using Cursor, you know that .cursor/rules (or .mdc files) are the secret weapon for getting high-quality, context-aware code generation. But writing these rules manually? That feels like 2024.

In this post, we’ll explore a workflow to automatically generate and maintain Cursor rules, turning your codebase into a self-documenting system that teaches your AI assistant how to code like you.

The Manual Trap

Writing rules by hand is a losing battle. You have to:

1. Remember to update the rule when you change a pattern.
2. Write valid markdown/XML that the LLM understands.
3. Capture every edge case and nuance.

Instead of writing rules, we should be generating them.

The “Meta-Rules” Strategy

The core idea is simple: Use Cursor to write Cursor rules.

To do this effectively, we need to establish a few “foundational rules” that teach Cursor how to write rules. Once these are in place, the rest of the process becomes almost entirely automated.

1. The “Cursor Rules” Rule

First, we need a rule that defines the standard for all other rules. This ensures consistency in naming, structure, and location.

Create a file at .cursor/rules/cursor-rules.mdc:

---
description: How to add or edit Cursor rules in our project
globs: .cursor/rules/*.mdc
alwaysApply: false
---

# Cursor Rules Location

1. **Location**: Always place rule files in `PROJECT_ROOT/.cursor/rules/`.
2. **Naming**: Use `kebab-case` for filenames and always use the `.mdc` extension.
3. **Structure**:
   - Frontmatter with `description` and `globs`.
   - Clear sections for "Context", "Rules", and "Examples".
   - Positive ("Do this") and negative ("Don't do this") examples.

Now, whenever you ask Cursor to “create a rule for X,” it knows exactly how to format it and where to put it.

2. The Self-Improvement Rule

This is where the magic happens. We want a rule that encourages Cursor to proactively suggest updates to its own instructions.

Create .cursor/rules/self-improvement.mdc:

---
description: Guidelines for continuously improving Cursor rules
globs: **/*
alwaysApply: true
---

# Rule Improvement Triggers

Look for these opportunities to update rules:

- **New Patterns**: If you see a new pattern used consistently in 3+ files, suggest creating a rule for it.
- **Repeated Corrections**: If the user corrects your code in the same way multiple times, propose a rule to prevent this mistake.
- **Deprecation**: If a rule references code that no longer exists, suggest removing or updating it.

# Analysis Process

1. Compare new code with existing rules.
2. Identify patterns that should be standardized.
3. Check for consistent error handling or styling.

With this rule active, your AI assistant becomes a partner in maintaining your documentation, not just a consumer of it.

Automating Context Collection

One of the biggest challenges for AI is understanding the “big picture” of your project. Let’s automate that.

The Directory Structure Rule

Instead of manually explaining your file structure every time, generate a rule that maps it out.

Open a Cursor chat and type:

“List all source files and folders in the project, and create a new cursor rule outlining the directory structure and important files.”

Cursor will crawl your file tree and generate a rule like project-structure.mdc that explains:

• Where components live (/src/components)
• Where data is fetched (/src/lib/api)
• Where global styles are defined

The Tech Stack Rule

Similarly, you can have Cursor analyze your package.json, tsconfig.json, and other config files to create a tech-stack.mdc rule.

“Analyze my configuration files and dependencies. Create a rule that summarizes the tech stack, including versions (Next.js 14, React 18, etc.) and key libraries (Tailwind, Zustand, TanStack Query).”

This ensures that when you ask for “a new form,” Cursor knows to use react-hook-form and zod because they are part of your documented stack, rather than guessing or using vanilla HTML forms.

Generating Component-Specific Rules

The real power comes when you generate rules for specific parts of your codebase.

Let’s say you have a specific way of writing UI components (e.g., “Always use clsx for classes,” “Export named constants,” “Use a specific prop interface pattern”).

Instead of writing this down, just point Cursor to a “perfect” component you’ve already written:

“Read src/components/Button.tsx and src/components/Card.tsx. Extract the coding style, naming conventions, and structural patterns into a new rule called ui-components.mdc.”

Cursor will analyze your code and produce a rule that says:

• “Always use interface Props for prop definitions.”
• “Use clsx for conditional styling.”
• “Place helper functions outside the component.”

Best Practices for Automated Rules

1. Review Generated Rules: AI isn’t perfect. Always give the generated .mdc files a quick read to ensure they capture your intent.
2. Keep It Modular: Don’t create one giant master-rule.mdc. Break rules down by domain (database.mdc, testing.mdc, styling.mdc).
3. Use “Always Apply” Sparingly: Only set alwaysApply: true for critical rules (like the “Self-Improvement” rule). For others, let Cursor decide when they are relevant based on the globs or context.
4. Treat Rules as Code: Commit them to Git. Review them in PRs. They are part of your project’s source of truth.

Conclusion

By treating your coding guidelines as generated artifacts rather than static documents, you solve the two biggest problems in software documentation: maintenance and adherence.

Your codebase is constantly evolving. Your rules should be too. With this automated workflow, you stop fighting against entropy and start building a system that gets smarter with every commit.

So, stop writing rules by hand. Let your code speak for itself.