Adopting new Cursor features

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

Cursor feature names 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, so confirm a feature’s current name and plan availability in Cursor’s docs before you trial it. The page pins no current Cursor version; the features below belong to the Cursor 3.x line, checked on 2026-08-28.

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 or Cursor’s own 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 on 2026-08-28)	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)

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; 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 on the release-watch page works unchanged for Cursor.

Copy-paste prompt: triage a Cursor changelog entry

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

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):

{
  "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):

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

The Cursor MCP setup guide covers the file locations and authentication, and the MCP catalogue 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)	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 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 and the Bugbot guide 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 and the rules and templates guide show the formats; installing and managing skills 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/:

   # .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

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 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 (checked 2026-08-28)
Background Agents	Cloud Agents
BugBot	Bugbot
YOLO mode, Auto-Run	Run modes (a page under Agent security)
.cursorrules as the way to configure Cursor	Rules

Then search the repository and team docs for the old term (rg -i "background agent|yolo|cursorrules"), 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.

Caution

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 The dated list of what shipped, to feed the triage prompt

Cursor 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 The same adoption question for teams that also run Claude Code

Keeping a team current The cross-tool release-watch rota and decision record behind this trial

Cloud Agents and Automations Set up tier-3 features with the guardrails this page asks for

Metrics frameworks Turn trial signals into team metrics that hold up at the organisation level