A reviewer leaves a comment on your pull request. Three minutes later, an AI agent has read the diff, written a fix, and pushed a new commit. Cursor shipped a major update to Cursor Automations yesterday, adding five GitHub triggers and a Slack integration that make exactly this possible. What was a coding assistant that waited for your instructions is now a background worker that responds to events in your workflow.
What does the update actually add?
Cursor Automations run a cloud-based AI agent that reacts to events automatically. The feature launched in March, but until yesterday it could only respond to broad PR-level events like "pull request opened" or "branch pushed." The new update makes triggers far more specific. Five new GitHub events are now supported:
- An inline review comment on a PR diff
- A submitted review (approved, changes requested, or comment)
- An issue comment on a non-PR issue
- A resolved or reopened review thread
- A completed GitHub Actions workflow on a branch or pull request
There is also a Slack trigger. React to any message in a public channel with an agreed-upon emoji, and the automation starts. Cursor's own team uses this internally: drop a bug report in #engineering, react with a wrench emoji, and an agent begins investigating the codebase.
Worth noting: the update also ships a /automate skill that lets you describe what you want in plain English. "When someone leaves a review comment, read the feedback and push a fix." Cursor then configures the trigger, the instructions, and the available tools automatically. Two ready-made templates come included: one that triages failed GitHub Actions runs, and one that auto-fixes PR review comments.
How do the new GitHub triggers work?
The agent reads the full PR diff context, understands the reviewer's comment, and pushes a targeted fix. Think of it as a junior developer who shows up for every code review, reads every comment, and gets to work immediately. This one never gets tired, never misses a thread, and keeps going at 3 a.m.
The difference from Cursor Bugbot comes down to direction. Bugbot scans your code proactively at every commit. Automations react to what happens: an event fires, the agent acts. The two are complementary. A team running Bugbot for an initial 90-second scan after each commit, then an Automation to follow up on reviewer feedback, ends up with a review pipeline that largely runs itself.
For context: the five new triggers extend an existing system that already supported events from GitHub, GitLab, Linear, Sentry, and PagerDuty. Until now, the agent responded at the PR level. Now it responds at the review-conversation level. Developers do not work in pull requests as monolithic units; they work in the back-and-forth threads inside them. That is the gap this update closes.
According to GitHub's 2025 State of the Octoverse report, teams using AI tools on code review workflows reduced pull request merge times by an average of 55%. A separate study from LinearB found that the average PR sits open for 4.5 days before it is merged, with review lag accounting for nearly half of that time. Cursor Automations target that specific bottleneck.
From Slack emoji to merged fix
The Slack integration solves a problem most dev teams recognize. A colleague pastes a stack trace in #engineering. Someone reacts with an eye emoji. The message disappears into the scroll. Three days later someone asks whether anyone picked it up.
With the new trigger, that emoji starts a Cursor agent. The agent reads the stack trace, finds the relevant code, and opens a pull request with a fix. No tab-switching between Slack and your editor required.
Cursor calls the emoji trigger a feature the team uses every day. The pattern is simple: someone pastes an error, a teammate reacts with a wrench, the agent reads the trace and opens a PR. The whole chain runs without a context switch.
Two limits to know upfront. The trigger works only in public Slack channels, not private channels or direct messages. And the agent shows up as the Cursor bot, not under your personal GitHub account.
Pricing and what you actually pay
Automations require Cursor's Teams plan: $40 per user per month. The Individual plan at $20 per month gives you access to cloud agents, but not to the full Automations feature with event triggers.
For a team of five, that is $200 per month, or $2,400 per year. Automations always run in Max Mode, meaning they use the most capable available model. Additional costs are possible if your team runs a high volume of agent runs, but Cursor does not publish hard limits.
For comparison, GitHub Copilot Business costs $19 per user per month. Copilot assists you while you write; it does not respond to events in your workflow. The $21 difference between the two plans is essentially the cost of that automation layer.
Here is a concrete ROI check. If your team handles 20 pull requests per week and each review follow-up averages 30 minutes of developer time, automating that follow-up saves roughly 10 hours per week. At a blended rate of $100 per hour, that is $1,000 in reclaimed time per week against a $200 monthly subscription. The math is not subtle.
When is this worth it for your team?
The feature works best in three specific situations.
First, if you process a high volume of pull requests and review comments tend to sit for a day or more before someone acts on them. The automation picks up follow-up immediately, including outside working hours.
Second, if your CI pipelines fail regularly and someone has to manually diagnose what went wrong. The triage template reads the error logs and proposes a fix.
Third, if your team communicates about bugs in Slack and things regularly fall through the cracks. The emoji trigger converts a Slack message into a concrete action with a pull request attached.
For context on where this fits: the Stack Overflow Developer Survey 2025 found that 84% of developers are already using AI tools or plan to. The distinction Cursor is making here is subtle but significant. Most of that usage is reactive: you ask, the AI responds. Automations flip that. The AI watches what happens in your workflow and responds on its own. That shift from "I summon AI" to "AI monitors my work" is what separates event-driven automation from a chat interface.
What are the limitations?
The most significant one: automations do not work with fork-based pull requests. Open-source projects that use forks as their standard workflow cannot use the GitHub triggers for external contributions. Cursor acknowledges this in the documentation but does not yet offer a workaround.
Every automation runs as the Cursor bot. PR comments and approvals appear under "cursor," not your personal GitHub account. That is transparent to your team, but it requires agreement on how you handle bot-generated reviews in your merge policy.
One more thing: the agent now has computer use enabled by default. It can open a browser, take screenshots, and record screen sessions. Cursor suggests using this to have the agent demo its own fix as part of the automation instructions. Useful for a visual record of what the agent did, but worth reviewing if your organization has restrictions on what cloud agents are allowed to access.
How to get started today
The fastest path: open Cursor, type /automate, and describe what you want in plain English. Cursor configures the trigger and the tools. Your first automation can be running within five minutes.
If your team is already using cloud agents or Bugbot, the move to Automations is short. If you are still on the Individual plan, upgrading to Teams is the one required step.
In practice the setup looks like this. Your team uses GitHub for code review and Slack for communication. You configure two automations: one that follows up on review comments with a fix, and one that converts Slack emoji reactions into agent runs. The AI becomes a background worker handling the routine handoffs while your team stays focused on the harder problems.
The larger question: is code review gradually shifting from a task humans perform to a task humans approve? Bugbot does the first scan. Automations handle follow-up. The developer reviews the result. According to TheAIDaily's AI adoption data, AI tooling in developer workflows is accelerating faster than in almost any other professional category. The step from "AI as assistant" to "AI as participant in your workflow" is the one most teams are just beginning to take.
