Hey, welcome back. Now we are looking at a smaller real-world example, which is divided between frontend and backend. I want to show you how we could split our rules for such a project. You can see in this mermaid diagram frontend with pages and styles and the backend services with an index TS. The backend is an Express and TypeScript API with some libraries. For the frontend, we are using Next.js also with TypeScript and Tushdown for state management. Then we have the cursor folder with the rules folder. Here I've defined a database guideline, backend, and frontend. The frontend rules apply to this folder, the backend rules apply to this folder, and the database rules apply to SQL files, not to a specific folder. Then we have the AgentMDC. I just call it Agent. You can call it General Rules or whatever fits best for your project, where I have defined some global settings. Okay, let's look at the project files. In the AgentMDC, I just give it a role. You are an instructor, a senior developer in TypeScript. I added this rule because we use TypeScript throughout the whole project in both the backend and frontend. Then I've added a rule ensuring that every time we use chat composer or the agent, it always reads and applies the defined rules for this glob. I double-checked it with a short prompt. Okay, just look at the rules and be sure that you add them to your context. One global rule is always to use PNPM as the package manager instead of NPM, BUN, or YARN. That should do it. Now, let's look at the backend guidelines. Here, I’ve defined that we use SORT and proper error handling. These are basic rules, but you could also split the backend into API-specific rules later. For now, a general backend guideline is fine. Then for the database, the rule specifies using Drizzle ORM, Prisma, or whatever fits your tech stack. You get the idea. For frontend guidelines, use React best practices, function components, and avoid class components. Now, let's add a description. Let's call it frontend expert. For the globs, I define frontend/*. That means it applies to this folder. For the database, I define SQL database expert. It applies to the global space but only to SQL files. So if I create a folder DB and add a migration SQL create table, perfect. When I make changes or edits, the database guidelines will be applied, but this isn't 100% correct because Drizzle is based on TypeScript files. So maybe we should change this to backend DB and TS files. That would be a better match. We could also add a comma and write .SQL so it applies to both SQL and TS files. We add TS here as well. Okay. The backend guidelines apply to the backend folder, and the agent rules apply globally, meaning they are triggered every time we use the composer agent or any other specific mode. Good, now let's close everything and run a test. Let's say in the index TS, we want to add a library, let’s say the NUQS library. We switch to the agent, and for the model, I'm using Cloudy. Let's hit submit, and you can see that Cursor is now using PNPM instead of NPM. We can cancel this, go back to the agent, remove this, save it, and do it again. Now it uses NPM instead of PNPM. So with these rules, you can specify what package manager you want to use, what coding guidelines to follow, and how to structure your project. You can check these rules into a repository so your whole team can use them. This was just an example of how to use such rules in a real-world project. In the next lesson, we’ll look at another example. See you later.