Cursor Automations: Build Always-On Agents for Your Codebase

What Cursor Automations Actually Are

Most AI coding tools are pull-based. You open a chat, write a prompt, wait for a response. Cursor Automations change the model: you define a trigger and a set of instructions, and cloud agents run in the background without you having to ask.

The pattern is: trigger + prompt + tools. Pick something that fires the automation (a PR is opened, a Sentry error occurs, a cron fires at 9am), write instructions for what the agent should do, choose which tools it can use (GitHub, Slack, MCP servers), and save. When the trigger fires, Cursor spins up a cloud sandbox, runs your instructions, and verifies its own output.

This is meaningfully different from the interactive agent in your editor. Interactive agents are good for exploratory work: understanding a codebase, prototyping a feature, answering a question. Automations are good for recurring, bounded work that follows a predictable pattern: reviewing every PR for security issues, triaging incoming bug reports, posting a weekly digest of merged changes. Once configured, they run whether you are at your desk or not.

The Five Trigger Types

Understanding what can trigger an automation is the first step to seeing what is possible.

Scheduled Triggers

Scheduled triggers run on a clock. Choose from preset intervals or write a cron expression for exact control. A 9am daily automation that reviews recently merged code and identifies missing test coverage is a scheduled trigger. So is a weekly digest that summarizes what the team shipped.

Scheduled triggers with no repository are useful for knowledge-work tasks: pulling data from a Linear project, summarizing it, and posting to Slack. Scheduled triggers with a repository are useful for maintenance tasks: scanning for test coverage gaps, dependency updates, or documentation drift.

Source Control Triggers

Source control triggers respond to events in your connected Git provider (GitHub, GitLab, or Bitbucket Cloud). The core events every provider supports:

• Pull request opened: The most common trigger for code review automations.
• Pull request pushed: New commits on an existing PR. Useful for re-running checks after an update.
• Pull request merged: Good for post-merge workflows: update documentation, notify stakeholders, run a regression check.
• Push to branch: Fires outside a PR context. Useful for auditing direct pushes to main.
• Comment added: Runs when someone leaves a top-level PR comment. Can be used to respond to review feedback automatically.

GitHub has the richest trigger set, including CI completed (fires when a GitHub Actions workflow finishes), Issue label changed, and PR review submitted. If your team uses GitHub, these extra triggers unlock workflows that are harder to build on other providers.

Slack Triggers

Slack triggers let you use your team's existing communication patterns to kick off agents. Three options:

• New message in channel: When a message lands in a channel you connect. Add a keyword or regex filter to fire only on messages that match a pattern (e.g. messages containing "bug" or "incident").
• Emoji reaction: React to a Slack message with a specific emoji and the automation fires. This is surprisingly flexible: react with :beetle: to trigger a bug investigation, :mag: to trigger a code review.
• Channel created: When a new public channel is created. Useful for onboarding automations at the team level.

Webhook Triggers

Webhook triggers create a private HTTP endpoint you own. POST to it and the automation runs. This is your escape hatch for connecting Cursor to anything that is not in the built-in trigger list: internal monitoring tools, CI pipelines, issue trackers, third-party services. Authenticate with the API key generated when you save the automation.

Cursor appends the webhook payload as-is to the bottom of the configured automation prompt, so your instructions can reference and act on the incoming body. Cursor staff confirmed this behavior in the Automations launch thread. No special parsing step is required.

Issue Tracker and Incident Triggers

Linear triggers fire on issue created, status changed, or cycle end. When a new bug is filed in Linear, an automation can immediately investigate the root cause in the codebase. It can then attach a proposed fix or a summary of what it found to the issue.

Sentry triggers fire on issue created, issue updated, or any issue event. Connect your production error monitoring to an agent that pulls the stack trace, searches the codebase for the relevant code path, and posts a root-cause analysis to Slack.

PagerDuty triggers fire on incident events. When an incident is triggered, the agent can check Datadog logs, look at recent code changes, and message your on-call channel with a proposed fix before the engineer even picks up the alert.

