Cursor 201

0:01 Hey everyone. Um, I'm Julia. I'm a field engineer here at Cursor. Um, so my job is to be a technical resource and make sure all of our customers are able to get the most out of the Cursor product as possible. Thank you all for joining today. Um, if we're ready to get going, I'll go ahead and share my screen.

0:34 All right. Are we good all good there, Casey? Yep, we're all set and see the screen. Um, and someone asked if this is going to be recorded. Yes, it is going to be recorded. We can send it out afterwards. All right, awesome. So let's get going. So this is a 201 demo. So hopefully you all have played around with Cursor before and know some of the basic functionality. Um, what we're going to do today is go through some of the more advanced workflows that you can do in

1:06 Cursor. Um, so some of the topics that we're going to cover are skills and sub-agents, cloud agents and automations, computer use, and potentially bug bot if we have some time for it at the end. Um, encourage you to ask questions as I go. If anything comes up, we'll try to get to all of them.

1:29 Um, all right. So what we're looking at here is the Cursor 3 surface. So this is a new view that we released just a couple weeks ago. Um, this view has everything that the IDE has almost all of that functionality, but it's just a view that's a little bit more optimized for an agent first approach.

1:53 Um, so it gives you as you can see here on the left, gives you a view of all of the agents that you have across your different Cursor workspaces. So it's really great for working on agents in parallel across different projects and allows you to take more of a high-level agent orchestrator role. So the project we're going to be working on today is the Grafana repo which I've forked. Um, Grafana is some of you might be familiar with a open-source observability platform.

2:29 Um, if we open this side panel here, um, we can see Grafana open in this integrated browser window. Um, and I'll go through some of the other functionalities and buttons up here as we go through. Um, but for now this is the integrated browser view and here's our local instance of Grafana running right here.

2:57 Um, so Grafana is a pretty large repo. It's been around for a while and with any large repo, it takes a lot of time and effort to maintain it and to make sure that as new features are added and more code is added, we're not accumulating tech debt. So the first thing we're going to do today is go through a workflow to demonstrate how we can create a repeatable process for managing our tech debt in a large repo like Grafana. So um, we're going to use a skill to do this. So

3:35 we're going to just take a look at a skill that I've written here. All right, so skills are repeatable workflows that you can configure and allow your agent to follow that workflow. So if you find yourself kind of writing the same prompt and giving the same set of steps and directions to accomplish a certain task, that's a really great candidate to turn into a skill.

4:06 So under the hood, skills are just markdown files. We can see here that the agent will intelligently pull into context when it decides to that it needs to use that skill. Um, so we can create skills in a couple different ways. Um, first we can manually kind of write this markdown file.

4:31 That's a little bit cumbersome. I don't really recommend doing that unless you are really wanting to. But the easiest way to create a skill is to use this create skill command. Um, and we can say something like create a skill to format linear tickets with description, um, acceptance criteria, and classify with labels as bugs, features, etc.

5:04 Um, so prompting Cursor to do this will actually create a skill in your workspace that your agent can follow. Um, and this is a super quick way to make skills. Um, if you are curious about kind of like other skills that people have made or best use cases, we have some resources in our documentation under the skill [clears throat] section where you can see skills that other people have made that have worked well for them.

5:32 Um, you can also you don't need to use this create skill command. You can just describe in natural language, "Hey, can you create a skill to do XYZ, whatever I want to do." Um, okay, so you can see here as it's creating a skill, it's going to ask me some follow-up questions. I'll say it's a project skill.

5:53 Use it when creating or updating linear tickets. Let's strict template. So after I I enter all of these questions, Cursor is going to going to go ahead and create this skill in my project repo. So I'm going to actually stop that cuz we don't need to watch it make this skill. But getting back to our kind of main workflow, I'm going to go into ask mode and just ask it to summarize my identify tech debt skill. So that we can get a sense of what um,

6:35 the skill does. So on a high level, I'll let it write it out here, but what it does is goes through the entire repo, identifies areas of tech debt, so in the front end and back end areas where we're not following best practices or following conventions that the code base uses. Um, and then we ask it to update our linear tickets with the label tech debt. So we are kind of maintaining a collection of linear issues under this label that represent our sort of body of work for this tech debt.

7:14 And it'll ask it to make sure that we don't have any duplicates in that ticket collection, update any tickets if any of the code for those changed, and create new tickets if we find new issues. Um, and then it's uh, we also ask it to um, uh, write a file. So just a report on this kind of overview of the tech debt to a Confluence page. And then publish that either create a new one if it doesn't exist or update the existing one so that we have kind of like an up-to-date

7:53 record that other people on other teams can reference if they want to. Um, and then just give us a summary of that tech debt. So we're now that we have this skill kind of established and we know what it does, um, we're going to create a new agent. And we're going to create a cloud agent to actually go through and um, invoke this skill and have it work through this skill.

8:22 So if I come over here to a new agent, I'm in my Grafana repo and I want to create a cloud agent for this. So I'm just going to go to this drop down and select cloud. Um, and I'm going to ask it to use my identify tech debt skill. Um, I can make sure that I have my MCPs configured. So I have it last and turned on so that it's going to be able to publish that Confluence page. Um, I'm going to do it with uh, let's do it composer too fast.

8:59 Um, and then I'm going to kick that off. Whoop. Let's try GPT. Interesting. Um, okay, so live demo. >> [laughter] >> Uh, seems to be not working. Let's make sure that we're in um, we can do this locally for right now. Um, and get back to the cloud agents later. But I'll go ahead and kick this off and then I'll explain what a cloud agent is and when you would use it. So a cloud agent is essentially a agent that's working in a virtual environment that's spun up to kind of mirror your

9:44 local dev environment. So we launch this container and then we check out your repo into this container and then an agent works within that container to make changes, test those changes, um and uh then it can uh connect to your GitHub and post a PR for those changes. So, cloud agents are really great if you uh kind of don't want to um baby sit a uh certain agent and you kind of trust it to work uh in the background while you maybe work on something else. So, at the end of the day, say you uh

10:19 have made a plan, um like an implementation plan, um and then uh you want an agent to kind of straightforwardly implement that plan, you can kick off a cloud agent, shut your laptop, go do something else, um and that cloud agent will continue running. Um cloud agents are also really great for parallel work, um because uh each cloud agent runs in its own um uh virtual machine with its uh own checkout of the code. So, if I uh start one cloud agent and ask it to work

10:52 on one ticket and then start a different cloud agent in parallel and ask it to work on a different ticket, those two agents will work in separate checkouts of the code and uh not have any risk of uh clashing with each other. Um all right, so while that's running, um we're going to uh work on another ticket, and we'll go through a workflow that demonstrates um some use of uh sub agents. So, uh first thing I'm going to ask it to this new agent to do is to um pull my

11:28 open Jira tickets. And so, uh since we have that uh Atlassian MCP configured, um our agent is going to be able to uh talk to Jira and get those open tickets um uh through an MCP request to Jira. So, we can see this Atlassian MCP running here. All right, and we can see my um open tickets.

12:01 I can open these also um in Jira here. And all right, this is the ticket that we're going to be working on today. So, uh if we just go back to our uh Grafana app here, um we're going to be working on adding a logarithmic scale toggle to the explore graph panel. So, uh if I come into the explore page down here, um we can see this nice graph.

12:38 Um it has some different options for us to view uh the graph as, um but you can see that the scale um on the uh Y axis is always a linear scale. So, uh say that I had some data with uh that tended to have like really big spikes, um I might want to view this as a uh on a logarithmic scale so that I could um kind of better understand my data in uh for that use case. So, uh this is a um kind of more complex, more involved um feature.

13:13 And uh so, what I'm going to do um to start implementing that is I'm going to use plan mode. So, switch my agent into plan mode, um and then I'll ask it to plan out um cotton five. Um hopefully uh you already know about plan mode and have uh used it before, um but plan mode is a uh really great um workflow for more complex tickets.

13:41 So, it allows the agent to kind of think through all of the uh complexity and implications of the changes um that you might need to make in this ticket and kind of lay them all out before you kick off an agent to um actually go do and do the work.

13:59 All right, so I asked it to plan it out and we can already see some sub agents at work. Um So, sub agents, uh you will see them show up as these uh little um kind of separated boxes here. And what sub agents are are um specialized agents that your main agent will spawn um when it decides that it needs uh to use that sub agent. So, um we can see here that this is a uh explore sub agent. Um so, our main agent decided, "Okay, I need to explore a bunch of files. Um I uh don't want to do this kind of in

14:37 the main workflow. This is kind of a side task that I can delegate to a sub agent." So, uh two kind of important things about sub agents to keep in mind, um first is that uh sub agents, you can think of them as having kind of personas. So, you want to think of a sub agent as like, "Who are you?" Like, you have this personality. So, uh I have this explore um sub agent, and its job, and its only job, is to explore my code base. Um the second important thing to uh keep

15:11 in mind with sub agents is that uh they have their own isolated context window. So, how it works is that the main agent, when it spawns a sub agent, um it will give it kind of just the context uh information that it needs to do its specific task. And then the uh sub agent will run in its own context window.

15:31 So, it doesn't have um all of the information of the main chat um that's kind of uh could potentially like bloat its context window or um confuse it or get it off track of its task. And then any outputs that it generates, like uh in the explore agent, for example, it's going through a lot of files, it's generating a lot of outputs, um we don't want that output uh context to um be kind of bloating and corrupting our main agent's context. So, it's a really good

15:59 way to kind of control context and isolate context [clears throat] between different tasks so that our main agent can stay um focused on its uh kind of high-level uh list of things that it's trying to do. Um okay, so we have a few questions. We'll just go through them here.

16:21 Um we can see our uh devil's advocate sub agent ran also, and I'll just show you this one cuz this one is kind of cool. Um if I come into settings here, go to rule skills and sub agents, um I can come down here and see all of the sub agents that I have configured in my workspace. So, this devil's advocate sub agent, um we can see that it's uh make this a little bit bigger.

16:49 Um here is this description with its uh persona. So, uh this sub agent's job is to um kind of take a uh critical look at uh the plan or the code changes that you've done, and um kind of criticize them and bring up maybe uh differing opinions, um and kind of poke holes in your plan.

17:11 So, uh this one is really great for the planning stage, um and could be really powerful for iterating on your plan and hardening it, um and making sure that it's really um kind of set to go before you start building. >> [clears throat] >> So, sometimes uh there's a little bit of confusion between when to use a skill and when to use a sub agent, um and I think it's kind of important to uh get a good uh mental model of the distinction. So, a skill is uh what you're telling

17:42 your agent to do, so a workflow that you want your agent to do. A persona is like who you want your agent to be. So, it's a little bit nuanced, um there is some uh good documentation, um let me see if I can just pull that up really quickly. Um And here around sub agents, um there's a whole table, I think, down here outlining the difference between um skills and sub agents or when to use each.

18:26 I think that's in the documentation. Oh, yep, here we go. So, when to use sub agents. Um another thing that you can do is um that I do frequently is ask Cursor, um "Hey, I have this idea. Uh do I want um I want to do this thing. Would this be better as a skill or as a sub agent?" Um and that should give you some good guidance there.

18:50 All right, so if we go back to our main agent here, it looks like it made this plan um here to uh plan out our implementation. Um Oh, persona or sub agent. Um so, once this plan is done, I can um kind of iterate back and forth and um say that I want it to uh use the devil's advocate sub agent again.

19:21 Um I can invoke sub agents with that slash um command, just slash and then the sub agent's name, and that will give uh our main agent kind of explicit instructions to use that sub agent, and we can see it in here um going again. Um All right, so uh we could let that run and kind of listen to its suggestions. Um for right now, uh I'm going to stop this, um and uh for kind of the purposes of time, we're going to uh just stick with the plan that we have here.

19:56 Um I'm going to ask it to uh now um publish my plan to Confluence. Um under the plan's name in my Grafana project. So, this is again going to use that um Atlassian MCP and write this uh plan to my uh Confluence workspace. And uh this is a really great way to um share your plans as kind of technical design documents with the rest of your team um so that you can uh collaborate with them, um get feedback on it, maybe and iterate um before you uh start building.

20:44 So, we can see our plan here and it's going to open in the wrong window again. Um let's just navigate over here. All right, cool. So, here we can see our plan in Confluence. Um teammates can comment on this and then um say we left this up for a few days for a feedback, I could then um when I'm ready to actually build this, go back and um pull this Confluence page and get all of that feedback um along with it into my agent context.

21:32 All right, so um now that we have our plan and say it's been a few days, we've gotten the feedback that we need. Um I'm going to open up a new agent and let's try a cloud agent again. Um and I'm just going to ask it to um implement this plan. And I'm going to give it a link to my Confluence page.

21:56 And again, we'll just make sure that our MCP servers are all configured. And still no. Let me just quickly quit Cursor and reload it. Um and see if that helps. All right, so we're going to a new cloud agent. All right, cool. So, um now we can see uh this cloud agent at work. Um the first thing it's going to do that you can see um here is it's going to set up that environment um and that's that uh virtual environment that's running in the cloud um that is

22:53 checking out your code and then um it's going to start making changes here. So, uh we're going to let this agent run and then um flip back to our uh tech debt and check back in on that. Um okay, cool. So, here is our tech debt agent. We can see um that it worked for a little bit and then uh gave us this summary output.

23:21 If we want to see kind of exactly what it did um in this agent's uh window view, we can click into here and kind of see um all of the details of that run. Um but we can see that it uh published the content to Confluence, um did this kind of uh evaluation and scan of the tech debt and then um it didn't create any new linear tickets because I'd already run this skill before. Um but it looks like it updated too.

23:52 Um and we can uh go view the page uh in Confluence if we want. Um so, now that we have this kind of workflow to evaluate tech debt and um keep kind of a uh running living document on Confluence, um I might not want to manage this workflow um manually anymore. So, I might not want to run this skill and kick this skill off um kind of myself every night um to kind of keep on top of my tech debt. So, what I can do to help uh automate this with Cursor is I can

24:29 create an automation. Um and to do that, uh I'm going to go to um the Cursor uh website. This will be available in um Cursor 3 uh very soon. Um but right now you get to it from uh cursor.com/automations or right here. So, uh an automation is essentially like a always-on cloud agent um that you can uh trigger from a uh event or uh that you can run on a schedule.

25:03 So, there are uh some great kind of automation examples here uh that you can look at for some inspiration if you want. Um so, things like uh summarizing changes, um finding vulnerabilities, test coverage. Um there are also some more down here um to give you some good ideas on how you might want to use these.

25:26 Um but I'm going to create a new one. And I'm going to call it um update tech debt. I'm going to add this trigger. Um and you can see that we have uh some options for uh these schedule triggers, which is like uh essentially just a cron job, so you can specify um how often you want it to run. Maybe I want it to run every day um at like 11:00 p.m. or 10:00 p.m.

25:55 Um I want to do this in my Grafana repo and on the main branch. So, uh in addition to the cron uh schedule triggers, um there are also some uh event triggers that I mentioned. So, uh you can uh once you're integrated with GitHub, you can uh trigger some automations um from uh these GitHub events. Uh you can also trigger them from Slack events, uh linear events, PagerDuty, uh Sentry.

26:30 Um and then uh if you kind of none of these uh fit your use case, you can also trigger it from a webhook. Um so, these make it uh super uh configurable to kind of whatever use case you would need. Um we don't have Jira triggers right now, those are coming soon. Um but if you wanted to uh create an automation that um was triggered say like when you um moved a ticket into a certain status, uh you could use a webhook to accomplish that.

27:02 All right, so once I set up my triggers, um I'm going to give my uh automation agent some instructions, so I'm going to say run um uh Let me remind myself what my skill is called, identify tech debt. And um I'm going to say uh print the output and then uh DM me on Slack with that output.

27:34 You can run it with uh let's run it with Composer, too. Um and then I'm going to add the uh MCP tools that we need, so this will need um to use the Atlassian MCP. Um and we'll give it Slack. Um and then once it's done, I'm going to ask it to uh direct message me. And let's actually do this with um Codex.

28:18 All right, and it's going to validate my prompt. Um and uh we'll run it on the cloud. All right, and then we'll click create. Oh, looks like my Slack tool isn't configured yet, so uh we'll just disconnect that one for now. Um and just have it print the output.

28:49 All right, cool. If I had authenticated my Slack, it would have been able to um do that DM, but I don't want to waste time doing that now. So, I'll uh create my um automation and um now what I can do is this will run uh tonight at 10:00 p.m.

29:07 um but say that I want to do a test run to make sure that it's working, um I can come and click this button and run test and um that will uh kick off that test run that I can then um come and click into and uh watch the agent working to make sure that um my automation is uh kind of as expected.

29:39 All right. Um so, now that we've seen uh automations, um we can check back in on this um after we give it a minute to run. We're going to flip back to our agent view. And we'll check back in on this cloud agent that's implementing our plan. So we can see it's working. It's not quite um done yet, but it's made it through most of its to-dos and now it's just verifying the changes.

