Cursor Rules, Commands, Hooks, and Skills
Rules, commands, MCP servers, subagents, modes, hooks, skills... There's a lot to cover. This session breaks down what each concept is, when to use each one, and walks through a practical setup demo.
Terms in this video
Transcript
you know, all of us using cursor. Uh I think we're probably all heads down building uh all the time. Uh cursor is shipping a lot these days. Uh a lot of new features have come out and I think it's easy to just kind of continue to use the tool set uh that you know and is available to you and especially if you're busy on projects um it's predictable. Um but one of the reasons we wanted to do today's session is to um expose you to several new features that
have come out and my hope is that uh coming out of this session uh you'll be inspired to check one or two out. Uh I think they're all really powerful and as I was saying here as we were getting started the space moves so fast. Um, I know we're all busy at work, uh, but it is, uh, you know, part of the job is kind of staying on top of all these new features and leveraging all of the advanced capabilities of the agent. Um, I've got Emily and Vincent here with me
today. They're going to be manning the chat. So, if anybody uh has any questions as we're going through, uh, please drop your questions in the chat. They are all experts uh, on cursor and can answer as we go. and we'll try to save some time at the end of the session uh for some Q&A um where we can get into some of those questions. Okay, so let's talk about what we're going to get into today. Um want to first talk about rules. Rules are something that have
been around cursor for quite some time, but I think they're a really important part of getting the most out of these models. And so we're going to talk a little bit about rules and just best practices around rules. Um, I travel around the world talking to cursor users uh in every corner of the globe here and I would say rules is one of the topics that I get the most questions about. So, we'll dig into that. Skills is a new feature uh of cursor uh that you could
kind of consider as sort of an extension of rules. We're going to talk about how to create those and when to use them. Commands uh are really powerful uh uh feature in cursor that came out uh a few months ago. Uh great for triggering multi-step recurring things that you do in the product. We're going to talk about sub aents which is a brand new feature of cursor. something we're really excited about uh as we continue to look at ways that we can have
multiple autonomous agents running at one time um all without tripping over each other uh in a uh in a harmonious way. We're going to talk about hooks, which is a really powerful way to hack cursor. Uh I'm kind of surprised a lot of people don't know about hooks. Uh really allows you to extend the functionality for your own bespoke needs. And then last, we're going to touch on marketplace, uh, which is a new, uh, service that cursor rolled out a couple weeks ago and ties together all of these different features, uh, with
nice one-click installations. Um, and we're going to do all this, uh, building a little game for my daughter. Uh, my younger daughter, uh, is trying to master her multiplication tables. Um, so I thought as we go through each of these different features, uh, we will build out commands in a cursor project, um, and then build out this game leveraging, uh, all of these different pieces. So, let's get started. First, we'll talk about rules.
So, models are are non-deterministic. What this means is that you can submit the same prompt to the same model, let's say, five different times, and you will probably get a similar sort of end result from each of those prompts. But the way that the model creates the code for that prompt can be wildly different uh from one prompt to the next. And that's why we call these models non-deterministic. Uh this is different from say a Python script that you might write which is deterministic meaning
that every time you run that script the output is always going to be the same. And so rules and skills allow us to provide the model persistent instructions to ensure more consistent output. And what I mean by that is a rule allows you to add directives that cursor will always include in your prompts or invoke in certain situations. So you can kind of supplement the model's knowledge and its guidance with your own instructions. Uh so for example
if you are working on a development team and all of the engineers need to follow a certain style guide uh maybe they need to use tabs for their indents instead of spaces. Uh rules are a great way to provide that information to the model and ensure that it's included in every prompt so you don't have to uh include it in in your prompts. Um so let's talk a little bit about how to create a rule.
I'm going to pop over here into a brand new cursor workspace. Um, and I'm going to click on settings here, uh, with this cog button in the upper right hand corner. And I'm going to go to the rules, skills, and sub aents tab where we're going to spend a lot of time here today. Uh, and I'm going to click here on this project that we're working on. And I'm going to come down here to rules. So when you create a rule, it is going to create a markdown file in your
codebase. And in this case, I've opened up a new project uh with just an empty folder. So we don't have anything uh in the root yet. And I'm going to go ahead and click on new here and choose project rule. And what this does is it reveals an interface where I can give this rule set a name and then provide directives for the rule. So, I'm going to just call this general rules.
And um actually have some rules here that I've created for this game that I'm going to just paste in here. Uh and I'm going to go ahead and click done. And what you'll see this does is it creates a cursor directory in my root. And then if I expand out that directory, you'll see there is a rules subdirectory where this cursor markdown file has been created. I'm going to go ahead and open up that file so we can see how it's structured. Um, so what I've done here
is I provided just some basic guidance that I want the model to always have as it's building. Um, so I'm going to include the text stack here. Uh, I want it to always know that we're going to use React Type TypeScript. Uh, that we're going to use Tailwind for the CSS. So kind of the basic stack that we're going to build. Uh, and some basic information around what we're building.
uh that this is for my nine-year-old daughter. Uh my daughter loves cats and she loves the color lime green. So, I want that to be a consistent theme in what we build. A little guidance here on the structure of the game. And some engineering constraints. So, what I'm doing here is I'm going to set this up as an always apply rule. And what that means is that this rule is going to get attached to every single prompt that I submit to the model. Cursor also allows
you to set other types of rules. And I can create as many rules files as I want in this rules directory. And each one of those files can be assigned a different rule type. So always apply means that the rule is going to be attached to every single prompt. Apply intelligently allows you to include a description of when that rule should be invoked. There's also apply to specific files where you can enter in one or more glob patterns to target that rule. So for
example, I might enter in asterisk.p py and then these rules would only apply to files with a py extension or I have apply manually. And with an apply manually rule, I can be typing in a prompt and when I want to invoke that rule, I hit the at symbol and I can just attach it. Now, you might be wondering, Nick, why wouldn't we just always use always apply? Why have these other rule types? Well, when we think about the context window, uh what you are
including in each chat session, you want it to be as focused and have as singular a story line as possible. And so, if you are including a lot of different directives in your rules, you can tend to degrade the output of the model. the model really does best when it has the least amount to pay attention to. So what I recommend is for your always apply rule, really only include the basic most important information. And then when you have other rules uh that
you want to include, consider if they don't necessarily need to be included in every prompt and use one of these different types. If I have an always apply rule with let's say 300 different directives in it, what that means is that every time I prompt the model and I say, "Hey model, I want you to do X."
I'm also going to be saying, "By the way, I also want you to do these 300 other things." And models are very much like humans. If I asked you to do something and then said, "Oh, by the way, do these 300 other things at the same time." Chances are you're not going to be able to follow all those rules either. So what I recommend doing is for your always apply rule, keep it very very simple and basic. When you think about other directives you might want to
add, consider creating different files with other file types. And then when I build up this always apply rule, I really try to do it in reacting to the model's behavior. When the model shows me it needs more guidance, for example, if it's making the same mistake more than a few times or if it's getting confused about the same thing more than a few times, that is usually a good signal that I need to add another directive into those rules. I do that
instead of trying to include every possible preventative rule just in case the model does this or does that. I find that you tend to really cloud the rules and then in turn cloud the context window and again it will degrade the output of the model. Also I would say that you know we were talking at the beginning of this session how long we've been using cursor. Uh Emily I think has hit two years now. Um I'm at about a year and a half. If we think no a year
and three/4ers um if we think about you know what the models were like a year and a half two years ago they really needed far more guidance than they do today. So I would say that rules, best practices have even changed over time and we need to include less and less of those kind of preventative and behavioral uh instructions and keep things more simple. And again, let the uh model tell you when uh it needs more guidance and then that is a sign to add
more rules. So I'm going to go ahead and save this rule. And uh just to recap here on the rules, best practices, start with the basics. When the model shows you it needs more guidance, then you can add another directive to your rules and use rule types to only invoke those rules when needed. Some things are going to be appropriate for an always apply, but a lot of your rules likely can be moved to a different rule type, so they're not included in every prompt.
Also, I recommend don't be too verbose. Uh, you want to be as concise and straightforward as you can in these rules. Um, you don't want to have excessive rules like we talked about. Really let the model show you when it needs more guidance. And I think you'll be surprised at how effective the rules can be. And you want to make sure that the rules aren't conflicting with each other and they don't get stale. Um, I find especially when I'm working on a
longer uh horizon project, many weeks, many months, I really try to get in the habit of revisiting my rules on a regular basis. You know, these projects evolve as they go. The rules that you wrote in the first couple days may not necessarily be relevant as time goes on or may even conflict with what you're trying to build. So, it's good to revisit these rules and make sure that they continue uh to remain accurate. All right, so just a little recap here on
rules. Again, this is a feature that's been in cursor for quite some time, but such an important part of giving those models more guidelines, more constraints, kind of reigning them in and adjusting their behavior to be more consistent and more in line with whatever your requirements are as an organization and in the project. All right, let's move on to skills next.
So skills is um a new uh open standard that has uh come out and is being adopted by a lot of different uh products in this space. Uh cursor has support for skills, claude code has support for skills, codeex has support for skills and essentially this is a way to extend the agent um with domainspecific tasks. Now, what's interesting about skills, and this sort of uh piggybacks onto what we were talking about with rules, is that when you create a skill, you give it a name and you give it a
description. And the skill is not invoked in every single chat automatically. The agent can see the skill name and it can see the skills description. And then when it gets into territory where based on that name and description, it feels the skill is relevant, then it will invoke it and bring it into the context window. So skills are smart in that way. Uh they're not necessarily going to be included every time. And similar to the apply intelligently rule that cursor offers uh the agent knows when those rules uh or
knows that the rules or the skills are available and then we'll just invoke them uh when the time is right. All right. So um oh one other thing I wanted to mention here. Uh let me just pop open my browser. Um you know the cursor docs are really good. Um they continue to get better and better. Uh when I started a cursor a little over a year ago, we were kind of struggling really getting the docs dialed in. And I feel like in recent months, they have just gotten so
good. I want to click here on the skills page uh in the docs. And I just want to scroll down and talk a little bit about the architecture of skills. And one thing that's really cool about skills is that they are portable from one project to the next. And let me just find this here. Um, oh, we may have removed this from the documentation, but the point I wanted to make here, sorry about that, is that if you create a skill uh in codeex or you create a skill in clawed
code, uh where those products place the skill in the codebase, cursor will pick that up as well. So if you're m moving projects between different platforms, uh know that when you create those skills and whichever platform you build it in, cursor will see those and pick those up, which is nice. Um so let's create a skill for this project. I'm going to go back to our workspace.
We've got our rules here. And um what's really cool about skills is that you can uh create them here from the rules, skills, and sub agents uh panel. But you can also use the forward slash and choose create skill and essentially just write out what you want the skill to be and then the agent will take a first pass at creating that skill. So you can use that forward slash command or here from the skills tab you can click new skill and you can see here it will open
up a chat pane with this pre-written prompt. Create skill help me create this skill for cursor. Um, so I'm going to create a skill here that is [clears throat] inspired by uh a skill that a lot of us use uh here at cursor and I think it's something that is relevant to everybody uh in the audience. It is uh what we call a dlop uh skill. You know when these models write code uh they do certain things that adds slop to the code and this skill will help evaluate the code that's written by the model and then remove the
typical kind of slop that we see here that's really just extraneous. So I'm going to just put in uh a basic description here. Remove AI generated code slop and cleanup code style. And uh I'm going to go ahead and submit this. And what you'll see here is that the model is going to get to work uh creating this skill and it will ultimately create a skill file. It may come back and ask me some clarifying questions as well just to kind of get this skill dialed in. And it's ultimately going to create a skill.md
file. Uh again with that title, the description and the instructions. So you can see here it's getting to work building out this file. I should mention that you can also use the model to write rules. Um, in my case for creating my general rules rule set, I put in rules that I had written before. But you can also talk to the model and ask it to create the rule. And that's going to be the case for most of the things that we're talking about here today. Um, I do
find that sometimes the models are a bit more verbose uh for my taste. Uh, and typically once I have the model, write my skill or write my rule, I will go in and refine it and often trim it down. But it really is uh a great kind of start uh to get things going, get some good architecture built out for that skill or rule or whatever and then you can work within what the model has created. So you can see we've got a remove AI slop skill that has been
created and I can click on this and I can review. Uh, so it called it remove AI slop. I'm actually gonna rename this D slop, which I like a bit more. And the description here is identifies and removes AI generated code slop generic patterns, verbose comments, overengineering, and cleans code style for consistency. [snorts] use use when the user asks to clean up code, remove AI slop, fix code style, or when reviewing AI generated code. So again, now the agent is going to know that this skill is available based on the name and
the description. And then whenever we get into this sort of situation, it will invoke these instructions. And let's just take a look at what the model wrote. Um, it first lays out when to apply the skill. uh so when I ask it to delop or polish the code when I mention anything about slop or AI generated code uh and then here it lays out the different patterns and how to address them. So um we've got generic variable names and function names overengineering
and unnecessary abstraction which you often see uh bad boilerplate stuff. Um, so this is a pretty good uh layout. And again, what I would typically do here is come in and refine this. Uh, often it's a bit verbose, as I said, and trim it down. Uh, but for the case of uh of this uh demo here, we'll go ahead and save this. So now we have uh our D slop skill. And um I've set this up for this project, but you can also carry skills uh over to all of your different
projects. I find that I'm often creating uh skills and and some of these other assets that we're going to be building today. Uh and I set them up so they're available across all the different projects that I'm working on. And this dlop skill uh is definitely a good example. Um okay. So I'm going to I'm just going to rename this folder [snorts] as well to DLOP.
Okay, great. All right. Uh, so we've got our skills set up. Terrific. >> Next, let's talk about command. Oh, yes. >> Further, quick question. I'm seeing a lot of folks ask like maybe you can touch on when should you use a role and when should you use a skill and maybe is one better than the other or Yeah.
>> Yeah, definitely. Um, and Emily would love your input on this as well too and please chime in as we get more questions. I'm glad you you um you brought this up. Um so when to use a skill and when to use a rule. You know I have gotten in the habit uh of using um skills as a replacement for apply intelligently rules. Um, what I liked about apply intelligently is I could tell the agent when this rule is going to be invoked and when the agent got
into that territory, the agent was smart enough to invoke it. And it it usually worked. I wouldn't say it was the the most uh reliable and consistent feature uh of the cursor rule support and skills I see as a much more capable version of this use case. um you the agent is trained to understand that it has this set of skills again it has the name and has the descriptions and it's able to invoke those. Um also skills can be far more complex and comprehensive uh than
rules. You can have templates in there, you can have workflows in there. Uh but again it only gets invoked into uh the context window and into the session when uh when the agent feels it's necessary. Um for rules I am typically using rules uh I focus on always apply rules. uh again for my basics and then typically for other types of rules that I feel uh are going to be too excessive to be an always apply I often use those as a manual rule. Um I'll give you an
example. Let's say that you uh we'll go back to this example where you're working with a team of engineers and you have a certain style guide uh that everybody needs to follow. Um for variable names we need to use camelc case. Um for again indents we need to use tabs etc. And I've seen some of these style guides can be quite comprehensive. They can be hundreds of lines long. You don't necessarily want to put that in an always apply rule. Uh but setting it up as a manual rule. What I would typically do is then do kind of
recurring audits of my code once I finish a feature or a set of files where I then say audit this code and ensure it complies with the style guide and then I'll hit the at symbol and invoke that manual rule. Emily, do you have any other thoughts here on skills versus rules?
>> Yeah, I think for rules, I typically have them one sentence always apply where I give them very specific context on, for example, I have one user rule that says never leave AI slop comments um rather than cleaning them after up after the fact. But I think most of the stuff now that skills came out, I think the agents are pretty good at figuring out which ones to pull in. Um so I've been switching to that. >> Yeah, definitely. I um I really do think
it is a more effective way um to um to to use the apply intelligently kind of style of rules. >> Um >> one thing I also did want to cover on like kind of ways to distribute them. So there's user level rules they just apply and skills they just apply to you. Um there's anything committed to the repo can be accessed by anyone with access to the repo. And then we just launched teams marketplaces where you can actually set up rules that are applied orwide. I think Nick's probably going to
touch on it. I see you smiling and nodding, but um that lets you one set up kind of systemwides that everyone in your or can use or also set up sub teams. So you can say here's um a set of configurations for the design team, the backend infra team and so forth. Um that lets you do a lot more customization across multiple repos. But that Nick, the floor is yours.
>> Excellent. All right, let's get into commands. So commands are essentially reusable prompts that you can run as a slash command. Meaning that when you are in the input interface in cursor, uh you can press a forward slash button here, bring up a menu, and your commands will be listed. And what the way I think about commands is they're really ideal for things that I do on a regular basis, on a recurring basis, and especially things that require multiple steps. So, some examples here, running a test
suite, uh fixing compile errors, creating a pull request, spinning up local servers. These are all things that typically take more than one action to kick off. Uh let's use for example um committing and pushing some new code. Uh when you commit and push new code, you need to stage files, you need to commit them, you need to write a commit message, you need to push uh these are several different steps uh for something that you do on a recurring basis. I love
using commands for this. I can create a command that has instructions for the agent to follow those steps and then I can just hit forward slash choose that command and run it. And we're going to do that here in a second. Um I'm going to come back here to this council command which is was written by one of our engineers and I think is really cool. Uh but before we do that, let's go ahead and set up I want to show you how to create a command in the IDE. So
again, I'm going to come back here uh into cursor. I'm going to go to settings. I'm going to go back to rules, skills, and sub aents. And you'll see there's commands here down below. And I'm going to click new command. We'll call this a project command. I'm going to give this uh command a name. Uh let's create a command to spin up the local environment that we're going to build. So we're going to build this game. I'm going to build it locally initially. This is probably something that I'm going to be
working on for several days. So, I'm going to be creating uh this project. I'm going to open it. I'm going to close it. I'm going to open. And each time I come and work on it, I'm going to want to spin up the local environment uh to get this thing running. Great example where there are several commands I would probably need to run in the terminal to get that environment set up. And uh I can create a slash command to do that for me with just a couple keystrokes.
So, I'm going to give this command a name. I'm going to call it start local. And what that does is it creates a markdown file with that name in a commands directory in the cursor directory. And uh then you can enter in your command. And uh I've written one here that I'm going to include.
Um, and this is just very simple instructions telling the agent how to spin up our project. Uh, three steps here. And what I like to do in in when I create my commands is also include instructions on how the agent should ultimately respond to me. So you can see here in step three, I say print the local URL and confirm the server is responding. Um, the models can sometimes be a little more verbose than we might like and I think especially for a command which is really designed to be efficient. Um, I like to tell the model
how to respond. Otherwise, sometimes I get like a paragraph or two that comes back and just the cognitive load of that is unnecessary. Um, so I'm going to go ahead and save this. And what you'll see is now at any time I can hit the forward slash. I can come down here and choose start local and then just hit return.
and the agent will then read these instructions and go ahead and execute. So you can create as many of these slash commands as you'd like. And I think once you start to get this into your workflow, you'll see how powerful they can be. I want to come back to this console uh slash command. Again, this was written by uh one of our engineers, and I think it it it kind of gives you a a deeper and more complicated example of how slash commands can be used. So this
command is called council. Uh again, you would create it and then you could just hit forward slash and console. And here's the instructions of what would go in the markdown file. Based on the given area of interest, please dig around the codebase in terms of the given area of interest and gather general information such as keywords and architecture overview. Then it says spawn off n= 10 unless specified otherwise. So these are going to be sub aents that are spawned.
We'll talk about those in a minute. um to dig deeper into the codebase in terms of that given area of interest and some of them should be out of the box for variance. Once the task agents are done, use the information to do what the user wants. If the user is in plan mode, use the information to create the plan. And here are some examples of how it could be called. You would type this into your input box. Use console n equals 15. How does authentication work? Um so just
gives you kind of another example of how you can really go deep uh on uh the commands. This is something that this engineer uses uh on a regular basis to investigate. Uh he figured out sort of certain instructions for the model to get the most out of these investigations. It's something that you do he does one does regularly uh when when working with models. And so now with just a couple keystrokes, you can do that investigation and do it in this
very advanced way. Um, so commands again, once you kind of figure out how to fit this into your workflow, you'll find it is extremely powerful. Okay, next up, sub aents. Sub aents is a new feature uh that came out in version 2.5 of Cursor. Um over the last few months, I'd say since uh last kind of late fall, we've really shifted our focus to how can multiple agents run at one time in cursor kind of the most harmonious way. Uh for those of you that
uh have been using cursor since agents originally came out uh back in the fall of 2024, um they were incredible when they came out and it was really cool that you could open up multiple tabs in the IDE and run multiple agents simultaneously, but they often would kind of trip over each other. If one tab had an agent running and another tab had another agent running and they both tried to edit the same file, um they would stop. they would ask you to uh to
accept the changes from one tab before the next could continue. And as cool as it was, we knew at Cursor we really needed to find a way for these multiple agents to run uh in a more harmonious way. And sub agents is one of uh the efforts that we've been pushing on here to achieve that. What sub agents allow is when you are prompting uh your agent in the IDE. Um that agent can actually spawn sub agents that will run simultaneously to satisfy that prompt. Um there are three different sub aents that are built
into cursor and then you can create your own custom sub aents. One of the sub aents built into cursor is the explore sub aent. And what the explore sub aent does is that anytime you ask the model to do something where it needs to explore the codebase and better understand it, it will kick off an explorer sub aent. The bash sub aent is anytime the agent wants to run a terminal command, it will launch a bash sub aent.
And the browser sub aent is for anytime the agent wants to launch the browser and interact with the browser that's built into cursor. So there's some big advantages to sub aents as I mentioned they can run simultaneously. So you can ask the agent to do something and if it needs to do any of these things uh in that task it can launch these sub aents that can run at the same time instead of previously where they would need to run sequentially. Also each of these sub
aents have their own context window. So when you see a sub aent kick off it's actually running its own context window. It's then writing the output of its findings to a file and then the parent agent can read that file and just bring into the parent agents context window what is relevant. This is using a technique called dynamic context discovery. Um which is a way that cursor has really kind of rethought the way that the agent manages context. Um
highly recommend you go to cursor.com/blog. Uh there is a great post I think it's on the second page now when you go to the blog page and Emily maybe you can drop it in the chat really good overview of how dynamic context discovery works but this started in version 2.4 before and has really changed the way that uh the agent in cursor brings in context where before the context window would just get loaded with every file, every tool, all the output from an MCP server which would really bloat your context window.
It would cost you more tokens and as we all know as the context window grows and grows the accuracy of the model degrades. With dynamic context discovery, uh the model or the agent um kind of uses a file system approach where it now has all of these different elements that it can read from and then bring into the context window what it deems relevant. Very similar to how the agent reads the uh file index and brings in the code that it needs uh in that
session. So, what's really cool about these sub aents is again they're writing all of their output to files and then that parent agent using dynamic context discovery will bring in just what it needs uh into the context window. So, your agents are going to run faster, they're going to be more performant. Um, and you are going to eat up that context window much more slowly. Uh, which is going to cost you less tokens and it is going to allow your model to perform
better for longer. Um, so let's uh take a look here. Uh, we mentioned the three different agents that are built into cursor and there could be others that are coming in the future, but you can also create your own sub agents. I'm going to go back here to the IDE and um, let's go ahead and do this. Now, what's interesting uh about sub agents, you can go into your settings here um and you can go to sub aents and you can click new. You can also use the forward
slash here and just choose uh create sub aent. Actually, you know what? You have to do it from this button in this version. So, when I click new here, uh you can see I get the create sub aent command and it says help me create this sub agent for cursor. Um, one sub agent that I've been having a lot of fun with is uh something that I like to refer to as the devil's advocate sub agent. I think something that you'll find with these models is um they're amazing at
writing code. Um, but you can often get a lot more out of them if you question their judgment and you make them think more deeply about the assumptions that they're making. And so I like creating a devil's advocate sub agent uh to do that. So the model will just automatically kick off that sub agent uh when appropriate uh to do that sort of work. So here's a little description I've wrote I've written here. Uh technical devil's advocate that challenges feature plans, strategies, and implementation approaches. Use
proactively when planning features to designing systems or proposing solutions. ask probing technical questions to uncover risks, edge cases, and alternative approaches before implementation begins. So, I used to have to do this manually. Uh, you know, I would prompt the model, I would ask it to do something, and we go through several uh iterations there as I'm doing this. Now, I can have the agent launch a sub agent to question its own work and
ideally get even better output. So, uh, I'm going to go ahead and submit this. And then, and again, what I did here in sub agents is I clicked new, and that brought this, uh, pre-written prompt. And then you can see here the model is now getting to work, uh, creating this sub agent. And, uh, we're using Composer 1.5, and it is really fast. I I never I still am not used to how fast it is. So, let's just click on this and see what it's done. Make sure we're happy with
it. Um, so sub agents use a similar sort of format as skills where you have a name and then a description here. And let's take a look. It it looks like it basically took my description. Uh, devil's advocate. Uh, challenges, feature plans, strategies, and implementations. Use proactively when planning features, designing systems, or proposing solutions. I'm also going to say here um always use for plan mode because I think that is one area where it's particularly
powerful. Um and then you can see here it's got uh the agent has taken a pass uh writing out uh this sub agent. Now again I I like to use the model often to take a first pass. Uh if we had more time here I would I would I would go through this and and really improve it. Um this one actually isn't that verbose.
Um, again, I often find that I need to kind of trim down what the model has written. Uh, but I would iterate on this and improve it, but we'll leave it as is for now. And now I have my first uh custom uh sub agent. Uh, which is is really cool. Um, you know, sub agents are one of these things where I think it takes a little time to wrap your head around the feature. Uh, takes some experimentation to understand when the agent calls these sub aents. Um, but
they um they really can be a powerful way to extend the capabilities of your parent agent, improve performance. And something else that is really cool about sub agents and uh let me just see if I can open this up again. Um, when I open up this sub aent uh here from the file, uh you'll see here that it has a model menu. So when it's set to inherit, that means it's going to use the same model as the parent agent. But I can also choose a different model for this sub
aent to run. Um maybe I really love using Opus. It's an expensive model, but maybe this particular sub aent uh doesn't need to be that smart. And Devil's Advocate probably isn't the best example. With Devil's Advocate, I probably would want to use a smarter agent. In fact, I'm going to set this to Opus 4.6. And just a little side note, I got to say I think in general we uh those of us using these tools to write code often reach for far more powerful
models than we really need. Um I'm lucky that at Cursor I get unlimited tokens. I I don't have to pay for them. I can run Opus 46 all day long. But the truth is like most of the work that I do, I don't need a model that is most powerful. I'm a huge fan of Composer. Um Composer 1 was a much less expensive model. Uh it's extremely fast. I'm addicted to the speed. Um I often am using less powerful uh less expensive models for my low to mid-level coding test. They work great.
You do not need the power and the cost of something like Opus 46 for everything that you do. But this Devil's Advocate sub agent is a great example where you would want that extra firepower uh to really look deeply to think deeply about whatever it's auditing. So I would choose opus 46 for this. And that means that even if I'm run running uh a lesser uh not as smart model, maybe not as capable model, that means when this sub agent kicks off, it will use opus 46.
Okay, we'll save that. And um one last thing I want to touch on here is hooks. Um and then marketplace, which sort of ties all this together with a bow. Uh let's touch on hooks next. Hooks, as I said, uh gives you a way to customize um cursor. Um you know, uh I work with enterprise customers every day. And what we found in the uh early days of of starting to work with enterprise customers is that they all had these different kind of bespoke requirements
uh that they wanted a cursor to be able to do. And we were always trying to play catch-up, trying to make everybody happy, including everybody's features. And we pretty quickly realized that we needed a solution like hooks that would allow uh any user of cursor to sort of extend the functionality of cursor. And what hooks does is it allows you to include your own scripts in the workflow and about a dozen different trigger points uh in the IDE uh in the CLI. So
sample hook points are things like when you submit a prompt, uh when the agent reads a file, when the agent writes a file, when the agent makes an MCP tool call, when the agent uh runs a terminal tool call. At each of these points, you can include your own scripts and your own deterministic scripts. So I'll give you an example. Um this this kind of shows a hook setup file. Uh before you submit a prompt, you could include your own script. Maybe you want to log every
single prompt that you submit. You could include a script there that would log that script, let's say, to a database before it went on and got passed to the model. Or maybe you're concerned about sensitive data being passed to the model. Maybe PII information or API keys. You could include a script that would look for that in each prompt. And then if it found any offending uh data there in the prompt, it could actually stop the prompt from going on to the
model and return a uh an error message of your choosing to the user. Um so would encourage you to check out uh the hooks documentation. Um I could do a whole hour on hooks um here and I believe it is right here. uh but really good documentation here that explains all the different hook points where you can call your scripts. It also has some examples of uh hook scripts just to kind of give you an idea of how this works. Um but hooks can be a really powerful
way again for you to customize and extend uh the functionality in cursor. Okay. Um I want to make sure we have time for Q&A. And uh while we're doing Q&A, I'm going to go ahead and kick off a prompt to build our little uh multiplication uh uh piece here. But I want to quickly just talk about marketplace. Marketplace is something that we launched a couple weeks ago and you can go and find it at cursor.com/marketplace.
And essentially what this is uh is a collection of plugins that you can install in cursor with just one click. Now, a marketplace plug-in can include rules. It can include skills. It can include sub aents, commands, MCP servers, and hooks. And you can see here we partnered with a lot of well-known brand names here uh to launch uh the marketplace. We are continuing to add additional uh plugins to the marketplace. In fact, anybody can submit a plugin to be included. I think we're kind of envisioning this as like an app
store for cursor. I'm not sure it's something that we're going to charge for, but what's really cool about this is you can very easily with one click install a collection of these different uh artifacts. Also, I think this is a great way to see uh different skills, different sub aents, see how they've all been written. Essentially, everything that's in a plug-in except for the MCP server is visible. So, as you're thinking about how to use these different tools, I think it's also great just to kind of click around and see how
uh these plugins have been written. Uh, this continual learning plugin is one of my favorites. This is one that we released here at Cursor. It's experimental. Um, but I'm going to go ahead and click on this here. And what you'll see is with Continual Learning, it includes a skill and includes a hook.
So, again, the plugins don't have to include all of these different artifacts. You may find some plugins that's just an MCP server. In this case, it's just a skill or a hook, but you want to click through these uh these different plugins and kind of see how they work. Um, so what this is is uh this is triggered uh with a uh stop hook. And a stop hook is when you submit a prompt uh and the agent is running and running and running. Once it finishes
that run, that is the stop hook. And so when the stop hook uh is triggered, this will call the continual learning skill. And let's just take a look at this skill. So it's called continual learning. And why don't we just look at it raw. And you can see here, let's see if I can zoom in a little bit. Uh the description incrementally extract recurring user corrections and durable workspace facts from transcript changes and then update agents.md with plain bullet points only. Use when the user asks to mine previous
chats, maintain agents.md memory or build a selfarning preference loop. So essentially what's going to happen is every time the agent finishes running, this skill is going to be invoked and then any learnings that came out of that last run, it's going to write to an agent's MD file and essentially allow the agent to get smarter and smarter with any sort of missteps, corrections, additional information that you've given the agent in that run. Really cool
continual learning. So for me to install this, all I have to do is click add to cursor. And uh this will then deep link me into the IDE. And you can see here in the plugins tab of settings, I now have this continual learning uh plugin here. Um and this is set up uh for all of my projects. I can also just set it up for a particular project. Uh but now this is set up to run. Okay, we've got about 10 minutes left. Uh, I'm going to go ahead and jump into plan mode. And, um, I've
got a prompt here for my multiplication game. I'm going to drop this in. I'm a big fan of Opus for planning. I'm going to go ahead and kick this off. But, uh, since we only have 10 minutes left, Emily, I don't know if there are any questions that we want to discuss in real time. Anything, uh, that has come up that that we want to dig into here. By the way, you can see here sub aents are already kicking off. Uh this is the explorer sub aent. Anytime you see a sub
aent, it's going to show up in a box like this. You can always expand it and see it's working. Um and then when it writes to a file, you can click on it and you can see the output there that again that parent agent can read. Emily, anything in the uh in the Q&A that we want to hit?
>> Um yes, we've had over 200 questions, but I've been curating a few of them to expose. Um >> great. One thing I commonly see is ask like multi-reo workspaces and folks um maybe one talk about how you can do it and two maybe talk about how rules and context are shared across the different repos and [clears throat] then not to confuse you with too many questions but on top of that maybe touch on best practices. When should people create a user role versus a project level role versus something shared orwide?
>> Yeah. Um, multiroot workspaces is like uh I think it's one of the most powerful um hacks in cursor. Um, what a multiroot workspace allows you to do is add multiple root folders to your workspace. So um when I opened up this project aka workspace uh I chose this folder called 260305 webinar and that is the root folder here in uh in my project. I can actually go to the file pulld down menu here. I can choose add folder to workspace and I can add as many additional folders as I want to the workspace. So let me find another
folder with some code. So, here's another root folder. And you can see here now I actually have two different root folders in my workspace. There are so many different use cases for this. Uh I'm going to go ahead and remove this just cuz I don't want my agent to get confused. But one sort of obvious use case, let's say you're doing full stack development and you have one repo with your front-end code, maybe React, another repo with your backend code,
maybe it's like a Python fast API. um two different repos, but you want to have it in one project and cursor so the agent is aware of all that code and can update both repos when you're building out a feature. Um, as it relates to rules, um, I have seen some organizations maintain a repo with all of their rules that they use across multiple projects and then they will open up a project uh, that they're working on and then they'll add that rules repo to the project. Again, the agent is going to or the project is
going to index everything in the workspace from all of those different routes. The agent will be able to see it all and act on all of it. So, a lot of different use cases for multiroot workspaces. Uh, hopefully uh light bulbs are going off for those of you that are just hearing about this now, but so many different ways you can use this to expose the agent uh to just more uh more content to index and and more content to work on. um as it relates to rules. Um
so cursor has been doing a lot of work uh as of late that allows you to start sharing out uh these different assets to multiple projects to an entire team. Uh and that is true with rules. So you can create a um you could create rules for a specific project and that's what I've been doing here. Oh, let me just go ahead and kick off our uh we have our we have our plan here. I'm going to go ahead and just kick this off. I'm going to use composer 1.5. We'll let it start
building. Um, but we have our rules here in this project. Um, so this is going to get committed to uh my repository once I start committing here. Uh, and anybody else that is working on this would be able to pull down those rules. I might also want to create my own personal rule sets that I don't share with other team members. And I could include those here and just add them to the git ignore file so they don't get pushed up to the repo and they're not shared. Then you can
also set up rules that are uh shared across the entire organization. Um so there may be some rules that apply to every project that you're working on and so you are able to create those rules and uh and share them across that way. And as I mentioned the multiroot workspace is another way uh to do this.
I would say that that is sort of a hack that people would use before we started to support organizationwide rules. Uh but definitely something that you can implement there. What else we got Emily >> or anything you want to add there? >> Um well I think a little bit separately I'm seeing a lot of people ask about kind of our rules and skills included in the token count. Um so the answer there is yes. So did want to highlight that.
Um but I think also building on that people are curious maybe a bit about model selection and so is one sub agents always using composer 1.5 can you customize the model used and maybe briefly if you could touch on how we think about choosing the right model for each task?
>> Yeah. Um so just just one quick point on like tokens being used for rules and skills. There the tokens are going to be used if those rules or skills are invoked in the session. Right? So you can create a skill and the agent is going to be able to see the name and the description. Uh it's not going to eat any tokens until the agent chooses to use that skill with rules obviously and always apply. It's going to be included in every prompt. Although cursor is
going to see in one session um that those rules are uh were included in the first prompt. It's not like every subsequent prompt it's going to eat the same amount of tokens, but it is going to those rules are going to be included with every submission to the model which is going to eat tokens. Um, as far as uh sub aents and model selection, um the um the the the sub aents are going to use the model uh that you selected for the parent uh model unless you specify a
different model. Emily, do you know if like our explorer sub agent, does that always use the parent agent? >> What do you mean by always use the parent agent? >> Uh, I'm wondering I I I I should know the answer to this, but I'm wondering if, for example, I'm running Opus 46 as my parent agent, uh, if an explore sub agent kicks off, which is built into cursor, is it going to use opus 46? Do you happen to know?
>> Yeah. So, you can actually specify the model that sub aent uses. Um, drop an example in chat. But we have one internally which is Oracle that I've saw a lot of mutter internally about being spawned and it's just it tells it to use the most expensive thinking model really intelligently apply it and use it to kind of do deep reasoning. Um you can also spin off really fast cheaper models as well. Um so this is something that you can specify. Yeah, in that sub aent
file, you as I showed you there, you can you can specify uh the agent and and by the way, what we're seeing on screen here is uh composer one has finished up uh building out the uh the uh multiplication game and it is now testing um and using screenshots. It appears to be really good at multiplication, which is impressive. Um in terms of uh model selection, um and we can kind of close out with this. You know, I kind of think uh of models um being in kind of three different categories. There are standard models,
there are thinking models, also known as reasoning models, and then we also have max mode. Um so standard models are going to be the models in the list uh in that menu picture picker that don't have a brain next to them. Um, those are going to be the fastest models to respond and the least expensive, meaning that when you submit a prompt to a standard model, it thinks once and responds back to you. A thinking model, which are the models with the brain next
to them. Those are going to use something called chain of thought reasoning. And this is a process where the model thinks and reflects, thinks and reflects, thinks and reflects until it gives you an output. As a result, it takes longer for it to return a response to you and it eats significantly more tokens. So, I would save thinking models for really when you need deeper reasoning work, when you're doing a plan, let's say, or if maybe a standard
model is um it's just not cutting it, it's hitting a wall. Uh I would I would reach for that that thinking model. Um and then lastly, max mode is a feature in cursor that will significantly increase the size of the context window for the model. This is essentially increasing the amount of short-term memory that that model has. Again, as the context window grows and grows, the accuracy of the model degrades, but there are certain use cases where you
want a really large context window. For example, if you're asking the model to audit a really large codebase and it needs to be aware of all those files. So, I would think about in terms of model selection and also economical choices, standard thinking and then max mode and try to just reach for the model or the mode that's appropriate for your particular use case.
All right, Emily, we're on the hour here. I'm going to pass it back to you to close it out. Thank you to you and Vincent for helping out in the Q&A. And I hope everybody uh is inspired here to um to try some new tools and cursor. >> Awesome. Thanks everyone for joining. And I did want to plug our newest feature that launched today, which is automations that actually where you can build agents that run automatically. Um so think about kind of rules, command,
sub agents that you trigger whenever a specific action happens. Um so drop the link in chat. We'll also send out the recording after the call and saw some folks ask for a one-page summary of everything we covered, when to use each tool. So, we'll make sure to send that out afterwards. But thanks again for joining and have a great day. Thanks everyone.