Four Automations Worth Setting Up This Week

The Cursor Marketplace has templates for all of these. You can use them as-is or customize the prompt for your team's conventions.

1. Security Review on Every Push to Main

This is the automation Cursor runs on their own codebase. Trigger: push to main. Instructions: audit the diff for security vulnerabilities, skip issues already discussed in the PR, post high-risk findings to a Slack channel.

Because this runs post-merge rather than blocking the PR, the agent can work longer on subtler issues. It is not catching everything a dedicated security audit would catch, but it catches the obvious patterns (hardcoded credentials, SQL injection vectors, unvalidated inputs) automatically.

Prompt pattern:

Review the diff pushed to main in the last commit.
Identify security vulnerabilities: hardcoded secrets, SQL injection risks,
missing input validation, insecure deserialization, and dependency CVEs.
For each finding:

Severity (critical / high / medium / low)
File and line number
What the vulnerability is
A one-line fix recommendation

If no issues are found, do nothing. Only send a Slack message if there is at
least one critical or high-severity finding. Post to #security-alerts.

2. PR Code Review with Inline Comments

Trigger: pull request opened. Instructions: review the diff for bugs, style inconsistencies, and logic errors. Post inline comments on the PR. Auto-approve if no issues are found above a threshold.

This replaces the first pass of a human review for straightforward changes. Engineers still review agent comments and make the final decision, but they are reviewing the agent's observations rather than reading the diff cold.

Prompt pattern:

Review the pull request diff.
Check for:

Logic bugs that would cause incorrect behavior
Missing error handling (especially around API calls and DB operations)
Obvious performance issues (N+1 queries, unbounded loops)
Code that deviates from the existing conventions in this file

Leave inline comments where you find issues. Be specific: quote the
problematic code and explain why it is a problem.
Do not leave nitpick comments on style unless it is a material inconsistency.
If the PR looks clean, approve it. If there are critical issues, request changes.

3. Bug Triage from Slack

Trigger: new message in #bugs channel with no keyword filter, so the automation picks up everything. Instructions: check if the bug is a duplicate, create a Linear issue if not, investigate the root cause in the codebase, post a summary back to the thread.

This is the workflow Cursor uses internally. A bug report lands in Slack. The agent checks Linear for existing issues, creates one if needed, then goes into the codebase to find the most likely cause. By the time an engineer looks at the thread, there is already a root-cause hypothesis and a Linear ticket.

Prompt pattern:

A bug report was posted in #bugs.


Search Linear for existing issues matching the symptom. If a duplicate
exists, reply to the Slack thread with the Linear issue link and stop.


If no duplicate, create a new Linear issue with:

Title: [Bug] {brief description}
Priority: based on severity described (p1 if production is down, p2 otherwise)
Description: full bug report text



Investigate the codebase to find the most likely root cause:

Search for the relevant code path
Look at recent commits that touched that path



Reply to the Slack thread with:

The Linear issue link
Your root-cause hypothesis (1-3 sentences)
The files most likely involved

4. Weekly Changelog Digest

Trigger: scheduled, every Monday at 9am. Instructions: summarize meaningful PRs merged in the last seven days, organized by category. Post to #engineering-updates.

This is the automation that saves the most time relative to effort. No one wants to write the weekly digest. Once configured, it writes itself.

Prompt pattern:

Summarize the pull requests merged to main in the last 7 days.
Organize by category:

New features
Bug fixes
Performance improvements
Security updates
Dependency updates
Technical debt

For each PR, include the PR title, author, and a one-sentence description
of what changed and why it matters.
Skip PRs that are purely documentation or CI config changes unless they
represent a significant process shift.
Post the summary to #engineering-updates. Use Slack formatting
(bold headers, bullet points). Keep the total under 60 lines.

How Memories Make Automations Better Over Time

One of the most useful features of Cursor Automations is the Memories tool. When enabled (it is on by default), the agent can read and write persistent notes that survive across runs. Each memory is stored as a named entry, MEMORIES.md by default, outside the agent's working filesystem.