30:20 So I ran this wasn't sure this was going to run in time, so I ran this before an implementation of the same um prompt to make this plan for the same ticket. And this is a cloud agent that ran earlier. We can see it ran for half an hour. And what I asked it to do in the prompt um was to create a video artifact that um walked through the actual UI changes that it made to kind of validate uh that it did the right thing and implemented the feature. So we can see that the agent ran. It

30:58 made its changes. Um and then created this video walking through this environment. So what we're looking at here, the video is quite quick, so I'll just pause it for a second. Um what we're looking at here is the browser running inside of that VM. So the agent went in to that VM, made its changes, and then spun up a local service to run Grafana, and then actually navigated through that browser UI.

31:29 So hopefully you can see this and this isn't too small or dark. Um but here is our explorer graph that we were looking at earlier. And what was added was this linear and log toggle. So it starts on linear, and then we can see that the agent knew that it needed to pull up this page where it made the changes, and then to demonstrate the changes it switches from that linear view to that log view. So these artifacts are super super helpful when you're spinning up cloud agents to

32:03 get some validation pretty quickly that the agent did what you wanted or not. So especially for UI changes, these can be super super powerful. Sometimes just a tip, you need to kind of explicitly tell it to make a video artifact, especially depending on which model that you use. Some of them are kind of more uh eager than others to kind of take it upon themselves to make that artifact. So if you want to see these, I just told it in the prompt to create a video artifact for that.

32:39 Um from here, once this agent this cloud agent is done it goes ahead and makes a PR for this change. Um so we're looking right now in the changes tab. And this tab allows you to review changes in different files so that you can see kind of exactly what the agent did. Um this is a link to the PR. Here, so we can see um It's open here, so it opens a PR in a draft state, gives a kind of overview overview of what it did, and then it will actually link that video that it made kind of automatically directly to this

33:30 PR. So we can see this play again right from the PR. Um Cool. And then from here I can also just mark this as ready, which will switch it from a draft view to a ready to review PR. Um see if there's any other anything else to show on here. Um No, that's that's good.

34:06 Um all right, while we seems like we have a little bit of time left, so I'm just going to also show you um the bug bot report on that PR. Actually bug bot didn't run on that PR. I'll show it to you on a different PR. Um so once you make a PR and either you or an agent opens up a PR um you can configure your GitHub to run bug bot automatically.

34:40 Um You open up this one. Um to run a comprehensive code review on all of the changes in the PR. So we can see on this PR it's still in draft and bug bot still ran. There are some configurable settings that you can set on bug bot to whether you want it to run kind of on every PR or not not on not run on draft PRs etc. But we can see our bug bot reviewed automatically and found two issues.

35:17 Um so bug bot I personally have been very impressed by kind of the depth that it goes into in reviewing code and really the kind of like holistic view it takes when finding bugs. So it's really good at finding issues kind of across files instead of just reading through the diff and identifying like single file issues.

35:43 So we can see it left a couple of comments here. Um if I wanted to I could go ahead and just fix this in cursor. And um can just stash our changes here. Um and this will open cursor and bring in that prompt from bug bot and give the agent like instantly kind of enough context that it needs to solve this issue.

36:24 Um all right, before I show um the uh marketplace and some plugins. Are there any questions, Casey, that were not answered from the chat? Yeah, there's been a bunch pouring in, so think yeah, I've been answering most of them async, but Joey, if you want to maybe scan through a couple of them if you have some time, go for it. There's like 10 open right now. Yep.

36:53 Um Okay, let me just find the ones that um Okay, cool. So how did you open the Grafana interface? Um let me show you. So if I open up a new agent, I'm in the Grafana repo here. This is a drop down that will let me select different repos for my workspaces. Um I click this and apologies, this is really small. >> [laughter] >> Um that might be issue, but I click this show panel up here.

37:34 And then I come over to the side panel. I have a couple different options up here. These are my changes, so I have no local changes now. There's a terminal view in here. And then this is the integrated browser view. Um see if my local is still running. Okay, it's not running anymore. Um but this would bring up if my local service is running. Let me actually just um Oh, it's cuz I'm on a different branch. Um this will uh let me just start this local server. Um

38:22 if my local server is started, I can just come into this integrated browser here. This is a full chromium browser, so I can go to I think my permissions. Yeah, I can go to like any website like google.com. Um but I can this is probably most helpful for viewing your local apps in here.

