Cursor x Slack

0:01 Thanks everyone for joining. Really excited to tell you a little bit more about how Cursor's using Slack as well as how the Slack team is using Cursor. Thanks for joining our workshop today. For those of you who haven't met, my name is Jack Clary. I'm a member of our field engineering team and so I work really closely with customers from a technical perspective on how to leverage the most out of Cursor. Joined alongside me, we have Nathan and so we're going to go ahead and kick off here. Please feel

0:28 free to drop any questions in the chat and we'd be happy to answer them. And I'm going to go ahead and hand it over to Nathan and learn a little bit more about his workflow. So, thanks. Hey everyone, I'm Nathan. I'm with Slack's security team. Massive fan of Cursor so when this came together, I jumped at the occasion. We'd love to use Cursor at Slack and I feel like working at Slack you kind of learn how to use Slack in maybe unique ways and it's always fun to kind of share that with other people that

1:00 [clears throat] use Slack and now Cursor. So for today's demo I'm just going to share my screen. I'm going to show a few things. So everyone might know that Slack has a Slack MCP now that Cursor can use and then Cursor also has a Slack integration. So we want to kind of show you guys those both in real time. So in our demo space here, we've got Steven Lee who is let's say he's like a support engineer. So he's on call receiving alerts, triage those alerts, working with like the feature teams

1:41 but doesn't necessarily know kind of the underlying code that those alerts or customer feedback is coming in about. And so before it would be a really manual process for Steven to kind of like track down like what team works on this feature and like who should I escalate to. But we want to show like kind of the power of Slack and Cursor together where it kind of empowers somebody like Steven to really kind of cut through all that noise and kind of

2:07 leverage the power of both. So in this example we've got like a a feedback channel where we've got some like fake customers writing in about some sort of payments feature being broken. And so without having to know what these people are really even talking about from like a code perspective, Steven could come in and I've mentioned Cursor and just say like, "Hey, can you investigate this customer feedback?

2:32 Let's see what's wrong with the payments code, right?" Like no no reference to like what the repo is or that code lives cuz I mean Steven for this purpose doesn't know that. And then says like, "Hey, can we create a fix and open a PR?" So we'll send that and that will kick off the Cursor integration which is installed in this channel. I'll open the thread in a second when it gets us there. So yeah, that'll kick off a cloud agent.

3:02 And so the cloud agent has decided to point itself at our demo repo which is where the payments code lives and it's going to start its process. And so kind of like what's going on behind the scenes is it's going to pull that repo into its context. And then on top of that, it's going to start using Slack MCP to kind of process our first instruction.

3:25 So it's going to read this entire channel and this if this channel was bigger, it would just page through and it's going to start kind of picking out like the relevant context. And so in this demo like we've given it a few like details that are kind of like wide ranging that kind of gives it a sense that like, "Hmm, this payments code or or some sort of flow is creating like negative payments which is not what you want when you're making code that is supposed to facilitate payments. You

3:53 don't want to be giving people refunds essentially. So it's gone through the MCP and now it's running through the actual code. You can kind of see it in live time. It'll just kind of show these updates. Another view that we could pop into is also like Cursor's agents browser itself and we could open kind of the same thing to kind of see it working there.

4:13 And so I mean we can already see it's starting to make code changes but I'm going to pop back to Slack because while this runs, I also want to show kind of another way that we could kick this off because this will take a second and it'll be fun to come back to once it's done. But this is one sense where like somebody could come in and like just leverage the Slack context here to give Cursor kind of like a head start of where to look. As you can see like it

4:38 actually works pretty great, right? To like find the context based off of like these messages to where to like kind of filter the files it looks at and then it kind of well it reads the code and then can go from there. Another cool way that we like to use this internally at Slack is sometimes we'll set up CI channels where it's just alerts from could be like Buildkite, could be GitHub actions, it could be whatever CI system you're running. And if a test comes in that's failed or some sort of failure alert, you can actually

5:13 also tag Cursor right in this thread and say like, "Hey, can you investigate this thread and then post a fix?" And I mean we probably have a good example here of kind of showing kind of similar to what I just did but obviously it starts off with a lot more context, right? Because it's it can go read like the exact alert failure and then get a head start from there. So if you want like a really surgical fix like maybe Steven in this case like actually

5:45 works with the payment code, right? And knows exactly what to do. I'm just going to pause. We just saw that Cursor pushed a fix and our test came back successful. So our other thread is working. But to go back to this example, yeah like you you could be really surgical but or if you are like how we started, if you actually don't know the code you're working in, like that Slack context kind of helps Cursor get it to the point where it's as if you

6:14 invoked it in that thread. Um I guess it's still running a task. I'm sure it's just opening the PR. It's doing the screen recording. So I mean we can go back to payments. We don't need to open. I don't need to wait for PR to open. I mean this this shows that the code works. This is Cursor's got this really cool feature where it will actually like go through like a mock browser and do a screen recording of it proving it works and it's decided to do that for our live

6:46 demo instead of just opening a PR. But yeah, I mean that kind of shows um using some Slack context and I mean I want to like talk about too like how I personally use it. So some some kind of cool ways like in this case, we can actually check if the PR has been opened before the um screen.

7:11 Yeah, 2 minutes ago. Cool. Let's open that. Okay. So I mean this is the PR created. And so and I didn't prop this so I'm not surprised to see it. But like in my actual day-to-day work when I'm actually creating PRs with Cursor and Slack, I'll actually like I have like a Cursor rule and even a skill if I need to get a little bit more in depth where it will actually like create a whole Slack context section. So in our case, when it read all of those contextual messages in like the customer's feedback channel I

7:47 have a rule and a skill that will actually like kind of work that into the PR description that says like, "Hey, like these are the failing reports." Like sometimes it counts them if if we're dealing with volume. This is like what we identified as a fix. The PR is obviously the fix.

8:05 And then Cursor will also give you the Slack thread to where we invoked it. So when I said, "Add Cursor, can you fix that?" So now for the reviewer, they're not just getting like a blind PR, right? Like in our case it's the diff is pretty small so that's probably fine. But again like somebody like Steven or if somebody's reviewing this and they have no idea they haven't seen like the failing reports yet, maybe they missed the GitHub actions failure report. Um they can pop right back into Slack. There's

8:35 no searching in Slack. There's no DMing somebody like, "Hey, what is this PR about?" Cursor can build like a really nice little section here. And so that is like one of the huge ones I do at Slack. Another cool thing is if I know I mean this demo person has no name. But if I let's let's call this person Mary. If I knew Mary really cares about something in development. So like if she really cares about guardrails and like does this feature meet these guardrails that we want to implement for this code?

9:09 I actually use Cursor while reading the code that I'm working on to actually go look at the stakeholders that that code belongs to. So whether that's kind of going through like the Git log history to kind of see like, "Okay, who's touching this code frequently?" Or going into like the PR's channel and saying like, "Who's reviewing this code frequently?" Kind of a mix of both. I'll actually ask Cursor to use Slack MCP to like give me a highlighted bullet point list of like, "Okay, like

9:38 what is important to Mary when they're reviewing code? Like what do I what what like bar do I need to meet for Mary to be happier with my review?" And Cursor plus Slack is great because it it kind of automates all that searching and kind of me deciding like read through hundreds if not more messages from Mary and like all of these GitHub reviews and it gives me like a great sense of like, okay, this is exactly what Mary wants. I actually use that this morning for real work.

10:08 I needed to reach out to a stakeholder and I just had cursor and Slack MCP spin me up like what is the stakeholder most interested in and like when I'm coming to them with this ask like A, how should I draft the message? Like what style do they appreciate? Like do they concise concise? Do they like deep dive and detail? Do they like a mix? And then also like what projects are they working on because maybe there's some crossover and stuff like that. So

10:35 that is on like the code side. I also want to touch on we can also check Let's see. Okay, it's still doing screen recording. I also want to touch on the cursor's plan feature. I'm a huge fan of the cursor plan feature if anyone's tried it and I will make plans for my plans.

10:57 And why I say that is because normally like my plan for my plan is actually a lot of cursor and Slack just going through hundreds if not thousands of messages and kind of like getting me the context without me having to do that manually of like, okay, this is the idea I'm interested in or like this is the problem I'm trying to solve. Go find me like the existing conversation about this and then I kind of have a cursor break that into kind of some categories. So like tell me about like the the

