So far, we have controlled the behavior of the eye through the different prompts that we have provided,
and also through the specification that we have written inside our repository.
There's also another way that is much more effective to ensure that the output that we're getting from
the eye matches what we expect.
And this particular feature is called rules.
So through rules we can better control how the eye behaves.
And cursor allows us to use project specific but also global rules.
Now personally I like to use project specific rules even if there's a bit of duplication between various
projects.
I just like project rules because it is just related to a specific project, and I don't want to get
a behavior that I don't want from somewhere else.
So when does it make sense to have rules?
Well, for example, earlier we have noticed that after we're making some changes, the agent doesn't
automatically run the end to end tests.
So for example, we can have some testing rules saying hey, after you make a change, also test on
your own data.
Tests are passing.
Just ensure that you haven't broken any functionality by making this change.
So this saves us the additional prompt of manually telling the AI.
Hey, also, run this test to make sure that you haven't broken anything.
All right.
So if you want to set up project rules, that is relatively simple.
All we need to do is to open the command palette.
And this is slightly different depending on the operating system.
And then add a new cursor rule.
So let's jump into cursor.
And what we're going to do here depending on the operating system I'm going to press Ctrl shift plus
P or command shift plus P.
And this should open the command palette.
We need to be here inside cursor.
Let's do exactly that.
And what we need to do is right here cursor and rule.
And we're going to find here something which is called new cursor rule is relatively nice.
And then we need to specify a rule name.
So let's go ahead and hold this testing, for example.
And what exactly is happening here?
Well, cursor has automatically created a directory dot cursor.
And inside that directory there's another directory called rules.
And inside there we're going to have this testing dot file.
So this is a cursor specific file.
It's pretty much marked down for cursor and does have a few interesting parts here.
So it says here rule type.
Also this rule is always attached to every chat.
So this is exactly what we want.
And we can also go ahead and put here our own content, which you're going to find also as a resource
to this lecture.
So we're going to say here okay this is regards to testing.
This is going to be the header.
And then we're going to have here two rules.
For example first rule is going to be once you are done making changes to the code base run all tests
to ensure they pass.
So this is something sensitive.
But apart from this we also want to proactively ask the user if after making some changes, we want
to create additional tests to cover that particular functionality.
So this is now covered in terms of testing.
So we can take a look at exactly what we can do.
We're going to do here a small change.
So we can see here from the home page remove the word welcome.
So now unfortunately we're going to see that these rules have not taken effect.
We need to investigate why that is the case.
We can go again and ask did you use the rules.
And let's see what is coming back.
So they are saying here I ran the test to ensure that they have passed, not seeing this explicitly.
So it says here I didn't explicitly run the test immediately afterwards as it was a minor text removal.
So it has kind of like figured out, okay, this is not going to break any tests, but it does confirm
that it has followed the rules.
So it's an indication that those rules have been included.
Now there are many, many other rules that we can add here.
So this is not just about testing.
We can see here generally speaking, like example use cases, we may have some framework specific rules.
In general it's about how the code is written, the code style we have, any architectural preferences,
and so on.
And there are a lot of projects which are sharing rules.
For example, here as a resource of this lecture we're going to find cursor dot directory.
It's a very nice website right here on top it has rules.
If you click here on rules you're going to find here rules for TypeScript.
You're going to find here rules for various programs.
So we have here react or we have TypeScript.
So there are a lot of rules that can be added here.
Implementation guidelines and so on.
Now I think these are a good inspiration but I wouldn't go.
Click on copy and get them into the project.
More rules is not better if you know what you're doing.
That's great.
You don't know what you're doing.
My recommendation is to start with a few basic rules and adapt as needed.
So just adding a lot of more context to the eye doesn't 100% guarantee that the output is going to be
better.
So if you have a specific issue that you're noticing and it annoys you, and you see that the AI is
always doing the same error and you don't want it in there, go ahead and create some rules.
Get some inspiration from the existing rules, but do not simply go ahead and copy paste.
I'm also going to add some additional resources.
So this is another GitHub repository with a lot of rules.
Now before we conclude this lecture, there's one important aspect I want to mention.
If you find resources mentioning the Fylkir rules this is deprecated.
So this is an older version of this system of writing rules within cursor.
So I definitely do not recommend using this particular file.
Use the approach that I've shown where if for some reason the approach doesn't work, you can also manually
create this file.
It just saves a bit of time.
Anyway, this is all in terms of rules.
I'm going to reject the changes that have been made here and we're going to continue with the rest.