# Adopting new Cursor features

URL: https://developertoolkit.ai/en/cursor-ide/reference/feature-adoption/
Description: Sort each new Cursor feature by blast radius, trial it in a worktree against merged tickets, prove it with CI gates, then commit it to the repo.

Adopting a new Cursor feature safely means sorting it by blast radius (personal, shared through the repository, acting unattended, or touching review and release), trialling it in an isolated worktree against recently merged tickets, judging the result by CI gates and rework rather than impressions, and only then committing its configuration to the repository where the whole team gets it.

This page is for the developer who reads Cursor's changelog and the tech lead who decides what the team switches on. The familiar failure looks like this: someone enables a new agent feature on Friday, it rewrites half a module on Monday, nobody can say whether it helped, and by Wednesday three engineers run three different Cursor setups. The fix is a short, repeatable trial with evidence, sized to the risk of the feature.

**What this page checked, and when**

Feature names in the first table below come from Cursor's own documentation, read on 2026-08-28, as recorded in this site's research notes. Cursor's site could not be re-read on 2026-09-26; on 2026-10-12 it could, and that day's check covers the features in the second table and the older names stamped 2026-10-12 in the renamed-features table. Plan availability is recorded as Cursor's entries state it, so confirm it in [Cursor's docs](https://cursor.com/docs) before you trial a feature. The features below belong to the Cursor 3.x line. Cursor numbers desktop releases in its release notes, and the current release is 3.24 (2026-10-09, checked 2026-10-12).

## What you'll walk away with from adopting Cursor features

- A four-tier blast-radius table that tells you who decides and how long a trial of each Cursor feature runs.
- A seven-step trial you can run on one feature in about two weeks, with the evidence that decides it.
- Three copy-paste prompts: release-note triage, trial design, and turning a working habit into shared repository config.
- A migration routine for renamed or retired features, and the recovery steps when adoption goes wrong.

## Which Cursor features are worth a trial?

Start from what changes your work, not from what is newest. The table groups the Cursor features whose names were verified on 2026-08-28 by where they act. For the dated list of what shipped, read the [Cursor changelog on this site](/en/cursor-ide/reference/changelog/) or [Cursor's own changelog](https://cursor.com/changelog).

| Where the feature acts | Cursor features | What it changes for you |
| --- | --- | --- |
| Your session only | Plan Mode, Worktrees, Subagents, `/loop` (a bundled skill since 3.5), `/goal` (announced 2026-08-19; still rolling out per Cursor's docs, checked 2026-10-12) | How one agent plans, splits and repeats work on your machine |
| The repository, for everyone | Rules, Agent Skills, Hooks, Plugins, MCP servers | What every teammate's agent is told, may run and can reach |
| Unattended, in the cloud | Cloud Agents, Builds, Automations, the Cloud Agents API, the Cursor SDK (`@cursor/sdk`, `cursor-sdk`), the CLI's print mode (`-p`) | Work that starts without you: on a schedule, from GitHub, GitLab, Slack, Linear, Sentry, PagerDuty or a webhook |
| Review and release | Bugbot, Security Agents, PR Routing & Approval, Origin | Who reviews a pull request, whether a bot may approve one, and where the code and pull requests live (Origin) |

Cursor added the features in the next table on or after 2026-08-19, and each was read in Cursor's changelog or docs on 2026-10-12. The same tiers apply to them.

| Where the feature acts | Cursor feature added since 2026-08-19 | What it changes for you |
| --- | --- | --- |
| Your session only | Skills as Custom Modes (Cursor docs and the changelog of 2026-08-19): "Any skill with a valid frontmatter block can back a Custom Mode, which keeps the skill in context for the whole session" | How long one skill stays in context: the whole session |
| Your session only | Remote control for local agents (changelog, 2026-10-06): "You can now see and reply to the local agents running on your computer from the Cursor iOS app." It is on by default except for Enterprise organisations, where admins enable it. Cursor for iOS is on the Start, Pro, Pro+, Ultra, Teams and Enterprise plans | Where you can watch and answer a running agent. Because it is on by default, check whether people on your team already use it |
| Unattended, in the cloud | Start from scratch (changelog, 2026-08-27): "Cloud Agents no longer require a connected GitHub or other third-party SCM provider to get started." **Start from scratch** in the repo picker creates an Origin repo, and, per Cursor's Origin docs, Origin is "currently released in early beta" | A Cloud Agent can start without a repository you host elsewhere. Trial it on a throwaway project while Origin is in beta |
| Unattended, in the cloud | Self-hosted machines (changelog, 2026-09-02): "keep tool execution entirely in your own network" with **My Machines** (one laptop or VM) or **Team pools** (named worker queues that scale and can hibernate idle machines). Workers start with `agent worker` | Where an unattended agent's tools run: in your own network |
| Unattended, in the cloud | Cursor Projects (beta) (changelog, 2026-09-10): a project takes on "a feature, a migration, or a full app". Its coordinator agent "doesn't write code itself" and runs "on its own computer in the cloud". Available on all paid plans including Enterprise (Enterprise needs Cursor 3.21.9 or later), not on Hobby, and not with Privacy Mode (Legacy) | Long-running work that keeps context over months. Treat it as tier 3 and trial it on one low-risk repository |
| Review and release | Rollouts and Security Review (changelog, 2026-09-23), both on Teams and Enterprise. Rollouts attaches a monitor to every pull request and reports each environment as "verified healthy, regression detected, or inconclusive"; it "does not merge or roll back on its own today". Security Review posts one comment per pull request on exploitable bugs and skips draft pull requests | What comments on your pull requests and what monitors them. Treat both as tier 4, with a shadow period first |

Two definitions from Cursor's docs matter for the risk call. Plugins "package rules, skills, agents, commands, MCP servers, and hooks into distributable bundles", so one plugin can change all four layers of the repository tier at once. PR Routing & Approval "can approve low-risk PRs when your criteria are met", so it moves a merge decision from a person to a rule you write.

## Sort each Cursor feature by blast radius

The tier decides who signs off, how long the trial runs and what evidence is enough. A higher tier never skips the steps of a lower one.

| Tier | Example | Who decides | Trial | Evidence before it spreads |
| --- | --- | --- | --- | --- |
| 1. Personal | Plan Mode on your next three tickets | You | A few days | Your pull requests pass the same CI gates with no extra review rounds |
| 2. Repository | A hook that runs the type check after agent edits | Tech lead, through CODEOWNERS on `.cursor/` | Up to two weeks | Re-run of five to eight merged tickets; gates and rework no worse |
| 3. Unattended | A scheduled Automation that bumps dependencies | Tech lead and the repository owner | Two weeks on one low-risk repository | Every run leaves a pull request that passes CI; no run writes outside its branch |
| 4. Review and release | PR Routing & Approval auto-approving docs-only changes | Tech lead and whoever owns production risk (often security) | Shadow period first: write the approval criteria but leave auto-approval off, so it only assigns reviewers; for each pull request, record whether your criteria would have matched, and compare that with the human verdict | Where your criteria would have matched, the human verdict was approval on every pull request in the shadow period |

Adopt one feature per tier at a time. Two features trialled together produce one result you cannot attribute to either.

## Run a Cursor feature trial in seven steps

The trial replaces "it felt faster" with a result anyone on the team can re-check. For the team-wide release-watch rota that feeds candidates into it, see [keeping a team current when the tools ship weekly](/en/teams/keeping-current/); this section is the Cursor-specific half.

1. **Read the primary note.** Open the changelog entry and the feature's docs page. Record the Cursor version you run, the plan the feature needs, and whether the docs say "beta" or "rolling out".

2. **Triage the note with the agent.** Paste the entry into the agent chat with the first prompt below. Discard anything that touches no workflow you use this month.

3. **Write the hypothesis and the eval before you start.** One sentence: "Plan Mode reduces review rounds on API tickets." Then pick five to eight merged tickets on that workflow whose tests decide success. The second prompt below drafts both.

4. **Isolate the trial.** Use a Cursor worktree or a branch for tier 1 and 2. For tier 3, point the Automation or Cloud Agent at one low-risk repository. For MCP, start with a read-only server such as Context7 (below) before any server that can write.

5. **Re-run the tickets.** Give the agent each ticket's original description, not the merged diff. Keep the model and your usual run mode fixed, so the feature is the only variable.

6. **Judge by the gates.** Compare against the merged originals using the evidence in the next section. You read the failures and a sample, not every line.

7. **Decide and record.** Adopt, reject or extend the trial by one week. Write the decision, the version it needs and a one-line rollback in the pull request that changes shared config. The [decision record format](/en/teams/keeping-current/) on the release-watch page works unchanged for Cursor.

**Copy-paste prompt: triage a Cursor changelog entry**

```text
Here is a Cursor changelog entry and the docs page it links to:
<paste both>

Read this repository first: package.json, the CI workflow files, and
everything under .cursor/. Then, for each feature in the entry:
1. Say which workflow in THIS repository it would change, citing the file
   or script that runs that workflow today. If none, mark it "noise".
2. Put it in one tier: personal, repository, unattended, or review-and-release.
3. Name the plan or setting it needs, quoting the docs. If the docs do not
   say, write "not stated" instead of guessing.
4. Propose one first test on a branch that cannot affect main or CI.
Output a table. Do not enable, install or configure anything.
```

**Copy-paste prompt: design the trial and its eval**

```text
I want to trial Cursor's Plan Mode for API endpoint tickets in this repo.
Use git log for the last 90 days to find 5 to 8 merged pull requests that
added or changed an endpoint under src/pages/api/ and came with tests.

For each one, give: the PR number, the original task description (from the
PR body or the linked issue), and the test files that decide success.
Then write:
- a one-sentence falsifiable hypothesis;
- what counts as better, same and worse, using only CI results, number of
  review rounds, and follow-up fix commits within 14 days of merge;
- the exact files the trial may change, confirming none are shared config.
Do not start implementing anything.
```

Replace `Plan Mode` and `src/pages/api/` with the feature and the directory you are testing; the rest of the prompt stays the same.

### Add an MCP server as a tier-2 trial

An MCP server in the project configuration reaches every teammate's agent, so treat it as a repository change. Start with a read-only documentation server. Context7's vendor README documents this Cursor configuration for its remote server (the API key header is optional and only raises rate limits):

```json
{
  "mcpServers": {
    "context7": {
      "url": "https://mcp.context7.com/mcp"
    }
  }
}
```

Only after that trial passes, add servers that act, such as Playwright MCP, and give each one the narrowest scope it needs. Playwright's vendor README documents this entry for the project's MCP configuration file (the MCP setup guide below gives its location):

```json
{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}
```

The [Cursor MCP setup guide](/en/cursor-ide/quick-start/mcp-setup/) covers the file locations and authentication, and the [MCP catalogue](/en/ecosystem/mcp/) compares servers.

## How do you prove a Cursor feature helped without reading every diff?

You judge the re-run tickets by signals that already exist in CI and Git, so the verdict does not depend on anyone reading every line the agent wrote.

| Signal | Where it comes from | Counts as worse |
| --- | --- | --- |
| Gates on first push | CI: tests, type check, lint | More red runs than the merged originals |
| Review rounds | Pull request history | More "changes requested" rounds |
| Rework | Follow-up fix or revert commits within 14 days | Any revert the original did not need |
| Scope | `git diff --stat` against the original | Files touched outside the ticket's area |
| Usage | Cursor's usage figures for the trial window (see [token management in Cursor](/en/cursor-ide/operate/token-management/)) | A rise the time saved does not justify |

Read two things by hand: every failed gate, and one passing ticket chosen at random. If the random one surprises you, the gates are weaker than you thought, and that is the finding to fix first. The [evidence-not-diffs guide](/en/ladder/evidence-not-diffs/) explains how to build gates you can trust this way.

For tier 3 and 4 features, the evidence moves from tickets to runs. An Automation or Cloud Agent must leave a pull request that passes the same required checks as a human one. A review bot starts with a shadow period: you write its approval criteria but leave auto-approval off, so it only assigns reviewers. For each pull request, you record whether your criteria would have matched and compare that with the human verdict before the bot may approve anything. The [rollouts and approval guide](/en/cursor-ide/ship/rollouts-and-approval/) and the [Bugbot guide](/en/cursor-ide/ship/bugbot/) cover those two cases in depth.

## Graduate a working feature into the repository

A feature has been adopted when a new teammate gets it by cloning the repository, not when one person has it switched on. Cursor's Rules, Agent Skills, Hooks, Plugins and MCP configuration can all live in version control, so graduation is a pull request.

1. Commit the configuration under `.cursor/`, and any other agent-config paths your repository uses, such as a shared skills folder. The [project rules guide](/en/cursor-ide/quick-start/project-rules/) and the [rules and templates guide](/en/cursor-ide/automate/custom-rules-templates/) show the formats; [installing and managing skills](/en/ecosystem/skills/installing-managing/) covers shared skills.
2. Route those paths to the tech lead so no one changes every agent's behaviour unreviewed. Add a line for each agent-config path the repository uses, not only `.cursor/`:

   ```text
   # .github/CODEOWNERS
   /.cursor/  @your-org/tech-leads
   # one line per other agent-config path, for example your shared skills folder
   ```

3. Put the version the feature needs and the rollback in the pull request description, for example "needs a Cursor build with `/goal` available; rollback: revert this pull request".
4. Show it once in the team's next review session. A feature only one person can use has not graduated.
5. Set a review date 90 days out, and keep, change or remove the feature then.

**Copy-paste prompt: turn a working habit into shared config**

```text
For the last two weeks I have started every API ticket by asking you to:
read the route's existing tests, list the edge cases, write failing tests,
then implement until the tests, type check and lint pass.

Turn this into shared repository configuration for Cursor:
1. Decide whether it belongs in a project rule, an Agent Skill, or a hook,
   and explain the choice in two sentences. Quote Cursor's docs for the
   file location; if you cannot, say so instead of inventing a path.
2. Write the file contents.
3. Write the pull request description: what it changes for every
   teammate's agent, how to verify it on one ticket, and a one-line rollback.
Do not modify CI, permissions or anything outside .cursor/.
```

When a team outgrows one repository, a Cursor plugin can bundle the same rules, skills, hooks and MCP servers for several repositories. The [plugins overview](/en/ecosystem/plugins/) compares that with per-repository config.

## When adopting a Cursor feature goes wrong

Most adoption failures are process failures: too many features, untracked config, or a feature that changed under you.

**Three features enabled at once, no clear result.** Recovery: switch all three off, keep the tier-1 feature with the strongest hypothesis, and restart its trial. Queue the others.

**The feature was renamed or removed.** Old notes and articles still use retired names. Map them before you change config:

| Older name | Current name in Cursor's docs (date checked) |
| --- | --- |
| Background Agents | Cloud Agents (checked 2026-10-12; Cursor's help: "In Cursor, we call these Cloud Agents") |
| BugBot | Bugbot (checked 2026-08-28) |
| YOLO mode, Auto-Run | Run modes: Auto-review, Allowlist and Run Everything, in Settings > Agents > Approvals & Execution (checked 2026-10-12) |
| Ask Every Time, Run in Sandbox | Allowlist: Cursor 3.5 deprecated Ask Every Time (use Allowlist with an empty allowlist for the same behaviour) and folded Run in Sandbox into Allowlist with sandboxing enabled (checked 2026-10-12) |
| `.cursorrules` as the way to configure Cursor | Rules: project rules in `.cursor/rules` as `.mdc` files, or `AGENTS.md` in the project root and subdirectories (checked 2026-10-12). Cursor's help: "The `.cursorrules` file in your project root is legacy and will be deprecated" |

Then search the repository and team docs for the old term (`rg -i "background agent|yolo|cursorrules|ask every time|run in sandbox"`), and change each hit in one pull request.

**Config drift between teammates.** Symptoms: "it works in my Cursor". Recovery: compare each person's user-level settings with what `.cursor/` holds, move anything the team depends on into the repository, and delete the personal copies.

**An unattended run acted on untrusted input.** Automations can start from Slack messages, webhooks and issue trackers, which anyone with access can write into. Recovery: pause the Automation, review every pull request it opened, and narrow its trigger to sources only your team writes to. Then make sure branch protection requires review on everything it opens. Never give an unattended agent a secret it does not need for that one job.

**A review bot approved something it should not have.** Recovery: turn off auto-approval so it only assigns reviewers while a human keeps approving, repeat the shadow period (record whether your criteria would have matched each pull request and compare that with the human verdict), and when you turn approval back on, limit its criteria to paths with strong tests (for example docs-only changes).

**Usage rose and nobody knows why.** Cloud Agents and Automations run without you watching. Recovery: compare your usage figures for the trial window with the previous one, cap the schedule, and see [token management in Cursor](/en/cursor-ide/operate/token-management/).

Do not trial a new run mode, sandbox setting or permission change on a machine or repository that holds production credentials. Use a disposable worktree or a sandbox repository, and return to your usual settings when the trial ends.

## Where to go next with Cursor features

- [Cursor changelog](/en/cursor-ide/reference/changelog/) — The dated list of what shipped, to feed the triage prompt
- [Cursor upgrade guides](/en/cursor-ide/reference/upgrade-guides/) — Update Cursor itself safely and roll back when an update breaks MCP or extensions
- [What Claude Code can do that you haven't tried](/en/claude-code/build/features-you-havent-tried/) — The same adoption question for teams that also run Claude Code
- [Keeping a team current](/en/teams/keeping-current/) — The cross-tool release-watch rota and decision record behind this trial
- [Cloud Agents and Automations](/en/cursor-ide/automate/cloud-agents-automations/) — Set up tier-3 features with the guardrails this page asks for
- [Metrics frameworks](/en/org/metrics-frameworks/) — Turn trial signals into team metrics that hold up at the organisation level