11:29 decisions we've made. Tell me about any insights you've learned about this topic and then also tell me about all the open questions, right? Because maybe I'm answering one of those open questions and that'll help me kind of steer what I'm building or maybe I have the same open questions and based on kind of that report it generates, now I suddenly know who to go talk to with those open questions cuz it's really good at like kind of finding patterns of like, hey so and so asked this and then

11:56 they asked this highly similar question. So this seems like a good stakeholder to go talk to. So like not only is it kind of helping me inform the code and kind of like the problems or like the approach to problem-solving, but it's also like giving me that context of like who are the stakeholders involved like not all conversation happens in GitHub and not all conversation happens in Slack, right? Like when you're developing things get split. You can even add Jira or or some sort of kind of like task tracking to

12:25 that. So cursor with Slack MCP really kind of helps me cut all cut through all of that and generate. So that first plan is a lot of Slack context, a lot of kind of discussions and then I do a pass and kind of feed my own ideas and my own questions into that and then I use that actual initial plan to then go generate the real plan that is actually like what do I want to do to the code base now based on all of that like Slack context. And prior to all of this, that would

12:58 have been like a really long manual process of like sharing a Slack canvas, like get eliciting feedback, right? Like talking to everyone involved and not to say that that's all gone, but it's a huge huge jump forward in like kind of not spending an hour in Slack search trying to corral all of that context together. I can just have kind of a cursor agent or multiple agents doing that. Um in the background while I'm actually doing work that I'm interested in. And then kind of like the final thing

13:30 that I've really started to do and this is maybe less about development and more about career, but now that I spend so much time in cursor and I really spend a lot of time in Slack cuz I work at Slack. Every time I close out a PR project, I'll actually have like a cursor sub agent that I've created go through and kind of pull out like the wins and then it will actually go update a Slack canvas I have just in my own DM to kind of keep like a career log for me cuz if anyone's done career development

14:01 you've all been asked like, so what was the last quarter? Like what did you do? Like what are some stats you can share or like what have what have you been doing for like the last year? Again, prior to that since that was all in Slack for me, that would be a huge task of like constantly going through Slack, Jira, GitHub, Figma, whatever. All of those trying to like bring everything together and now I just have a cursor sub agent that's plugged into all of my tools and obviously the

14:29 code and I can run as I kind of create that code kind of like do all of that busy work for me. And it's great because it's one thing that I like don't like doing, but it's kind of necessary if you want to like kind of prove what you've been doing, but also like I feel like it probably does a better job than me, right? Because it's going to keep it's going to keep looking and I can keep invoking it if I need to keep looking versus [snorts] like after an hour of searching Slack for some obscure commit that I really

15:00 want to showcase and not finding it. Chances are I'm probably going to like give up, right? And come back later, but I can kind of offload all of that. Um not exciting, but still important work to cursor because it's really good at that. Um So yeah, it's kind of like the main interesting ways I've been using cursor with Slack. I'd love to kind of hear from people once we have um a question period. I wish I could show you this done. Um it is still

15:30 Okay, so it's modified the PR still Okay, so it's modified the PR probably with the screen recording. But yeah, I hope that kind of gave everyone a sense of like the power. And I mean I want to show I mean if it if it works, we can There we go. Yeah, perfect perfect timing.

15:44 I so I just want to show like once it's done, it will actually update the thread with kind of like the final log of what's what it's done, which is really cool. So also like using cursor and Slack as you would expect isn't kind of like a blind process like it actually tell you what it's done. In this case it produced a really cool screen share. And then like if you wanted, this is an actual like cursor chat, right? So we could just like kind of ask questions about it here. But yeah, that is kind of the whole process

16:15 of two ways that you can invoke cursor in Slack and then hopefully you found some interesting points and how I actually use it day to day. Thanks Nathan. Yeah, I found this super interesting and I'm I'm sure that now that our productivity is unbounded by time, we can send off all these agents before we close work and then wake up the next morning to see, you know, the fixes. It's also interesting on the cloud agent front how if you're working across a distributed team in multiple time zones,

16:45 sometimes it can be helpful to trigger these tasks such that they can then go review them maybe when you're offline. And so I wanted to show a little bit more about these types of workflows and in order to do that, I thought it would be helpful to just share some more color on how cursor is using cursor.

17:04 plus Slack. And so I'm going to go ahead and share my screen here. Cool. So before I jump into Slack uh one question I get a lot is, you know, how does cursor build with cursor? And with respect to Slack, how can we make this you know, really productive for our workflows?

17:24 And so I want to share a few examples from our team. And when we think about building sort of this agent system and this theme that we're building towards, I think one of the really useful things to think about is from the other direction. You know, what are all of the human steps in this new world of development?

17:41 And of course as we all know in the software development life cycle, we have a planning phase, a building phase, a shipping phase where we're validating and making sure that the infrastructure is running properly and then of course we have the retrospective phase to make sure that we're learning from mistakes and making sure that things are getting better for the next run. And so in these you know, distinct phases, there's of course ways that we can chain

18:06 together systems like the ones that we're seeing on this screen. So let's assume we can chain together and get agents to do a lot of the stuff in between. A lot of the things that are kind of gumming up our plates taking us away from working on more novel and high leverage projects. And so let's say that you have a workflow at your company that needs to happen you know, correctly 99% of the time and AI is at the center. This is extremely difficult to achieve

18:30 and while we're maybe not at yet at the point where you can reliably hit the three nines, honestly even one nine is hard, but each additional nine is just as hard as the last. And so when you're building these these agent systems, you need to know when they're wrong and when they should escalate to a human. And they need to be interruptible. And so I like to approach it from that angle and ask myself, what are the things that we still want a human to do and what are kind of the steps that we need to take

18:58 in order for that to happen. And so as we saw in Nathan's demo, there's sort of that visual artifact that just lets you know when you're in the planning phase, you can kind of imagine agents are getting really good at collecting user feedback. They're good doing good at exploring the code base and then preparing sort of plans and visual screen recordings to show if they're on or or off the right track. But at some point before you spend too much time building, you also want to make sure that you know, that artifact

19:27 in in visual code that it's building is something that indeed that you want to invest in. And so in this build phase, obviously there's a lot of friction that happens here. And so by the end of the day once you get it into production, I think all of us all of us have agreed that we still want a human name on it who said, yes, this looks good and it's ready to go to production. And so we'll probably have to make further improvements for reviewing and approving, whether we're using like a

19:55 cursor bug bot or building our own agent team to do that review ourselves. And so, I want to share some notes from the field, and I think what's interesting here is that in each distinct phase, there's a lot of different collaboration and conversations happening in Slack. And so, uh I like to think of our jobs as basically turning intelligence into software. So, when we are using intelligence with these models, the harness, that's sort of what's made a lot of this AI revolution possible. And then we have

20:26 humans at the top. Um so, this is just one example of like maybe, you know, reviewing a PR and then giving feedback uh back to the agent on these artifacts. But in the middle, we have this system. This is the team of agents that we need to build, and I think the really hard part is figuring out what should be coming out of this system. Um ideally, it's very clean like artifacts and PRs that are reviewable, um and have a very clear synthesis of what the agent

20:52 did. And obviously, you want to have a really good input and output I/O loop where the human is still able to give high-fidelity feedback to the agent. And so, as I think about it more and more in this next generation of building, Slack is sort of becoming the IDE in some way where we'll take on um all of these systems that we're building and then have a human in the loop review them sort of in Slack. And so, um the two agents that I want to introduce you to that that we've been building is

21:20 first our product manager agent and then our engineering manager agent. The product manager agent on the left uses Slack sort of part and parcel with its workflow. So, I'm going to show you how this is set up. Um but we do indeed have these agents working in production. Um if you would have told me a month ago that we would have a PM agent and an EM agent, I would have told you you were crazy. Uh but I actually think this has been really helpful for helping our team

21:44 stay productive. And we have an engineer in our team that that noticed a problem. Uh I'll explain the problem in a little bit, and then I'll walk through the agent team architecture here. Um but basically, when we were launching Glass, which is our new internal name for the agent window, it's basically just an orchestrator control plane that allows you to manage all of your agents in one place.

22:06 We encouraged our entire company to adopt the agent window and Glass as much as possible and report every single paper cut, every single bug, every single polished detail into a channel that's called issues glass. So, we had a Slack channel called issues glass that we were just reporting all of our internal feedback to. And so, we have this Slack channel.

22:27 Folks are reporting, you know, 10 to 20 issues a day. And I think the team at Cursor is doing other things than just writing lines of code. Every team has tribal knowledge that lives in our Slack Slack threads, our Jira tickets, our GitHub PRs, um or your 2:00 a.m. on-call engineering sort of incident channels. All of that context lives in Slack, which means that a lot of our people would sort of report an issue, and then we would spin up a cloud agent and say like, "Actor, you know, server, please fix." Um and

22:56 so, we sort of have this internal joke where we say that we have a guy working on it, which really just means I booted up a cloud agent to go and solve this problem. Um and that cloud agent usually boots up from Slack. Uh but we noticed that our cloud agents weren't making a ton of progress all the time. They didn't get stuck, but they just weren't actually shipping fixes all the time. And so, we had this interesting idea where we said, "I wonder what would happen if we got a little bit more rigorous in how we

23:25 reported uh paper cuts in Slack?" And um if we could build a consistent pattern for how we want to report this, would this meaningfully improve agent output? And so, we built a skill, and then from that skill sort of markdown file, uh we basically taught the agent how to inspect the bug in more rigorous detail and get a quite more like, you know, useful explanation of, you know, what's going on in that part of the code. And we also gave it a system prompt just

23:57 so that it can re-prompt the user who's reporting this issue every couple minutes and come back with a bunch more questions about the bug and get into a lot more detail to dig out the nitty-gritty sort of reports from the issue that is uh being reported by a customer or internal sort of employee.

24:15 And so, sometimes it actually resolves itself like it opens up a support ticket. Other times, if it's a bug, it often triggers a feature request. Uh and so, that was sort of the first unit kind of of of brilliance in this workflow was let's use these skills and then let's make sort of a bug reporting agent. And so, that was kind of the genesis of the product manager agent. Um and now we have a bunch of issues flowing through this Slack channel, and we're doing a lot more synthesis on what's happening,

24:45 which is reducing the time it takes for our PMs to actually step in and prompt for more questions. The agent can kind of handle that itself. Um and then there's this other agent, which is a little more exponential, which is you know, who's actually going to go and fix these bugs? And so, the second one we're still working on, but it's basically an engineering uh manager that just assigns um the issues that the PM agent reports to cloud agents that can go and fix them.

25:13 And so, just to kind of show you the architecture of what this looks like before we go through a demo. Um again, these are fully autonomous. And when we say agent manager, there's usually a fully autonomous agent that is running. It's always on. It's sensitizing the objections that we have running around bug reports. And then each of these is using a couple different skills, sub-agents to do bug reporting, uh sub-agents to do code exploration and

25:39 research, and sub-agents to do security review, as well as it has a bunch of tools at its disposal, one of which being the Slack MCP, to actually, you know, re-prompt the thread for more information and then post back into that thread once it's done. And we're getting a lot closer to, you know, building these self-regulating systems.

25:59 I think one important callout though is that this PM agent is still, you know, not quite in the build phase. There's times when it can reach for opening up a PR and fixing, but we're actually closer to more of the planning phase of the SDLC. And so, we've taken this, you know, really annoying task that would traditionally, you know, require an engineer to have to do, and we've made it a lot faster, much more delightful, and and much more automated. And so, I think we definitely have a long ways to

26:26 go here, and this will start to get better over time. Um but the last piece I want to share is really that skills are kind of the basis for all of these workflows. So, I know there's been some questions in the chat like, "How do we manage context? How do we ensure that, you know, these agents are actually working effectively with verifiable outputs?" And I think that skills are really under-appreciated part of this workflow. If the machine doesn't know

26:49 what you know, it can't help you. And so, I think give it your runbooks, codify your runbooks, your workflows, all that tribal knowledge on how this should be working. Um we actually spent a bunch of time with this. Uh we spent a bunch of time on this while we were building out the PM agent. And I think it's really important to the overall kind of vision of of this agent team. We have a very lengthy and precise how skill, which is kind of shown on the

27:15 right-hand side of this this slide, which is the critical piece that was missing when we were assigning cloud agents to things. Um we weren't getting it to rigorously test and explore the code base enough to figure out what was happening before it would quickly jump uh to make a fix. And so, that's why this this how skill is incredibly important. It's kind of an insight of when a Slack message comes in, I use this skill and then another skill to get

27:40 more information from the end user, and then that thing starts to become a much more durable experience that uh has has been giving us a a lot better results. So, I want to take you through one deep dive to just give you a sense of how these things are built and how they're working.

27:55 And so, to do that, uh I'll jump over to two examples of the PM agent. One of these was yesterday night, uh and the other one was this morning, so they're fairly fresh. Um the first one was uh one of our engineer managers basically had an idea where they wish you could hit E to start editing um from a part of the agent window. And so, immediately, our our PM agent kicked off cuz this is an always-on agent that's just inside of this Slack channel.

28:24 Uh it we didn't even need to prompt it or say at Cursor, it's just always on. And then it looked up the code and said, "Yes, you're correct. Uh looks like there is sort of an equivalent of this, um but if you want a single keystroke E, we'll need to sort of file a feature request for this." And so, it said, "Not filing a ticket for now." because it found that we had another engineer that already had something drafted. And basically, that engineer then reached out and was like,

28:51 "Great, I have something drafted. Um I'll ping you when it's merged and issue kind of resolved." And so, this was able to reduce the back and forth of like someone checking our code base, reviewing for PRs. Um it also avoided creating a, you know, accidental feature request that maybe had already had work actively being worked on. So, it's checking for duplicates, which I think just helps maintain a polished ticket manage system. And so, this one is kind

29:20 of one example of the PM agent um not necessarily doing any fixing um or even talking to other uh you know, systems to create a ticket, um but rather just doing the research that, you know, as PRs are being shipped so often, we're not necessarily always aware of what all of our teammates are working on. And so, that one kind of was a a good solution to that problem.

29:40 And then on the right-hand side here, uh this was more of a a feature request kind of build where we needed to get more information. So, uh one of our engineers reported what looks like um some sort of regression uh where basically they switched to debug mode, which is just a way to similar to plan mode um you know, test uh and form hypothesis for why an issue exists. It's just a native kind of uh /debug that you can use. Um but noticed a regression there. So, the PM agent started to take a look. No need to sort

30:15 of @mention me. It's just replying in this thread as normal, but it did notice that it needs more information. Often times when we're in a pinch and we're moving fast, we sort of, you know, inadvertently maybe don't give a lot of high-fidelity information that helps us get to the root cause of the issue. And so, this PM is basically just asking for more information. So, basically when you say it's completely missing, did the user, you know, resubmit it or what is

30:42 happening there? And then it also asked what client version are you on? Like just wanted to make sure that it's checking the right code path. I think this is kind of the secret sauce here. Um as versions are coming out, it wants to make sure that it's checking um the most recent sort of section of the code.

31:00 Then uh the same engineer was able to reply back one and two, as well as another sort of screenshot. And um from there, we actually had someone else kind of jump in and say that they already had a fix for it. Uh but what's interesting here is that um this conversation continued. The agent is already in the loop, and so basically it tracked the the issue. It used that how skill to try to understand what was going on. Um and then what's interesting here is that it then replied back to the engineer who had a fix and

31:30 said, "Hey, your fix, just to confirm, is for this specific issue or is it for something else? I want to make sure you're looped into the right ticket." And so, she replied, "Wonky spacing, those fixes already landed on main." And then our agent was like, "Got it, thanks. Uh I'll update sort of um the ticket and then make sure that this is all kind of being tracked effectively. So, this is just helping, I think, with a lot of that coordination step.

31:55 And so, those are two examples of how um the PM agent is working to sort of actively triage issues and do more deep work and investigative work. Now, I want to show you how this is actually working under the hood. So, um what this is using is something called cursor automations.

32:13 And so, for those of us that are familiar with cursor automations, um it's a cool feature that lets you configure workflows to trigger cloud agents on custom events. And so, these events could be anytime a certain message is sent in Slack or These agents are fully customizable with your own prompts, your own choice of tools and MCPs to do whatever you may need. And so, what this uh automation is doing, automation is sort of synonymous with the agent team uh for

32:46 this PM agent. And what this is doing is three things. There's a start trigger, a system prompt tied to a model, and then a number of tools that this agent can use at its disposal to sort of do work. And so, first, anytime a new message is sent in our issue glass channel uh from anyone in the channel, um it basically opens up a cloud agent uh in the respective repo um for uh the, you know, agent window product. And then it runs through this very tightly defined system instruction um to basically turn turn a vague report

33:20 into something that's actionable. Um and before it starts, it basically creates a to-do list um to acknowledge the report in the thread, classify it as um you know, a category of an issue, whether it's a bug, performance, feature request, or more of a feedback and question. And then it uses that how skill um to sort of understand uh and ask initial questions and do reconnaissance in our codebase to try to understand more and more um what is sort

33:47 of the root cause or, you know, ideas behind why this issue may exist. It can also cross-reference Linear, which is, you know, a ticket software that we use, which is very similar to Jira. Uh and then can skip ticket creation or perhaps append uh details to existing tickets.

34:04 I think the killer feature of this system prompt is how it uses the Slack MCP to actually uh interact with the uh reporters. And so, what it does is it polls the Slack thread via the conversation replies tool call in the Slack MCP every 10 seconds. And then it checks for new replies for anyone in the channel. Another thing it does is it uses the Slack API to download any shared images and examine them. So, as we saw in the example, um if someone reports a screenshot, uh it can actually carry

34:36 those details uh into its context. And so, if a video is shared, um you know, it will provide basically, "Can you add screenshots instead?" Uh because right now um it can't necessarily process video, but it can sort of process uh uh screenshots. And so, this is just one sort of gotcha that we added into the system prompt uh just to make it, you know, uh an order of magnitude more productive, so it's not spinning its wheels thinking what it should do.

35:06 The reason I say that is because we're giving it a very tightly defined tool call, only use this tool call, so it's not confused on what it should do. Um the second thing is we're giving it uh the member number of the the Slack group um or the Slack group, you know, ID. So, we have product areas to team mapping.

35:26 And when the agent is aware of those product areas to team mapping, uh it can ping individuals on the team to check the get history, use the get CLI to actually go and pull like get status um and uh actually build more context around, you know, the lineage of of the code that's being written or the code that's being investigated. And so, what's also nice is we're saying, "Don't mention in the Slack group uh directly." And I think one other thing that we

35:53 learned as we were building this system prompt, um given that, you know, this is trial and error, uh that's kind of why it's it's called prompt engineering, is one thing we found is that the agent was replying to the channel, but we wanted it to reply specifically to the thread. And so, we just told it to never post in the channel directly, every message is a threaded reply. And so, this just gave it a little bit more guidance on how it should interact. Following that same mental model of give it your run book,

36:20 give it an instructions just so that it knows how to interact uh within your organization. And so, from there, we can give it any tools. So, we give it access to the Slack MCP, uh Notion, Sentry, uh Linear, akin to Jira, uh as well as DataDog so that um if it needs to, it can pull relevant trace logs and then inject those trace logs back into its context as it's doing an investigative work. And then finally, it's using Databricks SQL. That's just what we use uh internally um for more product telemetry

36:52 tracking. And all of these tools are just deterministic ways that we can give the agent uh access to, you know, human systems that that we're maintaining um so it can get the context it needs for the job that we're giving it. And so, that is the PM uh agent. Um automations are really simple to build.

37:13 We can spin one up right here that basically just says like, you know, "Help me build a automation that automates the full loop of Slack-triggered CI failure to context-aware debugging all the way to PR creation and communication inside of our Confluence. Make sure this reduces tool switching and uh removes the guesswork behind retrieving context from our repos."

37:38 Cool. If my dictation worked, which it looks like it didn't, uh I will go ahead and just retype it um just for demo's sake here. And then what this is going to do is it will actually spin up the scaffolding of this automation um and then allow you to sort of iterate and kind of uh whittle down basically what it creates. I like to use this as a first pass uh just so that um as we're building, it can kind of give me like uh a good kind of starting point. So, we could call this like CI

38:07 supervisor here. Uh add a trigger. Maybe that's something in PR like anytime uh you know, main branch is failing or completed. Uh it could also be in Slack maybe when there's a new message in a channel. I'll select our product discussion channel here.

38:31 And we'll say all issues, and then we can select sort of my test repo. What's nice about this is any skills that I've created in our test repo, for example, I have one that's called do ticket. This just follows a workflow of how to interact with Jira. Um I can provide those skills to the cloud agent system prompt. Um and then I can give it sort of uh you know, more of a tightly defined instruction list. So, I might say like, you know, "Please uh look at Slack-triggered CI failure, um create PRs where necessary

39:01 with appropriate fixes, make sure that you pull the relevant issues and errors, if relevant, from DataDog." So, just giving it a first pass here. And then from here, we can add any MCP tool that we need. Um if you want to add an MCP that is uh not uh shown kind of in our out-of-box integration, one thing you can do is just go to MCP tool server and then say add custom MCP. So, maybe your team already has one. This is kind of a catch-all, so uh if you don't see

39:33 the integration listed out of the box, you can just add this sort of, you know, catch-all agnostic connector, uh which can just connect to sort of any MCP. And then from there uh any other additional tools that we may need and then to kind of wrap here before we go into Q&A. I could go back to a different Slack channel. Maybe product discussion where we had installed this. We see that we sort of have you know a brief description of what we want. Maybe we had some back and forth on

40:02 planning and then cursor can go ahead and you know open a PR with this fix following that pattern that we've given it the skills and anything else at its disposal and now I can have sort of a nice visual artifact of what it did. So this worked for about 40 minutes. Um I can go ahead and open up this video. I can see you know each part of the agent as it's thinking. So it ran into some failures. So it's using the get CLI to reload the dev server. It's checking sort of

40:34 its console and network logs to unblock itself and self-verify. Cool. So it got the issue. And then it realized it needed to apply a new skill to reload and then now I can know if this is on or off the right track. Even if my laptop got thrown into a river, I still have this artifact. I can access it on my mobile device.

40:55 These sort of agents have their own computers to work with access to more compute and they can also run sort of asynchronously. So I could fire off all these tasks before I you know close off my night. Wake up the next morning and we have you know actual work that can be done just to make sure I'm staying productive here. So To get started a couple different ways that you can integrate into Slack. I would say first and foremost make sure that when you go to your

41:24 cursor.com dashboard under integrations you can just add in Slack directly. This will allow you to do the app cursor mentions. But for more tightly defined workflows like the PM agent that we defined here I'd recommend probably exploring building an automation. And so you can set up cloud agents for any environment or repo that you want. There's a self-guided process.

41:50 This will basically just take a snapshot of your code base and install any dependencies and environment that you need using sort of any environment variables that we give it. Once that's done then we can go over to our agent sort of dashboard automations and then start to actually build out you know these these systems that can work at different parts of the SDLC. So That sort of covers a couple other examples of how we could start to build different sort of agent teams using some of the primitives that cursor has out of

42:22 the box. Hope this was helpful. Maybe in the last couple minutes we have here we can pause for any you know major themes or questions. Let me just do a quick peruse of the chat. Cool. Yeah, I will share some of these skills afterwards. If you go to the cursor marketplace one thing that you can find is a number of these skills that I showed today as well as um how to actually get started with using the Slack MCP.

42:56 So if you just go to marketplace this has marketplace is the most up level of where you store your plugins. Plugins just store all of your MCPs, your sub agents, your skills, your commands, your rules and your hooks. So all of the markdown files that you use to build your agents can be bundled together inside of a plugin and hosted on the cursor marketplace either publicly or privately respective to your team private marketplace. So we have the Slack integration. And then the one that I

43:28 think goes very well with with using you know any of the other systems of records that you're using is our cursor team kit. And so we open sourced for example this CI agent sub sub agent that just watches CI continuously and checks for relevant past failure logs and then proactively kind of monitors it.

43:51 These can be used in GitHub actions or in that automation primitive that we are walking through here. And so these skills we can always invoke like CI supervisor assuming that I had this you know installed as a plugin. And so would encourage you all to kind of check out the marketplace.

44:09 Another quick plug is that we'll be hosting sessions on this later this month. But we did also release a SDK. I believe it's coming tomorrow as a sneak peek. And so you can think of this as more of a heavy code primitive where you can start to build more and more of these systems that can interact with all of the the systems that you work with every day. So Yeah, we'll go ahead and wrap there.

44:34 Thanks so much for the engagement and for the Slack team for showing off some really cool workflows. And yeah, you can always reach out to us at hi at support um for any sort of issues. Otherwise we'll sign off and thanks all for joining.