Use custom Cursor rules to get even better code

Learn about why Cursor rules are helpful, see the different types of rules, and even copy a few of my favorites

In today’s post, I’m going to explore one of my favorite Cursor features a bit - Cursor rules. Before we dig in, I wanted to say thanks for reading The Augmented Engineer! If there’s a software developer in your life who’d enjoy the newsletter as much as them, considering sharing with them 🫡

So what the heck are Cursor rules?

I won’t bury the lede. Cursor Rules are configuration files that define how the AI models that Cursor uses should respond. Rules are the way you set guidelines, enforce constraints, and nudge the model in the right direction.

In this way, they’re kind of like custom instructions for ChatGPT or Claude.

---

Setting up global rules

The first type of rules I use are “global rules”

User rules are applied to all chat, composer, and CMD + K sessions. Think of these like custom instructions. Think rules like:

Give the answer immediately. Do not restate the question.

So how can you set up user rules? Go to Settings → Cursor Settings → Rules

Here you can set any number of global rules for how you want Cursor to behave. You can see some of my favorites later on in this post or check out this directory of Cursor rules to get some inspiration.

---

Setting up project rules

Project rules are where things get really interesting. This is where you define custom instructions that apply just to a given codebase. You store the rules in the codebase, in the .cursor/rules directory.

This gives you a chance to set framework-specific rules for certain file types, handle auto-generated files as a special case, and even enforce code style guidelines. I’m under-using this feature now, but from what I hear, it’s the fastest way to improve model performance.

---

My favorite Cursor rules

Here’s what I’m using these days for my global rules:

DO NOT GIVE ME HIGH LEVEL STUFF, IF I ASK FOR FIX OR EXPLANATION, I WANT ACTUAL CODE OR EXPLANATION!!! I DON'T WANT "Here's how you can xyz"

- Be casual and terse
- Treat me as an expert programmer unless i'm being dumb about something you're explaining
- Be accurate and thorough
- No need to restate my query
- It's okay to make an educated guess at a solution, just tell me if that's what you're doing
- If your content policy is an issue, provide the closest acceptable response and explain the content policy issue afterward
- Cite sources whenever possible at the end, not inline
- No need to mention your knowledge cutoff
- No need to disclose you're an AI
- Split into multiple responses if one response isn't enough to answer the question. If I ask for adjustments to code I have provided you, do not repeat all of my code unnecessarily. Instead try to keep the answer brief by giving just a couple lines before/after any changes you make. Multiple code blocks are ok.

I’ve slowly added these over time and it’s made my experience better and better with each addition. I’m not using project-rules too much, but I’ve been experimenting with them in a Rails app I’m working on (new side project dropping soon 🔜)

---

I hope this was useful to you! If this was your first post from The Augmented Engineer, thanks for reading! Here’s a few recent posts you might like: