.cursor/rules Overview
.cursor/rules Overview
Hey, welcome to this lesson. We've already covered cursor rules and AI rules in detail, but with the latest changes in Cursor 0.45, there's a complete overhaul of how cursor rules work. I want to show you the evolution of these rules and how we can migrate to the new system. I'll also explain the new capabilities and what's different. Let's start with a simple example. Here, I still have an old cursor rules file. These rules are getting deprecated, meaning they'll be removed in a future version. For example, I wrote: "Avoid using !important, use specific selectors instead of forcing priority." This applies to CSS. Right now, if we look at the CSS file, we see !important used everywhere. Now, if I type "Optimize my CSS" and hit enter, the !important flags are removed automatically since they’re part of the rule file. Even without this rule, Cursor might still recommend removing !important, since it's generally bad practice. But this example shows how rules enforce specific coding styles. Alright, let's accept this and add a more comprehensive rule set. Now we have rules for databases, JavaScript, and CSS. For example, JavaScript: Use let or const instead of var. Database: Define clear data types. If we check the code, we still have some var declarations that will be replaced with let and const. The database part doesn't have clear data types defined yet, so we could write VARCHAR(50) or VARCHAR(255), for example. Now, let's tell Cursor to optimize the code base. I'll open a new composer, type "Optimize my code base", and hit enter. Since this is a small project, everything will be processed at once. The cursor rules are automatically applied in the first context, and we can already see that the data types are being corrected. Let's accept these changes. For the index.html file, we didn’t define any rules, so nothing changes. Let's check the CSS file, position absolute was removed, which is fine. In JavaScript, var was replaced with const. Everything is optimized. Let's save it and start the live server. Now, let's test it. I'll enter "Pizza Time" and set the time to 15:00. Everything still works, so we're good to go. So, cursor rules still work for now, but we need to reorganize them since they are being deprecated. Let's undo all our changes and migrate to the new system. Now, I’m back to the previous version of our application. The CSS file still has !important, so let's migrate to the new .cursor/rules directory. First, create a new folder .cursor/rules. Inside this folder, create a new file, let's call it general.mdc. This file will store our global rules. Inside general.mdc, we describe what it does: "This applies to the whole code base." We can then define a scope using globs, such as *.vue, .md, .tsx, or an entire folder like app/components. If we leave it blank or use , it applies globally. This replaces the old cursor rules file, which also applied globally. So, I’ll remove the old rules, copy everything into general.mdc, and save it. Now, let's test if it works. I'll add an output statement: "Hey, I'm your frontend buddy!" Save it, then run "Optimize my code base" again. If we see "Hey, I'm your frontend buddy!", we know the new file is being read. Yep, it works! The !important flag is removed, and CSS variables are applied. The database type definitions also look good. Let's accept all changes. That’s how you migrate one-to-one from the old cursor rules to the new system. But we can fine-tune this even more. If your project grows, having all rules in one file isn't ideal. You don’t want database rules loaded when you're only editing CSS, it wastes context space and increases token usage. To fix this, we’ll split the rules into separate files. Instead of manually creating a file, let’s use the command palette. Press Cmd + Shift + P, then type "New Cursor Rule File", and hit enter. Let's create database.mdc, "You are a PostgreSQL/Supabase expert." styles.mdc, "You are a CSS expert." javascript.mdc, "You are a JavaScript ES6 expert." Each file should only apply to relevant file types. For example, in database.mdc, I’ll add globs: [".sql"], so it only applies to SQL files. The same goes for styles.mdc (.css) and javascript.mdc (.js, *.ts). Now, I'll move the respective rules into these files. The general rules file is now mostly empty, just listing the expert roles. To test, I'll add "Hey, I'm your DB expert" in database.mdc, and do the same for CSS and JavaScript. Now, let's test if the split works. I’ll open main.css, change a color to blue, and check if the CSS expert message appears. Yep, it does! That means the rule applies only to CSS files without interfering with other rules. The setup is now much cleaner. And that's it! We've successfully migrated from the old cursor rules to the new .cursor/rules directory. Everything is modular, making it easier to manage in large projects. See you in the next lesson!