38:45 Um I'll answer the next question while this goes. Um I've tried to create context markdown files throughout my projects with the idea that it will help the agent understand, but I've wondered if there's really a value in this practice as maybe cursor or the models can interpret the code just fine without extra context. So it's worthwhile to create extra markdown files throughout the project for cursor in addition to rules and skills.

39:13 Um yeah, that's a good question. So um I so cursor and the agents um especially depending on which model you use, will generally be pretty good at understanding your code base without having to provide any additional kind of markdown files for like agent instructions or documentation.

39:35 Um cursor kind of specifically as a product uses something called semantic search, Um, is uh, we're able to do by um, indexing all the files in your workspace um, and then uh, embedding them into a vector store. Um, and then when you run a prompt or ask a question about your code base, uh, we embed that prompt and run a uh, similarity search against your code base. So, uh, that allows cursor to uh, pretty quickly and um, with pretty high quality um,

40:05 understand uh, your code base and kind of the context of like what change you want to make and uh, where you want to make those changes. Um, so you shouldn't really need to or feel like you need to make um, additional uh, markdown files or documentation. Um, but that being said, if there's um, certain uh, like uh, practices or um, conventions that are uh, maybe not exhibited by your entire code base or um, certain things that uh, you think an agent might not be

40:38 able to um, glean from just like reading the code itself. Um, you can create uh, a rule. Um, let me show you. Um, I think that would be a good a good candidate for a rule. Um, so I don't have See in here. Okay, so I have some rules here. Um, uh, Yeah, so this is a rule uh, this is an orgrid rule um, around brand style guides.

41:15 Style guidelines. Um, and rules compared to um, uh, just markdown files uh, that you have in your code around certain documentation is that rules are um, always uh, injected into the system prompt. Uh, you can also specify them uh, only when you're reading certain files, but uh, most important to remember is that uh, rules will get kind of like preferential treatment over just a normal markdown file in your repo.

41:45 Um, would it be possible to share these skills? Um, yes. So, uh, assuming that you're uh, meaning share these skills with the rest of your team. Um, or share the skills that I'm specifically working on. Um, if you mean share the skills with the rest of your team, uh, yes, you definitely can do that.

42:06 So, um, skills and rules and sub agents exist on um, kind of three different scopes. So, you can have uh, user level ones that are kind of personal to you. Um, if you like doing things a certain way or you're kind of um, testing playing around with certain things.

42:23 You can keep them at a user level. You can also keep them at a or repo repo level. Um, and commit them to your source code um, and then anybody who pulls that repo will have access to those uh, skills and rules and sub agents. Um, and then you can also have um, organization wide uh, or team wide uh, rules, skills and sub agents. Um, so I'm part of this uh, cursor field engineering team. So, as soon as I log into cursor, I inherit all of these um,

42:58 things just by being uh, part of that team. Um, another thing which uh, I was going to show, so I'm glad you asked that question. Um, is uh, this plugins uh, feature. So, um, a plugin is essentially just a bundle of rules, skills, sub agents, um, hooks and uh, MCPs. So, we have a bunch of plugins that are published by um, these like verified official third parties like um, if we look at what's a good one? Like the data dog one. So, data dog has gone and made this

43:34 plugin um, in coordination with cursor. Um, and they wrote these uh, skills for basically how to work with data dog um, as an agent. So, these are available um, these are really uh, cool and easy to work with. Um, you can also uh, if you go to the um, marketplace.

44:10 If you go to the marketplace here, um, you can see not only uh, these kind of like publicly available plugins, but you can see plugins for um, kind of published and usable by your team. So, since I'm part of this team, um, I can uh, download this cursor starter pack plugin.

44:28 Um, and this really lets uh, kind of power users at uh, your organization um, kind of build up this uh, tool set that everybody else can benefit from. All right, sorry. That was a really long answer. Um, how can we get access to the skills and sub agent information? Looking for the MD file. So, um, if we go back to our file tree here. Um, so again, uh, these things are at three different um, kind of scopes, user pro user, project and org. If you're not

45:07 able to find one, um, it might be at a different scope than you're looking at. So, uh, the um, project level ones will be under your um, workspace under this dot cursor file. Um, in these uh, sub folders. Org level ones, you can see um, by going to uh, settings here and then rules, skills and sub agents. Um, and you can also see your project ones here. I think this is probably the easiest way um, to see them at uh, this is my user level.

