
Lesson Description
The "Cursor AI Rules" Lesson is part of the full, Cursor & Claude Code: Professional AI Setup course featured in this preview video. Here's what you'd learn in this lesson:
Steve discusses how Cursor rules are persistent instructions developers define for AI tools to follow every time they edit or interact with a codebase. Cursor rules eliminate the need for prompts to contain the same guardrails every time and can help return higher-quality and more accurate results. The rules can be defined at the project level or the user level.
Transcript from the "Cursor AI Rules" Lesson
[00:00:00]
>> Steve Kinney: So the first piece of that is these cursor rules. Cursor rules are just persistent instructions. That way I do not have to type stuff like I need it to be accessible. I need it to be responsive design. Now, that one I got on its own like that.
[00:00:14]
We use BUN instead of NPM for installing things. Don't install js DOM. I already have Happy DOM installed. Ask me how I'm coming up with these so quickly, cuz I've written them, right? And a lot of times it is a living document, which is. It does thing you hate.
[00:00:31]
You update rules. Hopefully it does not do thing you hate. If it does, you either a use stronger language or get more specific. Like there's some, you know, some thinking on your part that has to happen, right? But the rules are persistent instructions that you define. And ideally, and there's some nuance to how this works, like not even.
[00:00:49]
Like maybe sometimes it reads it. Like you can tweak which ones get read, when and why. And that's important because those rules count towards your context window, right? And so let's say you have a whole bunch of rules for how you want a REACT component to get written.
[00:01:07]
Those are good rules. I love that for you. You probably don't need to take them up in the context window if you're making an API endpoint, right? And so you can kind of be a little. It's not like you want all your rules followed all the time or included all the time, because sometimes you don't want rules that don't matter included.
[00:01:23]
I don't need any mention of BUN mentioned when we're writing css, so on and so forth. There's kinda two types of rules. One I use and one that maybe I should use, but I don't. Project level rules. These are like in your project file, in the case of cursor, they're in .cursor/rules.
[00:01:47]
They are MDC files. I assume the C is cursor. They're like markdown files with some YAML front matter that cursor cares about. You can commit them into Git and share them with your team. Again, you can say what frameworks or. Rylan and I have one project that he's working on right now, which is he actually has a system where it's like every task or whatever, any big thing actually goes into a CSV file and he has to approve it by flipping the little boolean from false to true.
[00:02:23]
And then it has to work down that list and he curates the list so it's like if you get something that looks bigger than a tiny little change, it goes onto the spreadsheet. I will triage it and put it in the right order and then you can go do the thing.
[00:02:38]
You can get from everything from your coding style to how we roll and what we're doing in this case. So you can have in the project level, you can also have user level rules. I don't know that I at this point in my life consistently feel like outside of main repo, where I'd have to navigate somewhere else to tweak them and change them.
[00:02:59]
And applying to all of my projects, obviously project level ones supersede the user level ones one day. I aspire to have a set of rules that I'm so comfortable with. I want them applied to all of my projects. I'm not fully there yet. Also, in the line of work that I do where, like I said, I use BUN at work, I'm not gonna make you all install bun.
[00:03:19]
So I use NPM here. I can't live like that. So they're usually project level for me. But if you're making lots of tiny repos or stuff like that, but they're also not checked into version control at that point, your mileage can vary. I tend to use project level ones, so on and so forth.
[00:03:35]
You have, like I said before, you don't necessarily want all of the rules applied all the time because you are sending those to an LLM where if you're paying by the token, cool, you just paid Claude Opus at a very expensive price. All your opinions on how CSS should be written so that it could write like a shell script.
[00:04:04]
You don't necessarily want to do that. So auto attached takes a bunch of file globs, so patterns for files that it should apply to, which is okay if you are reading a .css file. I think you should know about our opinions on how CSS gets written around here.
[00:04:21]
However, if you go then to read a Rust file, that rule is not included. Seems good. That is probably your best friend in this case. But one thing that I will do, and I'll mention it now just in case I don't find a reason to bring it up later, is I will then get really fancy with my file extensions.
[00:04:40]
So I'm working on this agent thing that has tools of its own. Those tools I want certain rules for. So all of my tools are called whatever.tool.ts, right? And so now whenever I touch one of those files or you can have it applied to just a directory if it's going into your design system component directory you can say like source slash components slash star, star, you know, whatever, tsx, right?
[00:05:11]
So you can only pull in the react rules on TSX files, but the typescript rules on every TS or TSX file. You can get kind of like nuanced and flexible with this next two we don't trust for two reasons. The two people who are likely to fail in this case agent requested, which is you kind of give it a sentence about when you think this rule applies and the LLM will decide if it agrees that the rule applies and then it will read it.
[00:05:38]
Don't trust that one second person. I don't trust me. And the other was manually where I can do an @ symbol and mention the rule and if I mention the rule then it is applied. I'm not gonna do that. I'm going to forget. I'm going to forget. And then we get angry when it doesn't listen to my rule because when I just think about all my rules, I tend to forget which mode I set it to.
[00:06:04]
So I don't trust anything but the first two. But the other two exist for a reason and maybe you're a better person than I am and my job is to tell you that they exist, so on and so forth. No surprises here because I put all of the real cheat sheet in the very beginning.
[00:06:21]
What makes a good rule? I don't know. It's specific. If you want to use the React functional component type all the time, great. Just saying use TypeScript not as good. Add JS comments to all exported functions is better than document code. The clearer you are about what you want, the better things are going to end up for you.
[00:06:49]
If you are using React Redux or RTK Toolkit or React Query in this case, or what have you, that's a good file to put it in and say auto attach to any TSX file. If you have certain context APIs that you want used, this is a good place to just outline all those things.
[00:07:10]
The better you can express your architecture, the better the LLM is going to understand your architecture versus handle Async properly, so on and so forth. Even better than the versions that I wrote that last slide because it fit on the two column slide and then even then I was uncomfortable so I wrote the second slide.
[00:07:34]
And even these, you don't want to make them too long because again you're like, I'm going to be so specific about everything that I want. Cool. Those are gonna get loaded in the context window every time. So you do need to find that balance. A few good resources for rules before we play around with some.
[00:07:54]
As is true in the modern era, whenever there's a thing ever there is an awesome list. This one unsurprisingly called awesome Cursor Rules. You will see a .cursorrules mentioned. In simpler times when we thought we get away with a single file that had all the rules and we didn't want to worry about auto attached versus always versus manual versus reference.
[00:08:18]
You had one file that had all your rules, you will still see that mentioned. Do not do that. It's bad for all the reasons that I've been saying over and over and over again, don't do it. But the site exists and it has a bunch of them. And again, if you're writing Vue, my react rules are not going to be great for you.
[00:08:38]
Unsurprisingly, so on and so forth definitely proves that. And there is another site that's even more extreme called Cursor Directory which also has a bunch of MCP servers which we'll talk about a little bit, as well as rules where you can search and type and go find some.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops