SNACK three-line summary
- Cursor announced /automate and Slack/GitHub triggers on June 18. Users can now create automations in natural language and run always-on agents when a Slack emoji reaction or GitHub event arrives.
- Combined with the cloud development environment setup, /in-cloud subagents, and local-to-cloud handoff announced on June 17, this completes a workflow where long-running tasks can keep moving outside your own PC.
- The key point is that AI coding tools are shifting from chat assistants into event-driven automation workers. That is convenient, but teams still need to define which tasks should be automated and where permission boundaries should sit.
Snackgirls editor note
AIKO: “This is no longer just asking for help once inside the IDE. We are starting to see a structure where agents keep working when a Slack reaction or GitHub review event comes in.”
Red: “The big part is that cloud subagents can run for a long time on separate VMs and branches. Instead of waiting with your own laptop tied up, the workflow is increasingly becoming: send off the task and receive the result later.”
What was announced?
In its June 18 changelog, Cursor announced a package of updates: the /automate skill, Slack emoji triggers, and new GitHub event triggers. According to the description, users can create automations in natural language from a local agent session, and those automations can respond to events such as issue comments, PR review comments, review submissions, review thread status changes, and completed GitHub Actions runs.
In other words, instead of manually asking “please review this PR” every time, teams can build flows where an agent summarizes the cause when an action fails, or continues fixes automatically when review comments are added.
Why view this together with cloud agents?
A day earlier, on June 17, Cursor announced cloud development environment setup, /in-cloud subagents, and session handoff between local and cloud for the Agents Window. Based on the official explanation, agents run on separate VMs and branches, and environment snapshots can be saved so later runs can resume faster.
That is why the June 18 automation announcement is better understood not as a standalone feature, but as the final piece of a puzzle where cloud agents keep running after events arrive, carrying work through testing and fixes.
Who will feel the difference most?
This shift will matter most to teams with a lot of CI failure triage, follow-up fixes after PR review, and repeated operations requests through Slack. Cursor’s own examples include triaging failed GitHub Actions runs and automatically fixing PR review comments.
Put simply, if earlier AI coding tools were “an assistant sitting next to you for a quick hand,” this structure is closer to a night-shift operator who clocks in whenever a specific bell rings. That difference can be significant in team operations.
What to check first
Still, always-on automation does not immediately mean unlimited self-driving work. Cursor’s docs also explain that foundations such as development environment setup, repository permissions, secret access, and network connectivity need to be in place before agents can close the loop through testing and verification.
So the first question for teams is not simply “can this be automated?” It is how far the agent should be allowed to fix things automatically, and which events should only proceed up to the point of human approval. Always-on agents can be valuable, but loose boundaries can also increase operational burden.
Sources and checked date · Announced 2026-06-18 / Checked 2026-06-20T01:36:22+00:00
Sources
Leave a comment