Practical use cases for memory in automations:

• Avoiding repeat comments: A security review automation can remember which issues it has already flagged and not re-raise them on subsequent pushes.
• Learning team conventions: An engineer can leave a note in the automation's memory explaining how the team structures a specific module. The automation's next run incorporates that context without you putting it in the main prompt.
• Tracking trends: A weekly digest automation can compare this week's changes to its memory of last week's, flagging when a previously-fixed issue category is reappearing.

Memory is most valuable for automations that run frequently on the same codebase. An automation that runs once on a repository benefits less from memory than one that runs daily for months.

Prompting Patterns for Reliable Automated Agents

Writing prompts for automations is different from writing prompts for interactive agents. In an interactive session, you can course-correct. In an automation, the agent runs without you watching. The prompt needs to handle edge cases explicitly.

Three patterns that improve automation reliability:

Define a Do-Nothing Threshold

Tell the agent when it should take no action. An automation that always posts something is more annoying than useful. An automation that only fires when something is actually wrong is high signal.

If no issues are found at severity high or critical, take no action.
Do not post a Slack message. Do not open a PR. Silence is the correct output
when nothing is wrong.

Use If-Then Logic Explicitly

Automated agents do not have the context a human reviewer would bring. Make decision branches explicit:

If the PR touches authentication code: apply the strict review checklist.
If the PR is marked [chore] or [deps]: only check for breaking changes, skip style.
If the diff is over 500 lines: post a comment asking the author to split the PR
before proceeding with review.

Specify the Output Format

Automations that output to Slack or GitHub comments need predictable formatting. Vague instructions produce inconsistent output across runs. Specific formatting instructions produce consistent, readable output.

Format your findings as a GitHub comment using this structure:
## Automation Review
**Risk level**: [Low / Medium / High]
**Summary**: [One sentence]
### Issues Found
- [File:Line] [Description] [Severity]
If no issues were found, post: "✅ No issues detected in this diff."

Billing and Model Selection

Automations are billed by cloud agent usage. Three permission scopes affect how billing works:

• Team Owned: Bills to the team's shared usage pool. The right choice for automations the whole team benefits from.
• Private / Team Visible: Bills to the user who created the automation. Use for personal productivity automations.

Model selection matters for cost. You can choose which model powers each automation. High-frequency automations that run on every PR push can use a lighter model (Claude Haiku 4.5 is supported) without sacrificing much quality for straightforward review tasks. Reserve heavier models for complex security audits or multi-repo investigations where the context is large and nuanced judgment matters.

A practical default: use Haiku for anything that runs more than ten times per day. Use Sonnet for scheduled weekly tasks and complex code review automations where depth matters.

Current Limitations Worth Knowing

Cursor Automations are genuinely new (launched March 2026). A few limitations from the current version that are worth knowing before you invest time designing complex workflows:

• Single-trigger Boolean logic: You cannot combine trigger conditions (AND / OR). Each trigger is independent. If you need "PR opened AND authored by a core committer," you need to encode that as a conditional in the prompt, not in the trigger configuration.
• Automation run steering: Once a run starts, you cannot interactively steer it. Runs are designed to be autonomous. If you need mid-run intervention, you are better off with an interactive cloud agent.

These limitations are known to the Cursor team and are active areas of development based on forum feedback.

Next Steps

The fastest way to start: go to cursor.com/automations, open a template from the marketplace, and edit the prompt to match your team's conventions. The security review, bug triage, and weekly digest templates are solid starting points.

If you want to design your own from scratch, use the /automate skill inside an interactive agent session. Describe what you want in plain language and Cursor will configure the trigger, tools, and initial prompt.

For teams already using the Building with Cursor workflow, including rules files, MCP servers, and plan mode, Automations are the natural extension. You have already taught Cursor how your codebase works. Automations let that knowledge run continuously, not just when you remember to ask.

If you want to go deeper on agentic workflows, join AI Builder Club. We share what is actually working in production, not just what looks good in a demo.