Cursor Automation Team Conventions

Use Cursor Automations when you want a governed, repeatable agent workflow inside the IDE, not a loose pile of plugins, prompts, and model experiments. In Cursor 3.8, released on June 18, 2026, the important change is that teams can create automations from a local agent session with /automate, then connect them to triggers like GitHub and Slack.

Cursor, Anysphere's AI code editor, now makes a cursor agent workflow easier to turn into a team habit. A Cursor Automation is an always-on Cursor agent that runs a repeated task from defined triggers, instructions, and tools.

For Cursor Workshop teams, the practical move is simple: write the convention before you add the automation. If you are building shared Cursor skills, custom agents, or Cursor rules, keep them tied to a reviewable repo artifact and link them from your Cursor subagents and skills training path.

Start with one boring automation

Pick a task that already has a checklist. Good first candidates are release-note drafts, stale issue triage, dependency PR summaries, or “when a PR is opened, compare it to our review checklist.”

The new /automate skill matters because it lets you describe that task in a normal local agent session and have Cursor configure the triggers, instructions, and tools. That is a friendlier path than asking every engineer to hand-roll automation wiring from memory.

The trap is starting with a high-risk workflow. Do not make your first Cursor Automation merge PRs, change infrastructure, or edit production config. Start with read-heavy work where the output is visible and reversible.

A good first workflow might be: when a GitHub pull request is opened, ask a Cursor agent to summarize risk, test coverage, and missing docs, then post the summary for a human reviewer. That keeps the automation useful without pretending it is the reviewer.

Put durable rules in the repo

Team automations need repo memory, not oral tradition. Put durable constraints in AGENTS.md and Cursor rules, then let task prompts stay small.

Use AGENTS.md for boundaries that apply across coding agents: architecture, test commands, ownership, and “never do this” rules. Use Cursor rules when you want Cursor-specific behavior, file patterns, or review habits that should follow the repo inside the IDE.

The trap is one giant root instruction file. Nested rules and scoped notes are easier to obey because local context wins. For example, apps/web/AGENTS.md can define frontend test commands while packages/billing/AGENTS.md can define stricter migration rules.

A small .cursor/rules/automation-review.mdc stub is often enough:

---
description: Review expectations for Cursor Automations that comment on pull requests
alwaysApply: false
---

When reviewing automation output:
- Treat summaries as hints, not approval.
- Check changed files before accepting risk labels.
- Require tests or a written reason when behavior changes.
- Never let an automation merge, deploy, or approve its own work.

For a deeper companion pattern, see Cursor Review Workflows With Subagents.

Turn repeatable expertise into skills

Cursor skills are a good place to package reusable workflows: how your team writes migrations, how you inspect flaky tests, how you prepare a release, or how you triage security findings. A Cursor skill should have a clear name, a sharp description, and enough instructions that the agent can do the job without re-learning the repo every time.

The description is not decoration. It is the activation surface. If the description says “helps with backend work,” the skill will be fuzzy. If it says “summarizes API compatibility risk for changed OpenAPI schemas,” the agent has a much better chance of using it at the right moment.

The trap is turning every preference into a skill. Keep skills for workflows that repeat and have a recognizable shape. Keep one-off task details in the prompt or automation instructions.

A real team might keep a release-risk skill for release candidates, a migration-check skill for database changes, and a pr-review-summary skill for GitHub-triggered automation. Those are easier to audit than a dozen private prompt snippets.

Use MCP only where the agent needs real context

Model Context Protocol, or MCP, is the integration layer that lets an agent connect to external systems such as GitHub, Slack, databases, issue trackers, design tools, and private docs. In Cursor Automations, MCP is useful when the agent needs context that is not already in the repo.

Use MCP to fetch issue details, inspect a linked design, read a runbook, or post a Slack summary. Keep secrets, write permissions, and production access tightly scoped.

The trap is connecting everything because you can. Every integration increases the review surface. If a workflow only needs changed files and test commands, repo context plus Cursor rules may be enough.