45:40 Um, my project level and then these are my team level. And then if I click into one of these, um, it will open the markdown file that I can read. Um, How can I make cursor's plan file names more readable? That's a good question. I've often wondered that. Let's see if we can um, I'm sure there's a way to do that. Let me see.

46:14 Um, where is my planning agent? Here we go. So, this did name it something good, but I have definitely had it name it things that aren't um, aren't super helpful. One thing that you can do is um, if you save this plan to your workspace, um, then it will just open as or then it will save it to just a file um, that you could probably rename like manually. Um, let's see if we have True, let's save that. Oh, I think we're on a different branch, so.

47:11 Um, but if you save it to your workspace, it should be just uh, stored as a regular file um, in your workspace and you should be able to change the name of that. Um, and you can also uh, edit this if you want to change like the title. Um, From where can you trigger bug bot? So, uh, bug bot is um, generally triggered automatically um, once you've configured it within uh, GitHub. So, if you go to um, your cursor dashboard, I believe.

48:04 Um, Oh, here we go. You go into integrations. Let me look at the docs for how to configure it. Um, but you should be able to connect um, through these uh, settings. Let me ask um, this is another cool feature of the documentation if you haven't seen this um, before. You can uh, open up this side panel and ask an agent specifically about cursor docs. So, where on the dashboard do I configure bug bot?

49:09 I may have already used my uh, my limit for this today. Um, but it's going to be a combination of your cursor settings and your GitHub settings and then it should um, be triggered automatically. Um, you can also configure it um, to Oh, here we go. So, uh, team settings. If you just uh, click enable here, um then it should kind of automatically um kick off uh once you do go through the off flow and everything.

49:48 Um I've time for a few more. Can we enable bug bot auto fix to run manually then trigger auto? Um yes, you can configure that um so that uh bug bot runs automatically um if you want it to and I I believe um similar to uh the other settings I mentioned, you can configure it to run automatically um kind of in certain situations. So, you might not want it to run automatically like um for every [clears throat] commit, but you might want it to run automatically for the first commit. Um pretty sure that there

50:33 uh that there's some configurability around that. Uh would it be a good use of a skill to add steps such as produce video artifacts so that regardless of the agent, it would have a video produced reliably? Um yes, that is a I think a good idea. Um you should I encourage you to play around with that. Um and uh yeah, that might be a uh helpful way to get it to kind of always uh produce an artifact when it's making a UI change.

51:24 Um a couple questions on uh Bitbucket integration um and automation with Bitbucket PR creation or similar example. Um so yeah, Bitbucket. I know that we're working on some tooling around Bitbucket right now that isn't uh quite out yet, but uh as I mentioned, you can um configure the uh webhooks. Um I'm not I don't have too much experience with configuring uh webhooks in uh Bitbucket, but I can show you um in the automations um what it looks like if you configure a webhook.

52:17 Um This is a bit of a bug, right? It takes the page. Um You see that might be a setting that you have to do. Um See if there's docs around. The webhook triggers. Um okay, yeah, these docs should provide um some information on how to create your own webhook. Um Apologies, I don't have that flow like locked and loaded. I've never done that but I've seen it do it from a Jira event. Um so, I know it's possible.

53:41 Um all right, maybe time for one more. Um okay, cool. This one is a good one. Um for sub agents, they are not inheriting the LM model from the main session. They are defaulting to the cursor composer model. Can you share if your sub agents are inheriting your main session? Um that is a good question. I don't think I covered that or didn't cover that in too much detail.

54:15 Um if we look at our Okay, here's our plan. So, uh cursor comes with a couple um like pre-configured sub agents. So, this one for um exploring, for example, um is kind of built in from cursor and it will use this when it needs to. Um and this is configured, I believe, to run um on the composer model.

54:46 Um when you create a sub agent, um let me actually open in here. Uh when you create a sub agent, you can specify um which model or which model class you want it to run on. Um and so, you can give it like specific model names or classes um and then it will pick those up. So, if you see it kind of defaulting to composer, it might be because it's a um one of those built-in sub agents. If it's not one of those, um would encourage you to kind of validate that um the model you selected here is

55:26 available to you and um like a valid uh model name. Um okay, I think that's all the time we have for questions. Um thank you again, everybody, so much for joining and um asking questions. Um sorry if I didn't get to your question. Tried to get to all of them, but um yeah, thanks so much for um taking the time.

55:53 Thanks, everyone. Appreciate it. Have a good one. Bye. All right, bye.