For teams comparing Cursor agents with Cline, the open-source coding agent originally created by Saoud Rizwan, or DeepSeek models from DeepSeek AI, this is the useful lens: a cursor ide agent plugin cline deepseek 2026 evaluation should compare the operating model, not just the model name. Ask where rules live, how tools are permissioned, how outputs are reviewed, and whether the workflow is easy for the whole team to inspect.

Paste this automation convention

Copy this into docs/engineering/cursor-automations.md, then link it from your root AGENTS.md. Treat it as the first draft, not sacred text.

# Cursor Automation Convention

## Purpose
We use Cursor Automations for repetitive, reviewable engineering tasks.
Automations may summarize, classify, draft, and prepare work.
They may not approve, merge, deploy, rotate secrets, or change production state.

## Good first automations
- Summarize a new GitHub pull request for reviewer attention.
- Draft release notes from merged PRs.
- Triage stale issues and suggest owners.
- Post Slack reminders for missing tests or docs.

## Required repo artifacts
- `AGENTS.md` defines team-wide boundaries and test commands.
- Nested `AGENTS.md` files define local ownership and risk areas.
- `.cursor/rules/*.mdc` defines Cursor-specific review behavior.
- `.cursor/skills/*/SKILL.md` packages reusable workflows.

## Automation proposal checklist
Before creating or changing an automation, answer:
- What trigger starts it?
- What files, tools, or MCP servers can it read?
- Can it write anywhere? If yes, where exactly?
- What output does a human review?
- What failure mode would annoy or endanger the team?
- Which rule, skill, or AGENTS.md section teaches the behavior?

## Adoption path
1. The proposer opens a PR with this checklist filled out.
2. One code owner reviews the workflow and permission scope.
3. One frequent user reviews the output format.
4. The automation starts in draft/comment-only mode.
5. After one week of useful output, the team may keep, narrow, or remove it.

## Review rule
Every automation output must name the evidence it used.
A human reviewer owns the final decision.
No Cursor background agents, Cursor custom agents, or Cursor agent mode sessions may approve their own changes.

The adoption path matters more than the exact wording. Someone proposes the automation, code owners review the permissions, frequent users review usefulness, and the convention lives in the repo where engineers already work.

The review rule is the enforcement hook. If an automation cannot show the evidence it used, the team should treat the output as a draft guess and either narrow the instructions or remove the trigger.

Common questions

• Should we use Cursor Automations or just run Cursor agent mode manually?

  Use Cursor agent mode manually for exploratory work and use Cursor Automations for repeated work with a known trigger. The useful dividing line is whether the task can be described in one checklist: trigger, tools, output, reviewer, and failure mode. If that checklist is still fuzzy, keep it manual.

• Are Cursor background agents the same thing as automations?

  No, treat Cursor background agents as an execution surface and Cursor Automations as a governed repeated workflow. As of June 2026, the Cursor 3.8 changelog describes Automations as always-on agents with /automate, GitHub and Slack triggers, and computer-use support. Your team convention should still define permissions and review.

• How should we compare Cursor agents with Cline or DeepSeek-based setups in 2026?

  Compare the team operating model first, not only the agent or model. For a serious 2026 evaluation, check four artifacts: repo rules, reusable skills, integration permissions, and review logs. Cline or DeepSeek-based workflows may fit some teams, but Cursor teams should judge whether the workflow is inspectable inside their IDE and repo.

• Where should Cursor custom agents and custom subagents be documented?

  Document Cursor custom agents and custom subagents beside the repo rules they must obey. A short note in AGENTS.md, plus a scoped Cursor rule or skill, is usually enough for the first version. Avoid private-only setup notes, because the team cannot review what it cannot find.

• How much governance is enough for a small team?

  Use the lightest governance that makes mistakes visible. For a small team, one markdown convention, one code-owner review, and comment-only automation output is enough to start. Add stricter approval, logging, or enterprise controls when the automation gets write access, touches customer data, or affects production systems.

Further reading

• Cursor — Agent
• Cursor — Rules
• Cursor — Skills
• Cursor — MCP
• Cursor — Enterprise
• Cursor — Changelog
• Model Context Protocol — specification

Start with one pull request

Open one PR that adds the convention, one scoped rule, and one proposed automation checklist. If the team can review that calmly, you are ready to let /automate help with the first boring task.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.